引言
在任何領域中，語義都非常重要，而在面向服務的體系結構（Service-oriented architecture，SOA）中更是如此。由于 SOA 涉及多個團隊和組織，因此就相關術語達成一致至關重要。本系列將帶著您開始 SOA 之旅，為您定義基礎術語和主要概念。您將了解 SOA 領域中所使用的各個詞匯。對于每個術語，將說明其為何對 SOA 重要、其在這種情況下的含義、相關的標準有哪些以及與其他術語的區別如何。
本系列的第 1 部分確定了業務焦點，并通過定義服務 和 SOA 等術語為后續部分打好了基礎。本文將介紹成功 SOA 采用所必需的軟件工程方法和流程，還說明交付 SOA 解決方案所需的構件（如模型和資產）。
開發流程和方法
成功的軟件開發需要以下因素：
需要得到理解和遵循的原則。
進行了正式說明的基于經過驗證的最佳實踐的方法和技術。
可以進行定制的流程。
方法內容
方法內容 描述需要生成什么內容、如何執行相關工作以及由誰執行。
方法內容構件包括：
角色 ：定義技能和工作產品職責。軟件架構師 就是角色的一個例子。
工作產品 ：任務的結果，可以為交付內容，也可以不是交付內容。服務模型 就是工作產品的一個例子。
任務 ：特定角色執行的步驟序列。任務使用輸入工作產品來生成或修改輸出工作產品。標識服務 就是任務的一個例子。
指南 ：文檔說明。術語表、模板、示例 和工具使用指導信息 都是指南。
流程
流程 用于將方法內容組織到開發周期中，并指定要完成的工作的順序。要完成的工作的順序獨立于開發生命周期模型（如瀑布式或迭代）。可以將流程視為工作流或分解結構。通過流程，項目經理可以確定在項目的每個階段需要哪些人員以及修改了哪些工作產品。如果熟悉 Rational Unified Process? (RUP)，則可以將 RUP 規程（如分析與設計實現）視為方法內容，而將 RUP 階段（如細化和構造）視為流程元素。
務必將方法和流程這兩個概念加以區分，并提供框架來支持分別對其進行修改。
Rational Method Composer
IBM Rational? Method Composer (RMC) 是基于 Eclipse 的方法與流程創作平臺，用于集成、定制、代碼化和發布流程。使用方便而且功能強大的 RMC 提供了一組流程，可以方便地加以使用或自定義，如 Rational Unified Process (RUP)。負責維護流程的項目經理、項目管理者以及程序管理員通常會使用 RMC，該工具可為本部分所描述的概念提供支持。
RMC 中進行的工作的輸出是作為 HTML 發布的流程（通常采用網站的形式）。希望遵循該流程的組織可以隨后使用此流程站點。
軟件流程工程元模型
本部分將討論開發流程。軟件流程工程元模型（Software Process Engineering Metamodel，SPEM）是正式描述軟件開發流程的的標準規范。作為 Object Management Group (OMG) 標準，SPEM 是獨立于供應商、方法和框架的。1.1 版于 2005 年 1 月正式發布，而包含重大更新的 2.0 版目前正在制訂中。
Rational Unified Process
Rational Unified Process (RUP) 基于全球數千項目所采用的最佳實踐，是能夠針對具體項目進行方便定制的軟件開發流程。RUP 包括有關優先級權衡、迭代開發、可視建模、軟件質量和團隊協作的主要原則。RUP 定義規程（方法內容）和階段（流程），如圖 1 中所示。
圖 1. Rational Unified Process (RUP)
Rational Unified Process for Service-Oriented Modeling and Architecture
Rational Unified Process for Service-Oriented Modeling and Architecture (RUP Plug-In for SOMA) 構建于 RUP 之上，可提供有關開發面向服務的解決方案的指導。2.4 版（請參見參考資料）提供了組合之前 RUP for SOA 內容和 IBM Global Business Services (GBS) SOMA 方法的統一方法。RUP Plug-In for SOMA 為軟件架構師和設計人員提供了有關面向服務的體系結構的分析、體系結構和設計的具體指導信息。
提供了專用統一建模語言（Unified Modeling Language，UML）概要，用于建模領域特定的解決方案（包括 SOA），并隨之提供了緊密相關的專用流程。例如，有支持 RUP Plug-In for SOMA 的 UML 2.0 profile for Software Services。
注意：將在本系列的后續文章中討論與管理相關的流程。
IBM 技術
如本系列的第 1 部分中所述，組件業務建模（Component Business Modeling，CBM）可幫助組織對策略、技術、操作和投資一致性形成大量新的認識。CBM 支持對形成差別的業務組件進行標識，還支持對業務流程進行分析。
面向服務的建模與體系結構（Service-Oriented Modeling and Architecture，SOMA）提供了有關 SOA 解決方案的分析和設計的指導信息。SOMA 支持對與業務保持一致的服務進行標識、規范化和執行（在設計層）。將在稍后詳細討論此主題。
模型、UML、資產與模式
元數據
元數據即關于數據的數據。例如，關于所錄制的歌曲的元數據可能包括關于演唱者、專輯、作曲、長度或質量的信息，而數據則是音頻記錄本身。
根據上下文不同，相同的數據可能為實際數據，也可能為元數據。以前面討論的開發方法和流程為例。在 RMC 中修改開發方法時，定義要類型化的內容（由元數據提供支持）。例如，可能會定義工作產品、任務和角色的新實例。在此級別，工作產品、任務和角色是元數據元素，元數據還定義這些類型（角色執行的任務）之間的關系。現在考慮設計人員定義有關方法的概念時的情況。假定他們在使用 UML 建模工作產品、角色和任務的概念。在此級別，工作產品、任務和角色是實際的數據，而 UML 是元數據。將稍后在 RMC 中將此數據作為元數據使用。這樣看來，可以將 UML 視為元-元數據！
模型
RUP 將模型定義為系統的抽象表示或模擬，可從特定的角度提供對系統的完整描述。模型經常用于更好地了解系統如何工作，或用于記錄實際實現的設計決策。模型經常由多個不同類型的部分組成。這些部分作為模型元素進行歸類。
模型的目標受眾是能夠理解這些模型的人群。例如，系統分析人員和設計人員創建和使用分析模型，數據庫設計人員設計和查看數據模型。模型可以基于文本和/或圖形。由于建模是在保持嚴密性和完整性的情況下減少復雜性（如在較高的抽象級別進行描述），因此最好使用豐富的圖形設計符號，例如在 RUM 中描述為可視建模 的統一建模語言 (UML)。模型位于特定的抽象級別，可以將其轉換到更低的級別抽象。例如，分析模型通常會轉換為設計模型。
在本系列的第 1 部分中，我們說明了協作 SOA 更為重要。例如，您的公司可能會將詳細設計或實現外包給其他公司。進行建模時，請牢記要將建模結果提供給其他人使用。另外，您的 SOA 設計和開發平臺也應該能夠接受模型，并將其轉換為其他模型。
自動化與轉換
SOA 設計與開發平臺應該允許進行模型的半自動化轉換，從而從高抽象級別轉換到低抽象級別，最終轉換為代碼。例如，UML-to-Java? 轉換能從 UML 類關系圖生成 Java 代碼。
基礎框架還應該考慮可跟蹤性，該功能實際上就是回溯到較高的抽象級別。例如，假定您希望了解需求中的變更對您的設計的影響。應該能夠通過在進行設計決策來支持特定需求時添加的鏈接（軌跡），以確定在設計中對此需求進行了何種處理。然后，在影響分析期間，應該能夠看到所有與該特定需求相關的設計決策（通過軌跡或鏈接），應該了解此需求中的更改對您的設計的影響。
元模型 是關于模型的模型。這是特定領域的模型，定義概念并提供用于創建該領域中的模型的構建元素。例如，可以將 SPEM 視為流程工程元模型。
Eclipse Modeling Framework
作為開源 Eclipse 項目，Eclipse Modeling Framework (EMF) 包括了一個模型元模型（建模領域的元模型）。以下是 EMF 網站上提供的定義：
“EMF 是用于基于結構化數據模型構建工具和其他應用程序的建模框架和代碼生成工具。通過采用 XML 元數據交換（XML Metadata Interchange，XMI）格式描述的模型規范，EMF 提供了工具和運行時支持，從而為模型生成一組 Java 類；這包括一組適配器類（支持查看模型和基于命令對模型進行編輯）和一個基本編輯器。
核心 EMF 框架包括用于描述模型的元模型 (Ecore)，并為模型提供運行時支持，包括更改通知、采用缺省 XMI 序列化的保存支持以及用于對 EMF 對象進行常規操作的非常高效的反射應用程序編程接口（Application Programming Interface，API）。”
統一建模語言 (UML)
“統一建模語言 (UML) 是行業標準語言，用于指定、可視化、構造和記錄軟件系統的構件。它簡化了軟件設計的復雜流程，為構造創建“藍圖”。”來源：Object Management Group (OMG)
UML 的好處在于其具有廣泛的行業支持。該規范最初于 1997 年提交給 OMG，擁有很多供應商的設計與開發環境的全面支持，如 IBM Rational Software Modeler (RSM) 或 IBM Rational Software Architect (RSA)。
作為 OMG 標準，該規范的當前正式版本為 2.1.1。其中定義了 13 組概念 和歸入兩個類別的關系圖類型：
結構 ；類、對象、組件、組合結構、包、部署
行為 ：用例、活動、狀態機、序列、通信、計時、交互概述
UML 是一種通用建模語言，其主要優勢之一是能夠使用 UML 概要針對領域特定的建模工作進行擴展。
EMF 與 UML 的區別何在？
EMF 是建模框架（包括元模型），而 UML 是規范。以 Eclipse UML2 項目為例，該項目是基于 EMF 的 UML 元模型實現，支持為 Eclipse 平臺開發 UML 建模工具。從這個角度而言，可以將 EMF 元模型 (Ecore) 視為用于在 Eclipse 平臺上實現 UML 模型的元模型。
UML 概要
UML 概要為獨立于領域的 UML 提供了簡單的擴展機制。概要支持定義領域特定的實體和規則。UML 概要能很好地與開發流程一起使用。例如UML Profile for Business Modeling 支持 Rational Unified Process (RUP) for Business Modeling Plug-In。
概要主要由構造型組成。構造型定義哪個 UML 類（元類）與其關聯、該類上的屬性以及有關構造型元素如何與其他元素關聯的約束。例如，在 UML 2.0 Profile for Software Services 中，Service Specification 構造型擴展 Interface UML 元類。它定義名為 published 的屬性來指示服務規范是否已發布到服務注冊中心。最后，其約束之一是，所有 Service Specification 操作都應該標記為 public。
UML 2.0 Profile for Software Services
UML 2.0 Profile for Software Services 是“允許對服務、面向服務的體系結構 (SOA) 和面向服務的解決方案進行建模的 UML 概要。該概要（有時候稱為服務概要）已經在 IBM Rational Software Architect (RSA) 中實現，已成功在制定復雜客戶場景的模型方面得到了應用，可用于幫助傳遞有關與開發面向服務的解決方案相關的注意事項。”
該概要定義 Message、Service Specification 或 Service 之類的構造型。它還為這些概念提供可方便區分的圖形符號。圖 2 顯示了 UML 關系圖的一個示例：保險領域的消息設計模型（在 IBM Rational Software Architect 中）。它將使用服務概要中的 Message 構造型表示為類關系圖（一種結構關系圖）。
圖 2. UML 類關系圖
模型驅動的體系結構
模型驅動的體系結構（Model-Driven Architecture，MDA）為業務和技術提供獨立的模型，能滿足業務和技術不斷更改的情況下的需要。以下是摘自 OMG MDA 用戶指南的定義：
“OMG 的 MDA 是一種在軟件開發中使用模型的獨立于供應商的方法。MDA 提供了相應的方法，支持提供用于以下方面的工具：
指定獨立于為其提供支持的平臺的系統
指定平臺
為系統選擇特定的平臺
將系統規范轉換為針對特定平臺的規范
MDA 的主要目標是通過從關注點的體系結構分離來實現可移植性、互操作性和可重用性。”
MDA 的核心是系統（現有或以后的系統）、平臺（提供 J2EE 或 Web 服務等功能）和視角（關注特定概念的抽象概念）之類的概念。
MDA 定義以下模型：
計算獨立模型（Computation-Independent Model，CIM）： 用于定義功能的需求的領域模型。
平臺獨立模型（Platform-Independent Model，PIM）： 獨立于可以采用其進行構建的技術的業務功能和行為模型。
平臺特定模型（Platform-Specific Model，PSM）： 將 PIM 的規范與特定類型的平臺的使用方式進行組合。
MDA 定義了轉換，以將系統的模型轉換為同一個系統的另一個模型（如從 PIM 到 PSM）。將一個模型轉換為另一個模型的方法使用映射進行說明。
MDA 的主要目標之一是允許提供設計及為其提供支持的開發工具。
模型驅動的開發
本部分目前所介紹的內容（即模型和轉換）形成了模型驅動的開發（Model-Driven Development，MDD）的基礎，該方法有時候也稱為模型驅動的軟件開發（Model-Driven Software Development，MDSD），是采用 MDA 作為說明標準的軟件工程方法。模型驅動的開發 (MDD) 是基于模型和轉換的軟件開發方法。MDD 支持采用半自動化方式生成代碼，可使用一組模型到模型轉換以及模型到代碼轉換從高級業務分析模型生成代碼。此功能以一組模型的定義、模型實例的完整性和轉換中使用的不同模型間的元素的映射作為后盾。另外，MDD 支持對變更的影響進行分析。
IBM Rational Software Delivery Platform (SDP) 支持使用 MDD（或其他方法，如業務驅動的開發）方法進行端到端企業解決方案的團隊開發。"業務驅動的開發（Business-Driven Development，BDD）是一種基于角色的集成軟件開發方法，能使業務和 IT 保持一致，可大幅度提高業務的性能。“BDD 也使用模型，關注的是業務和 IT 模型在整個 SOA 生命周期中的協作”（請參見本系列的第 1 部分）。IBM BDD 方法通過 IBM Software Delivery Platform 支持各種角色，如業務分析人員、IT 架構師、J2EE 開發人員或集成開發人員。
請參見參考資料中提供的 IBM Systems Journal 文章的鏈接，IBM 思想領袖 (thought leader) 在其中深入地討論了模型驅動的軟件開發方法。
資產
資產或服務？
資產和服務在說明、重用潛力和粒度（細粒度和粗粒度）要求方面具有相同的特征。服務可以為一種資產，可能需要很多資產進行表示。服務資產的有些元素在開發期間使用較多，如業務流程模型或測試用例，而服務資產的其他元素更多地應用到運行時，如 Web 服務描述語言（Web Services Description Language，WSDL）、XML 模式描述符（XML Schema Descriptor，XSD）或企業存檔（Enterprise Archive，EAR）。SOA 治理定義指定此類服務和資產的生命周期的規則。
資產和模式是 SOA 成功的關鍵，因為這二者為進行重用提供支持。事實上，采用基于資產的業務模型的企業可獲得巨大的增長能力。此類企業不再像傳統的基于人力的業務模型中那樣受到其員工的效率或數量的限制。恰當使用資產可以對軟件投資帶來巨大的變化。不過，采用此模型的任何人都會告訴您，這并不簡單，需要恰當的治理和基礎設施支持。
對 SOA 而言，創造性可能會對效率造成影響。讓架構師、設計人員和開發人員完全從頭進行每個新項目是我們所不希望的。類似的需求應該能夠得到一致的體系結構和設計。資產和模式允許恰當的創造性，使您能夠在可能的情況下重用經過驗證的解決方案，然后將您的時間和精力集中在需要全新開發的內容上，如特定于該項目的業務邏輯等。
資產是提供上下文中問題的解決方案的構件集合。在此上下文中，構件可以為任意內容，如需求、設計模型、實現代碼或測試用例等。可以將構件視為文件系統上的文件。對其成功至關重要的是，資產包括有關如何使用、自定義和擴展資產的說明。有關資產的構成要素的更多信息，請參見可重用資產規范。
模式
資產或模式？
資產和模式均提供上下文中問題的解決方案。那么，二者的細微區別在哪里呢？資產可以包含任意類型的構件（如電影），而且還包括模式。模式是一種特殊的資產。資產所倚重的是有關如何描述和設計其結構的標準化模型 (RAS)：模型可以使用概要進行擴展。可以將模式視為其規范和實現。
模式是對給定上下文中重復出現的問題的解決方案。模式是一種特定類型的可重用資產。可以對模式的規范（問題、上下文、各個因素和解決方案的說明）與實現（如 Java Bean）加以區分。單個模式規范可以有很多個實現。
根據其應用到的開發過程的階段不同，模式可歸入不同的類別。例如，IBM 電子商務模式將模式分為以下幾類：業務、集成、組合、應用程序和運行時。Gang of Four (GoF) 設計模式也非常有名。
使用模式時，可以確保所提供或代碼化的解決方案是正確、有用的，而且經過了驗證。不過，和任意可重用資產一樣，只有在給出了說明何時、為何以及如何使用模式的上下文和方法時，才可以加以采用。存在很多模式，而上下文是開始使用的必要條件。例如，電子商務的模式以流程的形式提供（基于技能和環境），可幫助您標識處理您的業務問題的相關模式。
最后，模式的目標之一是提供一致性，以便最終能因為在設計中使用了模式而基于相同的一組需求得到相同的體系結構。
可重用資產規范
可重用資產規范（Reusable Asset Specification，RAS）于 2005 年開始采用，是用于描述可重用軟件資產的結構、內容和說明的 OMG 標準。RAS 的目標是提供有關如何以一致的標準方式打包資產的最佳實踐。按照規范中的定義，RAS 資產的核心特征包括：
分類 ：資產相關的上下文。
解決方案 ：資產中包含的構件。
用法 ：有關安裝、使用和自定義資產的規則。
相關資產 ：此資產如何與其他資產相關。
構件的類型可以由其文件名后綴決定，如 .xml、.txt、.doc 或 .java；也可以由其用途決定，如用例模型或分析模型。由于軟件資產 是較為寬泛的術語，RAS 還提供了用于描述特定資產類型的概要。此概念與 UML 概要相同。可以使用 UML 概要來擴展獨立于領域的 UML。類似地，可以采用領域特定（如 Web 服務）的 RAS 概要來擴展獨立于領域的 RAS。
RAS 資產的文件擴展名為 .ras，打包為 .zip 文件，這意味著其中包含一個清單，可以使用 WinZip 將其打開。圖 3 摘自 RAS 規范，說明了核心 RAS 資產的主要部分。
圖 3. 核心 RAS 資產的主要部分
結束語
本文定義了有關軟件工程流程和方法的術語。定義了用于構建 SOA 解決方案的軟件構件，如模型、資產和模式等。另外還介紹了主要的標準，如 SPEM、UML 和 RAS。
后續文章將定義與分析、設計、實現、運行時和管理相關的 SOA 術語。歡迎您繼續閱讀 developerWorks 上本系列的其他文章！
在任何領域中，語義都非常重要，而在面向服務的體系結構（Service-oriented architecture，SOA）中更是如此。由于 SOA 涉及多個團隊和組織，因此就相關術語達成一致至關重要。本系列將帶著您開始 SOA 之旅，為您定義基礎術語和主要概念。您將了解 SOA 領域中所使用的各個詞匯。對于每個術語，將說明其為何對 SOA 重要、其在這種情況下的含義、相關的標準有哪些以及與其他術語的區別如何。
本系列的第 1 部分確定了業務焦點，并通過定義服務 和 SOA 等術語為后續部分打好了基礎。本文將介紹成功 SOA 采用所必需的軟件工程方法和流程，還說明交付 SOA 解決方案所需的構件（如模型和資產）。
開發流程和方法
成功的軟件開發需要以下因素：
需要得到理解和遵循的原則。
進行了正式說明的基于經過驗證的最佳實踐的方法和技術。
可以進行定制的流程。
方法內容
方法內容 描述需要生成什么內容、如何執行相關工作以及由誰執行。
方法內容構件包括：
角色 ：定義技能和工作產品職責。軟件架構師 就是角色的一個例子。
工作產品 ：任務的結果，可以為交付內容，也可以不是交付內容。服務模型 就是工作產品的一個例子。
任務 ：特定角色執行的步驟序列。任務使用輸入工作產品來生成或修改輸出工作產品。標識服務 就是任務的一個例子。
指南 ：文檔說明。術語表、模板、示例 和工具使用指導信息 都是指南。
流程
流程 用于將方法內容組織到開發周期中，并指定要完成的工作的順序。要完成的工作的順序獨立于開發生命周期模型（如瀑布式或迭代）。可以將流程視為工作流或分解結構。通過流程，項目經理可以確定在項目的每個階段需要哪些人員以及修改了哪些工作產品。如果熟悉 Rational Unified Process? (RUP)，則可以將 RUP 規程（如分析與設計實現）視為方法內容，而將 RUP 階段（如細化和構造）視為流程元素。
務必將方法和流程這兩個概念加以區分，并提供框架來支持分別對其進行修改。
Rational Method Composer
IBM Rational? Method Composer (RMC) 是基于 Eclipse 的方法與流程創作平臺，用于集成、定制、代碼化和發布流程。使用方便而且功能強大的 RMC 提供了一組流程，可以方便地加以使用或自定義，如 Rational Unified Process (RUP)。負責維護流程的項目經理、項目管理者以及程序管理員通常會使用 RMC，該工具可為本部分所描述的概念提供支持。
RMC 中進行的工作的輸出是作為 HTML 發布的流程（通常采用網站的形式）。希望遵循該流程的組織可以隨后使用此流程站點。
軟件流程工程元模型
本部分將討論開發流程。軟件流程工程元模型（Software Process Engineering Metamodel，SPEM）是正式描述軟件開發流程的的標準規范。作為 Object Management Group (OMG) 標準，SPEM 是獨立于供應商、方法和框架的。1.1 版于 2005 年 1 月正式發布，而包含重大更新的 2.0 版目前正在制訂中。
Rational Unified Process
Rational Unified Process (RUP) 基于全球數千項目所采用的最佳實踐，是能夠針對具體項目進行方便定制的軟件開發流程。RUP 包括有關優先級權衡、迭代開發、可視建模、軟件質量和團隊協作的主要原則。RUP 定義規程（方法內容）和階段（流程），如圖 1 中所示。
圖 1. Rational Unified Process (RUP)
Rational Unified Process for Service-Oriented Modeling and Architecture
Rational Unified Process for Service-Oriented Modeling and Architecture (RUP Plug-In for SOMA) 構建于 RUP 之上，可提供有關開發面向服務的解決方案的指導。2.4 版（請參見參考資料）提供了組合之前 RUP for SOA 內容和 IBM Global Business Services (GBS) SOMA 方法的統一方法。RUP Plug-In for SOMA 為軟件架構師和設計人員提供了有關面向服務的體系結構的分析、體系結構和設計的具體指導信息。
提供了專用統一建模語言（Unified Modeling Language，UML）概要，用于建模領域特定的解決方案（包括 SOA），并隨之提供了緊密相關的專用流程。例如，有支持 RUP Plug-In for SOMA 的 UML 2.0 profile for Software Services。
注意：將在本系列的后續文章中討論與管理相關的流程。
IBM 技術
如本系列的第 1 部分中所述，組件業務建模（Component Business Modeling，CBM）可幫助組織對策略、技術、操作和投資一致性形成大量新的認識。CBM 支持對形成差別的業務組件進行標識，還支持對業務流程進行分析。
面向服務的建模與體系結構（Service-Oriented Modeling and Architecture，SOMA）提供了有關 SOA 解決方案的分析和設計的指導信息。SOMA 支持對與業務保持一致的服務進行標識、規范化和執行（在設計層）。將在稍后詳細討論此主題。
模型、UML、資產與模式
元數據
元數據即關于數據的數據。例如，關于所錄制的歌曲的元數據可能包括關于演唱者、專輯、作曲、長度或質量的信息，而數據則是音頻記錄本身。
根據上下文不同，相同的數據可能為實際數據，也可能為元數據。以前面討論的開發方法和流程為例。在 RMC 中修改開發方法時，定義要類型化的內容（由元數據提供支持）。例如，可能會定義工作產品、任務和角色的新實例。在此級別，工作產品、任務和角色是元數據元素，元數據還定義這些類型（角色執行的任務）之間的關系。現在考慮設計人員定義有關方法的概念時的情況。假定他們在使用 UML 建模工作產品、角色和任務的概念。在此級別，工作產品、任務和角色是實際的數據，而 UML 是元數據。將稍后在 RMC 中將此數據作為元數據使用。這樣看來，可以將 UML 視為元-元數據！
模型
RUP 將模型定義為系統的抽象表示或模擬，可從特定的角度提供對系統的完整描述。模型經常用于更好地了解系統如何工作，或用于記錄實際實現的設計決策。模型經常由多個不同類型的部分組成。這些部分作為模型元素進行歸類。
模型的目標受眾是能夠理解這些模型的人群。例如，系統分析人員和設計人員創建和使用分析模型，數據庫設計人員設計和查看數據模型。模型可以基于文本和/或圖形。由于建模是在保持嚴密性和完整性的情況下減少復雜性（如在較高的抽象級別進行描述），因此最好使用豐富的圖形設計符號，例如在 RUM 中描述為可視建模 的統一建模語言 (UML)。模型位于特定的抽象級別，可以將其轉換到更低的級別抽象。例如，分析模型通常會轉換為設計模型。
在本系列的第 1 部分中，我們說明了協作 SOA 更為重要。例如，您的公司可能會將詳細設計或實現外包給其他公司。進行建模時，請牢記要將建模結果提供給其他人使用。另外，您的 SOA 設計和開發平臺也應該能夠接受模型，并將其轉換為其他模型。
自動化與轉換
SOA 設計與開發平臺應該允許進行模型的半自動化轉換，從而從高抽象級別轉換到低抽象級別，最終轉換為代碼。例如，UML-to-Java? 轉換能從 UML 類關系圖生成 Java 代碼。
基礎框架還應該考慮可跟蹤性，該功能實際上就是回溯到較高的抽象級別。例如，假定您希望了解需求中的變更對您的設計的影響。應該能夠通過在進行設計決策來支持特定需求時添加的鏈接（軌跡），以確定在設計中對此需求進行了何種處理。然后，在影響分析期間，應該能夠看到所有與該特定需求相關的設計決策（通過軌跡或鏈接），應該了解此需求中的更改對您的設計的影響。
元模型 是關于模型的模型。這是特定領域的模型，定義概念并提供用于創建該領域中的模型的構建元素。例如，可以將 SPEM 視為流程工程元模型。
Eclipse Modeling Framework
作為開源 Eclipse 項目，Eclipse Modeling Framework (EMF) 包括了一個模型元模型（建模領域的元模型）。以下是 EMF 網站上提供的定義：
“EMF 是用于基于結構化數據模型構建工具和其他應用程序的建模框架和代碼生成工具。通過采用 XML 元數據交換（XML Metadata Interchange，XMI）格式描述的模型規范，EMF 提供了工具和運行時支持，從而為模型生成一組 Java 類；這包括一組適配器類（支持查看模型和基于命令對模型進行編輯）和一個基本編輯器。
核心 EMF 框架包括用于描述模型的元模型 (Ecore)，并為模型提供運行時支持，包括更改通知、采用缺省 XMI 序列化的保存支持以及用于對 EMF 對象進行常規操作的非常高效的反射應用程序編程接口（Application Programming Interface，API）。”
統一建模語言 (UML)
“統一建模語言 (UML) 是行業標準語言，用于指定、可視化、構造和記錄軟件系統的構件。它簡化了軟件設計的復雜流程，為構造創建“藍圖”。”來源：Object Management Group (OMG)
UML 的好處在于其具有廣泛的行業支持。該規范最初于 1997 年提交給 OMG，擁有很多供應商的設計與開發環境的全面支持，如 IBM Rational Software Modeler (RSM) 或 IBM Rational Software Architect (RSA)。
作為 OMG 標準，該規范的當前正式版本為 2.1.1。其中定義了 13 組概念 和歸入兩個類別的關系圖類型：
結構 ；類、對象、組件、組合結構、包、部署
行為 ：用例、活動、狀態機、序列、通信、計時、交互概述
UML 是一種通用建模語言，其主要優勢之一是能夠使用 UML 概要針對領域特定的建模工作進行擴展。
EMF 與 UML 的區別何在？
EMF 是建模框架（包括元模型），而 UML 是規范。以 Eclipse UML2 項目為例，該項目是基于 EMF 的 UML 元模型實現，支持為 Eclipse 平臺開發 UML 建模工具。從這個角度而言，可以將 EMF 元模型 (Ecore) 視為用于在 Eclipse 平臺上實現 UML 模型的元模型。
UML 概要
UML 概要為獨立于領域的 UML 提供了簡單的擴展機制。概要支持定義領域特定的實體和規則。UML 概要能很好地與開發流程一起使用。例如UML Profile for Business Modeling 支持 Rational Unified Process (RUP) for Business Modeling Plug-In。
概要主要由構造型組成。構造型定義哪個 UML 類（元類）與其關聯、該類上的屬性以及有關構造型元素如何與其他元素關聯的約束。例如，在 UML 2.0 Profile for Software Services 中，Service Specification 構造型擴展 Interface UML 元類。它定義名為 published 的屬性來指示服務規范是否已發布到服務注冊中心。最后，其約束之一是，所有 Service Specification 操作都應該標記為 public。
UML 2.0 Profile for Software Services
UML 2.0 Profile for Software Services 是“允許對服務、面向服務的體系結構 (SOA) 和面向服務的解決方案進行建模的 UML 概要。該概要（有時候稱為服務概要）已經在 IBM Rational Software Architect (RSA) 中實現，已成功在制定復雜客戶場景的模型方面得到了應用，可用于幫助傳遞有關與開發面向服務的解決方案相關的注意事項。”
該概要定義 Message、Service Specification 或 Service 之類的構造型。它還為這些概念提供可方便區分的圖形符號。圖 2 顯示了 UML 關系圖的一個示例：保險領域的消息設計模型（在 IBM Rational Software Architect 中）。它將使用服務概要中的 Message 構造型表示為類關系圖（一種結構關系圖）。
圖 2. UML 類關系圖
模型驅動的體系結構
模型驅動的體系結構（Model-Driven Architecture，MDA）為業務和技術提供獨立的模型，能滿足業務和技術不斷更改的情況下的需要。以下是摘自 OMG MDA 用戶指南的定義：
“OMG 的 MDA 是一種在軟件開發中使用模型的獨立于供應商的方法。MDA 提供了相應的方法，支持提供用于以下方面的工具：
指定獨立于為其提供支持的平臺的系統
指定平臺
為系統選擇特定的平臺
將系統規范轉換為針對特定平臺的規范
MDA 的主要目標是通過從關注點的體系結構分離來實現可移植性、互操作性和可重用性。”
MDA 的核心是系統（現有或以后的系統）、平臺（提供 J2EE 或 Web 服務等功能）和視角（關注特定概念的抽象概念）之類的概念。
MDA 定義以下模型：
計算獨立模型（Computation-Independent Model，CIM）： 用于定義功能的需求的領域模型。
平臺獨立模型（Platform-Independent Model，PIM）： 獨立于可以采用其進行構建的技術的業務功能和行為模型。
平臺特定模型（Platform-Specific Model，PSM）： 將 PIM 的規范與特定類型的平臺的使用方式進行組合。
MDA 定義了轉換，以將系統的模型轉換為同一個系統的另一個模型（如從 PIM 到 PSM）。將一個模型轉換為另一個模型的方法使用映射進行說明。
MDA 的主要目標之一是允許提供設計及為其提供支持的開發工具。
模型驅動的開發
本部分目前所介紹的內容（即模型和轉換）形成了模型驅動的開發（Model-Driven Development，MDD）的基礎，該方法有時候也稱為模型驅動的軟件開發（Model-Driven Software Development，MDSD），是采用 MDA 作為說明標準的軟件工程方法。模型驅動的開發 (MDD) 是基于模型和轉換的軟件開發方法。MDD 支持采用半自動化方式生成代碼，可使用一組模型到模型轉換以及模型到代碼轉換從高級業務分析模型生成代碼。此功能以一組模型的定義、模型實例的完整性和轉換中使用的不同模型間的元素的映射作為后盾。另外，MDD 支持對變更的影響進行分析。
IBM Rational Software Delivery Platform (SDP) 支持使用 MDD（或其他方法，如業務驅動的開發）方法進行端到端企業解決方案的團隊開發。"業務驅動的開發（Business-Driven Development，BDD）是一種基于角色的集成軟件開發方法，能使業務和 IT 保持一致，可大幅度提高業務的性能。“BDD 也使用模型，關注的是業務和 IT 模型在整個 SOA 生命周期中的協作”（請參見本系列的第 1 部分）。IBM BDD 方法通過 IBM Software Delivery Platform 支持各種角色，如業務分析人員、IT 架構師、J2EE 開發人員或集成開發人員。
請參見參考資料中提供的 IBM Systems Journal 文章的鏈接，IBM 思想領袖 (thought leader) 在其中深入地討論了模型驅動的軟件開發方法。
資產
資產或服務？
資產和服務在說明、重用潛力和粒度（細粒度和粗粒度）要求方面具有相同的特征。服務可以為一種資產，可能需要很多資產進行表示。服務資產的有些元素在開發期間使用較多，如業務流程模型或測試用例，而服務資產的其他元素更多地應用到運行時，如 Web 服務描述語言（Web Services Description Language，WSDL）、XML 模式描述符（XML Schema Descriptor，XSD）或企業存檔（Enterprise Archive，EAR）。SOA 治理定義指定此類服務和資產的生命周期的規則。
資產和模式是 SOA 成功的關鍵，因為這二者為進行重用提供支持。事實上，采用基于資產的業務模型的企業可獲得巨大的增長能力。此類企業不再像傳統的基于人力的業務模型中那樣受到其員工的效率或數量的限制。恰當使用資產可以對軟件投資帶來巨大的變化。不過，采用此模型的任何人都會告訴您，這并不簡單，需要恰當的治理和基礎設施支持。
對 SOA 而言，創造性可能會對效率造成影響。讓架構師、設計人員和開發人員完全從頭進行每個新項目是我們所不希望的。類似的需求應該能夠得到一致的體系結構和設計。資產和模式允許恰當的創造性，使您能夠在可能的情況下重用經過驗證的解決方案，然后將您的時間和精力集中在需要全新開發的內容上，如特定于該項目的業務邏輯等。
資產是提供上下文中問題的解決方案的構件集合。在此上下文中，構件可以為任意內容，如需求、設計模型、實現代碼或測試用例等。可以將構件視為文件系統上的文件。對其成功至關重要的是，資產包括有關如何使用、自定義和擴展資產的說明。有關資產的構成要素的更多信息，請參見可重用資產規范。
模式
資產或模式？
資產和模式均提供上下文中問題的解決方案。那么，二者的細微區別在哪里呢？資產可以包含任意類型的構件（如電影），而且還包括模式。模式是一種特殊的資產。資產所倚重的是有關如何描述和設計其結構的標準化模型 (RAS)：模型可以使用概要進行擴展。可以將模式視為其規范和實現。
模式是對給定上下文中重復出現的問題的解決方案。模式是一種特定類型的可重用資產。可以對模式的規范（問題、上下文、各個因素和解決方案的說明）與實現（如 Java Bean）加以區分。單個模式規范可以有很多個實現。
根據其應用到的開發過程的階段不同，模式可歸入不同的類別。例如，IBM 電子商務模式將模式分為以下幾類：業務、集成、組合、應用程序和運行時。Gang of Four (GoF) 設計模式也非常有名。
使用模式時，可以確保所提供或代碼化的解決方案是正確、有用的，而且經過了驗證。不過，和任意可重用資產一樣，只有在給出了說明何時、為何以及如何使用模式的上下文和方法時，才可以加以采用。存在很多模式，而上下文是開始使用的必要條件。例如，電子商務的模式以流程的形式提供（基于技能和環境），可幫助您標識處理您的業務問題的相關模式。
最后，模式的目標之一是提供一致性，以便最終能因為在設計中使用了模式而基于相同的一組需求得到相同的體系結構。
可重用資產規范
可重用資產規范（Reusable Asset Specification，RAS）于 2005 年開始采用，是用于描述可重用軟件資產的結構、內容和說明的 OMG 標準。RAS 的目標是提供有關如何以一致的標準方式打包資產的最佳實踐。按照規范中的定義，RAS 資產的核心特征包括：
分類 ：資產相關的上下文。
解決方案 ：資產中包含的構件。
用法 ：有關安裝、使用和自定義資產的規則。
相關資產 ：此資產如何與其他資產相關。
構件的類型可以由其文件名后綴決定，如 .xml、.txt、.doc 或 .java；也可以由其用途決定，如用例模型或分析模型。由于軟件資產 是較為寬泛的術語，RAS 還提供了用于描述特定資產類型的概要。此概念與 UML 概要相同。可以使用 UML 概要來擴展獨立于領域的 UML。類似地，可以采用領域特定（如 Web 服務）的 RAS 概要來擴展獨立于領域的 RAS。
RAS 資產的文件擴展名為 .ras，打包為 .zip 文件，這意味著其中包含一個清單，可以使用 WinZip 將其打開。圖 3 摘自 RAS 規范，說明了核心 RAS 資產的主要部分。
圖 3. 核心 RAS 資產的主要部分
結束語
本文定義了有關軟件工程流程和方法的術語。定義了用于構建 SOA 解決方案的軟件構件，如模型、資產和模式等。另外還介紹了主要的標準，如 SPEM、UML 和 RAS。
后續文章將定義與分析、設計、實現、運行時和管理相關的 SOA 術語。歡迎您繼續閱讀 developerWorks 上本系列的其他文章！
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
