MDA的陣營劃分

MDA提出已經(jīng)有5,6年的歷史了，其主要標(biāo)準(zhǔn)還是MOF，UML（包括OCL），XMI和CWM四大核心。目前正在制訂的標(biāo)準(zhǔn)還有QVT（即模型的查詢、視圖和轉(zhuǎn)換）。這些標(biāo)準(zhǔn)族之間相互關(guān)聯(lián)共同組成了MDA這個(gè)龐大的體系結(jié)構(gòu)?？梢哉f，MDA是由系列的標(biāo)準(zhǔn)族加上模型驅(qū)動(dòng)開發(fā)的思想共同組成的。而后續(xù)的研究者根據(jù)自己的興趣又有了不同的側(cè)重點(diǎn)，導(dǎo)致了MDA陣營的分裂（劃分？）。

四個(gè)陣營

Steve Cook將MDA研究者劃分為三個(gè)陣營，Martin Flower也同意他的觀點(diǎn)，并針對(duì)這三個(gè)陣營對(duì)待Language workbench的態(tài)度進(jìn)行了詳細(xì)的討論。另外，Martin還提出了一個(gè)MDD陣營?？偨Y(jié)他們兩個(gè)人的意見，可以將MDA陣營劃分為四個(gè)部分，其中有的陣營是完全對(duì)立的，而有的則是兼容并蓄的：

1.         UML PIM陣營：使用UML來建立PIM，然后利用模型轉(zhuǎn)換來生成PSM，最后用PSM生成代碼；

2.         MOF陣營：不使用UML，而用MOF來代替，建模語言和模型轉(zhuǎn)換都使用MOF來定義；

3.         可執(zhí)行的UML陣營：建立UML編譯器，將UML直接作為編程語言，使UML可以執(zhí)行。

（以上來自于Steve Cook的blog，原文如下：

1. The UML PIM camp: MDA involves the use of UML to build Platform Independent Models (PIMs) which are transformed into Platform Specific Models (PSMs) from which code is generated.

2. The MOF camp: MDA does not involve the use of UML, but instead the crucial technology is MOF, and the definition of modelling languages and language transformations using MOF.

3. The Executable UML camp: MDA involves building a UML compiler, making it a first class programming language.

）

4.         MDD（Model Driven Development）陣營：他們也可以說不屬于MDA的陣營，因?yàn)樗麄儾⒉魂P(guān)心OMG的MDA系列規(guī)范。他們關(guān)注的是模型驅(qū)動(dòng)的開發(fā)思想，可以說，MDA就是MDD在OMG規(guī)范上面的實(shí)現(xiàn)。

也有部分研究者將MDA劃分為狹義和廣義的兩個(gè)陣營。同上面的聯(lián)系起來看，狹義的MDA即前三個(gè)陣營，而廣義的MDA即MDD陣營。我是這么認(rèn)為的。

UML PIM陣營

UML PIM陣營可以說是目前最強(qiáng)大的，因?yàn)樗侨绱朔?/SPAN>MDA最初的構(gòu)想，從大家了解最多的UML開始建立PIM，然后轉(zhuǎn)換為PSM（例如CORBA，J2EE，.NET），然后生成代碼，一切看來都如此流暢，和以前出現(xiàn)的技術(shù)可以兼容，并且也不缺少工具和廠商的支持。

但是，它也是受到詬病最多的一個(gè)陣營，一個(gè)最大的問題就是關(guān)于UML是否是平臺(tái)無關(guān)的問題，如果UML不是平臺(tái)無關(guān)的，則顯然它不適合用來構(gòu)建PIM。MOF陣營的人對(duì)于UML的拋棄就是基于這個(gè)原因，他們認(rèn)為MOF才是MDA的本源，過多的使用UML會(huì)導(dǎo)致不能真正的構(gòu)建PIM，因?yàn)?/SPAN>UML本身就是一個(gè)平臺(tái)。我覺得關(guān)于平臺(tái)無關(guān)的爭論可以休矣，當(dāng)初C也是被認(rèn)為平臺(tái)無關(guān)的，只要在不同的操作系統(tǒng)上重新編譯一次即可；后來的CORBA也號(hào)稱一舉解決了網(wǎng)絡(luò)平臺(tái)不兼容的問題；再來就是J2EE?？墒?，當(dāng)你解決了上一個(gè)平臺(tái)相關(guān)問題時(shí)，你所創(chuàng)建的新技術(shù)同時(shí)變成了一個(gè)新的平臺(tái)，如CORBA平臺(tái)，J2EE平臺(tái)等。為了解決不同的CPU硬件平臺(tái)不兼容，發(fā)明了操作系統(tǒng)；為了解決不同的操作系統(tǒng)問題，發(fā)明了高級(jí)語言；為了解決網(wǎng)絡(luò)不兼容問題，發(fā)明了中間件；為了解決中間件不兼容的問題，發(fā)明了MDA和web service等等技術(shù)。目前看來，使用UML來建立的模型基本上具有平臺(tái)無關(guān)性，我（我是屬于UML PIM陣營的）認(rèn)為使用UML來建立PIM是合適的。

