MDA 如何影響迭代開發過程

模型驅動體系架構介紹

第三部分：MDA 如何影響迭代開發過程

Alan W. Brown, 杰出工程師, IBM Rational
Jim Conallen, IP 開發, IBM Rational

2005 年 8 月 01 日

本文來自于 Rational Edge：作為迭代開發框架，Rational Unified Process 或稱為 RUP，足夠靈活地適應多種項目管理方式。隨著基于 RUP 的團隊開始采用模型驅動體系架構（model-driven architecture，MDA）策略，為成功地采用 MDA，他們需要了解 RUP 中的哪些任務、工件和階段需要特別關注。

使用模型驅動體系架構（MDA）方法建立解決方案需要改變開發過程。雖然我們的經驗是許多當前關于企業軟件開發的最佳實踐仍舊適用，但是解決開發過程的模型驅動方法要求對這些實踐進行一些重要的變更。

在本文（關于 MDA 系列文章的第三部分，也就是最后一個部分）中，我們將探究那些變更以及 MDA 在現代軟件開發環境中的應用。在本系列的第一部分中，我們討論了如何將建模應用到當今的行業中，以及 MDA 與現今系統的相關性。在第二部分中，我們用這種設計并使用 IBM 的 MDA 工具包的觀點來檢驗模型驅動開發的方法。當我們從開發過程的角度來結束本系列文章的時候，我們將分析一個眾所周知的開發過程，即 Rational Unified Process 或稱為 RUP，并考慮在 MDA 項目上說明并執行過程的方式。

RUP 概述
Rational Unified Process 是當今使用中的實際標準的軟件工程過程。¹RUP 的目標是確保能夠按時并在預算之內生成能夠可預見地滿足最終用戶需求的高質量軟件。RUP 為在開發組織內分配任務和職責提供規程式的方法，并已經應用到許多項目中，這些項目有各種大小和復雜度，開發團隊有大有小，且開發時間有延續幾周的，也有延續幾年的。

圖 1 以二維的形式說明 RUP 的整個體系架構。水平軸代表時間并顯示了過程生命周期的各個方面。生命周期階段的管理視圖在頂部，迭代的軟件工程和項目管理視圖在底部。垂直軸代表按照邏輯分組的規程，表示過程的靜態方面 —— 如何用過程部件、規程、活動、工作流，工件和任務來描述 RUP。

圖 1. 規程、階段和迭代的 RUP 概念

在基于 RUP 項目的任何時間點，都會有按照多種規程發生的活動。區別不同生命周期階段的東西不是缺少某些規程，而是不同規程在整個工作流中所做出貢獻的相對量?；顒拥幕旌蠒S著項目的重點和優先權的變更而隨時變化。例如，在早期的迭代中，您將更多時間花費在需求上，而在晚期的迭代中，您將更多的時間花費在實現上。

RUP 階段和迭代
從管理觀點出發，RUP 軟件生命周期包括四個順序的階段，每個階段都以一個主要的里程碑結束。進行評估以確定是否達到階段的目標。令人滿意的評估結果可以使項目向下一個階段進行。簡要地說，RUP 生命周期的階段是：

