首頁 »
2006/03/28

模型驅動開發的今天

模型驅動開發的今天 模型驅動設計承諾帶來開發時間的縮短、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只是將一個開發項目中涉及的各種人都團結在一起,允許大家在各自擅長的抽像層次上進行工作。



Part2,ECOIII實作WEB ASP.NET 討論區←上一篇 │首頁│ 下一篇→MDA 與軟體開發工具:從 Delphi 2005 談起
本文引用網址: