构建您的 SOA，第 3 部分: 面向服务的统一过程

领测软件测试网

有一种方法可以帮助您构建面向服务的体系结构 (SOA)——并将其好处带到将来的开发工作中。本系列（共 3 部分）的第 3 部分将介绍面向服务的统一过程（Service-Oriented Unified Process，SOUP），这是一种适应性非常强的软件方法。在这种方法中，将首先使用 IBM Rational Unified Process® (RUP®) 创建 SOA，接着在构建了 SOA 的基础后使用极限编程（Extreme Programming，XP）对服务进行构建、装配和重用。

引言

虽然 SOA 可以带来许多好处，但同时也可能受到以下一个或多个问题的困扰：

• 高复杂性和短上市时间，这样会增加失败的风险
• 由于高成本和量化投资回报 (ROI) 困难而导致较难容忍出现错误
• 需要恰当管理的动态要求和业务需求

如果您使用了软件方法——软件开发的系统方法——来在初始 SOA 推出期间提供所需的严格控制和过程，并在优化 SOA 的过程中进行调整，就可以避免这些问题。在考虑此处给出的软件方法之前，请阅读本系列的第二篇文章，该文指出，在面向服务的体系结构成熟度模型的第 3 级或第 4 级的“面向服务的体系结构成熟度模型”组织应使用 RUP 等正式的软件方法进行开发工作。只要达到了第 5 级，他们就应该使用 XP 之类的灵活方法了。

您的企业如何在保持开发过程一致的前提下过渡到较高的成熟度级别呢？本文将介绍一种最佳组合的方法，面向服务的统一过程 或 SOUP，用于开展构建工作并随后进行持续优化。在继续阅读本文之前，您应当对 RUP 和 XP 的工作方式有基本的了解。请参阅参考资料，以获得可帮助您了解相关知识的链接。

回页首

什么是 SOUP？

SOUP （Service-Oriented Unified Process）是一种使用 RUP 和 XP 中的最佳部分来构建和管理 SOA 项目的软件方法。它的目标是任何组织中正在进行的 SOA 项目。

典型的软件开发项目包含应用程序开发过程、项目管理以及所使用的技术。此外，软件开发项目通常具有四个变量：时间、预算、范围 和质量。任何一个变量的变化对整个项目都有影响。不断变化的业务需求使得范围和质量成为两个最难管理的因素。技术复杂性可能导致时间和预算管理方面出现问题。

SOA 项目比通常的软件项目复杂得多，因为它们要求配备更大的跨功能的团队，并且还有因此而带来更复杂的团队间沟通和日常管理工作。

虽然 SOA 可以为组织带来许多好处，但同时也可能带来很大的成本支出和时间消耗。如果项目没有经过良好定义，并且在项目启动时没有关于最终结果的远景，则失败的可能性就非常大。

可以帮助 SOA 成功完成的关键因素有：

• 明确定义的开发过程
• 与业务相关的项目团队之间增强的沟通渠道
• 明确的支持和控制策略

在初始开发过程中，采用正式软件方法是尽可能地减少已确定的风险的最好办法。成功建立了 SOA 项目后，可利用正式的维护和增量开发方法来增加项目的 ROI。然而，XP 之类的灵活方法可能不够正式，不适合在初始阶段使用。SOUP 方法可帮助减少 SOA 推出阶段的风险，并能让您随后进行持续 SOA 优化工作。

SOUP 是一个由六个阶段组成的软件开发方法。每个阶段代表对于 SOA 成功推出非常关键的一组特有的活动。当然，和在任何项目中一样，您将需要根据所在组织的情况对相关过程进行调整。

图 1 显示了 SOUP 过程。此方法也没有非常特别的地方：所有软件或 SOA 项目都是采用类似的方式定义的。

图 1. SOUP 过程模型
soa-method3/figure1.gif" width="445" twffan="done"/>

我将 SOUP 过程分为两类：

• 用于初始 SOA 部署的 SOUP
• 用于后续 SOA 管理的 SOUP

回页首

用于初始 SOA 部署的 SOUP

图 2 显示了用于初始 SOA 部署的 SOUP 的各个阶段。

图 2. SOUP 与 RUP 模型

