51CTO之前的文章《使用模型驅(qū)動開發(fā)（MDD）的十五個理由》詳細(xì)介紹了使用模型驅(qū)動開發(fā)對程序員、項目以及商業(yè)需求方面的種種好處，但模型驅(qū)動開發(fā)的內(nèi)在特質(zhì)是怎樣的？MDD究竟會如何發(fā)展？本文將帶您深入模型驅(qū)動開發(fā)，講解MDD的發(fā)展趨勢和幾個必要組成。

“模型驅(qū)動開發(fā)”——體會一下這幾個詞。它們說出了這個不斷變化的工業(yè)中一個新的改變。這里不是說一種革命，而是一種緩慢的變化，但是肯定會滲透到我們開發(fā)系統(tǒng)的方式中。這種推動將降低代碼的重要性，并且專注于一些開發(fā)中的真正事情：最終的應(yīng)用程序被期望怎樣工作，并確保你能夠根據(jù)客戶的需求可靠地建立起它來。

模型驅(qū)動開發(fā)（MDD：Model-Driven Developement）是更偉大視景MDA 中的一部分。MDA 是模型驅(qū)動體系架構(gòu)（Model-Driven Architecture）的簡稱，由對象管理組織OMG（Object Management Group）所驅(qū)動。MDA 表示了一種模型驅(qū)動開發(fā)方法的概念框架。然而，盡管完整的MDA 還沒有成為現(xiàn)實，模型驅(qū)動開發(fā)現(xiàn)在已成為可能。實際上，它已以較低級的形式存在了較長一段時間，所以我們并不是在做某種新的東西。

沒有魔法

如果模型驅(qū)動開發(fā)這么好的話，為什么不是每個人立刻加入到這個潮流中來呢？

首先，模型驅(qū)動開發(fā)不是一個銀彈，能神奇地解決你所有的問題。總有某人需要去實現(xiàn)系統(tǒng)的功能，并且還找不到任何工具來完成這一點。所有你能發(fā)現(xiàn)的工具只是使這項工作更容易和直接一些。

第二，采用模型驅(qū)動開發(fā)，并不只是在開發(fā)項目的過程中更換一種工具。它還必須和已根深蒂固的開發(fā)過程結(jié)合起來（如果沒有的話，你就可以開始使用模型驅(qū)動開發(fā)了；否則你就只能改善當(dāng)前的情況），但實際上更重要的是，你還會擔(dān)心它對現(xiàn)有應(yīng)用程序的影響。決定改用基于模型的方法前確實需要有一些仔細(xì)的考慮，并且，一般說來，為了不影響當(dāng)前的工作，你只會在新項目中改變開發(fā)方法。

第三，你還需要獲得那些使用工具的人們的支持（你需要一些工具來應(yīng)用模型驅(qū)動開發(fā)）。開發(fā)人員常會認(rèn)為“模型驅(qū)動開發(fā)不是編程”而回避它，并且當(dāng)心他們的工作難于被接受。他們還可能擔(dān)心模型驅(qū)動開發(fā)將會使他們以前辛苦學(xué)來的一些技巧過時。他們的擔(dān)心也不是完全沒有理由。采用模型驅(qū)動開發(fā)后，市場確實很有可能會減少對那些精通好幾種編程語言的開發(fā)人員的需求。但是另一方面，所有好的開發(fā)人員，首先和最主要的是，他們是問題的解決者。他們感興趣的是盡可能地為手邊的主要問題找到新的更好的解決方案。模型驅(qū)動開發(fā)激動人心的一點就是它允許開發(fā)人員集中精力于解決主要的設(shè)計問題，增加新的、酷的功能；而不是花費他們的主要時間于改正語法錯誤，防止內(nèi)存泄露，或無休止的低級bug 上。

還有第四點，它也是第三點的一個結(jié)果，工具必須足夠的好。不幸的是，有時用戶對工具期待太多，或工具提供廠商承諾過多，實際上卻不能交付。這兩種情況都很容易使用戶放棄模型驅(qū)動開發(fā)的想法。你確實需要保證工具能夠滿足你的需求。

可視化軟件工程

模型驅(qū)動開發(fā)（MDD）的基礎(chǔ)是模型和表達(dá)模型的語言。模型提供了這樣一種能力，能夠一致性地顯示這個系統(tǒng)的不同視圖。一個常見的錯誤是認(rèn)為模型驅(qū)動開發(fā)是模型和代碼之間的一種關(guān)系，通過代碼實現(xiàn)了模型。確實很多情況下，這二者是等同的，但它大大限制了我們的視野。

