文 / 姚冬

　　本文介紹了集統一軟件開發和敏捷開發方法優點于一體的新型軟件開發方法——模型驅動開發。

　　當今是一個快速發展的時代，軟件的功能更強大，應用更廣泛，系統架構更復雜。與此同時，軟件開發的難度也越來越大，軟件質量難以得到保障。在與業界同行交流的過程中，我感受到更多的不是自信，而是對軟件質量的無可奈何與力不從心。為了解決軟件開發存在的問題，業界不斷涌現出許多開發方法、過程以及模型，試圖從方法論、工程學等角度對軟件開發過程進行改進和管理。其中最為知名的，要數RUP（Rational Unified Process，統一軟件開發過程）和近十年涌現的各種Agile（敏捷）開發方法了。但從實際效果來看，似乎都沒有達到預期的目的。 

　　本文試圖以模型驅動開發（MDD）為契合點，在RUP的堅實與Agile的靈動之間找到一種平衡。

　　模型驅動開發概述

　　模型驅動開發就是以“模型”為核心的軟件開發過程，業界存在許多特定領域的建模語言（如DoDAF、AUTOSAR等）。但是以UML最為通用、規范和科學化，成為業界建模事實上的標準。

　　模型驅動開發專注于業務的建模和抽象，而不是具體的語言和算法。這種軟件開發方法使開發人員把更多精力放在產品的需求分析和功能劃分上，而不是糾纏于軟件的實現細節。模型以圖形化的方式來表述所研究的系統、過程、事物或概念，而圖形化的方式更符合人腦的思維方式。

　　用文字去表述的概念，例如軟件需求，很容易造成誤解。相比較人類的語言文字，模型在表述時更加準確，尤其是標準化的建模語言，例如UML。

　　模型驅動的開發方法使軟件實現和模型設計完美地統一起來。軟件發展的模型驅動方法不是一種全新的方法，隨著UML2.0（目前最新版本是2.3）及相關工具的推出，其支持性技術越來越成熟，也愈加受到重視。

　　模型驅動開發的成熟，不僅體現在效率方面，更體現在可測量性方面。這種能力是與方法及工具密不可分的。UML2.0版本在語言定義精確程度有了相當的提高，是模型驅動開發的必要條件。UML2.0從通信界代碼生成技術最成功的SDL語言汲取了大量語法語義，使得代碼完全自動生成成為可能。自動化意味著模型轉換時的不明確和不精密的消除，同時能夠保持良好的一致性，使由模型直接生成最終代碼成為切實可行的方案，也為最終生成代碼的質量提供了保障。同時對特定領域的改進和支持也使得UML能夠更好地適應各種應用需要，例如嵌入式領域。

　　從圖1可以看出，軟件開發的整個過程都是圍繞著模型與需求展開的，這里有三個驅動力。

　　需求驅動的開發：以需求為核心，需求是關鍵，是第一驅動力。一切任務都來源于需求，需求是定義開發范圍，驗證開發結果的唯一標準。

　　模型驅動的開發：建模活動貫穿始終，模型是我們工作的方式，通過模型去描述需求和設計系統，進行具體的實現，甚至通過模型進行測試以驗證我們的設計和實現。測試驅動的開發：測試驅動用來驗證各階段任務是否正確合理，保障各階段始終保持一
致，測試過程并不是只存在于開發的后期，而是分布于開發過程的每一個階段。

　　可以說，需求、模型、測試，三者相互關聯，貫穿開發生命周期的各個階段，有機地推動開發過程向前發展。

　　模型驅動的開發過程，也是迭代的開發過程。在需求分析、系統設計階段，我們可以隨時進行驗證和迭代。在軟件具體的開發階段，我們按不同的粒度，進行多次迭代，使一個周期就是從設計到開發再到測試的過程。

　　模型驅動開發與RUP、Agile