每个阶段都包含主要交付内容和活动：

初始

在此阶段，将确定组织对 SOA 项目的需求。您可以通过应用 SOA 成熟度模型来确定组织的体系结构成熟度水平并确定 SOA 的驱动因素。此时，您将需要向为业务服务的所有项目团队说明 SOA 的基本概念，并拟订与反馈和建议流程有关的策略计划。

此阶段的主要交付内容有：

• SOA 远景和范围：给出项目的整体远景。它还提供了确定项目范围的边界，该范围至少应包含两个业务线或项目。
• SOA 策略：说明项目将如何执行的概略计划。
• ROI 分析：给出此项目将带来的成本支出和节省情况。
• 沟通计划：说明 SOA 团队将如何与其他项目团队和业务用户进行沟通。

客户（即业务干系人）通常并不能完全了解新软件产品可以带来的好处。定义 SOA 策略的企业团队需要利用项目团队的专业知识来帮助确定业务问题以及简化操作的方法。

跨功能分析人员和项目管理人员将对客户的业务进行分析，以确定基于 SOA 的解决方案的优势。分析人员将对客户的内部操作进行研究，此外还要分析其与合作伙伴、供应商以及他们的客户的交互情况，而且也会研究其总体业务模型。这些因素有助于分析人员制定 SOA 策略并向客户推荐。

在此阶段，您还需要对推荐的 SOA 策略进行全面的 ROI 分析。此分析应当清楚地表明短期、中期和长期的成本优势。

此阶段最重要的交付内容是沟通计划。项目 IT 团队和业务干系人比体系结构团队和分析人员更了解业务。沟通计划可以确保这些内部干系人能够理解并参与到开发过程中来。

定义

到目前为止，定义阶段是 SOA 项目中最为关键的阶段。此阶段业务和项目团队的参与将最终决定项目的成功。团队成员需要积极地参与到作为初始 SOA 推出的一部分开发的需求定义和用例方面的工作中来。

项目生命周期的此阶段的活动包括：

• 收集需求
• 分析需求
• 定义非功能需求
• 制定项目计划，其中包含时间安排和项目估算
• 定义技术基础设施
• 定义和实现用例
• 定义和记录总的体系结构

此阶段的主要交付内容有：

• 功能需求文档：详细描述 SOA 将作为业务服务提供的所有业务流程。
• 非功能需求文档：包括性能注意事项、服务水平协议 (SLA) 和基础设施要求。
• 用例和用例实现：详细说明将构建的所有业务服务的用例。
• SOA 体系结构文档：描述项目总的体系结构，包括硬件和软件组件。
• SOA 适用性文档：说明哪些项目将在 SOA 项目的范围内以及如何在 SOA 的基础上构建后续项目。
• 基础设施定义文档：包括详细的基础设施部署图，其中列出相关服务器以及实现 SOA 所需的服务器的连接和连接位置。
• 项目计划：整个项目的详细计划，包括里程碑和依赖关系。
• 支持和控制模型：描述将如何支持和控制 SOA。其中包括各种注意事项，如 SLA 监视和管理。

研究（请参阅参考资料）表明，与需求相关的问题是软件项目失败的首要原因；SOA 项目也不例外。软件质量 有时定义为软件对其需求的满足情况。但是，测定软件质量的更好办法可能是通过其满足的需求的质量 测定，而不是通过其满足的需求的数量 测定。

在明确说明了交付内容后，SOUP 方法将建议一个用于进行需求收集和管理的正式流程。XP 并不定义用于收集和记录需求的正式流程；而 XP 开发人员将创建一些用户案例（请参阅参考资料）并按逻辑顺序对这些案例进行排列，以提供一个需求序列。在此开发阶段，这样的流程并不够用。在 RUP 中，相应的流程更为详细，并使用更多的正式技术来确保举行相关的需求收集会议、对需求进行记录并加以验证。我建议使用需求存储库，该存储库将与用例、设计和代码紧密结合，以在项目进行的整个过程中提供可跟踪性。该存储库可以为 IBM Rational® RequisitePro® 工具或您组织选用的任何其他需求管理工具。更改管理流程也很重要。

此阶段最重要的交付内容是支持和控制模型。组织将如何支持 SOA？控制指导方针有哪些？如果推出了一个 SOA，但没有人使用，则项目就失败了。支持和控制模型文档可以防止发生这种情况。

企业应当在制定了真实可行的计划和目标的情况下启动项目。其他需求应留待以后解决。如果在预期的时间和预算内，可以完成有关需求的有效业务-IT (B2IT) 协作，则可以帮助确保项目的成功。

请在项目早期定义支持整个 SOA 所需的技术基础设施。这包括服务器、网络基础设施和培训要求方面的详细评估。

设计

在设计阶段，您将对定义阶段确定的设计构件进行细化。用例实现和软件体系结构文档将转化为详细的设计文档。

此时，SOA 架构师（通常为企业架构师中的一部分）需要与项目架构师合作，以确保 SOA 团队给出的设计可以供具体的项目使用。SOA 架构师甚至可能选择完成一些概念验证 (proof-of-concept) 项目，以证明 SOA 远景。此阶段的主要交付内容有：

• 详细设计文档：描述如何设计和构建服务。
• 应用程序编程模型：提供有关设计开发项目的结构的指南。涉及的主题包括使用的流程和技术、编码标准以及部署过程。
• 数据库模型：包括 SOA 使用的数据库的实体关系图。
• 测试和 QA 计划：详细说明测试和 QA 计划，并在其中包括测试用例。

构造

在构造阶段，将使用您选择的迭代构建方法来构建 SOA。此阶段中包括新的开发和集成活动。您的活动不仅限于软件方面，还涉及到与基础设施相关的子项目，如硬件整合项目或服务器承载集中化工作。虽然整个工作是在单个 SOA 项目中进行管理的，但仍然很有可能将由各种小型子团队进行不同的构造活动。

项目生命周期的此阶段将涉及到各种活动，如：

• 迭代开发
• 迭代 QA 和测试
• 用户文档

此阶段的主要交付内容有：

• 基本代码：该代码应存储在某类源代码管理存储库中。
• 测试结果：执行测试用例和 QA 计划的结果应可供进行检查分析。
• 文档：文档中应包含关于代码以及对设计文档的任何更新的详细信息。

部署

在部署阶段，您将向各个项目团队推出 SOA，这些项目团队将开始在其生产环境中的项目上使用此 SOA。此阶段最明显的主要交付内容或许就是投入生产环境中使用的应用程序。然而，SOA 试验项目的计划却是更为重要的交付内容。这将导致进入 SOUP 方法的下一个步骤，该步骤将确定后续项目如何使用新体系结构。此阶段的其他主要交付内容有：

• 部署模型：给出总的 SOA 部署结构。
• 用况模型：提供有关如何使用 SOA 的指南。随着各个项目团队和业务线开始使用新体系结构，此模型会变得非常重要。
• 后续支持级别模型：将对定义阶段开发的支持和控制模型的任何更新进行系统化。

支持

软件开发周期的这最后一个步骤非常重要。在支持阶段，您将确保提供后续 SOA 支持、错误修正和进行新功能开发。项目生命周期的此阶段将涉及到各种活动，如：

• 维护
• 错误修正
• 培训
• 持续项目投入

您的 SOA 现在已经投入生产了。但项目团队如何从该体系结构受益呢？为了构建使用现有服务的应用程序，或设计使用现有 SOA 的新服务，他们是否需要遵循上面详细列出的所有步骤？正如您将在下面的部分中看到的，实际上，他们可以从一个更为轻量级的方法中获益。

回页首

用于后续 SOA 管理的 SOUP

SOUP 方法可以用于那些使用已经推出的 SOA 的项目。在这种情况下，SOUP 对 XP 进行了大量的参考。图 3 表明了 SOUP 和 XP 过程彼此重叠。

图 3. 重叠的 SOUP 和 XP 过程

这种方法主要带来什么样的好处呢？SOA 项目的价值在于，它可提供良好定义的体系结构和严格的技术指南。您获得了一个框架，可以在其中以服务的形式构建应用程序。项目团队的主要任务是构建和使用服务。他们最适合执行这些任务，因为他们具有必要的业务领域知识。但是，他们并不需要考虑技术体系结构或技术的创新，因为这些任务将由 SOA 团队完成。