• 初始：初始階段的目標是在所有涉眾之間達成關于項目的生命周期目標的協議。具有代表性的是，在項目進行之前必須確定重要的業務和需求風險。對于那些少量增強現有系統的項目來說，初始階段是簡短的，但仍舊著重于確保項目即值得做又可能實現。生命周期目標里程碑是初始階段的主要出口標準。它估計了項目的基本生存能力。
  
  
• 細化：細化階段的目標是為系統體系架構設定基礎，用來為構建階段的大多數設計和實現工作提供穩定的基礎。細化階段會描繪出一個將必要的業務需求結合了技術體系架構的可執行的系統，并論證所選技術方法的生存能力。該體系架構進化了對最重要的需求（哪些需求對系統的體系架構有很大的影響）的考慮和對風險的評估。生命周期體系架構里程碑為系統的體系架構建立了一個受控的基線，并令項目團隊在構構建段進行測量。
  
  
• 構建：構建階段的目標是澄清剩余的需求并完成基于基本體系架構的系統的開發。構建階段在某種意義上說是一個制造過程，在此階段要強調對資源的管理和對操作的控制，用來優化成本、進度和質量。在這個意義上說，管理團隊經歷著一個從初始和細化階段的知識產權的開發到構建和產品化階段的可部署產品的開發的變遷。初始的操作能力里程碑確定是否可以將產品部署到用戶能夠接受的環境中。
  
  
• 產品化：產品化階段的重點是確保軟件對最終用戶是可用的。產品化階段可以跨越若干次迭代，該階段包括為發布而進行的產品測試，以及根據用戶反饋做出較小調整。在生命周期的這個階段，用戶的反饋應主要用于對產品進行微調、配置、安裝和解決可用性問題，在項目生命周期的更早期就應該解決所有的主要結構問題。產品版本里程碑是一個您需要在此決定項目是否達到目標，及您是否應該開始另一個開發循環的位置。從軟件工程和項目管理的觀點出發，隨著迭代的進行，事情會逐日的發生。階段由若干迭代組成 —— 依照基本計劃和評價標準的不同序列的活動會致使工件的發布（內部或外部的）。生命周期的每個階段都由一系列迭代組成，迭代的特性根據您所在的生命周期的位置不同而不同。

RUP 和 MDA
目前，RUP 沒有提供對如何將軟件開發的 MDA 式樣整合到整個過程中的具體指導。這不奇怪，RUP 反映當前行業的最佳實踐，且只有在領域內很好地確定之后才能編制方法。MDA 是一個新興的方法，應用到 RUP 項目中重要的 MDA 最佳實踐僅到現在才變得可以得到。

然而從我們的經驗中可以得來許多重要的方式，我們可以以這些方式用 MDA 項目的最佳實踐來增強 RUP。特別是，RUP 的靈魂，即以體系架構為中心的迭代的開發過程，與 MDA 概念保持高度一致，并為在 MDA 方面取得成功提供極好的基礎。

然而，存在著一些領域對 MDA 提供額外的適當指導。在此，我們考慮許多重要的關于將 RUP 應用到 MDA 項目中的重要方面。

• MDA 項目所影響的主要階段是細化階段。觀察細化階段的活動并簡要地描述 MDA 改進是很重要的。
  
  
• 架構師是細化階段的主要角色，需要對其進行額外的考慮。隨著“架構師”的專業化，許多 MDA 項目都需要 MDA 架構師角色。從本質上說，該角色規定了具體的 MDA 活動和工件，創建轉換等。因此，出自該角色的主要 MDA 工件是映射文檔、轉換和 UML profile 文件。
  
  
• MDA 如與模型驅動自動化一樣與模型驅動體系架構有關。這提供了某種關于如何觀察 MDA 和 RUP 的指導。有代表性的是，MDA 自動操作 RUP 中的活動。MDA 利用針對支持將許多主要 RUP 活動自動化的額外工作來擴充 RUP 活動，而不是改變它們。
  
  
• MDA 的應用涉及許多 RUP 任務，但它們不需要額外的活動。相反地，每個任務中的標準活動將要求加入關于那些活動如何利用所選的具體工具和 MDA 技術來實現自動化的細節。在 RUP 中，我們稱這些額外的細節為 RUP Tool 指導。例如，一個進行關于對象的數據映射的團隊可能會利用建模工具進行一組 MDA 轉換。但在高級別上，他們關于“定義設計類”的工作流會基本上保持不變。
  
  
• 更深入的是，對 RUP 的主要變更包含對開發過程的視圖的更微秒的改變。MDA 促使架構師和開發人員在比非 MDA 項目中期望的更高的抽象級別上工作。這在構建階段是最明顯的，在此階段，MDA 的代碼自動化方面較大地改變了實現工作的重點。開發人員能夠在對 MDA 轉換進行輸入時繼續進行更抽象的分析并設計模型。他們發現他們更少地處理實際的實現模型和源代碼，而更多地進行針對解決方案的適當的著重于業務的工作流的設計。會有更少的開發人員實現模型到代碼的轉換。
  
  
• MDA 轉換常常形成于預先建立的解決方案框架（也稱為“參考體系架構”或“應用程序框架”）周圍。MDA 轉換用具體領域的業務邏輯擴充這些框架。這種將 MDA 和解決方案框架結合的方法具有很大的意義，因為完整的 MDA 方法是作為自動化一組可重復技術和資產的中心。然而，它更進一步地使開發過程更著重于重用、管理資產和增加了的解決方案的交付。

使用 MDA 定制解決方案框架
當今的企業軟件系統很少是（如果有的話）在集成開發環境（IDE）中從零開始，一行行地被開發出來的。相反，它們是通過用具體領域的業務邏輯來擴展現有解決方案框架，通過連接（并利用）來自不同源頭的信息，并通過設計豐富環境的用戶顯示和迭代服務創建而成的。因此，隨后的開發方法不是典型的“瀑布”方案，在瀑布方案中，收集需求之后進行分析和設計，并進行系統的實現。相反，此種開發方法是連續地擴展并細化現有的部分解決方案，通過一組迭代向解決方案中添加值來達到所期望的目標。

這些形成了新系統核心的部分解決方案可能出自以下幾個來源之一：

1. 一組現有的應用程序。主要的途徑是拿到一個現有的解決方案并按照業務需求的指示以有效的方式進行擴展。因此，大量設計工作會涉及對那些現有應用程序如何構建，以及在不損害現有應用程序質量的情況下將有意義的擴展添加到何處的理解。在多數情況下，原有的應用程序并不是以重用為目的而設計的，這一事實使得過程變得復雜。
   
   
2. 組織所使用的專有應用程序框架。在建立了許多種特殊領域內的相似解決方案之后，一些組織就萃取出核心的應用程序功能作為可重用的專有服務在未來的解決方案中使用。這些服務幫助提高共享公共特性的一系列系統的生產率，并增加未來系統開發的可預測性。舉個例子 Accenture 的 General Reusable Netcentric Delivery Solution (GRNDS) 框架²。
   
   
3. 已獲得的應用程序框架，不管是開源的還是商業的。識別一致的體系架構模式（用于設計某些種類的應用程序）已經使得許多技術幫助組織創建符合這些模式的解決方案。結果的應用程序框架可以用作商業產品，也可以用到開源團體中，且可作為獨立框架，或與工具綁定來幫助創建、管理及擴展那些框架。例子包括用來創建某些種類的 n 層 J2EE 解決方案的 Struts 及 JSF 框架。
   
   
4. 一組對封裝的應用程序的擴展和定制。許多組織從封裝的應用程序的供應商那里得到了對于關鍵業務過程的綜合解決方案。然而，組織需要使那些解決方案滿足他們的需要。所以，封裝的應用程序的供應商 1) 構造他們的解決方案以支持不同種類的擴展和定制，2) 提供定義明確的 API 以訪問封裝的應用程序的內部，或者 3) 用詳細設計文檔、擴展實例和具體包裝的工具擴充封裝的應用程序。

倘若這些都是可能的，許多 IT 項目管理人所面對的主要任務是生成對領域的清晰理解，在獨立于平臺的領域模型（其支持各種類型的分析以確保正確性和一致性）中表達那種理解，并且將那種領域模型映射到一個具體平臺上，通過擴展解決方案框架進行實現。模型到模型的轉換幫助細化領域，而模型到代碼的轉換將領域模型映射到具體的解決方案框架上。