　　在模型驅動開發的實踐中，已經總結出了一些需要遵循的基本原則，很多原則都與RUP以及Agile的思路一致，從中我們也可以看到，模型驅動開發與RUP和Agile的關聯。

• 可工作的軟件為核心和評估標準。

• 模型驅動。

• 計劃，追蹤與調整。

• 持續反饋，重視質量及優化。

• 持續的代碼生成。

• 持續的調試與測試。

• 持續集成。

• 測試驅動開發。

　　模型的天然特性結合相關工具的支持，既可以借助RUP完整定義的流程，又可以有效地實施敏捷開發的最佳實踐。通過模型建模，快速地構建系統框架，建立起快速原型，并借助模型的仿真和執行，來模擬目標系統的運行行為。這種方式可以盡早將軟件系統原型與客戶進行溝通和呈現，更形象化地與客戶進行交流，快速捕獲客戶的需求和反饋，進而指導下一步開發和下一個原型的產生。

　　這使得“以更低的成本交付高質量系統”成為事實上的可能。

　　模型驅動與RUP的關聯

　　UML是模型驅動開發中最常見的語言，它本身就與RUP一脈相傳，因此模型驅動開發與RUP關聯緊密。RUP強調的軟件開發過程，在MDD模型驅動開發中同樣適用，而且會遵循得更加有效。

• 迭代的開發

　　模型的分層構架，從不同層面、不同角度對系統進行描述，通過UML對系統良好的描述和內建的關聯，使迭代開發成為必然。借助工具的仿真和執行，我們可以在不同階段對模型設計加以驗證，而每一次的迭代，都可以由模型直接生成可運行的原型。圖2是一個從分析到開發再到測試的以模型為中心的連貫的迭代過程，它關注持續集成，同時測試驅動的理念貫穿始終。

• 需求管理

　　需求同樣可以進行建模，并且能夠在工具中管理起來，進行需求的關聯分析、覆蓋度分析、變更影響評估、需求的回溯、需求風險分析，從而使得需求管理變得容易，實現從軟件開發的根源把控質量。

• 基于構件的體系結構

　　工具支持由模型生成不同架構的目標代碼，模型又可以支持不同的設計模式，甚至有專門針對模型開發的設計模式，有效地保障了生成代碼的質量，并且良好地支持模型的可重用性。

• 可視化軟件建模

　　在這方面，RUP與模型驅動開發是一致的。不同的是，MDD工具的出現，使得可視化建模變得更簡單、更合理，而且可以支持整個生命周期的開發建模，從需求捕獲，到系統設計開發、模型測試、代碼生成，都可以圍繞建模展開。

• 驗證軟件質量

　　軟件質量通常由測試來保障，而傳統軟件開發之所以測試不利，一個原因是不能更早地介入，無法在早期階段針對需求分析和設計進行測試驗證。而借助工具的支持，模型驅動開發得以將模型仿真，支持設計的驗證，生成快速原型，及時有效地與客戶交流。

• 控制軟件變更

　　軟件變更的控制，一方面需要評估變更造成的影響，這一點通過模型之間建立起來的關聯可以輕易達到；另一方面需要測試驗證變更涉及模塊，保證修改在準確實現變更的同時，不影響其他功能模塊。這可以通過工具支持的模型回歸測試等手段實現。

　　MDD對敏捷開發的借鑒

　　模型驅動開發在很多方面與敏捷開發的思想非常契合，而模型自身的特點，也使得它在實踐敏捷開發多種實踐時來得更容易、更自然、效果更好。

• 持續迭代，持續反饋

　　使用短周期的迭代可以加速開發過程，例如Scrum的一次Sprint。基于開發出的快速原型，客戶可以更好地理解自己的需求，開發者也能了解到如何才能更好地滿足客戶的需求。模型的可執行性決定了模型驅動的開發可以快速地生成可執行的原型，從而使得持續迭代成為簡單的事情，與客戶的持續反饋也變得更加容易溝通和理解。

