中科永聯高階技術培訓中心（www.itisedu.com）

MDA(Model Driven Architecture)是模型驅動架構，它是由OMG定義的一個軟體開發框架。它是一種基於UML以及其他工業標準的框架，支援軟體設計和模型的視覺化、儲存和交換。和UML相比，MDA能夠創建出機器可讀和高度抽象的模型，這些模型獨立於實現技術，以標準化的方式儲存。MDA把建模語言用作一種程式語言而不僅僅是設計語言。MDA的關鍵之處是模型在軟體開發中扮演了非常重要的角色。

MDA源自於眾所周知的把系統操作的規範從系統利用底層平臺能力的方式細節中分離出來的思想，MDA提供了一種途徑（通過相關的工具）來規範化一個平臺獨立的系統、規範化平臺、為系統選擇一個特定的實現平臺，並且把系統規範轉換到特定的實現平臺。MDA的三個主要目標是：通過

模型驅動架構（MDA）是OMG組織近年來一直熱炒的一個新的技術體系，同時也是眾多搞軟體模型研究人員的一個新熱點。MDA（模型驅動）核心的思路是希望通過對商業模型（比如企業資訊化或建築領域的解決方案）的領域研究。進而提煉出一個相對核心的領域模型，同時抽象出一個PIM（平臺無關模型）。之後根據不同的開發平臺（例如.net或J2EE），應用平臺（windows或unix）形成相應的 PSM（平臺相關模型）。依照相應的工具，例如 ArcStyler可以完整地生成相應的程式碼和軟體系統。當然這裡只是羅列出一個大致的思路和方法。

1 MDA理論還處在一個探索期，很多理論和方法並不成熟，當然無從談起有成熟的工具，從目前的趨勢而言，從理論到實際的工具都離OMG組織所提出的預想有較大距離，至少還需要數年的努力才能成型 。

2目前無論是國外的開源組織還是國內的一些組織對MDA都只是處在一個草創階段，很多人所謂的應用MDA 其實都只是在MDA的體系中作一個最初的探索和嘗試。例如 ORM就是在一定層次上實現MDA 在資料庫應用方面的探索，但也只是解決了一個實體模型對映的問題。前幾天一個面試人員用 ArcStyler4.X 做了一個銀行POS系統的應用模型，生成了一點還需要修改的框架程式碼。就告訴我說他已經掌握了 MDA，斯等水準真是讓我汗顏！佩服！

3 MDA的第一個熱點可能是橋接器，而在MDA領域中，對映是個很重要的點，而轉換和互動都只是在這個點上的延伸 。

4 目前而言，最有可能在MDA體系中得以實現的語言是 JAVA，儘管我很討厭JAVA的一些愚蠢方法。

5 MDA的核心是PIM，因為他是最抽象和協同性最高的。同時就當前形勢而言，PIM也是一個瓶頸！同時就目前的 UML2.0（從OMG那裡得到最新的）而言，還不足以作為建立整個MDA體系的語言。同時對於MOF中的一些定義似乎還有提升的必要。因為對於整個體系而言，MOF應該更多的作為一個標準，只有在標準成熟的前提下，才有可能產生正確的對映規則。

6 等到MDA風光無限的那天，會使一部分程式員失業，但不會是全部，起碼MDA工具要有人做，因為一個MDA工具不足以應付所有的領域。這就好比沒有一個財務系統能適應所有的企業一樣。因為各個領域的標準化不同。

一、MDA（模型驅動架構）背景

MDA目前在以下領域得到了應用：

*銀行業
*保險業
*公共企業(特別在金融管理領域)
*嵌入式系統
*後勤保障系統

您將會看到，MDA確在其中起到了作用。

MDA的流程
MDA的實現主要集中在以下3個步驟：

1 首先，您用UML對您的應用領域進行高度抽象的建模，這個模型和實現它的技術（或者底層技術）完全沒有關係。這個模型我們稱之為平臺無關模型(PIM)。

