【51CTO譯文】什麼是模型驅動開發（MDD）？為什麼使用MDD？本文將回答這些問題，告訴您在軟體專案中使用模型驅動開發的十五個理由。

1、MDD開發更快速

相比傳統軟體開發，模型驅動開發（MDD）的軟體專案中，應用程式被指定為一個更高層次的抽象模型。通過對模型的解釋/執行或產生的程式碼，抽象模型會自動轉化為可工作的軟體應用。

在程式碼方面，因為模型具有更高的抽象層次，所以比相同實現的其他方式具有更小的程式碼量。換句話說，模型中的每個元素（符號或其它偽程式語言）可以代表多行程式碼；這樣，我們可以在相同的時間內實現更多的功能。比如，對比Mendix和Java開發， MetaEdit+或其他MDD開發工具比傳統開發方式快五倍的速度。

2、MDD使開發成本更低

MDD能夠以更低的成本高效的實現專案。正如上文所說，MDD的開發速度更高，可以縮短軟體產品的交付日期，提早上市時間。其次，使用MDD本身就可以用較低的成本完成開發；比如，可以用更少的工程師和非專業人士並保證軟體高質量的完成。當然，能節約多少成本還取決於學習MDD的成本和開發或購買MDD開發工具的成本。

另外，使用MDD來改變正在開發和維護的專案也能夠節約成本。在維護方面，閱讀高抽象模型的應用程式行為更加容易（詳細參考第六點），此外，我們還可以更快的使用高階語言新增或改進產品的功能。

3、MDD可以提高開發質量

在使用MDD的軟體開發過程中，應用程式使用高階的抽象模型，而模型由一個引擎執行或被解釋成程式碼；所以，該程式模組的質量將取決於執行引擎或直譯器，而執行引擎或直譯器一般是由一流軟體公司和專家級程式設計師打造的。

此外，我們在專案中所使用的所有好的方法都可以包含在模型驅動開發（MDD）引擎中，並且在使用MDD工具開發軟體時應用到你的專案中。如果你購買了一個MDD工具，你也同時購買了眾多優秀的開發工具，因為MDD工具建立在過去所有軟體專案的優秀技術總結。

4、MDD出錯率更低

每個具有軟體開發經驗的人都知道，測試會花費開發人員大量的時間和精力。MDD可以確保我們專注於程式功能的測試，這意味這我們只需進行驗收測試。技術細節的測試已經包含在MDD測試工具中。比如，對基礎構造或安全問題的測試。

5、MDD的有效性驗證

在使用MDD時，程式功能本身是低錯誤的，因為程式的有效性驗證時在MDD的高層模型中完成的。我們知道，在使用傳統的程式語言時，IDE會提供一些語法檢查，甚至會進行靜態程式碼的分析。但這並不能真正幫助我們避免程式的功能性錯誤。

當使用MDD方法時，對特定領域的有效性驗證可以在系統設計時進行，由此產生的錯誤也可以控制在一定的範圍內。比如對本文的一個靜態文字驗證。在使用Mendix模型環境中，我們可以使用實時的一致性檢查以確保模型的一致性並保證其可以在執行時環境執行。

6、MDD使人在軟體中的影響降低

在第二點中我們提到過使用MDD可以用更少的工程師和非專業人士並保證軟體高質量的完成。當你不再需要技術專家來建立軟體，你可以挑選更多人來為你工作。另外，與傳統的開發方式相比，在使用MDD的專案中，如果有人中途加入，他可以更簡單的理解軟體應用的高階模型，因為他不必為搞懂程式的某些功能而閱讀大量的原始碼。

7、MDD給行業專家更高多空間

MDD可以使行業專家專注於軟體的行業特性，而技術專家將集中精力用於構建MDD的工具（詳見第八點）。構建複雜的應用程式將不再是精英程式設計師的專利，在MDD專案中，將允許行業專家用他們自己的知識系統使用特定的符號構建一個模型，並使之融入高層的程式模型中。

8、MDD使高階程式設計師只做他們該做的事

