|
<name></name>陳宇
2005 年 8 月
MDA的概念來自于OMG的規范，按照它的說法，MDA提供了一種開放的、供應商中立的 方法以應對商業與技術變化的挑戰。實際上，在真正應用這種技術的時候，開發人員 面臨著更大的挑戰，就是需要在面向對象（OO）開發的基礎上加入以模型為中心的思想。
1 I.MDA概述
1.1 定義
MDA的概念來自于OMG的規范，按照它的說法，MDA提供了一種開放的、供應商中立的 方法以應對商業與技術變化的挑戰。實際上，在真正應用這種技術的時候，開發人員 面臨著更大的挑戰，就是需要在面向對象（OO）開發的基礎上加入以模型為中心的思想。
MDA
是把建模語言作為編程語言來使用而不僅僅作為設計語言， 用模型語言編程能夠帶來提升生產力，軟件質量以及更長遠的好處。
1.2 目標
真正達到重用模型，實現以模型為中心的開發方式和使模型真正成為可復用資產。
對于厭倦了一遍遍在編碼層解決在建模的抽象層中同樣的問題提出徹底的解決辦法。
最小成本適應不同平臺間的遷移。
1.3 相關概念
UML、MOF、XMI、JMI、XML、J2EE、EJB、.NET、PIM、PSM
1.4 關于MDA的誤解
1) MDA不是代碼自動生成的規范，相反它的目標是盡量減少自動生成的代碼。
2) MDA不是代替RUP,XP等軟件工程的傳統開發過程，而是對這些開發過程一個有益的補充，特別是直接將分析設計階段所產生的模型應用于編寫程序，并最終影響部署后的系統行為方式。
3) 你所說的這種MDA實現還沒有達到開發企業級應用的階段，換句話說，根本不實際。其實，現在不僅僅有商業化的實現，也有很優秀的開源MDA平臺，例如，openMDX
1.5 其他介紹文章
* An introduction to Model Driven Architecture (Part I)
See document: 3100.html
* An introduction to Model Driven Architecture (Part II)
See document: index.html
* An introduction to Model Driven Architecture (Part III)
See document: index.html
2 II.MDA開源產品比較
對于MDA的實現來說，現在有兩種不同的途徑：I）使用模型驅動應用開發過程；II）直接利用模型驅動運行時應用系統的行為方式。前一種實現，大部分支持從UML模型轉換的代碼生成工具都可以歸入此類，例如AndroMDA，而后一種實現就比較少，例如openMDX。
這兩種方式沒有優劣之分，只是取決于你的應用目的而有不同的側重。
2.1 AndroMDA
AndroMDA的功能非常強大，主要用途在于從UML模型生成Hibernate,EJB,Spring,WebServices,和Struts等框架標準對應的代碼， 在開發過程的建模階段可以快速生成可運行原型，就此而言它是非常實用有效的工具，但是它的代價就是增加了很多對應各種框架類的 stereotype,這樣的模型事實上已不能再算作PIM了，這樣既不利于平臺的遷移和模型的復用。而openMDX則僅僅使用了兩個用于 語義描述的stereotype,這樣的模型顯得更加中立，更面向業務建模的視角。
在Struts和Spring已經成為事實上的J2EE框架標準的情況下，AndroMDA能夠滿足很多J2EE項目的框架要求，并且節約了很多重復性的編碼工時，特別是，相對于采用手工編寫此種代碼，避免了可能出現的"手誤"。
AndroMDA的長處也正是它的短處，因為完全面向J2EE平臺開發，對于通用、中立的類型沒有定義，也缺少對于屬性的特性支持，比如持久性屬性和導出屬性的區分。在模型的表達上，仍然是更傾向于從技術框架的角度進行建模和描述系統行為。
另外還有一個通常的"代碼生成器"都有的問題，就是對于模型的修改生成會覆蓋掉手工修改的代碼， 這僅僅是因為沒有哪個流行的架構會完全采用JMI或者接口編程的方式，這樣就很難避免在第一次生成代碼之后，需要小心再次生成模型可能會影響到的手工編寫的代碼。
2.2 openMDX
openMDX擁有自己獨立的中立性框架，支持J2EE、.Net和CORBA平臺等，同時具有極大的靈活性和擴展性。基于openMDX的系統，從桌面應用程序到完全分布式應用的轉化, 不需要改變一行代碼。在openMDX所使用的模型中，也沒有采用私有的模型標簽和功能增強。openMDX沒有提供UML模型工具，但是支持所有主流的UML模型工具:Rational Rose, MagicDraw, Poseidon, Together等。現有的插件已經提供了基本功能: 持久性,審核，歷史記錄和角色以及強大的日志功能。攜帶了一個集成的完整的界面生成引擎。
但是缺點也是顯見的，由于采用的框架完全圍繞模型來運行和部署，迫使開發人員從習慣的開發方式和設計思考模式轉變到完全不同的重心上。例如，不再首先考慮UI，業務層，持久層所采用的方式和數據庫結構等在以前的開發過程中作為核心的部分，而是首先考慮業務模型中的對象及其關聯關系，當然這在真正的業務建模中是核心部分，OpenMDX將模型的這種核心地位延伸到了開發、部署和交付使用階段。
另外，openMDX也沒有提供一個IDE來支持整個開發測試和配置應用。
對于這種苛刻的MDA實現方式，下面將介紹對于企業應用系統來說所帶來的利益。
3 III.openMDX帶來的利益
3.1 完全開源
開源軟件的好處在這里就不作討論了，OpenMDX提供了除了源代碼以外更多的東西，包括所有模型文件，API文檔，以及幾個不同使用方式的實例，甚至還有基于openMDX的完全開源的項目--一個企業級CRM應用，openCRX。
3.2 提供了基于標準（J2EE、.NET等）的基礎架構
基于openMDX的應用可以很輕松的移植到多個不同平臺，采用了MOF，JMI，XRI，XML等標準和協議，不用過多考慮會被綁定于某一平臺。
3.3 快速開發、部署和彈性配置
建立了成熟模型之后，開發測試的工作量降低到了難以想象的地步，舉例來說，openCRX總共兩百天的開發過程中，建模占了100天，界面設計定制用了70天，10天用于實現，20天用于測試部署。
3.4 極強的系統互操作性
openMDX平臺上發布的功能模塊，對于數據的導入導出都是基于Schema-XML，而且可以方便的發布為Webservice，跟其他異種系統的交互達到了輕松自如的地步。
3.5 降低總體擁有成本（TCO）
不僅僅因為平臺本身是開源軟件，而且更因為基于MDA規范，使得模型的重用得以實現，并且可以積累對于企業更有價值的部分--業務模型。對模型變更的快速響應，能夠在幾分鐘內實現從模型修改到生成代碼并部署運行的整個開發過程。
4 IV.基于openMDX的開發過程
4.1 openMDX開發過程簡介
openMDX 是一個OMG Model Driven Architecture(MDA)為起始的高級實現.openMDX是一個工業化的，開放的，模型驅動的運行時引擎和平臺獨立模型(PIMs)框架。 不象大多數商業工具，openMDX 沒有實現PIM到PSM映射的方法。 而是提供了一個普通的，分布式的對象引擎（作為PIM 平臺）。商業邏輯(模型的導出屬性和方法)是作為插件添加進去的。下圖說明了OpenMDX在軟件開發過程中所起到的作用：
-
建模: 創建PIM。當前版本中, openMDX 僅僅需要與MOF兼容的類圖中的靜態模型圖，其他對系統行為建模的圖則暫不被支持，對于UML動作語義和活動圖和狀態圖的支持將在以后的版本中作為可選項加入。 openMDX 提供了工具將兼容MOF的模型映射, 即采用了JMI和 XMI 的映射。由MOF 映射所定義,類圖表達了一個組件對外的行為規范, 例如組件的接口。
-
開發: 在這一步中開發者編寫客戶端和服務端的代碼。要注意，就像以后會看到的，現在手工編寫的代碼是平臺獨立的。
-
部署: 將生成的MOF 映射, 手工編寫的代碼, 部署信息和openMDX運行時環境，在部署階段集成在一個可運行、可部署的應用服務平臺上，例如，J2EE應用服務器、.Net服務器等。
openMDX 并未覆蓋整個開發過程。它沒有支持諸如需求工程，測試等階段的工作。 當然，所有這些階段都是開發應用的基礎階段。
4.2 openMDX模型基礎及Hello-World實例簡介
在openMDX的發布包中，有一個Hello-World的實例，在文檔中有一篇《openMDX Quick Start》是專門介紹這個實例的配置運行方法的，在這里不再贅述，只是討論以下幾個要點，為下一篇的深入介紹做好基本概念的準備：
1．在openMDX中，代碼與模型的關系
2．在基于openMDX的模型中所用到的一些UML概念
3．w3c的基本類型介紹
4．openMDX中所用到的stereotype的介紹
5．Hello-World的模型
1．在openMDX中，代碼與模型的關系
在基于openMDX的開發過程中，一旦模型創建完畢，并符合openMDX的建模規則，即可使用Ant構建生成基于openMDX的工程。其中，使用generate target可以導出模型，分別生成對應JMI和XMI標準的文檔，其中前者是java代碼，后者是XML格式的模型定義文件。搭建起Hello-World在Eclipse中的工程環境之后，可以很清晰的看出，自動生成代碼和手工編寫的代碼是分放在兩個不同的目錄中，而對于導出屬性和操作則是通過delegate(委托)的方式去執行手工編寫代碼的，而其中的委托關系，是以package（包，包括java類中的包和UML/MOF模型中的包的含義）為單位去配置映射關系的。關于JMI和XMI在openMDX中的具體作用和運行調用關系，請參考《openMDX Introduction》。
2．在基于openMDX的模型中所用到的一些UML概念
openMDX的模型是兼容MOF標準的，另外加入了對于quarlifier（限定符）的支持。如果你對UML/MOF建模已經非常了解，那么可能只需要熟悉幾種openMDX中常用的關聯關系和設計慣例。由于openMDX采用了XRI協議訪問所有的應用資源（包括模型、包、類、對象/實例），所以所有類圖模型中所定義的實體類都必須被每個包中的Segment直接或者間接的包含并且是可導航的，而其他作為參數或者返回結果定義的類（stereotype為Struct）和作為抽象類用于被繼承的類（stereotype為root）則可以單獨存在。
3．w3c的基本類型
在openMDX的模型中，有一個org::w3c的包，其中定義了幾種標準的原始類型，是作為模型中的基本數據類型存在的，并且具有中立性，由OpenMDX平臺負責對這幾種基本類型到具體語言平臺的映射。
4．openMDX中所用到的stereotype的介紹
"0..1" (針對屬性的修飾版類, 表明這是個可選的屬性)
"list" (針對屬性的修飾版類, 表明這是一個沒有空值的排序集合)
"set" (針對屬性的修飾版類, 表明這是一個不重復的未排序集合)
"sparsearray" (針對屬性的修飾版類, 表明這是一個允許空值的散列數組)
"stream" (針對屬性的修飾版類,對于類型是org::w3c::string 和org::w3c::binary 的屬性，表明這是字符或者二進制流)
openMDX中的每個包含關系都需要一個類型為org::w3c::string 的quarlifier(限定符) "alias" （針對類的修飾版類,允許通過別名引用到一個給定類）
"root" （針對類的修飾版類，允許其他"root"或者非"root"類由此類繼承
"primitive" （針對類的修飾版類，表明了此類是原始類型，并由openMDX核心所支持
5．Hello-World的模型
下圖是此實例的初始模型圖：
注意在poseidon工具界面左方的面板里面，HelloWorld類的節點下面重復性的包含了SayHelloResult類的定義，如下圖所示：
因此，在做模型擴展的時候，需要注意，增加了SayGoodbyeResult類之后，同樣要在HelloWorld類中復制一份。否則，在使用Ant構建工程時，會報不匹配建模規則的錯誤。好在使用其他工具，比如Rose時，不會有這樣麻煩的需求。
Hello-World的模型非常簡單，沒有涉及到類與類之間的關聯以及對象實例的持久化等問題，這些將在后面的部分進一步講述。
|