2 然後，PIM將被轉換為一個或多個平臺相關模型(PSM)。這個翻譯的過程一般是自動實現的。PSM將用一個特定的實現技術來描述您的系統。它將用到這種技術所提供的種種架構，比如EJB, 資料庫模型，COM元件等等。

3 最後，PSM將被翻譯成原始碼。因為每個PSM已經完全依靠某種特定的技術，這個步驟一般是比較簡單的。

MDA流程中最難的一步，是從PIM生成一個PSM。它要求您對您要應用的基礎技術具有豐富且鞏固的知識，另一方面，源模型(PIM)必須具備自動生成PSM所要求的足夠資訊量。

通過模板生成：MDA-light?!

在MDA的實際應用當中，一個較容易的實現是通過模板(我們稱之為MDA-light)。這樣，平臺相關模型這一步可以說是被跳過了，您可以直接從高度抽象的PIM生成原始碼。您將繼續在MDA-light的基礎上進行真正意義的程式設計：您必須在原始碼，而不是UML，編寫細緻的應用邏輯。

使用MDA的前提

* 業界(甚至是整個世界)一個被廣泛接受的事實是：只有變化是永恆的。技術永遠在革新。這在中介軟體領域尤其明顯，當然還有資料庫技術，作業系統，甚至是程式語言都經常變化。這些技術明顯比應用領域的基本概念要變化的快。

* 如果您在某一特定的應用領域工作，在這個領域中的專案都具有一定的相似性。整個應用程式族或者不同的專案都屬於同一個應用領域，那麼，MDA或者生成流程將特別適合於您
。

MDA的優點

* 您對建模的投資將更加持久的有效--遠長於您目前實現它所應用的技術。這將更有利於保護您的投資。
* 您具有了技術上的靈活性。
* 您將不再受技術或應用所具有的不同變化週期的影響--在MDA的幫助下，您可以中立的保持兩方面的多樣性。

MDA的缺點

* MDA意味著更多的"組裝"而不是"開發"--在為一個應用建立PIM的時候，您基本上沒有技術上的周旋空間。這對於今天的很多開發人員來說，還是難以想象的。
* 軟體開發的創造性在一定程度上減弱了。開發人員常常覺得，就一種新技術展開爭論，在技術的前沿工作，是十分吸引人的。可是在MDA流程下，大量的工作是建立模型，這和具體的技術相距甚遠，但符合OMG的建議。
* 潛在的不成熟性。UML2.0還在幼年時代。MDA工具出現的時間也相對很短。這裡還隱藏了很多風險。

MDA流程和生成開發中有待解決的問題

* 資料和應用程式的移植：目前在商業領域經常需要面對的問題是，大量的資料和應用程式如何向新的，MDA為基礎的系統中移植。純粹的MDA流程將把資料模型和資料庫表結構看成是技術細節。它們不應該對平臺無關模型(PIM)層產生任何影響--那麼，您的MDA工具或生成器也負責生成資料庫指令碼嗎？
* 軟體維護：編制不同的發行版本，補丁或者升級，是對目前正在執行的程式進行維護的重要組成部分。MDA怎麼處理這些問題呢？每次進行一次全新的安裝？
* 投資報酬率(Return-on-Investment)：從什麼樣的環境和系統開始計算？從應用MDA的第二個專案？還是從第五個開始？
* 購買軟體架構還是自主開發？
* 生成器和相關工具造成了對其生產商的依賴--這種對生產商的依賴是我們以往一直極力避免的。
* 企業應用整合(EAI)：高度的抽象，聽起來不錯--但是對於已經在運轉的應用系統，怎麼得到這種抽象呢？
您可以看到--潛在很多實際問題（其回答都具有重要的意義）。這些問題正是我們創立openMDA的原因：在很多專案當中，某些以上的問題已經得到了實驗性的回答，您（和我們）都將從中獲益！

二、MDA的軟體開發週期

在MDA中軟體開發過程是由軟體系統的建模行為驅動的。下面是MDA的軟體開發週期：

