概念:制定组件解决方案
基于组件的开发是常规应用程序开发的变体。在本指南中,“组件”用于表示独立开发的和可部署的组件。
主要描述
生命周期范围内的活动:
  1. 简介
  2. 先启阶段活动
  3. 精化阶段活动
  4. 构造阶段活动
  5. 移交阶段活动
其他主题:

简介

基于组件的开发是常规应用程序开发的变体,其中:

  • 应用程序是分散的可执行组件汇编而成的,这些组件可能由不同的团队相互之间相对独立地开发和部署
  • 应用程序可通过只升级包含它的某些组件来进行较小幅度地升级
  • 组件可由多个应用程序共享,为复用创造机会,而且还建立项目之间的依赖关系
  • 虽然与“基于组件”关系不大,但基于组件的应用程序往往是分布式的

在整个页面中,“组件”用于指代这些独立开发的和可部署的组件。 但在 RUP 中的其他情况下,将在概念:组件中所述的更普遍意义上使用术语“组件”,并在必要时做出限定。

下面讨论 Rational Unified Process(RUP)为处理基于组件的开发难题所做的调整。

先启阶段活动

先启阶段的基本工作流程是适用的,并具有以下扩展或变体:

项目管理

  • 活动:评估项目范围和风险
  • 采用某种组件方法会改变某些风险的性质,也会引入新的风险。特别是:

    • 外部获得的组件增加了风险,因为它们引入了不受项目团队直接控制的关键元素
    • 外部获得的组件可缩短开发时间,减少资源风险
    • 外部获得的组件如果强加其自身的体系结构限制,则会使系统体系结构变形
  • 活动:计划项目
  • 任务:计划阶段和迭代中,构造阶段的计划可能会显示项目分成了两条不同但又并行的路线:一条路线开发特定于应用程序和特定于域的组件(在体系结构的较上层中组织 - 请参阅概念:分层),而另一条路线中特定于非应用程序和非域的组件在较低层中组织。在某些情况下,可重用的组件将由独立管理的开发团队来开发。引入并行路线的决定在很大程度上是人员配备和资源问题,由于希望将可重用组件作为独立于部署了组件的应用程序的资产来管理,故而引起了该问题。

需求

测试

  • 活动:定义评估任务
  • 应建立一个测试计划来确定项目的整体预期测试,该计划称为“主测试计划”。

环境

  • 活动:准备项目环境
  • 收集和准备项目指南时,请参阅 任务:准备项目指南来了解详细信息,并考虑指南所施加的特定组件框架和约束。指南应该包括如何使用框架来设计和编写代码。它们还应提供关于如何验证组件框架本身和组件间定义的接口 这两者一致性的测试指导信息。

精化阶段活动

精化阶段的基本工作流程是适用的,并具有以下扩展或变体:

需求

  • 活动:优化系统定义
  • 此外,任务:详细描述软件需求还注重于技术和非功能需求以及强加给所构建或购买的组件的约束。要考虑的具体非功能需求有大小、性能、内存或磁盘占用量、运行时许可问题以及将影响组件选择或构造的类似约束。

分析与设计

  • 活动:设计组件
  • 任务:子系统设计进一步优化了组件的设计,确定了组件中提供组件真实行为的类。在精化阶段早期可能有一个类,一种“子系统/组件代理”,作为桩模块来模拟用于建立体系结构原型的组件行为。 后来,该类的行为就分发到子系统内所包含的类的协作中。 包含的这些类是在任务:类设计中优化的。

  • 活动:设计数据库
  • 在精化阶段中,所注重的是确保持久策略是可伸缩的,并且数据库设计和持久机制将支持系统的全部需求。确定持久类并映射到持久机制上。分析数据密集型用例是为了确保机制将是可伸缩的。结合测试活动,评估并验证持久性机制和数据库设计。

实施

测试

  • 活动为:定义评估任务验证测试方法测试和评估实现可接受的任务改进测试资产

    精化阶段中的测试活动注重于验证体系结构。对于基于组件的系统,该注重对象转换为:

    • 使用组件之间的接口,确保组件边界是合适的
    • 更加注重性能测试,特别是性能伸缩测试,以确保可维持期望的事务量

    组件框架中的任何固有假设也需要评估。这些假设通常包括持久性和事务管理机制的可伸缩性和总处理能力,其中机制设计人员所做的隐含假设通常会显著破坏应用程序体系结构(如果它不理解假设)。

项目管理

  • 活动:计划下一次迭代

    如果将实施子系统用作“职责的逻辑单元”,则构造工作可分成两条或多条并行“路线”:一条注重于特定于应用程序的功能,另一条或多条注重于普通的可复用组件。当然,这取决于有足够的资源为并行开发工作配备人员。划分开发团队和并行工作的能力完全依赖于体系结构的稳定性,更具体地说,则依赖于组件之间接口的质量和稳定性。精化阶段中的强度工作将支持这种划分。

构造阶段活动

构造阶段的基本工作流程是适用的,并具有以下扩展或变体:

项目管理

  • 活动:计划下一次迭代

    以前曾描述过第一个构造迭代的计划,因为它是在精化阶段结束时进行的。继续进行迭代计划,划分开发团队和并行工作的能力继续依赖于体系结构的稳定性以及组件之间接口的质量和稳定性。

分析与设计

  • 活动:优化体系结构活动:设计组件

    在构造阶段中,所注重的是分析剩余用例并确定实现这些用例的合适组件和组件协作。现有体系结构得到扩展和完成,并且组件的“内部行为”是完整设计和实施的。

  • 活动:设计数据库

    在构造阶段中,所注重的是完成数据库设计,确保数据库和持久机制都支持所有的持久类。这项工作是与活动:优化体系结构活动:设计组件中所做的工作同步且迭代执行的。理想的组织是具有集成的组件团队,在持久性问题上保持跨团队协调一致,以确保良好的数据库设计。

实施

测试

性能测试仍然重要,但对功能测试的注重程度有所加大。需要处理功能的完整性、现有功能的回归测试以及与预期性能的一致性。

移交阶段活动

  • Web 环境中的产品发行往往是递增式和连续的,而较少注重于传统的介质分发。发行计划必须相应调整。
  • 生产支持逐渐成为该阶段的注重对象。
  • 执行数据转换活动