MDA 和當今的系統

有效的企業軟件開發

今天開發企業級的應用要求一種軟件架構的方法，這種方法應該能夠以一種靈活的方式幫助架構師來發展他們的架構。這種方法應該允許在及時的實現業務功能的新的能力的情況下重用已有的勞動成果，甚至是當目標基礎架構本身在一直的演進。兩個重要的思想現在被認為是應對這種挑戰的中心：

• 面向服務的體系架構(SOA)。企業解決方案能夠被視作通過良好的說明定義了他們的服務接口契約連接的服務聯合。結果的系統設計通常被稱作面向服務的體系架構（SOAs）。 ³ 通過將一個系統組織成為被封裝好的服務集合，這些服務可以通過他們定義的服務接口被操作，系統的靈活性被大大的增強了�，F在很多組織用一系列的服務和服務之間的相互連接表示他們的解決方案。
• 軟件的產品線。通常，在一個組織開發和維護的系統中，存在著大量的可公用的部分。從捕獲核心業務過程和領域概念的標準領域模型，到開發人員在代碼中使用的實現設計的實現細節方案，我們在企業的軟件項目的每一個級別上看到了重用的方法。當模式能夠被經驗豐富的從業者開發出來并在跨越組織的范圍內傳播時，軟件開發組織將獲得大量的效率。這表現了一種朝著促進計劃的資產重用，增加自動化的級別來實現被開發系統大部分的方案的軟件產品線開發視圖的遷移。 ⁴ 更加普遍的情況下，我們能夠將在開發的產品線視圖中定義良好模式的應用理解成為一種從一個抽象級別到一個更底層抽象級別的方案轉化描述的方法。

這兩種思想對對象管理組織（OMG）的思想有著重大意義的影響，一個開發和支持規范以改進企業軟件開發和部署實踐的軟件組織聯盟（在下一個部分 OMG 將扮演更重要的角色）。OMG 已經創建了一個概念性的框架 ⁵ ，這個概念性的框架將平臺選擇與獨立的面向業務的決定分離開來以使在架構和演進這些系統時允許更大的靈活性。這個概念性框架和幫助實現它的標準就是 OMG 稱為的"模型驅動的體系架構（MDA）."。 ⁶ 應用的架構師使用 MDA 框架作為表示他們企業架構的藍圖，并且使用在 MDA 中的開發標準作為他們獨立于供應商和技術的"未來的證明 "。

OMG 的 MDA 的概念通過 OMG 的構建模型的標準對系統的交互性提供了一種開放的、供應商中立的方法：統一建模語言（UML），Meta-Object Facility (MOF)， XML Metadata Interchange (XMI) 和 Common Warehouse Meta-model (CWM) 。企業應用的描述能夠使用這些建模標準被建立并被轉化到一種主流的開發的或者是私有的平臺上，包括 CORBA ，J2EE ，.NET 和基于 Web 的平臺。

在我們開始深入的了解 MDA 之前，讓我們考慮一下在軟件開發中進行建模的基本概念和好處。

建模的基本原理

模型提供了一個物理系統的抽象，模型可以讓工程師們通過忽略無關的細節而把注意力放到系統的重要部分來思考系統。工程中的所有工作形式都依賴模型來理解復雜的、真實世界的系統。模型被用在很多的方面：預期系統的質量，當系統的某些方面變化時推理特定的屬性，和為各種涉眾溝通關鍵的系統特征。模型也可以作為實現物理系統的先驅被開發，或者模型可以根據一個已存在的系統或者開發中的系統被產生作為理解系統行為的幫助手段。

系統和模型轉換

因為一個系統的很多方面也許都是讓人感興趣的，你可以及時的根據系統相關的部分在任何點上使用各種不同的建模概念和符號來突出一個或者多個特定透視圖或者視圖。此外，在一些情況下，你可以使用提示或者規則來添加一些模型，這可以幫助你將模型從一種表示法轉換成為另一種表示法。通常在相同的抽象級別上轉換到系統的不同視圖是必要的（例如，從架構視圖到行為視圖的轉換），并且模型的轉換將使它更加容易。在其他的情況下，模型之間的轉換是在一個特定的方面上進行的，這種轉換是從一個抽象級別到另一個抽象級別，這往往是通過按照轉換的規則添加更多的細節從更加高的抽象視圖到低的抽象視圖進行的。

模型、建模和 MDA

模型和模型驅動的軟件開發是 MDA 方法的核心。因此，為了更好的理解 MDA ，我們應該首先來了解一下企業應用開發人員是如何利用建模的。

