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

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

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

沒有魔法

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

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

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

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

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

可視化軟件工程

模型驅動開發（MDD）的基礎是模型和表達模型的語言。模型提供了這樣一種能力，能夠一致性地顯示這個系統的不同視圖。一個常見的錯誤是認為模型驅動開發是模型和代碼之間的一種關系，通過代碼實現了模型。確實很多情況下，這二者是等同的，但它大大限制了我們的視野。

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

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

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

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

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

UML 2.0 的作用

無疑，統一建模語言（UML，Unifid Modeling Language）就是設計用來進行模型驅動開發的語言。它第一次標準化是在1997 年，作為當時各種面向對象分析方法之爭的結果。然后它迅速成為最流行的建模語言，用于“可視化、構造和存檔在基于軟件的系統創建過程中的產品”。

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

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

工具的考慮

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

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

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