模型驅動開發MDD

模型驅動設計承諾帶來開發時間的縮短、bug的減少以及更好的可維護性。這是黃粱美夢嗎？或許Matthew Overington會說不是。

軟體開發行業花了數年功夫經曆了大規模成本削減的曆程，並開始新的進展。對軟體開發過程而言，我們需要更好的預測性、透明性和可信性。

建模並不是一個新的名詞。它是軟體設計和開發中的重要一環，但企業目前進行中更聰明和野心勃勃的計劃，應用程式模型來解決很多多年的老問題。

其中一個問題就是當前的編碼方法對建模的依賴－只有當模型經常更新維護時它才是有用的。過時的模型實質上是無用的，實際上有時候還是反生產力的，導致bug……。你覺得模型中應該有的功能在實際代碼中沒有。而現在的趨勢是希望可以得到這麼一個架構，允許模型通過各種方式進行轉換和應用，允許開發人員從這些資源（譯註：指這些模型）中得到更多用途。

Borland APAC產品線的主管Malcolm Groves認為模型驅動開發（MDD, Model Driven Development）是繼90年代的RAD和OO之後下一個革新。儘管RAD工具允許開發人員快速地開發實際可用的代碼，但其中很多產生的程式碼卻很垃圾。也有人認為RAD的困擾在於效率的不夠，因此開始使用UML模型，並手工編碼來產生結構良好的代碼。這樣確實可以得到不錯的結果，但卻損失了速度。MDD承諾搭起這兩者之間的橋樑，允許開發人員在快速同時便於維護的基礎上開發高品質的代碼。

在RAD中，通常是架構師驅動開發的進行，資料庫的結構在很大程度上決定了應用的形式。而使用MDD，開發人員可以方便地在資料庫和代碼之間來迴轉換。使用今年底將發布的ECO III, Borland將提供MDD for C#, 和MDD for Delphi .NET。

Borland正在努力用MDD來取代RAD，Grove認為對建模的更多依賴將是現實的途徑。開發人員可以在更高抽象層級上工作而無需擔心底層細節。模型驅動架構MDA提升了抽象層次，使開發人員可以關注於商務邏輯。

繼在定義UML中扮演了非常重要的角色之後，Rational對MDD也持相同的觀點。Rational在1990年左右開始提供Rational Rose和後來的Rational XDE。Eclipse項目目前已經開放原始碼，這也再次證明了Rational在該領域的領先地位。

根據IBM公司Rational分部的售前架構師Davyd Norris的說法，代碼產生方面更多圖形化工具的開發是很自然的進化方向。“MDD是關於向抽象層級的轉換，它允許一個項目中具有不同經驗和想法的不同的人在一起工作，而不管他們更適應於哪個抽象層次的工作”。

Norris認為企業架構師需要使用UML的敏捷方法，“企業們正在變得更加敏捷。更多的應用正基於進階別的模型進行開發。”

對Norris而言，從底層的代碼到高層的模型這些不同的抽象層次都是模型的一部分。他對代碼就是模型的說法非常不屑，企業架構中有很多東西是無法簡單用代碼來表示的。通過轉換工具可以實現不同抽象層級之間的切換，但它們都是對同一個問題價值相同的不同片斷。

微軟的姿態稍有不同。OMG官方定義MDA是使用UML開發應用的方式，而微軟卻不打算用UML來進行模型驅動開發，而取而代之的是DSL（領特定領域語言，domain specific languages），它被設計來支援特定的任務。微軟認為UML用來表達設計的大概意圖是有效，但用來作為源語言卻不合適，因為UML在addressability、可擴充性和一致性上都存在不足。

Jack Greenfield是微軟企業架構和工具部門的架構師，根據他的說法，Redmond方法將模型作為“軟體開發的源工件，這些工具可以被自動地處理，比如進行驗證、分析、跟蹤和代碼產生等”。這些模型的用途並不是作為文檔。

動力（Momentum ）

儘管先鋒部隊是Rational和Borland，還有大量小一些的公司有著同樣的熱情，並給出了不少強大的工具。