追溯到程序設計的最早的日子，在軟件工程的世界里，建模有著悠久的傳統。多數近期的革新都是關注于符號和工具的，這些工具允許用戶非常容易的映射到在特定的操作系統上能夠被編譯的編程語言代碼的方式來表示對軟件的架構師和開發人員有價值的系統透視圖。這些實踐的當前情況是使用統一建模語言（UML）作為首選的建模符號。UML 允許開發團隊在相應的模型中獲取一個系統的各方面的重要特征。這些模型之間的轉換主要是手工進行的。UML 建模工具典型的支持需求的跟蹤和模型元素之間的依賴關系，通過支持文檔和補充的咨詢信息提供如何作為大范圍開發工作的一部分來維護同步模型的最佳實踐的指導。

一個有用的刻畫當前實踐特色的方法是看一下用于同步模型和源代碼的不同的方法。這在圖 1 中被列舉 ⁷ 圖 1 顯示了今天軟件從業者使用的建模方法的光譜。每一個類型代表了一種獨特的幫助軟件從業者創建能夠運行在特定運行時平臺上的應用（代碼）和模型與代碼之間的關系的模型的使用。 ⁸

圖 1: 建模的光譜

今天，多數的軟件開發人員仍然在使用 單獨－代碼的方法（在建模光譜的左端，圖 1）并且根本沒有分離的定義模型。他們幾乎完全的依靠他們編寫的代碼，并且他們直接在一種集成的開發環境（IDE）中（比如，IBM WebSphere Studio ， Eclipse 或者 Microsoft VisualStudio ⁹ ）通過第三代的編程語言如 Java 、C++ 或者 C# 直接的表示他們正在建立的系統的模型。他們所做的任何"建模"都是以嵌入在代碼中的編程的抽象形式進行的（比如，包、模塊和接口等等），這些方式是通過程序庫和對象層次的機制進行管理的。任何分離的體系架構的設計模型都是不正規的和依靠直覺的，并且存在于白板上、PowerPoint 幻燈片上或者開發人員的腦袋中。然而這種方法對于個體開發者和小的開發團隊也許是足夠的，但是這種方法使在業務邏輯實現的細節中理解系統的關鍵特性十分的困難。此外，隨著系統的范圍和復雜度的增加，系統的演進或者在原來的設計團隊成員不能直接的與維護系統的團隊溝通時，這種方法對于管理這些方案的演進將是更加困難的。

一個改進是在一些適當的建模符號中提供了 代碼可視化。當開發人員創建或者分析一個應用時，他們通常希望通過一些輔助理解代碼的結構或者行為的圖形化符號來可視化代碼。作為一種編輯基于文本代碼的可選方式利用圖形化的符號也是可能的， 所以可視化的描寫變成了一種代碼的直接表示。這種描寫有時稱作代碼模型，或者實現模型。在允許這種畫圖的工具中（比如，IBM WebSphere Studio 和 Borland Together/J），代碼的視圖和模型的視圖可以被同時顯示；當開發人員對其中的一個進行操作時，另一個視圖也將立即進行同步。在這種方法中，圖與代碼表示緊緊的聯系在一起，并提供了在代碼級別上觀看和編輯的可選方法。

建模的更深層次的利益是通過 雙向工程（RTE）得到的，雙向工程提供了一種在描述系統的架構或者設計和代碼的模型之間進行雙向交換的機制。典型的情況下，開發人員將系統設計細化到一定的詳細級別，然后通過應用模型－代碼的轉換創建第一輪的實現，這通常是手工完成的。例如，一個工作在高級別設計的團隊也許會向工作在實現級別上的團隊提供設計模型（也許是通過簡單的打印出模型圖或者為實現團隊提供包含模型的文件）。實現團隊轉換這個抽象、高級別的設計成為詳細的設計模型的集合和編程語言的實現。其中表示上的重復將作為錯誤出現，這些錯誤既可以在設計模型中更正也可以在實現模型中更正。因此，如果沒有良好的紀律，抽象模型和實現模型常常 — 并很快 — 的因為步調不一致而結束。

工具能夠自動化的進行最初的轉換，也可以在設計模型和實現模型進行演進時幫助他們保持步調一致。典型的，工具可以從用戶必須進一步細化的設計模型生成代碼的框架。 ¹⁰ 對代碼的更改必須要在一些點上與原有的模型相一致（也就是術語"雙向工程"或者 RTE）。為了實現這一點，你需要一種方法來識別出被產生的用戶定義的代碼；在代碼中放置標記就是一種方法。實現這個方法的工具，比如 IBM Rational Rose 能夠支持在模型與不同實現語言之間雙向提供多種轉換服務。