在模型到代碼的轉換中，解決方案框架起到了關鍵作用，因為它約束并指導那些類型的有意義的轉換。例如，如果您正在使用基于 Struts 的應用程序框架，那么正在創建的應用程序就具有容易理解的結構，包括可以實現業務邏輯的眾所周知的擴展點。您可以根據該知識創建一組轉換。甚至，您可以創建向導驅動的工具來將那些用于包含適當類型信息的領域模型的轉換的創建自動化。這就是方法，例如，以這種方法，工具（如 IBM Rational Application Developer）使用聚焦領域的可視化設計工具來自動生成基于 Struts 或 Java ServerFaces（JSF）的應用程序框架的代碼。更一般的是，通過將解決方案框架作為系統的基礎，撰寫模型到代碼的轉換工作就特別簡單了，并且我們獲得了結果解決方案的更大的效率、可預測性、重復性和易管理性。

總之，我們再次重申，創建軟件很少從零開始，并且模型轉換（到另一個模型或代碼）可以幫助利用現有的解決方案框架。隨著這種建立在現有軟件上的方法不斷提升，通過幫助我們將擴展并定制那些框架的方法自動化來提升 MDA 的作用和價值。一些人將這種“定制自動化”視為創建不斷復雜的系統的唯一可行的選擇，并利用我們部署的組件和技術來回應施加給我們的約束。

總結及未來方向
軟件和系統開發的模型驅動方法已經使用了一段時間了。最近，關注的焦點集中在如何增大基于 OMG 的 MDA 方法的模型驅動技術的自動化。MDA 技術可以使組織為模型到模型和模型到代碼的轉換構建自定義自動化。利用這些轉換，技術專家可以在大型開發團隊中分享他們的專家經驗。特別地，MDA 提供許多優于其他方法的益處：

• 通過促使將大部分開發人員與他們不需要考慮的技術細節進行分離來執行他們所設計的滿足業務需求的企業解決方案的任務來增長開發的生產率。更多時間花在他們手頭的工作上：實現系統的業務功能。
  
  
• MDA 通過支持已知的行為模式的復用來提高質量，建立在現有的體系架構設計之上，并更有效地利用專家經驗。自動化的使用也促進一致性并改進系統設計和實現的質量，特別是解決方案在維護和升級過程的演進中。
  
  
• MDA 的可重復的實踐集是適合當今迭代開的發需求的，因為 MDA 提高了開發過程和要交付的解決方案本身的可預見性。自動化的使用加快了開發，特別是當開發人員的許多任務是重復且麻煩的時候。

在本系列文章中，我們已經探究了實現基于我們通常所使用的建模技術的 MDA 方法的許多實際的方面，以及對具體的 MDA Toolkit for IBM Rational XDE for Java 的設計和使用。這些經驗表明，雖然傳統的設計和實現實踐與 MDA 項目有關，但是仍舊存在額外的需求需要滿足以確保方法是最佳應用的。我們已經描述了許多這樣的需求并用實際例子進行了說明。

在第 2 部分中，我們將我們的重要發現分為對 MDA 實際應用的 12 個經驗。然而，這些經驗不是具體針對一組專一的技術。它們還可以應用于其他的 IBM Rational 工具中。根據我們對現有技術和實踐的經驗，包括那些在此敘述的，來自 IBM Rational 的最新一組解決方案通過提供我們認為必要的功能來支持 MDA 開發項目。因此，IBM Rational 工具為所有類型的自動化提供了一組豐富的功能，包括預定義的轉換和用于定制轉換的工具。³支持 MDA 的最新實例出現在 IBM Rational Software Architect 產品中。這是一個大范圍的工作平臺，它可以用來設計并構建支持企業系統的分析、設計和實現的各個方面的服務，包括復雜模型的編制及支持 UML 可視化建模的管理功能。具體到 MDA 項目，IBM Rational Software Architect 產品含有一個靈活的定制模式編寫環境，并支持以許多方式編制模型到模型和模型到代碼的轉換（根據預定義式樣和設計目的）：

