DSM（領(lǐng)域定義建模）和MDA（模型驅(qū)動架構(gòu)）[2]

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

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