在一種 以模型為中心的方法中，系統模型具有足夠的細節能夠從這些模型中生成整個系統的實現。為了實現這一點，模型也許應該包括，比如持久數據和非持久數據、業務邏輯和表示層元素的表示法。如果存在任何與遺留數據和服務的集成，對那些元素的接口也需要被建模。然后代碼生成過程應用一系列的模式將模型轉換成代碼，通常允許開發人員對被應用的模式進行一些選擇（比如，選擇各種不同的部署拓撲）。這種方法常常使用標準的或者私有的應用框架和運行時服務，這些應用框架和運行時服務能夠通過限制被生成應用的類型使代碼生成任務更加容易。因此，使用這種方法的工具典型的專攻于特定應用類型的生成（例如，用于實時嵌入式系統的 IBM Rational Rose Technical Developer 和用于企業 IT 系統的 IBM Rational Rapid developer）。然而，在所有的情況下，模型都是被開發人員創建和操作的主要產物。

一個 單獨模型的方法在圖 1 中的編碼/建模光譜的最右端。在這種方法中開發人員把模型純粹的作為理解業務或者方案領域，或者分析被提議的方案架構的輔助手段。模型通常被作為討論、交流和在一個單獨的組織或者是跨多個組織的項目中進行分析的基礎來使用。這些模型常常出現在新工作的建議中，或者裝飾在辦公室的墻上和在軟件實驗室中作為一種促進對一些復雜領域理解的方法并建立一個共享的在完全不同的團隊中的詞匯表和概念集。實際上，一個系統的實現，不論是從打草稿開始還是作為一個已有方案的更新，都可以從模型中分離出來。一個有趣的例子是越來越多的組織將他們的系統的實現和維護進行外包，而他們自己維護整個的企業架構的控制。

MDA：成長中的公認輿論

建模已經在軟件工程中起到了較大的影響，并且它對于每一個企業級方案的成功都是至關重要的。然而，在模型的表示和如何使用上有著很大的多樣性。一個有意思的問題是：這些方法中的哪一種我們能夠描述為"模型驅動呢"？如果我創建一個系統的某些部分的可視化表示，這能意味著我正在實踐 MDA 嗎？不幸的是，沒有一個確定的答案。然而，存在著一種正在成長的輿論認為 MDA 是最貼近于從更加抽象的模型自動的產生代碼，并且使用標準的說明語言來描述那些模型的方法。我們在接下來的部分探究這個概念。

MDA 的理論

對于 MDA 是什么和不是什么有著很多中觀點和意見，最權威的觀點是被對象管理組織（OMG）提供的，一個擁有超過 800 家公司、組織和個人的軟件行業聯盟。為什么 OMG 關于 MDA 的觀點是如此的重要呢？作為一個新興的體系架構的標準，MDA 屬于 OMG 支持的悠久傳統和過去二十年中的眾多計算機標準。 OMG 一直負責一些對于系統的說明和互操作性方面的工業上知名的和最具影響力的規范的開發，包括公共對象請求代理體系架構（CORBA），OMG 接口定義語言（IDL），Inte.net Inter-ORB Protocol (IIOP)，統一建模語言（UML），Meta Object Facility (MOF)， XML Metadata Interchange (XMI)， Common Warehouse Model (CWM) 和 Object Management Architecture (OMA)。此外，OMG 也增強了這些規范來支持特定行業，比如衛生保健業、制造業、電信業和其他的行業。

OMG 已經重新關注它的策略、標準和定位來支持 MDA 方法。OMG 正在將 MDA 作為一種開發更加準確的滿足客戶需要并且在系統的演進中具有更好靈活性的系統方法來促進它的發展。MDA 方法構建在較早期的系統規范標準的工作上，并且為定義相互連接的系統提供一種全面的具有互操作能力的框架。

MDA 原則

OMG 組織對于 MDA 的觀點下有四個原則：

• 以一中定義良好的符號表示的模型是理解企業級方案系統的基礎。
• 系統的構建能夠圍繞著一系列模型通過使用在模型之間的一系列轉換被組織的，并且能被組織到一個分層的和轉換的體系架構框架中。
• 以一系列元模型來描述模型的一種正式的支持能夠使在模型中有意義的集成和轉換變得容易，并且是通過工具實現自動化的基礎。
• 接受和廣泛采納基于模型的方法需要工業的標準提供開放性給客戶，并鼓勵供應商之間的競爭。

