今天在CSDN上看到有一個MDA專題、把一些文章轉過來吧、 http://www.csdn.net/subject/320/ 什麼是MDA Model Driven Architecture（MDA）是OMG提出的新的方法學。它是一種基於UML以及其他工業標準的框架，支援軟體設計和模型的視覺化、存儲和交換。和UML相比，MDA能夠創建出機器可讀和高度抽象的模型，這些模型以獨立於實現的技術開發，以標準化的方式儲存。因此，這些模型可以被重複訪問，並被自動轉化為綱要（schema）、代碼框架（code skeleton）、測試工具（test harnesse）、集成化代碼以及各種平臺的部署描述。MDA把建模語言用作一種編程語言而不僅僅是設計語言。 MDA以一種全新的方式將IT技術的一系列新的趨勢性技術整合到一起。這些技術包括基於元件的開發（Component-Based Development）、設計模式（Design Pattern）、中間件（middleware）、說明性規約（Declarative Specification）、抽象（abstraction）、多層系統（multi-tiered system）企業應用整合（Enterprise Application Integration）以及契約式設計（Design by Contract）。MDA的出現，為提高軟體發展效率，增強軟體的可攜性、協同工作能力和可維護性，以及文檔編制的便利性指明了解決之道。 MDA被面向物件技術界預言為未來兩年裏最重要的方法學。 MDA會帶來什麼 http://www.csdn.net/develop/Read_Article.asp?Id=22864 MDA概述 MDA是“模型驅動構架”（Model Driven Architecture）的縮寫。它是由OMG定義的一個軟體發展框架。其關鍵之處是，模型在軟體發展過程中扮演了非常重要的角色。在MDA中，軟體發展過程是由對軟體系統的建模行為驅動的。 MDA開發生命週期和傳統的生命週期並沒有很大的不同。MDA的工件是形式化模型，也就是可以被電腦理解的模型。下面列出的3種模型位於MDA的核心： • 平臺獨立模型（PIM）：具有高抽象層次、獨立於任何實現技術的模型。 • 平臺相關模型（PSM）：為某種特定實現技術量身定做，讓你用這種技術中可用的實現構造來描述系統的模型。PIM會被變換成一個或多個PSM。 • 代碼：用源代碼對系統的描述（規約）。每個PSM都將被變換成代碼。 傳統上，從模型到模型的變換，或者從模型到代碼的變換，主要是手工完成的。與此相反，MDA變換總是由工具執行的，許多工具可以把PSM變換成代碼，這並不令人驚奇。MDA的創新之處是把PIM到PSM的變換也自動化了。 軟體發展是什麼 Alistair Cockburn在他的Agile Software Development一書中歸納了業界對軟體發展的看法：以C.A.R Hoare為代表的數學觀、以Bertrand Meyer為代表的工程觀、以很多程式師為代表的手工藝觀，還有一些程式師則認為軟體發展是神秘的創造行為。當然，近20年來，也有越來越多的人對軟體發展持建模觀，比如Ivar Jacobson就曾聲稱：軟體發展就是建模。MDA Explained一書的作者也指出：代碼就是模型。Cockburn則在他的書中獨樹一幟地提出：軟體發展是一種協作遊戲。 自然，持不同軟體發展觀的專案主導者會關注軟體發展過程的不同方面。為了節省資源，我們希望軟體發展領域的研究者和項目主導者（實踐者）的關注焦點是真正決定專案成敗的那個方面。否則，學術界投入大量時間精力去研究對項目成敗無足輕重的因素，項目主導者把大量人力物力用於控制專案中無關緊要的方面（如Cockburn調侃地指出的：開發場所的環境濕度），那豈不冤枉至極？ 那麼，這個“至關重要”的方面究竟是什麼呢？是工具？是過程？是整個方法學？還是人？或者是別的我們尚未注意到的因素？目前，沒有人知道確切答案。或許，每個方面都對項目成敗有些影響吧。無論如何，因為MDA將會對軟體發展的各個方面都產生深遠影響，所以不管您對軟體發展持何觀點，您都無法回避MDA。下文我將簡述MDA對軟體發展各方面帶來的影響。 MDA改變了協作遊戲的角色和規則 好吧，我們就按照Cockburn的說法，把軟體發展看作協作遊戲好了。不過，任何遊戲總要有參與者和遊戲規則吧？目前，編碼員是重要的遊戲參與者，但在MDA版本的協作遊戲中，沒有這個角色了，取而代之的是建模者。但是，MDA也引入了另一個新遊戲——這個遊戲不是編寫軟體產品，而是編寫變換規則。變換規則市場會逐漸成長，就像基於元件的開發啟動了元件市場那樣。在新遊戲中，原來的編碼員中的精英人物將找到他們新的位置，而他們也將自豪地發現，他們編寫的代碼將獲得程度空前的複用。至於遊戲規則的改變，我在這裏說不好也說不全，請您在玩新版本的遊戲時慢慢體會吧J MDA改變了開發過程 目前，許多項目經理都很注重開發過程。或許因為過程對項目成敗真的很重要，或許僅僅因為過程是軟體發展中項目經理唯一可以施加較大影響的方面。無論如何，MDA對開發過程的改變不容忽視。 比如，開發過程的需求分析階段依然存在，不過需求分析員要編寫的不再是需求分析文檔，而是PIM——平臺獨立模型。需求分析文檔和PIM有什麼區別？閱讀需求分析文檔的是人，是設計師或者程式師，但閱讀PIM的則主要是類似於編譯器的自動工具。 既然需求分析階段產生的工件改變了，那麼依賴需求分析階段結果的設計階段自然也要改變，而“編碼”這項工作則需要完全重新定義了。測試、部署等階段也會有相應改變。此處不再詳敘，請閱讀本書正文。 MDA改變了開發工具 隨著技術的進步，開發工具的改變一直都沒有停止。當主流開發語言是彙編的時候，您可曾想像到含自動完成、重構、集成調試器的IDE？你可曾想到會有一天彙編代碼不再由人手寫而是由編譯器自動生成並且可以高度優化？那麼，當主流開發語言的抽象層次即將再次躍升，開發工具的革命也將到來。在MDA的世界中，“變換工具”扮演了傳統編譯器的角色，傳統編譯器則退居目前彙編器（就是把組合語言翻譯成機器語言的程式）的地位，其餘各層工具依次後退。調試器也將逐漸進化，就如同從機器碼級調試（組合語言級調試）向源碼級調試的過渡那樣，慢慢過渡到模型級調試。在IDE中最重要的也不再是基於文本的代碼編輯視窗，而是基於圖形的建模視窗。人們將像現在談論一個API函數那樣談論一個設計模式（design patterns），而代碼模式（idioms）將完全由變換工具自動生成，不再是人們關心的內容。 MDA讓你重新認識文檔、代碼、模型 以前，我們傾向於認為，給人看的文檔或者模型不需要寫得太精確，因為人總會有很強的理解力，人的大腦能夠“全自動”地更正一些無關緊要的錯誤並補全一些省略之處。另外，文檔或者模型寫得太精確是浪費時間，因為文檔和模型又不能變成可以運行的產品，你總是需要用代碼把模型重新翻譯一遍。Cockburn和一些XP推崇者的觀點更極端：文檔和模型不重要，人們拿著文檔或者圍在畫著模型的白板前的討論才重要，因為真正的溝通不是發生于閱讀文檔之時，而是發生於人與人的討論中。 好吧，或許以前確實如此。但MDA將完全顛覆這一現實。模型不再主要是給人看的了，而主要是給機器看的。寫的精確一點也不再是浪費時間，因為只寫一遍（您不需要再把文檔和模型手工翻譯成代碼）而且早晚要認真地寫一遍。至於圍在白板前的討論——如果是在討論如何編碼實現某個模型，那麼很抱歉，這樣的討論不再需要了。當然，其他方面的溝通還是需要的，但必須承認，遊戲規則已經改變，遊戲中的關卡已經改變，您有了不少新的“通關任務”，而很多老任務則自然取消了。 MDA帶來了數學般的精確性 是的，凡是能讓機器理解和自動處理的東西都必須是數學般地精確的。您在編譯程序時有沒有遇到過這樣的編譯器資訊：“警告：第nnn行代碼具有二義性”？那意思就是，請您把代碼寫得更精確些。那麼，MDA要說的就是，請您把模型建得更精確性。MDA工具會嚴格檢查您的模型以確保這一點的。 MDA為新方法學提供了土壤 如果軟體發展是遊戲，那麼方法學就是攻略。或許高手不需要攻略也能把遊戲玩通關，但大多數人在攻略的指導下能少走很多彎路。MDA制定了新的遊戲規則，那麼我們自然可以期待新版本的攻略如雨後春筍般出現。即便是同一個遊戲，您手中有了不同的戰鬥工具、不同的裝備，玩法也會不同。那麼，既然MDA帶來了很多新一代的工具，新的方法學會誕生也不足為奇了。 既然提到方法學，我就再多說幾句。把軟體工程中“methodology”這一術語譯為“方法學”其實頗具誤導性，因為這個詞的內涵往往不是哲學老師常掛于嘴邊的“世界觀和方法學”的那個方法學，而是指一系列你需要照著做的方法，或者說一系列約束開發人員的規則。它不是“研究方法的學科”，而就是一系列方法和規則的集合。 按照規則的多少和約束的強弱，可以大致地把方法學分為重型和輕型兩種。“重型方法學”比較正規和嚴謹，在採用重型方法學的專案中，開發人員具有較強的可替換性，因為方法學本身強制要求開發者把他所創造的所有東西都記錄在案（按照該方法學規定的格式），所以參與項目的新人能借助這些文檔很快上手（前提是新人也熟悉這種方法學規定的格式），從而開發人員跳槽對專案的衝擊也相對較小。項目經理們可能會比較偏愛這樣的方法學，因為這樣一來他們掌控的因素比較多，風險就比較小。開發人員則不會喜歡這樣的方法學，因為在採用重型方法學的項目中，他們只是可替換的螺絲釘，難以感覺到自己的重要性。而且做連篇累牘的文案工作純屬利他（對經理、對可能加入的新人有利），毫不利己（很無聊很費時間，而且佔用的是自己本可用于開發的時間）。 輕型方法學則具有相反的特質。記錄在案的東西不多，交付的就是代碼以及可以跑的產品，當然還有測試用例。大多數交流是口頭的、非正式的，很高效，但也只存在專案成員的腦海中。如果成員從項目中離去，那麼他腦海中的這些東西也隨之帶走。因為開發人員往往都希望自己具有不可替代的重要性，而且一般都覺得寫程式比寫文檔好玩，再者輕裝向前可以走得比較快（因為不必把時間浪費于編寫正規文檔），所以開發人員一般都比較偏愛輕型方法學。 一般而言，大型項目採用重型方法學好一點，因為項目人手多，週期長，即便所有員工都很愛戴老闆很忠於公司很喜歡這個項目，但這麼多人在這麼長時間內一個都不跳槽一個都不生病一個都不結婚生孩子也是挺難辦到的。而小型項目則往往採用輕型方法學好一點。Cockburn提出的水晶方法族就充分考慮了專案規模的因素，當然，還考慮了項目緊要性等別的因素。 那麼，MDA有沒有對某種類型的方法學特別垂青呢？沒有，MDA是“輕重鹹宜”的。既然XP（極限編程）儼然已是輕型方法的招牌，那麼自有好事者用模型替換代碼，提出了XM（極限建模）。輕型方法的另一特徵是迭代和重構，MDA極佳的同步特性也為之提供了有力支援。而重型方法也能從MDA獲益匪淺。重型方法有一大特徵就是書寫詳盡的文檔，創建大量的模型，那麼MDA說：讓文檔更詳盡些吧，讓模型更精確些吧……詳盡精確到機器都能理解並自動編譯了，這一量變到質變的轉換也就完成了。 從學術界及業界，我們已經看到，一些傳統的方法學正從MDA這一變革中汲取新的養分，而新的方法學也能從MDA的土壤中茁壯成長。或許未來20年中，又會有一批涉及MDA的新方法學著作出現吧。 創造性的腦力勞動是無可替代的 所有的改革都會在一定程度上重新分配社會資源，都會造成新的富人和新的窮光蛋。MDA也不例外。不過MDA所威脅到的是只會老老實實地把詳盡的設計文檔翻譯成C 或者Java代碼的人。 社會發展的歷史就是一部機器逐漸替代人的勞動的歷史。所以部分人失業是進步的必然代價。不要試圖阻止技術進步的腳步，因為技術進步的同時也會創造新的工作機會。比如MDA很可能就會創造出新的變換定義集市場。但是，只要您從事的工作具有創造性，就無法被機器取代。 軟體設計是需要創造性的，這一創造性或者體現在代碼中，或者體現在文檔中。在MDA出現之前，如果我們認真地編寫文檔，然後認真地編寫代碼，那麼我們進行了兩遍創造性勞動，這浪費了勞動力。而有些軟體成熟度（CMM）級別高的企業（特別是印度和日本企業）是這樣做的：認真地編寫文檔，代碼則是文檔的精確翻譯。更多的中國企業則是這樣做的：文檔敷衍了事（敷衍CMM檢查組或者敷衍上級領導和客戶），創造性勞動則在編碼階段做。這些做法的優劣不去評述，但只要您做的是創造性工作，那麼在MDA的世界中您會如魚得水的，因為工具只是為您節約了做無聊瑣事的時間，讓您可以把精力集中到創造性過程中去。 業界和IT媒體前段時間曾有“大量需要軟體藍領”的聲音，我不知道當時是否真的有此需要。但我在此大膽預言：MDA一旦普及，軟體藍領會大量失業。因此，我敬請讀者您不要把“軟體藍領”作為您的職業生涯目標。如要在未來立足軟體發展業，請您永遠不要放棄自己創造性思維的能力。 其他連接： OMG推薦模型驅動架構FastStart計畫 http://www.csdn.net/develop/article/23/23008.shtm OMG的MDA FastStart計畫進展迅速 http://www.csdn.net/develop/article/23/23009.shtm MDA驅動應用設計 http://www.csdn.net/develop/article/23/23010.shtm 對模型驅動軟體發展的理解 http://www.csdn.net/Develop/Read_Article.asp?Id=13862 模型驅動開發和UML 2.0 傳統編程方式的終結？(pdf文件) http://www.uml.org.cn/UMLSearch/pdf/mdaWhitePaper.pdf 其他： 模型驅動論壇 www.mdasky.com http://www.modeldriven.net.cn/bbs/ 一本書《應用MDA》 http://www.dearbook.com.cn/book/viewbook.aspx?pno=TS0012921 再提供一些Bold for Delphi的資料: http://www.howtodothings.com/showarticles.asp?subcategory=129 Starting with bold for Delphi part1 http://www.howtodothings.com/showarticle.asp?article=452 http://www.viewpointsa.com/bold_resources/getting_started_with_bold/Part1-IntroducingtheBasic.html Starting with bold for Delphi part2 http://www.howtodothings.com/showarticle.asp?article=453 http://www.viewpointsa.com/bold_resources/getting_started_with_bold/Part2-ExtendingModels.html Starting with bold for Delphi part3 http://www.howtodothings.com/showarticle.asp?article=499 http://www.viewpointsa.com/bold_resources/getting_started_with_bold/Part3-OCL.html

天龍有出一本中文書 專門介絡這個主題 有興趣的人可以去買回來看看

------
Thomas Chiou