　　通常一次迭代會由一系列任務組成，而每一個任務的進展都可以看作是一次更短周期的迭代過程，如圖3所示。需要強調的是，其中的分析設計與實現以及測試和執行都是圍繞模型展開的。

• 可工作的軟件

　　模型可執行性決定了設計、開發出來的軟件是天生可執行起來的，而是否正確工作則完全可以通過模型的仿真進行驗證，模型驅動開發的原則之一就是以可工作的軟件作為核心和評估標準。

• 響應變化

　　我們從不同層面不同角度對系統進行建模，建立起模型之間的關聯，在系統發生變更時，可以便捷地發現變更所造成的影響，同時通過模型的仿真與驗證快速驗證我們的改動，從而快速地響應變化。

• 測試驅動

　　模型驅動的測試是部署在整個軟件開發生命周期的，從系統需求的捕獲階段、系統設計到各個測試階段，都可以通過執行模型來進行驗證。

• 持續集成、持續構建、持續測試

　　通過工具軟件，我們可以很方便地進行持續集成、持續構建，而模型既可作為開發建模的輸出，又可作為測試用例的輸入來源，測試的進行也同樣可以依賴于工具自動進行。

• 團隊協作

　　整個開發團隊是以需求為核心、以模型為活動方式展開的。UML模型可以適應不同規模、不同復雜程度的系統，從而使得圍繞在模型驅動周圍的開發團隊也同樣可以適應不同的團隊規模。所有開發活動都可以圍繞著模型構架進行，模型構架的層次性使開發團隊的分工和合作變得簡單。

　　結束語

　　模型驅動開發是一種新的軟件開發方法，它結合了RUP和Agile開發的優點，借助強有力的工具支持，可以良好地實施多種最佳實踐。

　　需要強調的是，模型驅動開發不是萬能良藥，企業和開發團隊在實施的過程中，應當根據自身情況以及項目需要，進行量體裁衣。而且由于是基于模型的開發，使我們在學習和適應模型上需要時間的投入，在實踐的初期很可能效率上反而不如原有模式。這時就需要一點點堅持和投入的決心。

　　完全有理由相信，模型驅動開發將是推動軟件開發向前邁進的強有力支撐。也希望越來越多的行業人員能夠了解、熟悉并對其加以實施推廣，模型驅動開發的道路將越走越廣！

　　作者簡介：姚冬，北京郵電大學軟件工程在職研究生。現就職于某知名跨國企業，關注復雜系統開發，以及軟件過程改進等方面的研究。擁有12年的系統軟件開發和軟件工程實踐經歷。

　　參考文獻
　　《統一軟件開發過程》（美）Ivar Jacobson, Grady Booch, James Rumbaugh等著，周伯生, 馬學民, 樊東平等譯, 機械工業出版社 ISBN 7-111-07572-2/TP.1200

　　文章點評：

　　首先，我并不認為模型驅動開發已經成為流行的開發模式，這一構想在方法學上仍有很多難于實施的地方。其次， 我并不認為建模語言比編程語言表述更準確， 編程語言有其嚴密而精確的正確性論證， 但即使如此，一個再高明的開發者也會寫出不可理喻的錯誤代碼，這對建模語言所謂的“精確性”是同樣的挑戰。最后，僅從本文的探索來說，我認為作者的某些不嚴謹的陳述仍顯出矛盾的核心，即：項目全程建模的結果與工程實施的目標分別是模型與產品，二者仍然有相當遠的距離。這即是說，即使模型與代碼之間的轉換成本為零（當然，目前這仍然是夢想），那么轉換的結果仍然不是產品。進而說，MDD并不是產品開發的解決之道。以如上，嘗作一家之言。然而作者在本文中的嘗試，仍然可以為工程界新辟思路，即：在新的理論面前，舊的方法究竟是主動去融合他們，還是守住理論上的嚴密、謹慎求變呢？這是我對閱讀本文的一點建議。