[size=large][b]引言[/b][/size]
在任何领域中，语义都非常重要，而在面向服务的体系结构（Service-oriented architecture，SOA）中更是如此。由于 SOA 涉及多个团队和组织，因此就相关术语达成一致至关重要。本系列将带着您开始 SOA 之旅，为您定义基础术语和主要概念。您将了解 SOA 领域中所使用的各个词汇。对于每个术语，将说明其为何对 SOA 重要、其在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。
本系列的第 1 部分确定了业务焦点，并通过定义服务 和 SOA 等术语为后续部分打好了基础。本文将介绍成功 SOA 采用所必需的软件工程方法和流程，还说明交付 SOA 解决方案所需的构件（如模型和资产）。
[size=large][b]开发流程和方法[/b][/size]
成功的软件开发需要以下因素：
需要得到理解和遵循的原则。
进行了正式说明的基于经过验证的最佳实践的方法和技术。
可以进行定制的流程。
[size=large][b]方法内容[/b][/size]
方法内容 描述需要生成什么内容、如何执行相关工作以及由谁执行。
方法内容构件包括：
[b]角色[/b]：定义技能和工作产品职责。软件架构师 就是角色的一个例子。
[b]工作产品[/b]：任务的结果，可以为交付内容，也可以不是交付内容。服务模型 就是工作产品的一个例子。
[b]任务[/b]：特定角色执行的步骤序列。任务使用输入工作产品来生成或修改输出工作产品。标识服务 就是任务的一个例子。
[b]指南[/b]：文档说明。术语表、模板、示例 和工具使用指导信息 都是指南。
[size=medium][b]流程[/b][/size]
流程 用于将方法内容组织到开发周期中，并指定要完成的工作的顺序。要完成的工作的顺序独立于开发生命周期模型（如瀑布式或迭代）。可以将流程视为工作流或分解结构。通过流程，项目经理可以确定在项目的每个阶段需要哪些人员以及修改了哪些工作产品。如果熟悉 Rational Unified Process® (RUP)，则可以将 RUP 规程（如分析与设计实现）视为方法内容，而将 RUP 阶段（如细化和构造）视为流程元素。
务必将方法和流程这两个概念加以区分，并提供框架来支持分别对其进行修改。
Rational Method Composer
IBM Rational® Method Composer (RMC) 是基于 Eclipse 的方法与流程创作平台，用于集成、定制、代码化和发布流程。使用方便而且功能强大的 RMC 提供了一组流程，可以方便地加以使用或自定义，如 Rational Unified Process (RUP)。负责维护流程的项目经理、项目管理者以及程序管理员通常会使用 RMC，该工具可为本部分所描述的概念提供支持。
RMC 中进行的工作的输出是作为 HTML 发布的流程（通常采用网站的形式）。希望遵循该流程的组织可以随后使用此流程站点。
[size=medium][b]软件流程工程元模型[/b][/size]
本部分将讨论开发流程。软件流程工程元模型（Software Process Engineering Metamodel，SPEM）是正式描述软件开发流程的的标准规范。作为 Object Management Group (OMG) 标准，SPEM 是独立于供应商、方法和框架的。1.1 版于 2005 年 1 月正式发布，而包含重大更新的 2.0 版目前正在制订中。
[size=medium][b]Rational Unified Process[/b][/size]
Rational Unified Process (RUP) 基于全球数千项目所采用的最佳实践，是能够针对具体项目进行方便定制的软件开发流程。RUP 包括有关优先级权衡、迭代开发、可视建模、软件质量和团队协作的主要原则。RUP 定义规程（方法内容）和阶段（流程），如图 1 中所示。
图 1. Rational Unified Process (RUP)
[img]/upload/attachment/76568/c93c057f-68b4-3922-8024-bbfea232c5cb.jpg[/img]
[size=medium][b]Rational Unified Process for Service-Oriented Modeling and Architecture[/b][/size]
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。
注意：将在本系列的后续文章中讨论与管理相关的流程。
[size=medium][b]IBM 技术[/b][/size]
如本系列的第 1 部分中所述，组件业务建模（Component Business Modeling，CBM）可帮助组织对策略、技术、操作和投资一致性形成大量新的认识。CBM 支持对形成差别的业务组件进行标识，还支持对业务流程进行分析。
面向服务的建模与体系结构（Service-Oriented Modeling and Architecture，SOMA）提供了有关 SOA 解决方案的分析和设计的指导信息。SOMA 支持对与业务保持一致的服务进行标识、规范化和执行（在设计层）。将在稍后详细讨论此主题。
[size=large][b]
模型、UML、资产与模式[/b][/size]
[size=medium][b]元数据[/b][/size]
元数据即关于数据的数据。例如，关于所录制的歌曲的元数据可能包括关于演唱者、专辑、作曲、长度或质量的信息，而数据则是音频记录本身。
根据上下文不同，相同的数据可能为实际数据，也可能为元数据。以前面讨论的开发方法和流程为例。在 RMC 中修改开发方法时，定义要类型化的内容（由元数据提供支持）。例如，可能会定义工作产品、任务和角色的新实例。在此级别，工作产品、任务和角色是元数据元素，元数据还定义这些类型（角色执行的任务）之间的关系。现在考虑设计人员定义有关方法的概念时的情况。假定他们在使用 UML 建模工作产品、角色和任务的概念。在此级别，工作产品、任务和角色是实际的数据，而 UML 是元数据。将稍后在 RMC 中将此数据作为元数据使用。这样看来，可以将 UML 视为元-元数据！
[size=medium][b]模型[/b][/size]
RUP 将模型定义为系统的抽象表示或模拟，可从特定的角度提供对系统的完整描述。模型经常用于更好地了解系统如何工作，或用于记录实际实现的设计决策。模型经常由多个不同类型的部分组成。这些部分作为模型元素进行归类。
模型的目标受众是能够理解这些模型的人群。例如，系统分析人员和设计人员创建和使用分析模型，数据库设计人员设计和查看数据模型。模型可以基于文本和/或图形。由于建模是在保持严密性和完整性的情况下减少复杂性（如在较高的抽象级别进行描述），因此最好使用丰富的图形设计符号，例如在 RUM 中描述为可视建模 的统一建模语言 (UML)。模型位于特定的抽象级别，可以将其转换到更低的级别抽象。例如，分析模型通常会转换为设计模型。
在本系列的第 1 部分中，我们说明了协作 SOA 更为重要。例如，您的公司可能会将详细设计或实现外包给其他公司。进行建模时，请牢记要将建模结果提供给其他人使用。另外，您的 SOA 设计和开发平台也应该能够接受模型，并将其转换为其他模型。
[size=medium][b]自动化与转换[/b][/size]
SOA 设计与开发平台应该允许进行模型的半自动化转换，从而从高抽象级别转换到低抽象级别，最终转换为代码。例如，UML-to-Java™ 转换能从 UML 类关系图生成 Java 代码。
基础框架还应该考虑可跟踪性，该功能实际上就是回溯到较高的抽象级别。例如，假定您希望了解需求中的变更对您的设计的影响。应该能够通过在进行设计决策来支持特定需求时添加的链接（轨迹），以确定在设计中对此需求进行了何种处理。然后，在影响分析期间，应该能够看到所有与该特定需求相关的设计决策（通过轨迹或链接），应该了解此需求中的更改对您的设计的影响。
元模型 是关于模型的模型。这是特定领域的模型，定义概念并提供用于创建该领域中的模型的构建元素。例如，可以将 SPEM 视为流程工程元模型。
[size=medium][b]Eclipse Modeling Framework[/b][/size]
作为开源 Eclipse 项目，Eclipse Modeling Framework (EMF) 包括了一个模型元模型（建模领域的元模型）。以下是 EMF 网站上提供的定义：
“EMF 是用于基于结构化数据模型构建工具和其他应用程序的建模框架和代码生成工具。通过采用 XML 元数据交换（XML Metadata Interchange，XMI）格式描述的模型规范，EMF 提供了工具和运行时支持，从而为模型生成一组 Java 类；这包括一组适配器类（支持查看模型和基于命令对模型进行编辑）和一个基本编辑器。
核心 EMF 框架包括用于描述模型的元模型 (Ecore)，并为模型提供运行时支持，包括更改通知、采用缺省 XMI 序列化的保存支持以及用于对 EMF 对象进行常规操作的非常高效的反射应用程序编程接口（Application Programming Interface，API）。”
[size=medium][b]统一建模语言 (UML)[/b][/size]
“统一建模语言 (UML) 是行业标准语言，用于指定、可视化、构造和记录软件系统的构件。它简化了软件设计的复杂流程，为构造创建“蓝图”。”来源：Object Management Group (OMG)
UML 的好处在于其具有广泛的行业支持。该规范最初于 1997 年提交给 OMG，拥有很多供应商的设计与开发环境的全面支持，如 IBM Rational Software Modeler (RSM) 或 IBM Rational Software Architect (RSA)。
作为 OMG 标准，该规范的当前正式版本为 2.1.1。其中定义了 13 组概念 和归入两个类别的关系图类型：
[b]结构[/b]；类、对象、组件、组合结构、包、部署
[b]行为[/b]：用例、活动、状态机、序列、通信、计时、交互概述
UML 是一种通用建模语言，其主要优势之一是能够使用 UML 概要针对领域特定的建模工作进行扩展。
[size=medium][b]EMF 与 UML 的区别何在？[/b][/size]
EMF 是建模框架（包括元模型），而 UML 是规范。以 Eclipse UML2 项目为例，该项目是基于 EMF 的 UML 元模型实现，支持为 Eclipse 平台开发 UML 建模工具。从这个角度而言，可以将 EMF 元模型 (Ecore) 视为用于在 Eclipse 平台上实现 UML 模型的元模型。
[size=medium][b]UML 概要[/b][/size]
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。
[size=medium][b]
UML 2.0 Profile for Software Services[/b][/size]
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 构造型表示为类关系图（一种结构关系图）。
[size=medium][b]图 2. UML 类关系图[/b][/size]
[img]/upload/attachment/76569/a2cdde30-4a65-3ebc-9241-e75567c49adf.jpg[/img]
[size=medium][b]模型驱动的体系结构 [/b][/size]
模型驱动的体系结构（Model-Driven Architecture，MDA）为业务和技术提供独立的模型，能满足业务和技术不断更改的情况下的需要。以下是摘自 OMG MDA 用户指南的定义：
“OMG 的 MDA 是一种在软件开发中使用模型的独立于供应商的方法。MDA 提供了相应的方法，支持提供用于以下方面的工具：
指定独立于为其提供支持的平台的系统
指定平台
为系统选择特定的平台
将系统规范转换为针对特定平台的规范
MDA 的主要目标是通过从关注点的体系结构分离来实现可移植性、互操作性和可重用性。”
MDA 的核心是系统（现有或以后的系统）、平台（提供 J2EE 或 Web 服务等功能）和视角（关注特定概念的抽象概念）之类的概念。
MDA 定义以下模型：
[b]计算独立模型（Computation-Independent Model，CIM）：[/b]用于定义功能的需求的领域模型。
[b]平台独立模型（Platform-Independent Model，PIM）：[/b]独立于可以采用其进行构建的技术的业务功能和行为模型。
[b]平台特定模型（Platform-Specific Model，PSM）：[/b]将 PIM 的规范与特定类型的平台的使用方式进行组合。
MDA 定义了转换，以将系统的模型转换为同一个系统的另一个模型（如从 PIM 到 PSM）。将一个模型转换为另一个模型的方法使用映射进行说明。
MDA 的主要目标之一是允许提供设计及为其提供支持的开发工具。
[size=medium][b]模型驱动的开发[/b][/size]
本部分目前所介绍的内容（即模型和转换）形成了模型驱动的开发（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) 在其中深入地讨论了模型驱动的软件开发方法。
[size=medium][b]资产[/b][/size]
[b]
资产或服务？[/b]
资产和服务在说明、重用潜力和粒度（细粒度和粗粒度）要求方面具有相同的特征。服务可以为一种资产，可能需要很多资产进行表示。服务资产的有些元素在开发期间使用较多，如业务流程模型或测试用例，而服务资产的其他元素更多地应用到运行时，如 Web 服务描述语言（Web Services Description Language，WSDL）、XML 模式描述符（XML Schema Descriptor，XSD）或企业存档（Enterprise Archive，EAR）。SOA 治理定义指定此类服务和资产的生命周期的规则。
资产和模式是 SOA 成功的关键，因为这二者为进行重用提供支持。事实上，采用基于资产的业务模型的企业可获得巨大的增长能力。此类企业不再像传统的基于人力的业务模型中那样受到其员工的效率或数量的限制。恰当使用资产可以对软件投资带来巨大的变化。不过，采用此模型的任何人都会告诉您，这并不简单，需要恰当的治理和基础设施支持。
对 SOA 而言，创造性可能会对效率造成影响。让架构师、设计人员和开发人员完全从头进行每个新项目是我们所不希望的。类似的需求应该能够得到一致的体系结构和设计。资产和模式允许恰当的创造性，使您能够在可能的情况下重用经过验证的解决方案，然后将您的时间和精力集中在需要全新开发的内容上，如特定于该项目的业务逻辑等。
资产是提供上下文中问题的解决方案的构件集合。在此上下文中，构件可以为任意内容，如需求、设计模型、实现代码或测试用例等。可以将构件视为文件系统上的文件。对其成功至关重要的是，资产包括有关如何使用、自定义和扩展资产的说明。有关资产的构成要素的更多信息，请参见可重用资产规范。
[size=medium][b]
模式[/b][/size]
[b] 资产或模式？[/b]
资产和模式均提供上下文中问题的解决方案。那么，二者的细微区别在哪里呢？资产可以包含任意类型的构件（如电影），而且还包括模式。模式是一种特殊的资产。资产所倚重的是有关如何描述和设计其结构的标准化模型 (RAS)：模型可以使用概要进行扩展。可以将模式视为其规范和实现。
模式是对给定上下文中重复出现的问题的解决方案。模式是一种特定类型的可重用资产。可以对模式的规范（问题、上下文、各个因素和解决方案的说明）与实现（如 Java Bean）加以区分。单个模式规范可以有很多个实现。
根据其应用到的开发过程的阶段不同，模式可归入不同的类别。例如，IBM 电子商务模式将模式分为以下几类：业务、集成、组合、应用程序和运行时。Gang of Four (GoF) 设计模式也非常有名。
使用模式时，可以确保所提供或代码化的解决方案是正确、有用的，而且经过了验证。不过，和任意可重用资产一样，只有在给出了说明何时、为何以及如何使用模式的上下文和方法时，才可以加以采用。存在很多模式，而上下文是开始使用的必要条件。例如，电子商务的模式以流程的形式提供（基于技能和环境），可帮助您标识处理您的业务问题的相关模式。
最后，模式的目标之一是提供一致性，以便最终能因为在设计中使用了模式而基于相同的一组需求得到相同的体系结构。
[size=medium][b]可重用资产规范[/b][/size]
可重用资产规范（Reusable Asset Specification，RAS）于 2005 年开始采用，是用于描述可重用软件资产的结构、内容和说明的 OMG 标准。RAS 的目标是提供有关如何以一致的标准方式打包资产的最佳实践。按照规范中的定义，RAS 资产的核心特征包括：
[b]分类[/b]：资产相关的上下文。
[b]解决方案[/b]：资产中包含的构件。
[b]用法[/b]：有关安装、使用和自定义资产的规则。
[b]相关资产[/b]：此资产如何与其他资产相关。
构件的类型可以由其文件名后缀决定，如 .xml、.txt、.doc 或 .java；也可以由其用途决定，如用例模型或分析模型。由于软件资产 是较为宽泛的术语，RAS 还提供了用于描述特定资产类型的概要。此概念与 UML 概要相同。可以使用 UML 概要来扩展独立于领域的 UML。类似地，可以采用领域特定（如 Web 服务）的 RAS 概要来扩展独立于领域的 RAS。
RAS 资产的文件扩展名为 .ras，打包为 .zip 文件，这意味着其中包含一个清单，可以使用 WinZip 将其打开。图 3 摘自 RAS 规范，说明了核心 RAS 资产的主要部分。
[b]图 3. 核心 RAS 资产的主要部分[/b]
[img]/upload/attachment/76572/85d3091d-2fe7-3a85-841f-f308737aca2f.gif[/img]
[size=large][b]结束语[/b][/size]
本文定义了有关软件工程流程和方法的术语。定义了用于构建 SOA 解决方案的软件构件，如模型、资产和模式等。另外还介绍了主要的标准，如 SPEM、UML 和 RAS。
后续文章将定义与分析、设计、实现、运行时和管理相关的 SOA 术语。欢迎您继续阅读 developerWorks 上本系列的其他文章！
在任何领域中，语义都非常重要，而在面向服务的体系结构（Service-oriented architecture，SOA）中更是如此。由于 SOA 涉及多个团队和组织，因此就相关术语达成一致至关重要。本系列将带着您开始 SOA 之旅，为您定义基础术语和主要概念。您将了解 SOA 领域中所使用的各个词汇。对于每个术语，将说明其为何对 SOA 重要、其在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。
本系列的第 1 部分确定了业务焦点，并通过定义服务 和 SOA 等术语为后续部分打好了基础。本文将介绍成功 SOA 采用所必需的软件工程方法和流程，还说明交付 SOA 解决方案所需的构件（如模型和资产）。
[size=large][b]开发流程和方法[/b][/size]
成功的软件开发需要以下因素：
需要得到理解和遵循的原则。
进行了正式说明的基于经过验证的最佳实践的方法和技术。
可以进行定制的流程。
[size=large][b]方法内容[/b][/size]
方法内容 描述需要生成什么内容、如何执行相关工作以及由谁执行。
方法内容构件包括：
[b]角色[/b]：定义技能和工作产品职责。软件架构师 就是角色的一个例子。
[b]工作产品[/b]：任务的结果，可以为交付内容，也可以不是交付内容。服务模型 就是工作产品的一个例子。
[b]任务[/b]：特定角色执行的步骤序列。任务使用输入工作产品来生成或修改输出工作产品。标识服务 就是任务的一个例子。
[b]指南[/b]：文档说明。术语表、模板、示例 和工具使用指导信息 都是指南。
[size=medium][b]流程[/b][/size]
流程 用于将方法内容组织到开发周期中，并指定要完成的工作的顺序。要完成的工作的顺序独立于开发生命周期模型（如瀑布式或迭代）。可以将流程视为工作流或分解结构。通过流程，项目经理可以确定在项目的每个阶段需要哪些人员以及修改了哪些工作产品。如果熟悉 Rational Unified Process® (RUP)，则可以将 RUP 规程（如分析与设计实现）视为方法内容，而将 RUP 阶段（如细化和构造）视为流程元素。
务必将方法和流程这两个概念加以区分，并提供框架来支持分别对其进行修改。
Rational Method Composer
IBM Rational® Method Composer (RMC) 是基于 Eclipse 的方法与流程创作平台，用于集成、定制、代码化和发布流程。使用方便而且功能强大的 RMC 提供了一组流程，可以方便地加以使用或自定义，如 Rational Unified Process (RUP)。负责维护流程的项目经理、项目管理者以及程序管理员通常会使用 RMC，该工具可为本部分所描述的概念提供支持。
RMC 中进行的工作的输出是作为 HTML 发布的流程（通常采用网站的形式）。希望遵循该流程的组织可以随后使用此流程站点。
[size=medium][b]软件流程工程元模型[/b][/size]
本部分将讨论开发流程。软件流程工程元模型（Software Process Engineering Metamodel，SPEM）是正式描述软件开发流程的的标准规范。作为 Object Management Group (OMG) 标准，SPEM 是独立于供应商、方法和框架的。1.1 版于 2005 年 1 月正式发布，而包含重大更新的 2.0 版目前正在制订中。
[size=medium][b]Rational Unified Process[/b][/size]
Rational Unified Process (RUP) 基于全球数千项目所采用的最佳实践，是能够针对具体项目进行方便定制的软件开发流程。RUP 包括有关优先级权衡、迭代开发、可视建模、软件质量和团队协作的主要原则。RUP 定义规程（方法内容）和阶段（流程），如图 1 中所示。
图 1. Rational Unified Process (RUP)
[img]/upload/attachment/76568/c93c057f-68b4-3922-8024-bbfea232c5cb.jpg[/img]
[size=medium][b]Rational Unified Process for Service-Oriented Modeling and Architecture[/b][/size]
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。
注意：将在本系列的后续文章中讨论与管理相关的流程。
[size=medium][b]IBM 技术[/b][/size]
如本系列的第 1 部分中所述，组件业务建模（Component Business Modeling，CBM）可帮助组织对策略、技术、操作和投资一致性形成大量新的认识。CBM 支持对形成差别的业务组件进行标识，还支持对业务流程进行分析。
面向服务的建模与体系结构（Service-Oriented Modeling and Architecture，SOMA）提供了有关 SOA 解决方案的分析和设计的指导信息。SOMA 支持对与业务保持一致的服务进行标识、规范化和执行（在设计层）。将在稍后详细讨论此主题。
[size=large][b]
模型、UML、资产与模式[/b][/size]
[size=medium][b]元数据[/b][/size]
元数据即关于数据的数据。例如，关于所录制的歌曲的元数据可能包括关于演唱者、专辑、作曲、长度或质量的信息，而数据则是音频记录本身。
根据上下文不同，相同的数据可能为实际数据，也可能为元数据。以前面讨论的开发方法和流程为例。在 RMC 中修改开发方法时，定义要类型化的内容（由元数据提供支持）。例如，可能会定义工作产品、任务和角色的新实例。在此级别，工作产品、任务和角色是元数据元素，元数据还定义这些类型（角色执行的任务）之间的关系。现在考虑设计人员定义有关方法的概念时的情况。假定他们在使用 UML 建模工作产品、角色和任务的概念。在此级别，工作产品、任务和角色是实际的数据，而 UML 是元数据。将稍后在 RMC 中将此数据作为元数据使用。这样看来，可以将 UML 视为元-元数据！
[size=medium][b]模型[/b][/size]
RUP 将模型定义为系统的抽象表示或模拟，可从特定的角度提供对系统的完整描述。模型经常用于更好地了解系统如何工作，或用于记录实际实现的设计决策。模型经常由多个不同类型的部分组成。这些部分作为模型元素进行归类。
模型的目标受众是能够理解这些模型的人群。例如，系统分析人员和设计人员创建和使用分析模型，数据库设计人员设计和查看数据模型。模型可以基于文本和/或图形。由于建模是在保持严密性和完整性的情况下减少复杂性（如在较高的抽象级别进行描述），因此最好使用丰富的图形设计符号，例如在 RUM 中描述为可视建模 的统一建模语言 (UML)。模型位于特定的抽象级别，可以将其转换到更低的级别抽象。例如，分析模型通常会转换为设计模型。
在本系列的第 1 部分中，我们说明了协作 SOA 更为重要。例如，您的公司可能会将详细设计或实现外包给其他公司。进行建模时，请牢记要将建模结果提供给其他人使用。另外，您的 SOA 设计和开发平台也应该能够接受模型，并将其转换为其他模型。
[size=medium][b]自动化与转换[/b][/size]
SOA 设计与开发平台应该允许进行模型的半自动化转换，从而从高抽象级别转换到低抽象级别，最终转换为代码。例如，UML-to-Java™ 转换能从 UML 类关系图生成 Java 代码。
基础框架还应该考虑可跟踪性，该功能实际上就是回溯到较高的抽象级别。例如，假定您希望了解需求中的变更对您的设计的影响。应该能够通过在进行设计决策来支持特定需求时添加的链接（轨迹），以确定在设计中对此需求进行了何种处理。然后，在影响分析期间，应该能够看到所有与该特定需求相关的设计决策（通过轨迹或链接），应该了解此需求中的更改对您的设计的影响。
元模型 是关于模型的模型。这是特定领域的模型，定义概念并提供用于创建该领域中的模型的构建元素。例如，可以将 SPEM 视为流程工程元模型。
[size=medium][b]Eclipse Modeling Framework[/b][/size]
作为开源 Eclipse 项目，Eclipse Modeling Framework (EMF) 包括了一个模型元模型（建模领域的元模型）。以下是 EMF 网站上提供的定义：
“EMF 是用于基于结构化数据模型构建工具和其他应用程序的建模框架和代码生成工具。通过采用 XML 元数据交换（XML Metadata Interchange，XMI）格式描述的模型规范，EMF 提供了工具和运行时支持，从而为模型生成一组 Java 类；这包括一组适配器类（支持查看模型和基于命令对模型进行编辑）和一个基本编辑器。
核心 EMF 框架包括用于描述模型的元模型 (Ecore)，并为模型提供运行时支持，包括更改通知、采用缺省 XMI 序列化的保存支持以及用于对 EMF 对象进行常规操作的非常高效的反射应用程序编程接口（Application Programming Interface，API）。”
[size=medium][b]统一建模语言 (UML)[/b][/size]
“统一建模语言 (UML) 是行业标准语言，用于指定、可视化、构造和记录软件系统的构件。它简化了软件设计的复杂流程，为构造创建“蓝图”。”来源：Object Management Group (OMG)
UML 的好处在于其具有广泛的行业支持。该规范最初于 1997 年提交给 OMG，拥有很多供应商的设计与开发环境的全面支持，如 IBM Rational Software Modeler (RSM) 或 IBM Rational Software Architect (RSA)。
作为 OMG 标准，该规范的当前正式版本为 2.1.1。其中定义了 13 组概念 和归入两个类别的关系图类型：
[b]结构[/b]；类、对象、组件、组合结构、包、部署
[b]行为[/b]：用例、活动、状态机、序列、通信、计时、交互概述
UML 是一种通用建模语言，其主要优势之一是能够使用 UML 概要针对领域特定的建模工作进行扩展。
[size=medium][b]EMF 与 UML 的区别何在？[/b][/size]
EMF 是建模框架（包括元模型），而 UML 是规范。以 Eclipse UML2 项目为例，该项目是基于 EMF 的 UML 元模型实现，支持为 Eclipse 平台开发 UML 建模工具。从这个角度而言，可以将 EMF 元模型 (Ecore) 视为用于在 Eclipse 平台上实现 UML 模型的元模型。
[size=medium][b]UML 概要[/b][/size]
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。
[size=medium][b]
UML 2.0 Profile for Software Services[/b][/size]
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 构造型表示为类关系图（一种结构关系图）。
[size=medium][b]图 2. UML 类关系图[/b][/size]
[img]/upload/attachment/76569/a2cdde30-4a65-3ebc-9241-e75567c49adf.jpg[/img]
[size=medium][b]模型驱动的体系结构 [/b][/size]
模型驱动的体系结构（Model-Driven Architecture，MDA）为业务和技术提供独立的模型，能满足业务和技术不断更改的情况下的需要。以下是摘自 OMG MDA 用户指南的定义：
“OMG 的 MDA 是一种在软件开发中使用模型的独立于供应商的方法。MDA 提供了相应的方法，支持提供用于以下方面的工具：
指定独立于为其提供支持的平台的系统
指定平台
为系统选择特定的平台
将系统规范转换为针对特定平台的规范
MDA 的主要目标是通过从关注点的体系结构分离来实现可移植性、互操作性和可重用性。”
MDA 的核心是系统（现有或以后的系统）、平台（提供 J2EE 或 Web 服务等功能）和视角（关注特定概念的抽象概念）之类的概念。
MDA 定义以下模型：
[b]计算独立模型（Computation-Independent Model，CIM）：[/b]用于定义功能的需求的领域模型。
[b]平台独立模型（Platform-Independent Model，PIM）：[/b]独立于可以采用其进行构建的技术的业务功能和行为模型。
[b]平台特定模型（Platform-Specific Model，PSM）：[/b]将 PIM 的规范与特定类型的平台的使用方式进行组合。
MDA 定义了转换，以将系统的模型转换为同一个系统的另一个模型（如从 PIM 到 PSM）。将一个模型转换为另一个模型的方法使用映射进行说明。
MDA 的主要目标之一是允许提供设计及为其提供支持的开发工具。
[size=medium][b]模型驱动的开发[/b][/size]
本部分目前所介绍的内容（即模型和转换）形成了模型驱动的开发（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) 在其中深入地讨论了模型驱动的软件开发方法。
[size=medium][b]资产[/b][/size]
[b]
资产或服务？[/b]
资产和服务在说明、重用潜力和粒度（细粒度和粗粒度）要求方面具有相同的特征。服务可以为一种资产，可能需要很多资产进行表示。服务资产的有些元素在开发期间使用较多，如业务流程模型或测试用例，而服务资产的其他元素更多地应用到运行时，如 Web 服务描述语言（Web Services Description Language，WSDL）、XML 模式描述符（XML Schema Descriptor，XSD）或企业存档（Enterprise Archive，EAR）。SOA 治理定义指定此类服务和资产的生命周期的规则。
资产和模式是 SOA 成功的关键，因为这二者为进行重用提供支持。事实上，采用基于资产的业务模型的企业可获得巨大的增长能力。此类企业不再像传统的基于人力的业务模型中那样受到其员工的效率或数量的限制。恰当使用资产可以对软件投资带来巨大的变化。不过，采用此模型的任何人都会告诉您，这并不简单，需要恰当的治理和基础设施支持。
对 SOA 而言，创造性可能会对效率造成影响。让架构师、设计人员和开发人员完全从头进行每个新项目是我们所不希望的。类似的需求应该能够得到一致的体系结构和设计。资产和模式允许恰当的创造性，使您能够在可能的情况下重用经过验证的解决方案，然后将您的时间和精力集中在需要全新开发的内容上，如特定于该项目的业务逻辑等。
资产是提供上下文中问题的解决方案的构件集合。在此上下文中，构件可以为任意内容，如需求、设计模型、实现代码或测试用例等。可以将构件视为文件系统上的文件。对其成功至关重要的是，资产包括有关如何使用、自定义和扩展资产的说明。有关资产的构成要素的更多信息，请参见可重用资产规范。
[size=medium][b]
模式[/b][/size]
[b] 资产或模式？[/b]
资产和模式均提供上下文中问题的解决方案。那么，二者的细微区别在哪里呢？资产可以包含任意类型的构件（如电影），而且还包括模式。模式是一种特殊的资产。资产所倚重的是有关如何描述和设计其结构的标准化模型 (RAS)：模型可以使用概要进行扩展。可以将模式视为其规范和实现。
模式是对给定上下文中重复出现的问题的解决方案。模式是一种特定类型的可重用资产。可以对模式的规范（问题、上下文、各个因素和解决方案的说明）与实现（如 Java Bean）加以区分。单个模式规范可以有很多个实现。
根据其应用到的开发过程的阶段不同，模式可归入不同的类别。例如，IBM 电子商务模式将模式分为以下几类：业务、集成、组合、应用程序和运行时。Gang of Four (GoF) 设计模式也非常有名。
使用模式时，可以确保所提供或代码化的解决方案是正确、有用的，而且经过了验证。不过，和任意可重用资产一样，只有在给出了说明何时、为何以及如何使用模式的上下文和方法时，才可以加以采用。存在很多模式，而上下文是开始使用的必要条件。例如，电子商务的模式以流程的形式提供（基于技能和环境），可帮助您标识处理您的业务问题的相关模式。
最后，模式的目标之一是提供一致性，以便最终能因为在设计中使用了模式而基于相同的一组需求得到相同的体系结构。
[size=medium][b]可重用资产规范[/b][/size]
可重用资产规范（Reusable Asset Specification，RAS）于 2005 年开始采用，是用于描述可重用软件资产的结构、内容和说明的 OMG 标准。RAS 的目标是提供有关如何以一致的标准方式打包资产的最佳实践。按照规范中的定义，RAS 资产的核心特征包括：
[b]分类[/b]：资产相关的上下文。
[b]解决方案[/b]：资产中包含的构件。
[b]用法[/b]：有关安装、使用和自定义资产的规则。
[b]相关资产[/b]：此资产如何与其他资产相关。
构件的类型可以由其文件名后缀决定，如 .xml、.txt、.doc 或 .java；也可以由其用途决定，如用例模型或分析模型。由于软件资产 是较为宽泛的术语，RAS 还提供了用于描述特定资产类型的概要。此概念与 UML 概要相同。可以使用 UML 概要来扩展独立于领域的 UML。类似地，可以采用领域特定（如 Web 服务）的 RAS 概要来扩展独立于领域的 RAS。
RAS 资产的文件扩展名为 .ras，打包为 .zip 文件，这意味着其中包含一个清单，可以使用 WinZip 将其打开。图 3 摘自 RAS 规范，说明了核心 RAS 资产的主要部分。
[b]图 3. 核心 RAS 资产的主要部分[/b]
[img]/upload/attachment/76572/85d3091d-2fe7-3a85-841f-f308737aca2f.gif[/img]
[size=large][b]结束语[/b][/size]
本文定义了有关软件工程流程和方法的术语。定义了用于构建 SOA 解决方案的软件构件，如模型、资产和模式等。另外还介绍了主要的标准，如 SPEM、UML 和 RAS。
后续文章将定义与分析、设计、实现、运行时和管理相关的 SOA 术语。欢迎您继续阅读 developerWorks 上本系列的其他文章！
扫一扫
1170
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