UML PIM陣營的另一個(gè)問題是，UML過于繁瑣，UML2.0標(biāo)準(zhǔn)充斥著各種各樣作用不大的填充物，不僅沒有能夠讓UML更加實(shí)用，反而導(dǎo)致了UML的復(fù)雜度增加，可用性下降。就好比要使用一個(gè)錘子，但是UML給出了一整個(gè)房間的工具，在里面翻了半天卻沒有找到一把合適的錘子。唉。。。因此MOF陣營的人就決定自己去造一把錘子，反正它和UML一樣，都貼有OMG出品的標(biāo)簽。

當(dāng)目前的UML不能完全滿足需要時(shí)，UML給出了標(biāo)準(zhǔn)的擴(kuò)充機(jī)制，也就是Profile（包括Stereotype和tagged value）。但是，很多人認(rèn)為UML的擴(kuò)充機(jī)制和UML自身一樣，過于復(fù)雜，還不如用MOF重新構(gòu)建一個(gè)建模語言（我倒不這么認(rèn)為，感覺Profile還是比較簡單的）。

還有一個(gè)不能回避的問題是，UML PIM陣營更加注重系統(tǒng)的結(jié)構(gòu)，而不注重（不能解決）系統(tǒng)的語義（動(dòng)作/流程），因此很多人傾向于去掉UML動(dòng)作語義，或者根本不使用UML動(dòng)作語義。

盡管UML PIM有這么多的缺點(diǎn)，但是其優(yōu)點(diǎn)也是顯而易見的：1.符合標(biāo)準(zhǔn)；2.對(duì)于普通的軟件從業(yè)者來說，學(xué)習(xí)UML比學(xué)習(xí)MOF要更容易一些；3.可以使用的工具更豐富一些。

MOF陣營

使用MOF來直接構(gòu)建建模語言和模型轉(zhuǎn)換語言在一些書中稱為“重量級(jí)”方法，而使用UML Profile來擴(kuò)充UML生成新的建模語言稱為“輕量級(jí)”方法。由此可見，學(xué)習(xí)和使用MOF是一件比較耗時(shí)的事情，但是這并沒有阻擋MOF陣營的腳步，他們認(rèn)為MOF才是MDA的核心，才是純粹的MDA。

MOF定義的四層模型，幾乎將以往的模型概念一網(wǎng)打盡，在前人的基礎(chǔ)上（M1層和M2層的模糊概念）又定義了M3和M0層。其中M2層可以包容以往所有已知的建模語言規(guī)范，然后定義了一個(gè)唯一的M3層，可以創(chuàng)建出所有這些建模語言，目前所有已知的模型技術(shù)中，唯有MOF是擁有M3層的，而且它是自定義的。這樣MOF兼容并蓄了所有的建模技術(shù)，成為一支獨(dú)大的元元模型工具。目前幾乎所有的建模工具都號(hào)稱MOF兼容的，因?yàn)樽龅竭@一點(diǎn)實(shí)在是太容易了，只要稍微修改一下自己的模型規(guī)范即可?？梢赃@樣認(rèn)為，所有不愿意使用UML的建模者，在MDA出現(xiàn)后一定倒向了MOF陣營。而且，新的模型語言和DSL的創(chuàng)建和使用者，也大部分會(huì)倒向MOF（使用UML Profile對(duì)于這些人來說，不如使用MOF來得順手和自如）。

OMG在制訂MDA之初很明智的讓MOF脫離了UML，這樣增加了MDA的生命力，與其讓MDA技術(shù)與新的技術(shù)競爭，不如將MDA分化為幾個(gè)陣營之爭。MOF的缺點(diǎn)是學(xué)習(xí)困難，工具較少，而優(yōu)點(diǎn)則是靈活自如。由于對(duì)MOF沒有深入研究過，姑妄言之。

可執(zhí)行的UML陣營

這個(gè)陣營的人一定不會(huì)介意我將UML稱為第四代語言。在第三代語言（高級(jí)語言）瓜熟蒂落之時(shí)，就開始了第四代語言的爭論，到底第四代是屬于SQL這樣的描述性語言，還是類似于Agent系統(tǒng)這樣的智能系統(tǒng)，或者網(wǎng)格？神經(jīng)系統(tǒng)？Web Service？但是這個(gè)陣營的人會(huì)自豪的告訴你，第四代語言就屬于可執(zhí)行的UML，其他的無論影響力還是問題域的覆蓋性，統(tǒng)統(tǒng)不如。（可能我的語言有點(diǎn)偏激，大家不要砸磚。。。）