MDA生命週期和傳統生命週期沒有大的不同，主要的區別在於開發過程建立的工件，包括PIM（Platform Independent Model，平臺無關模型）、PSM（Platform specific Model，平臺相關模型）和程式碼。PIM是具有高抽象層次、獨立任何實現技術的模型。PIM被轉換為一個或多個PSM。PSM是為某種特定實現技術量身定做。例如，EJB PSM是用EJB結構表達的系統模型。開發的最後一步是把每個PSM變化為程式碼， PSM同應用技術密切相關。傳統的開發過程從模型到模型的變換，或者從模型到程式碼的變換是手工完成的。但是MDA的變換都是由工具自動完成的。從PIM到PSM，再從PSM到程式碼都可以由工具實現。PIM, PSM,和Code 模型被作為軟體開發生命週期中的設計工件，在傳統的開發方式中是文件和圖表。重要的是，它們代表了對系統不同層次的抽象，從不同的視角來看待我們的系統，將高層次的PIM 轉換到PSM 的能力提升了抽象的層次。能夠使得開發人員更加清晰地瞭解系統的整個架構，而不會被具體的實現技術所“汙染”，同時對於複雜系統，也減少了開發人員的工作量。

MDA的出現，為提高軟體開發效率，增強軟體的可移植性、協同工作能力和可維護性，以及文件編制的便利性指明瞭解決之道。MDA被面向物件技術界預言為未來兩年裡最重要的方法學。當今建模的主要問題在於，對於很多企業來說它只是紙面上的練習。這就造成了模型和程式碼不同步的問題，程式碼會被不斷修改，而模型不會被更新，這樣模型就失去了意義。彌補建模和開發之間的鴻溝的關鍵就在於將建模變為開發的一個必不可少的部分。MDA 是模型驅動開發的框架，MDA 的願景是定義一種描述和建立系統的新的途徑。MDA 使得UML 的用途走得更遠，而不僅僅是美麗的圖畫。很多專家預言MDA 有可能會帶領我們進入軟體開發的另一個黃金時代。

三、MDA框架

MDA 將軟體系統的模型分離為平臺無關模型PIM 和特定平臺模型PSM，同時又能通過轉換規則將它們統一起來，以這樣的方式試圖去擺脫需求變更所帶來的困境。平臺無關模型PIM 是對系統高層次的抽象，其中不包括任何與實現技術相關的資訊；特定平臺模型PSM是特定平臺相關的模型。在MDA 框架中，首先使用平臺無關的建模語言來搭建平臺無關的模型PIM，然後根據特定平臺和實現語言的對映規則，將PIM 轉換以生成平臺相關的模型PSM，最終生成應用程式程式碼和測試框架。

MDA框架的“建築材料”包括：高層次模型；一種或多種標準、精確定義的語言，用來編寫高層次模型；如何把PIM變換到PSM的定義；編寫這些定義的語言，這種語言能夠被變換工具執行；能夠執行變換定義的工具；能夠執行PSM到程式碼的變換工具。

上圖是MDA的框架，它的主要元素有模型、PIM、PSM、語言、變換、變換定義、以及變換工具。MDA 是一個開放的，中立於軟體供應商的架構，它廣闊地支援不同的應用領域和技術平臺，能夠成為應用領域和具體技術平臺之間的槓桿。在MDA 開發途徑中，PIM 代表對需求的建模，PSM 代表應用具體技術後的模型，這使得MDA 成為需求和技術之間的槓桿；它們各自的改變都可以是相互獨立的，不會造成商業邏輯和實現技術的緊密藕合，同時MDA 又可以通過轉換來彌補它們之間的鴻溝，從而保護我們的投資。MDA 開發途徑使得我們的系統能夠靈活地被實現、整合、維護和測試，系統的輕便性、互操作性和可重用性都是可以長期保持的，能夠應對未來的變化。

四、MDA的現狀

