Model Driven Architecture
　　在IT界，術(shù)語MDA一般是指在軟件開發(fā)過程中使用模型。但事實(shí)上，OMG把這個(gè)術(shù)語注冊為商標(biāo)，并將其引申為特殊的使用OMG的建模技術(shù)進(jìn)行模型驅(qū)動開發(fā)的概念。使用的建模技術(shù)的核心是UML和MOF（Meta-Object Facility 元對象設(shè)施），的這部分將簡要討論MDA，然后將關(guān)注MDA中所包含的建模技術(shù)，特別是UML和MOF，還將討論MDA中和我們相關(guān)的方法學(xué)。
 
　　MDA的本質(zhì)就是區(qū)別Platform IndependentModels (PIMs) 和 Platform Specific Models (PSMs)。當(dāng)使用MDA開發(fā)應(yīng)用程序時(shí)，必須首先創(chuàng)建PIM（平臺無關(guān)模型），然后使用標(biāo)準(zhǔn)映射，轉(zhuǎn)換到PSM（平臺定義模型），最后，映射生成最終程序代碼，依照OMG的MDA的FAQ：http://www.omg.org/mda“UML是MDA所使用的關(guān)鍵技術(shù)，任何使用MDA創(chuàng)建的應(yīng)用程序都基于標(biāo)準(zhǔn)化的，平臺無關(guān)的UML模型。”這樣，就意味著應(yīng)用程序的被定義為平臺無關(guān)的，這樣應(yīng)用程序就是可移植的。這很容易讓人回想其Java所宣稱的“write once run anywhere”，試圖去構(gòu)建一個(gè)平臺無關(guān)的框架，諸如Swing UI庫，必須在性能和平臺集成上作出折衷，在過去，這種折衷是很多產(chǎn)品失敗的根源，因?yàn)檫@些失敗，業(yè)界仍然非常懷疑MDA的宣言，在OOPSLA 2003上MDA的session就是佐證。
　 
　　不過，MDA的探索在某些應(yīng)用程序方面是有幫助的，一些廠商已經(jīng)向我們展示了基于J2EE的Web應(yīng)用，創(chuàng)建包含了數(shù)據(jù)實(shí)體，組件的UML模型，再映射到各種J2EE應(yīng)用。但是無論如何，就象前面所提到的，這對開發(fā)者意味著全面轉(zhuǎn)向敏捷開發(fā)，而且不能引起不必要的轉(zhuǎn)變和障礙，例如不可逆的代碼生成過程和調(diào)試上的問題。 mda.com 　
 
　　擴(kuò)展MDA到其他領(lǐng)域很困難，OMG所定義的“平臺”的概念很模糊，真正的例子也就是J2EE。在軟件開發(fā)過程中使用模型的道路上，使用模型來創(chuàng)建J2EE應(yīng)用是有效且使用的。事實(shí)上，幾乎沒有關(guān)于平臺無關(guān)模型和平臺依賴模型間的映射標(biāo)準(zhǔn)，現(xiàn)存的惟一一個(gè)也是針對Java平臺的，盡管還有很多非標(biāo)準(zhǔn)的，開發(fā)社區(qū)的實(shí)現(xiàn)聲稱支持其他平臺。
 
　　總而言之，MDA起錯(cuò)了名字，它不是體系結(jié)構(gòu)，它是基于對相似平臺的抽象的模型驅(qū)動開發(fā)標(biāo)準(zhǔn)。OMG在向業(yè)界推動MDA的時(shí)候，并沒有采納關(guān)于整和模型，框架，模式和工具來支持軟件產(chǎn)品線的建議，而且，我們將看到，MDA所基于的UML和MOF規(guī)約將會限制它的用途。
 