以Embarcadero公司為例。他們提供了模型驅動的資料管理解決方案，其中可以建立模型並且該模型被整個開發鏈中的所有人所理解。該公司的arsenal中包含了為一個分析資料庫應用所提供的模型驅動應用（ER/Studio），一個可視化建模和資料流設計工具（DT/Studio），以及一個模型驅動的分析、設計和開發環境（Describe）。這三個部分之間互相互動，可以將ER/Studio中得到的資料模型匯入Describe，並構建完整的應用程式模型。也就是，可以從模型直接產生代碼。

Embarcadero公司的APAC地區主管Philip Ball指出，當前的趨勢是解決多年的開發老問題－“意大利麵條問題－什麼東西都糾纏在一起。你可以改動一處代碼，但你不知道你影響了多少其它的地方。”

他認為模型的使用有助於提高開發過程的透明性，這將縮短開發時間，並降低bug帶來的衝擊。

Ball認為，MDD是將推動開發中對中繼資料的更多依賴。“存在儲存中繼資料的需要，這樣開發人員可以得到一個更全域的視圖，看到自己負責的部分在整個軟體生命週期中的位置。”

隨著近年來資料的大量增長，Ball感覺這個問題越來越成為如何來控制的資料的問題；如何保持一個全域的視圖同時可以有效地使用。根據Ball的估計，知識工人（knowledge workers）在開始工作之前需要花費50％的時間來理解他們面前的資料。“如果有模型和中繼資料，他們可以看到這些資料在更大視圖中的位置，這樣就可以削減這部分時間開支。”

Rational的Davyd Norris同樣強調在一個軟體生命週期中全域性的好處。軟體開發並不終止於測試。部署、維護和文檔化也是同樣重要，並往往會導致項目的成本超支。Rational致力於在整個生命週期中使用模型。這是一個很有野心的項目，但Rational已經為此努力多年了。

MDD的流行甚至MDA為軟體開發中各個環節上的人提供了好處，從DB設計者到架構師、底層開發人員。它允許項目主管可以更透明地監控開發；允許開發人員可以更快地復原代碼的變動；允許DB設計者在代碼產生中擔任更重要的角色；開發人員可以架起純技術和業務層之間的橋樑。Philip Ball指出，“建模和開發之間的界限開始模糊。”

現實世界

底層開發人員也開始追隨這個趨勢了。Granite Solutions的頭頭Dick Walker是一位Delphi開發人員，在過去15個月中他應用MDD加速了Ski Hire Shop的開發速度。3層WinForms業務應用處理預定、打包、付費等工作。他使用.NET remoting來支援用戶端和服務端的通訊，並基於Borland的ECO工具構建了應用。Walker看到了MDD在未來開發中將擔當的重要角色。他認為構建應用的經驗在於“識別系統中的對象和他們之間的關係”，根據Walker的理解，書寫的定義和方法的過程中常常會為代碼帶來錯誤，因此這個過程的自動化將縮短開發的時間。

當然不光有鮮花，Walker在使用C#Builder 和ECO的初期也遇到了很多問題，ECO現在還有很多限制。他認為這是“從RAD和DB對象開發到MDD應用開發的範式轉換”。現在他已經度過了這個學習階段，而且將不再回到過去的開發方式上去了。“MDD不是玩具，你可以用它來開發真正的應用程式。”他認為隨著工具開發商的努力，只有天空才是限制（譯註：MDD的限制會越來越少）。

魔術棒？

上面的這些往往使人們不禁認為MDD就是今天各種編程問題的答案了。不幸的是，現在我們還遠遠沒有到可以有一個一勞永逸的方案能夠給牙齒增白、防止脫髮的時候。我們也不會有什麼可以替代有經驗的開發人員來書寫好的代碼。這些建模工具的發展只是輔助好代碼的書寫，而不是替代。

MDD的擴充使用可以協助開發人員報告需求、在合并和收購時整合各種應用，當項目結束的時候產生文檔。MDD最本質的一點就是協助您提升資產的重用。

期望用UML來定義一個應用，然後按下一個魔術按鈕，得到最終的應用，這是不現實的。開發人員還是需要挽起袖子，老老實實地編代碼，這樣才能得到優美而高效的應用。Philip Ball的總結很棒，他認為MDD是“not automating good design methodology”。MDD只是將一個開發項目中涉及的各種人都團結在一起，允許大家在各自擅長的抽象層次上進行工作。