此类项目将遵循上一部分中列出的相同 SOUP 指南；不过，您将发现，每个阶段的工作量都大幅度地减少了。这一部分的许多交付内容都和前面描述的一样；必要时，我会说明它们与从头构建 SOA 时的项目中的对等项之间的差异。

初始

启动 SOA 并运行后，仍然需要进行一些开发工作。您无疑将希望构建使用现有服务或公开新服务的项目。初始阶段的主要交付内容有：

• 项目远景和范围：这仅包含单个项目的范围，而不包含更大的 SOA 计划的范围。
• 项目策略：描述此具体项目的策略和流程，并说明其如何利用 SOA。
• ROI 分析：项目的详细成本优势分析，这对于帮助进行与实现有关的决策非常关键。

定义

在定义阶段，您将构建与 SOA 项目有关的各项内容，并了解如何利用 SOA。您需要标识 SOA 可以提供的服务和仍然需要构建以满足您的项目目标的服务。

项目生命周期的此阶段的活动包括：

• 收集需求
• 标识服务
• 制定项目计划，其中包括时间安排和项目评估
• 开发测试用例

此阶段的主要交付内容有：

• 功能需求文档：软件项目的典型需求文档。
• 用例和用例实现：涵盖所有正在构建的新业务流程。
• SOA 适用性文档：说明现有 SOA 框架如何应用到此项目。
• 项目计划：详细说明整个项目，包括里程碑和依赖关系。
• 服务策略：标识已经存在并能够使用的服务以及可以公开的新服务。
• 测试计划：其中包括项目的测试用例。

在此阶段，您不需要严格遵循在 SOA 推出期间遵循的正式需求收集标准。相反，可以通过用户案例或类-责任-协作者（Class, Responsibilities, Collaborator，CRC）卡（请参阅参考资料）来简化需求收集。根据 XP 的思想，测试案例是在这种类型的项目的早期构建的。

设计

此阶段可以迅速完成，因为大部分服务都在初始 SOA 推出时已经完成。在设计阶段，只需要关心如何使用这些服务，需要在现有服务的基础上构建什么功能，以及需要构建哪些新服务。

此阶段的主要交付内容有：

• 详细设计文档：说明您的设计如何利用总体 SOA，并建立设计与应用程序编程模型。
• 数据库模型：封装供此特定项目使用的逻辑和物理数据设计。

构造

构造阶段涉及更多的是装配，而不是新部署。随着提供的服务越来越多，每个项目都将有越来越多的可重用服务，而需要构建的新服务也就越来越少。XP 的迭代开发技术是此开发阶段的最佳选择。在 XP 中，理论上的迭代周期设置为两周，当在 SOA 环境中构建小型服务和使用一组服务时，这一时间对于一个开发 Development-QA 周期来说绝对足够了。使用此迭代方法，SOA 可以通过快速软件发布提供有价值的业务灵活性。

项目生命周期的构造阶段的活动包括：

• 迭代开发
• 迭代 QA 和测试
• 用户文档

此阶段的主要交付内容有：

• 新服务：在本阶段结束时，任何将要公开的新服务都会准备就绪。
• 测试结果：执行测试用例所得到的结果应提供给所有相关方。
• 文档：此开发阶段应产生详细的代码文档以及对以前创建的其他文档的所有必要更新。

部署

在此阶段，将启动使用多个服务的应用程序，或启动新服务。由于基础设施是由 SOA 团队进行管理的，因此该流程相对比较简单。

支持

在此阶段，将仅为您的新服务提供支持。在进行此项工作的过程中，请遵循在原始 SOA 项目期间制定的支持指南。单个项目不需要花很多时间制定新的支持指南。

回页首

管理 SOA 生命周期

本文向您介绍了 SOUP，这种新的软件方法可用于构建 SOA 并将此体系结构的好处带给各个项目。文中说明了可以如何使用类似于 RUP 的正式方法来对 SOA 进行初始构建，然后转向 XP 样式的灵活流程，以进行后续服务推出工作。通过实现这两个过程的最佳组合，您可以依靠一个统一的开发模式来进行相关工作，此模式可提供足够的灵活性，以便对 SOA 生命周期的不同阶段进行管理。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/