• 普通插件（使用 Eclipse 插件開發環境）
  
  
• Pluglet（小型的，簡單的自動安裝助手，可以進行快速的一次性自動作業）
  
  
• 轉換（用來構造大型復雜的轉換的基于規則的框架）

對這些技術的支持是一組幫助組織采用模型驅動方法的最佳實踐。與 IBM Rational Software Architect 整合到一起的產品利用基于 RUP 的技術來指導具體環境的開發過程。此外，可以用具體項目的額外實踐和來自在線資源（如 IBM developerWorks）的可重用資產來擴充此指導。⁴

致謝
本文中提到的工作已經由許多人加以貫徹，并且我們很高興對他們的貢獻表示感謝。此處討論的想法反映出 IBM 中一個很大團隊（包括 Grady Booch、Gary Cernosek、Jim Conallen、Pete Eeles、Sridhar Iyengar、Simon Johnston、Grant Larsen、Martin Nally、Jim Rumbaugh 和 Bran Selic）的思想。我們還要感謝 Mike Perrow 對本文進行有幫助地審閱。

參考資料
您可以參閱本文在 developerWorks 全球站點上的 英文原文。

[1] J. Rumbaugh，G. Booch，I. Jacobsen，“The Unified Modeling Language Reference Manual，”Second Edition，Addison-Wesley，2004。

[2] P. Kruchten，“The Rational Unified Process: An Introduction，”Addison-Wesley，1998。

[3] P. Kroll and P. Kruchten，“The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP，”Addison-Wesley，2004。

[4] Evans Data Corp.，“North American Development Survey: Volume 1, "Response to question on "Use of UML in Application Design，”Fall 2003。

[5] Codagen，www.codagen.com。

[6] ArcStyler，www.arcstyler.com。

[7] AndroMDA，www.andromda.org。

[8] openMDX，www.openmdx.org。

注釋
¹例如參見 P. Kruchten，“The Rational Unified Process: An Introduction，” Addison-Wesley，1998。

²參見 http://www.accenture.com/xd/xd.asp?it=enweb&xd=services%5Ctechnical%5Ccapabilities%5Cgrnds.xml

³要了解更多細節，請參見 http://www.ibm.com/rational/mda。

⁴要了解更多細節，請參見 http://www.ibm.com/developerworks/cn/rational。

作者簡介 Alan Brown 負責 IBM Rational 桌面產品背后的技術策略工作。他還是負責協調 Rational 工具和組成 IBM 軟件開發平臺的 IBM 產品的領導團隊中的關鍵成員。另外，他負責為公司的模型驅動開發工具制定前景和策略。 由于對 IBM Rational 桌面產品的貢獻，以及對軟件行業前途的主要貢獻，他贏得了杰出工程師的頭銜。在超過十年的時間里，Alan 作為行業思想的引導者，通過他的書籍、論文、以及和 IBM Rational 頂級客戶的眾多交流來引導開發人員經驗的發展。要了解更多他的工作和思想，請訪問他的 Web 站點 www.jorvik.com/alanbrown/index.html. 1988 年 Alan Brown 于 Newcastle-upon-Tyne 大學取得博士學位。

Jim Conallen 是 IBM Rational Development Accelerators 小組的軟件工程師，他積極地投身到基于資產的開發和可重用的資產規范（Reusable Asset Specification，RAS）的領域中。Jim 經常在會議中演講，并撰寫文章。他研究的領域有 Web 應用程序開發，在該領域中，他開發了 Web 應用程序向 UML 的擴展（Web Application Extension for UML，WAE），即令開發人員在適當的抽象和具體級別上利用 UML 為基于 Web 的體系架構建模。此項工作作為 Rational Rose 和 XDE Web 建模功能的基礎。 Jim 已經撰寫過書籍 Building Web Applications with UML 的兩個版本，第一版著重于微軟的 Active Server Pages，最近的一版著重于 J2EE 技術。您可以通過 e-mail 聯系他。

原文轉自：http://www.kjueaiud.com