#T#模型的一個主要用途消除開發(fā)過程中各參與方之間的隔閡，需求工程師，系統(tǒng)分析員，軟件開發(fā)人員和測試者都可以使用同一種語言。你可以注意到，他們可能專注于語言的不同部分，以滿足他們的需要，但他們都會共用一些基本的結(jié)構(gòu)，并對他們正工作的系統(tǒng)有一個統(tǒng)一的認(rèn)識。而且使用統(tǒng)一的語言有助于消除角色間的界限，使得在項目的不同階段人員轉(zhuǎn)換到被需要的角色更加容易。還有另外一些人需要知道項目的進展情況，包括項目領(lǐng)導(dǎo)、經(jīng)理和評估委員會。更重要的是，用戶也需要知道什么將會被交付，需要加入到整個開發(fā)過程中，與創(chuàng)建系統(tǒng)的不同人員進行交流。一種圖形建模語言，比如UML，使得各參與方之間的交流成為可能，幫助架起參與方與某些系統(tǒng)復(fù)雜功能之間的橋梁。模型驅(qū)動開發(fā)正逐漸獲得公司高級管理者注意，其中的一個主要原因就是這種能夠逐漸增加用戶、管理層和大的組織機構(gòu)參與的能力。

那么編程將會怎樣呢？它不再需要了嗎？我們在這之前提及了一下，現(xiàn)在再詳細(xì)討論它。給模型提供足夠的信息，工具就能生成大部分和全部系統(tǒng)所需要的代碼。請注意，如果你用工具去生成全部的代碼，這就相當(dāng)于編譯你的模型。在很多方面，這都類似于當(dāng)從匯編編程轉(zhuǎn)到C 編程時發(fā)生的模式轉(zhuǎn)換，開始的時候，存在一定的懷疑，特別是那些匯編語言編程者。對于模型驅(qū)動開發(fā)，我們說的也是一種相似的模式轉(zhuǎn)換，建模語言代替了編程語言，用建模語言來實現(xiàn)系統(tǒng)。這主要是因為建模語言正變得更有表現(xiàn)力，允許用戶能夠指定詳細(xì)的系統(tǒng)行為。而且，主機上的確認(rèn)和驗證技術(shù)能用于檢查系統(tǒng)的正確性。在模型中，一般說來你會忽略掉那些令人不快的細(xì)節(jié)，比如分布式，代理和內(nèi)存管理，并且讓工具去生成它們的代碼。這些都表明你還需要對系統(tǒng)的行為進行建模（或者如果你愿意，也可以編程），但你可以在更抽象的層次上進行，關(guān)注于系統(tǒng)的重要功能。

你的明星程序員，你記不清他已多少次拯救你的公司了，可能會說，“如果我用編程的方式實現(xiàn)系統(tǒng)可能要快很多?！蹦阒浪f的可能是對的。但是，這是個大系統(tǒng)，或者請慢，他打算對什么編程呢？是誰為他創(chuàng)建了系統(tǒng)規(guī)范？難道他不是團隊的一部分嗎？或者這個系統(tǒng)確實很小，一個人就能夠確定規(guī)范，開發(fā)和測試？即使這樣，你愿意所有的信息都只存在這一個人的頭腦中？如果他不小心發(fā)生車禍，或者你的競爭對手為他提供了一份他無法抗拒的待遇，這時會怎樣呢？系統(tǒng)交付以后又會怎樣呢？最終用戶能夠修改實現(xiàn)嗎？或即使是理解系統(tǒng)？將來升級，系統(tǒng)維護起來方便嗎？

這將我們帶入到模型驅(qū)動開發(fā)的另一個主要用途，把系統(tǒng)和軟件開發(fā)更多地納入到系統(tǒng)和軟件工程規(guī)則中。模型驅(qū)動開發(fā)是關(guān)于開發(fā)和維護系統(tǒng)的，系統(tǒng)并不只是由應(yīng)用程序組成，還包括其他的部分，使得人們可以理解這個應(yīng)用程序。一個模型可以包含明顯可執(zhí)行的部分，但它幾乎總是還有其他部分，并不能被運行，比如需求，系統(tǒng)的粗略框架，商業(yè)模型和分析模型。在項目開發(fā)時，所有這些都應(yīng)該被創(chuàng)建出來并保持最新，它們對于將來的維護非常重要。