這個(gè)陣營里面的人有個(gè)很好聽的名字，“模型程序員”。當(dāng)UML真正可以執(zhí)行了，對(duì)于高級(jí)語言程序員的需求量就會(huì)像現(xiàn)在的匯編程序員一樣稀少了。（寫到這里，想起了前年和幾個(gè)網(wǎng)友一起為MDACHINA論壇的《模型程序員》寫稿的日子，時(shí)光荏苒啊，轉(zhuǎn)眼都當(dāng)爸爸了。）可執(zhí)行的UML也是MDA研究的熱點(diǎn)，尤其是在MDA技術(shù)提出之初，所有的MDAer都滿心歡喜的想象UML編譯器的出現(xiàn)，可以將手頭的模型直接轉(zhuǎn)換為可執(zhí)行程序。在OMG網(wǎng)站內(nèi)部，就介紹了三本可執(zhí)行UML的書籍。

當(dāng)然，在可以預(yù)計(jì)的將來（2,3年內(nèi)？），我都想象不到可以有完全不產(chǎn)生高級(jí)語言代碼的UML編譯器。也許在某個(gè)局部領(lǐng)域內(nèi)可以實(shí)現(xiàn)，但是能夠做到像高級(jí)語言編譯器那樣完整，在目前是根本不可能的。原因很簡單，目前的UML表達(dá)能力有限，它不能完全承載程序所需要的信息。即使是UML擴(kuò)充了動(dòng)作語義之后。

那么，通過進(jìn)一步的擴(kuò)充UML有沒有可能呢？當(dāng)然是可能的！當(dāng)初誰也不認(rèn)為高級(jí)語言可以完全取代匯編，可是現(xiàn)在已經(jīng)很少有人再用匯編了（特殊領(lǐng)域如驅(qū)動(dòng)程序等除外）。但是，目前的一個(gè)困境就是，UML已經(jīng)過于臃腫了，已經(jīng)由于體積的龐大遭到很多人的拋棄，如果再進(jìn)一步擴(kuò)充UML，是否會(huì)更加引起眾人的反感？

對(duì)于這種困境，我建議將UML分為兩個(gè)部分：UML前臺(tái)和UML后臺(tái)。前臺(tái)是在目前UML的基礎(chǔ)上進(jìn)行精簡，使之更加易學(xué)和實(shí)用；而后臺(tái)是為了定義UML編譯器，可以加入更多語義方面的東西。這樣，可執(zhí)行UML陣營的人可以致力于定義UML后臺(tái)，使之能夠完全承載目前高級(jí)語言所能表達(dá)的語義，從而使UML的執(zhí)行成為可能。類似于java虛擬機(jī)，UML虛擬機(jī)也是可能出現(xiàn)的，在這個(gè)虛擬機(jī)上面，用UML前臺(tái)編寫的模型可以自動(dòng)運(yùn)行，如果在前臺(tái)中沒有定義詳細(xì)的細(xì)節(jié)，那么后臺(tái)可以加上大量的默認(rèn)值使其可以運(yùn)行。

MDD陣營

MDD陣營嚴(yán)格說來不一定屬于MDA陣營，因?yàn)樗麄儫o視MDA的諸多規(guī)范，而是自成一體。他們是典型的“拿來主義”者，有用的就拿來，沒用的就扔掉。很多人號(hào)稱MDA的支持者，但是從來沒有遵循過任何MDA的規(guī)范。他們只是拿來了模型驅(qū)動(dòng)的思想來武裝自己的開發(fā)方法。不過他們也許更加清晰的認(rèn)識(shí)到MDA的精髓，畢竟他們還沒有在冗長的MDA規(guī)范中泡得發(fā)白。

從另一個(gè)方面來說，他們是更加純粹的MDA支持者，因?yàn)?/SPAN>MDA Guide的開頭就說：MDA is an approach to system development, which increases the power of models in that work. It is model-driven because it provides a means for using models to direct the course of understanding, design, construction, deployment, operation, maintenance and modification. MDA是一種方法，而不是僅僅是規(guī)范。

小結(jié)

謹(jǐn)以此文，獻(xiàn)給那些還在MDA泥潭中掙扎的戰(zhàn)友們，愿能拋磚引玉。很多地方都是我猜測的，不一定完全屬實(shí)，如果需要在正規(guī)文獻(xiàn)中引用，請(qǐng)參閱超鏈中的正規(guī)文獻(xiàn)（我鏈接的很多也不是正規(guī)文獻(xiàn)，汗！都是blog），或者參閱其他文檔。