　　The Unified ModelingLanguage
　　UML是一種通用建模語言，它開發(fā)于90年代早期，由Grady Booch, JamesRumbaugh和Ivar Jacobson合并成一個(gè)統(tǒng)一的圖形表示法。第一次標(biāo)準(zhǔn)化在1997年，經(jīng)過了多次修訂，最近正在開發(fā)第二個(gè)版本，這個(gè)版本已經(jīng)接近完成。
 
　　UML是龐大且難于理解的，版本2更是如此，要向深入的理解UML必須先理解它怎樣被使用。我們借用Martin Flower在《UML Distilled》一書中分類，Marting把UML的使用分為:用作草圖，用作Blueprint，用作程序語言。
 
　　把UML當(dāng)作草圖使用非常流行，很多項(xiàng)目都在白板上使用UML畫草圖。把UML作為草圖使用的另一個(gè)含義是把試圖從面向?qū)ο笤O(shè)計(jì)中生成結(jié)構(gòu)化的文檔被看作是不妥當(dāng)?shù)摹Ｔ谶@種情況下，UML是非常成功的，它完全達(dá)到了消除了面向?qū)ο笤O(shè)計(jì)和圖解表示的不一致問題的目的。
 
　　把UML作為Blueprint使用提升了門檻，這時(shí)的目標(biāo)是在開發(fā)過程中把多種UML模型結(jié)合起來。對于任何改動和自動化，都向系統(tǒng)地將UML模型轉(zhuǎn)換到源代碼，這也就意味這UML模型必須包含足夠的信息，才能保證轉(zhuǎn)換是有效且完整的。
 
　　當(dāng)我們嘗試這樣作的時(shí)候，會很快發(fā)現(xiàn)UML的問題，因?yàn)樗�不能很直接的轉(zhuǎn)換到我們所使用的技術(shù)，例如：一個(gè)UML類不能直接用來描述一個(gè)C#類，因?yàn)閁ML類并不能描述C#中的屬性的概念。類似的，一個(gè)UML接口不能直接用來描述一個(gè)Java接口，因?yàn)閁ML不包括Java中的靜態(tài)字段的概念。從這一點(diǎn)來看，把UML作為草圖使用時(shí)，沒有任何問題，但是，當(dāng)UML被用作開發(fā)一個(gè)類的制品時(shí)，要么違反標(biāo)準(zhǔn)，要么引入一些不和諧因素來修補(bǔ)這些不匹配的問題。
 
　　將UML作為程序語言由一些社區(qū)支持，但是他們不喜歡走到商業(yè)化的路上，在這里我們不作討論。
 
　　讓我們再來觀察這些UML的主要使用方法：作為草圖和Blueprint。把標(biāo)準(zhǔn)表述為一組靈活的，可擴(kuò)展的圖釋，并無縫地映射到開發(fā)所使用的技術(shù)，而且不存在任何不匹配的描述說明，這是非常有用的。只有從模型所表述的概念進(jìn)行無縫且可逆的映射才會被大多數(shù)開發(fā)者所接收。“UML輪廓”采用允許有限度的對語言擴(kuò)展來使藍(lán)圖具有可擴(kuò)展性。但是實(shí)踐證明這種可擴(kuò)展性是非常有限的，并且還不能提供無縫的從UML到時(shí)下流行技術(shù)的映射。
 
　　在微軟，我們的途徑是通過我們的建模工具，使用一些易識別的擴(kuò)展的表示法來表示概念。同時(shí)，我們發(fā)現(xiàn)UML表示法還不夠清晰，我們對其進(jìn)行了增補(bǔ)，例如：我們使.NET的類可視化，可以包含更多信息，更容易使用，而且使得圖釋的元素更精確。這保證了.NET中的術(shù)語和概念能夠在圖釋中清晰地表達(dá)。我們從客戶那里得到的反饋是壓倒性的支持這種作法。盡管我們的圖釋法不是標(biāo)準(zhǔn)的UML，但是它所表達(dá)的含義對任何人而言都是非常容易理解的。

轉(zhuǎn)帖于：軟件水平考試_考試吧