MDA 還處在一個發展的過程中，MDA還在不斷的演進。雖然MDA正朝氣蓬勃地走來，但是人們也能看出它所存在的問題。MDA最大的好處就是業務模型的持久價值，但是付出的代價是增加了抽象層，而目前看來，層之間的轉換並不是我們所期待的那樣順暢，至少，從PIM到PSM，從PSM到程式碼，這個實現的過程要遠比從3GL生成機器程式碼來得困難。在建模技術方面，UML正在暴露其固有的缺陷，它需要擴充套件更多的機制來支援精確建模和分析模型，雖然目前OCL為精確建模提供了一定的支援，但是這種支援距離可執行模型的理想還很遙遠。回顧MDA的歷史，我們可以看出UML的巨大成功為MDA的產生奠定了堅實的基礎，同時也感覺到：在由軟體工藝到軟體工程的漫漫長路中，MDA只不過是向前邁進了一小步，但卻給整個軟體業掀起了一場波瀾，它在模型定義、開發過程等諸多方面都將對未來IT技術產生深遠的影響。

目前在MDA開發工具市場上的情形是：由於從PIM 到PSM轉換方法的標準化尚未完成，IBM、Borland等大型廠商大都持謹慎態度，雖然也紛紛在他們的開發工具中提供部分的MDA功能，但並沒有完全遵循OMG定義的MDA規範。雖然如此，IBM除了在Rational中增加MDA功能之外，在開源專案Eclipse中，也提出了EMF（Eclipse Modeling Framework）這一創新的MDA程式碼生成系統專案，由此可見IBM對MDA這一發展中的技術的重視程度。Borland公司宣稱他們也在關注MDA技術，並且準備在Together中配置基於MDA的模型自動生成功能。相對於業界大廠的冷靜和矜持，一些中小廠商反而特別活躍，像Interactive Objects公司著名的ArcStyler、Compuware公司著名的OptimalJ，還有開放原始碼的AndroMDA等遵循OMG標準規範的MDA工具已在一些專案中得到了廣泛的運用，並取得了顯著的成效。

五、MDA的相關標準

為了實現MDA這一巨集大構想，OMG制定了一系列的標準：

UML：UML被MDA用來描述各種模型。它並不是為MDA而生，但是作為目前最為風行的建模語言，UML已經佔據了全球建模語言領域90％的市場份額，成為了建模語言事實上的標準，因此OMG將它作為MDA技術的基礎是自然而然的明智選擇。它是MDA的基礎，也是MDA最有力的武器。

MOF：MOF（Meta Object Facility 元物件機制）是比UML更高層次的抽象，它的目的是為了描述UML的擴充套件或者其它未來可能出現的類UML的建模語言。雖然MOF也不是為MDA而生的，但是我們可以體味到OMG的工程師們良苦的用心和長遠的目光。

XMI：XMI（XML-based metadata Interchange）是基於XML的元資料交換。它通過標準化的XML文件格式和DTDs（Document Type Definitions）為各種模型定義了一種基於XML的資料交換格式。這使得作為最終產品的模型可以在各種不同的工具中傳遞，這一點是非常重要的，它保證了MDA不會在打破了一種束縛之後再被加上一層新的束縛。

CWM：CWM（Common Warehouse Metamodel 公共倉庫元模型）提供了一種資料格式變換的手段，在任意級別的模型上都可以使用CWM來描述兩種資料模型之間的對映規則，比如將資料實體從關係資料庫變換為XML格式。在MOF的框架下，CWM使得通用的資料模型變換引擎成為可能。

在OMG的藍圖中，UML、MOF、XMI、CWM等一系列標準分別解決了MDA的模型建立、模型擴充套件、模型交換、模型變換這幾個方面的問題。OMG試圖通過標準化的定義，擴大MDA的應用範圍。同時通過這樣一個可擴充套件的建模語言環境，IT廠商可以自由實現自己的建模語言，以及語言到可執行程式碼的對映，然而不管怎麼樣，都必須處於OMG的標準化框架之下。