模型驅(qū)動開發(fā)的現(xiàn)代工具提供了運行一個（或部分）模型的能力，這使得可以更早得到確認(rèn)，系統(tǒng)能按預(yù)定方式工作。換句話說，這意味著項目風(fēng)險被極大地降低。在模型驅(qū)動開發(fā)中，測試也變得更加重要，因為能夠被更早和更頻繁地進行。這種方式，會使你對在項目后期，應(yīng)用程序的各部分能夠統(tǒng)一合作具有更多地信心。直觀地，你可能以為所有這些額外的工作會延長開發(fā)周期，但是經(jīng)驗顯示，產(chǎn)品上市時間實際上是縮短了。你花費更少的時間用于實現(xiàn)和測試階段，更多的時間用于分析和設(shè)計階段，當(dāng)你迭代重復(fù)這些過程時，你會發(fā)現(xiàn)，這種方式的好處是實實在在的。

UML 2.0 的作用

無疑，統(tǒng)一建模語言（UML，Unifid Modeling Language）就是設(shè)計用來進行模型驅(qū)動開發(fā)的語言。它第一次標(biāo)準(zhǔn)化是在1997 年，作為當(dāng)時各種面向?qū)ο蠓治龇椒ㄖ疇幍慕Y(jié)果。然后它迅速成為最流行的建模語言，用于“可視化、構(gòu)造和存檔在基于軟件的系統(tǒng)創(chuàng)建過程中的產(chǎn)品”。

我們沿著這條道路已經(jīng)走了五年，用戶和工具提供商對于UML 語言都有了更多的經(jīng)驗。我們知道什么很有用處，也知道什么需要被改進。而且，軟件工業(yè)在這些年也發(fā)生了變化，需要去支持一些新的技術(shù)，比如基于構(gòu)件的開發(fā)和可執(zhí)行的模型。這些需求還不能用現(xiàn)在的UML 合適地處理。為了解決這些問題，對UML 大的修訂工作兩年前由OMG 開始啟動，預(yù)計于2002 年底前完成。

在語言中新增加的性能，用于對系統(tǒng)架構(gòu)建模，都是些很重要的部分，使得更容易創(chuàng)建任何復(fù)雜度的實際系統(tǒng)。對這種規(guī)模可伸縮性的關(guān)注也擴展到了其他領(lǐng)域，包括對行為進行建模的圖形，比如順序圖和狀態(tài)機。既然UML 試圖適合很多參與方的需要，它需要變成一種相當(dāng)大的語言，但是并不是每一個人都需要知道語言的所有部分。它被有意識地分割成幾種視圖或圖形，允許你關(guān)注于只與你相關(guān)的專門領(lǐng)域。其他人可能希望工作在其他的視圖上，模型將保持這些視圖間的一致性。

工具的考慮

工具實現(xiàn)模型驅(qū)動開發(fā)的方式各不相同，給予用戶或多或少的靈活性。雙向工程是一個可憐人的選擇，他不能在模型中捕獲到系統(tǒng)行為，并且他還把自己與某種特定的編程語言綁定在一起，這還是一種以代碼為中心的方法，所有這些都將使你感到難受。在一些緊急的場合，你甚至?xí)浤Ｐ?，比如一個項目就要到達(dá)最后期限（看起來在某處總有一個最后期限）了。在項目的最后，你得到了一個可工作的應(yīng)用程序，還有一個沒有實際用處的模型。這時，你甚至懷疑建模的重要性了。

對雙向工程問題的一個讓步就是在模型中直接插入編程代碼，因此強迫你更新模型以確保最終得到一個可執(zhí)行的應(yīng)用程序。這同樣使你感到難受，又被綁定到某種特定編程語言，你還不得不在模型的很多地方插入代碼片斷。這很像在C 程序中插入?yún)R編代碼，盡管有時這是必要的，但是將來維護會是問題并可能傷害你。

考慮直接在模型中提供指定系統(tǒng)行為的能力，上述兩種方法都變得過時。在模型驅(qū)動開發(fā)中，你只需按一個鍵，在你選擇的平臺上，就能獲得自動生成的任何語言的代碼，這樣在模型這一級上就能實現(xiàn)應(yīng)用程序的可移植性。你不需要修改代碼，改變你的系統(tǒng)就能直接反應(yīng)到模型的實現(xiàn)上。當(dāng)然，目前還有一些路需要走，大部分的工具廠商目前都有他們自己的語言映射，但要實現(xiàn)MDA 的目標(biāo)，就需要有對不同語言和平臺的標(biāo)準(zhǔn)映射和腳本。好消息就是這種前景正在展現(xiàn)。模型驅(qū)動開發(fā)確實正在起作用，并必將改變我們開發(fā)系統(tǒng)的方式。