為了支持這些原則，OMG 已經定義了一系列的層次和轉換，他們為 MDA 提供了概念性的框架和詞匯表。特別的，OMG 確定了四種模型類型：計算無關的模型（CIM），平臺無關的模型（PIM），被一個平臺模型（PM）描述的平臺相關的模型（PSM）和一個實現相關的模型（ISM）。

對于 MDA 來說，“平臺”僅僅是相對特定的視圖觀點有意義的 --換句話說，一個人的 PIM 可以是另一人的 PSM 。例如，如果一個模型沒有 規定一種特定的中間件技術的選擇，那這個模型對于通訊中間件來說就是一個 PIM 。然而，當一個使用特定的中間件（比如CORBA）被決定使用時，這個模型就被轉化成了一個 CORBA 相關的 PSM 。新的模型在 ORB 的選擇上也許仍然是一個 PIM -- 在目標操作系統和硬件的方面這個模型也是一個 PIM 。如圖 2 所示。

圖 2: PIM 到 PSM 轉化的例子

作為結果，一個 MDA 工具也許通過幾個步驟支持轉化一個模型，從最初的分析模型到可執行的代碼。例如，IBM Rational XDE 的模式工具就支持這種多種轉換的開發。相比之下，一個工具（比如，IBM Rational Rose Technical Developer）能夠僅用一個步驟就將模型從 UML 轉化成可執行的代碼。

MDA 的從業者認可轉換能夠被應用到一個系統的各個方面的抽象描述以添加細節，使描述更加準確，或者在表示法之間進行轉換。不同類型模型之間的區別允許我們將軟件和系統開發想象成為一系列在不同模型表示法之間的細化。對于包括了在表示系統不同方面的模型之間的細化，對一個模型的細節的添加，或者在不同的模型類型之間的轉換的情況下，這些模型和他們的細化是開發方法的重要組成部分。

這里是關于模型的抽象本質和模型所表達的詳細實現的三種重要思想：

• 模型分類。我們能夠通過如何表示目標平臺的各個方面的術語對軟件和系統模型進行分類。在所有的軟件和系統開發中都存在著通過語言、硬件、網絡拓撲、通訊協議和底層架構等選擇所帶來的重要約束。這些約束的每一個能夠被作為一個方案"平臺."的元素被考慮。MDA 的方法幫助我們關注在被設計方法的業務方面的本質上，而不是在 "平臺."相關的細節上。
• 平臺無關。"平臺"的概念是相當復雜和高度依賴環境的。例如，在一些情況下，平臺也許是操作系統和相關的工具；在一些情況下，它也許是被良好定義的編程模型所代表的技術架構，比如 J2EE 或者 .Net ；在其他的情況下，它也許是一個特定的硬件拓撲的實例。在任何情況下，考慮根據不同抽象級別的模型被用于不同的目的，而不是將注意力分散到定義"平臺."上是更加重要的。
• 模型的轉換和細化。通過將軟件和系統開發想象成為一系列的模型細化，模型之間的轉換變成了開發過程中的第一類元素。這是重要的，因為大量的工作任務發生在定義這些轉換上，這通常需要特殊的業務領域的知識和用來實現的技術等等。我們能夠通過明確的獲取這些轉換和跨方案的重用它們來改進系統的效率和質量。如果不同的抽象模型被良好的定義，我們能夠使用標準的轉換。例如，在以 UML 表示的設計模型和以 J2EE 表示的實現模型之間，我們能夠使用良好理解的能夠被應用、驗證和自動化的 UML 到 J2EE 的轉換模式。

在這些模型表示法和支持的轉換之下是一系列的元模型。分析、自動化和轉換模型的能力需要一個清晰、明確的方法來描述模型的語義。因此，對于一個建模方法模型的本質本身也必須能夠以模型來表示，我們稱這種模型為元模型。例如，UML 的標準語義和符號就是用元模型描述的，工具的提供商以一種標準的方法使用元模型來實現 UML 。UML 元模型精確的描述了類、屬性和這兩個概念之間的關系的細節。

OMG 認可對于建模來說元模型和正規語義的重要性，，并且還定義了一系列元建模級別和用于表示元模型的標準語言：Meta Object Facility （MOF）。元模型使用 MOF 正式的定義一系列建模構想的抽象語法。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: MDA 系統