在使用MDD開發的專案中，開發人員很少進行重複性的工作。他們將有更多的機會在他們的工作中發揮創造性。比如，他們可以關注如何構建MDD工具；他們可以指導程式新手進行軟體的初級開發或配合行業專家進行系統建模。高階程式將用更多的精力去解決應用程式中關鍵部分的技術攻關。比如，行業專家可以為圖形使用者介面、處理流程和商業規則建立模型。應用的整合部分（WebServices、API呼叫、資料庫成等）對行業專家和開發新手存在困難，但這部分工作留給高階程式設計師去關注。高階程式設計師可以輕鬆而富有創造性的搞定這類專案中難度較大的部分。

9、MDD將消除業務和IT之間的隔閡

業務和IT的完美對接是在軟體開發中經常被談及的。MDD可以用以下方法使商業和IT之間走的更近：

◆行業專家或業務分析人員可以直接的參與開發過程（參考第七點）。軟體的應用部分被定義為一個很高的抽象模型，這些模型將無限接近業務概念中的描述和定義。

◆因為MDD可以更快速的進行開發（參考第一點），軟體的構建過程將更少的迭代，這將使軟體更符最初的需求（軟體交付日期縮短，從市場策劃到終端使用者的週期變短）。

◆業務和模型以及模型和IT系統之間的定義更加明確。比如，使用模型驅動的面向業務需求（SOA）的一個框架。

10、MDD使軟體開發不再懼怕商業需求變更

軟體開發界當前存在的一個問題是商業需求的經常變化，而且這種變化的速度遠遠高於軟體系統本身所容納的限度。這主要是目前企業的長期戰略無法保持足夠的時間就產生變化並導致核心IT業務經常變化。當前動態的商業環境不得使企業有足夠的反應時間。

但MDD可以提供有效的解決方案，因為MDD可以使軟體開發更加快速（參考第一點），它還可以是應用程式的改變更加容易（參考第二點和第六點）。如何商業需求和軟體應用模型的關聯足夠明確，需求變化甚至可以自動傳遞到軟體應用部分的變化（參考第九點）。

11、由技術產生的軟體變化更少

技術的更新與變化越來越快。想想Java EE、 SOA/SOBA、WebServers、REST、OSGi和最近一年雲端計算帶來的技術變革。MDD可以確保我們的應用程式模型在遷移到其他技術平臺時不會發生變化；我們只需根據所變更的技術平臺相應的改版程式碼編譯器或直譯器。更換直譯器後，所有的程式模型將直接被編譯成新平臺的程式碼。

12、MDD使架構更加強壯

公司經常會定義架構標準，軟體開發必須按照這些標準行事。但當所有程式碼都用手建立時如何檢查或執行這些架構標準？當選擇MDD進行專案開發時，應用程式會遵守既定的架構標準。你可以確保IT架構的標準化，因為這些架構標準在MDD工具中被定義。

一般，功能性的架構標準將指導功能設計。這些標準表現在你所採用的DSL（領域特定語言）。在MDD中，架構標準指導功能設計，並將在程式碼編譯器和直譯器中得到體現。

13、MDD使開發人員獲得更多行業知識

MDD的另一個好處是你不只是建立一個軟體，在高層的軟體模型中，你將獲得所建立軟體的領域知識。在大多數軟體專案中，領域需求的描述並不清晰，我們通常需要與行業專家或領域內不同的使用者接觸，用他們的專業知識來描述系統需求並建模。在MDD中，基於高度抽象的領域模型，我們可以通過行業專家對應用模型的描述獲得深入瞭解具體應用領域的機會。

14、MDD可以提供最新的文件

當使用MDD進行專案開發時，我們無需再忍受不完整或不及時的文件，因為模型就是文件。當使用正確的抽象方法，模型的描述對行業專家和專案需求方具有很高的易讀性（請參考第十三點）。

15、MDD使專案重心放在業務問題，而不是技術

就行前面提到的，MDD可以讓我們更多的關注業務問題而不是如何將這些問題用技術實現。所以，不要再討論我們該使用Java EE還是.NET，應該儘快開始MDD的學習和專案實踐。