概念:
|
生命周期范围内的活动: |
其它主题:
|
基于组件的开发是常规应用程序开发的变体,其中:
- 应用程序是分散的可执行组件汇编而成的,这些组件是相互之间相对独立地开发和部署的(可能由多个团队)。
- 应用程序可通过只升级包含它的某些组件来较小幅度地进行升级。
- 组件可由多个应用程序共享,为重用创造机会,而且建立项目之间的依赖关系。
- 虽然并非全然关系到基于组件,但基于组件的应用程序往往将是分发式的。
在整个页面中,“组件”用于指代这些独立开发和可部署的组件。但在 RUP 中的其它情况下,将在概念:组件中所述的更普遍意义上使用术语“组件”,并在必要时做出限定。
下面讨论 Rational Unified Process(RUP)为处理基于组件的开发难题所做的调整。
先启阶段的基本工作流程是适用的,并具有以下扩展或变体:
活动:制定业务用例的焦点调整为考虑使用组件改变开发的成本结构。具体的说,开发组件成本降低,但会有更多工作花在确定组件和验证所选组件是否符合其需求上。
采用某种组件方法会改变某些风险的性质,也会引入新的风险。具体地说:
在活动:计划阶段和迭代中,构造阶段的计划可能会显示项目分成了两条不同而又并行的路线:一条路线开发特定于应用程序和特定于领域的组件(在体系结构的较上层中组织 - 请参阅概念:分层),而特定于非应用程序和非领域的组件在较下层中组织。在某些情况下,可重用的组件将由独立管理的开发团队来开发。引入并行路线的决定在很大程度上是人员配备和资源问题,由于希望将可重用组件作为独立于部署了组件的应用程序的资产来管理,故而引起了该问题。
优化系统需求时,需要获取由所选组件框架强加的约束。组件框架部分地通过限制赋予软件设计人员和设计人员的自由度来提高开发生产力。活动:详细描述软件需求必须注重于记录这些约束。
应建立一个测试计划来确定项目的整体预期测试,该计划称为“主测试计划”。
收集和准备项目指南时,来了解详细信息,并考虑它所强加的特定组件框架和约束。指南应该包括如何使用框架来设计和编写代码。它们还应提供关于如何验证组件框架本身和组件间定义的接口这两者的一致性的测试指导信息。
精化阶段的基本工作流程是适用的,并具有以下扩展或变体:
活动:详细描述软件需求另外还注重于技术和非功能需求以及强加给所构建或购买的组件的约束。要考虑的具体非功能需求有大小、性能、内存或磁盘占用量、运行时许可问题以及将影响组件选择或构建的类似约束。
活动:体系结构分析使用组件框架以及技术和非功能需求来定义初始体系结构,包括初始分层方案和缺省的一套组件和服务(表示为分析与设计机制)。活动:用例分析注重于由具有体系结构重要性的用例来确定具有体系结构重要性的组件。
活动:构造实施模型建立与组件框架结构以及开发团队的结构和职责相符的实施模型。
活动:确定设计机制将优化初始设计机制,以考虑特定框架服务和组件。
活动:确定设计元素将确定具有体系结构重要性的主要系统组件。应将可能可重用的职责分组在一起,以改进可重用性;特定于应用程序的功能应该与特定于领域及独立于应用程序和领域的功能分开来。为了设计起见,组件可表示为工件:设计子系统。应对这些组件/子系统确定工件:接口。
活动:合并现有设计元素将确保已确定的组件与在以前迭代中确定的现有组件(来自框架本身或外部源)一致和相符。
活动:描述运行时体系结构描述了组件框架的基本流程和线程体系结构,而活动:描述分发描述了将执行组件应用程序的分发式计算环境。
活动:子系统设计进一步优化了组件的设计,确定了组件中提供组件真实行为的类。在精化阶段早期可能有一个类,一种“子系统/组件代理”,作为桩模块来模拟用于建立体系结构原型的组件行为。后来,该类的行为就分发到子系统内所包含的类的协作中。这些包含的类是在活动:类设计中优化的。
在精化阶段中,所注重的是确保持久策略是可伸缩的,并且数据库设计和持久机制将支持系统的全部需求。确定持久类并映射到持久机制上。分析数据密集型用例是为了确保机制将是可伸缩的。结合测试工作流程明细,评估和验证持久机制和数据库设计。
活动:实施设计元素必须符合组件框架所强加的约束的一部分而提供的《编程指南》中所述。在精化阶段,大多数组件将包含大量“桩模块”代码,因为在这里实施注重的是验证体系结构,而不是生成生产质量代码。
精化阶段中的测试活动注重于验证体系结构。对于基于组件的系统,该注重对象转换为:
组件框架中的任何固有假设也需要评估。这些假设通常包括持久性和事务管理机制的可伸缩性和总处理能力,其中机制设计人员所做的隐含假设通常会显著破坏应用程序体系结构(如果它不理解假设)。
将实施子系统用作“逻辑职责单元”,构建工作可分成两条或更多并行“路线”:一条注重于特定于应用程序的功能,并有一条或多条注重于普通的可重用组件。当然,这取决于有足够的资源为并行开发工作配备人员。划分开发团队和并行工作的能力完全依赖于体系结构的稳定性,更具体地说,则依赖于组件之间接口的质量和稳定性。精化阶段中的强度工作将支持这种划分。
构造阶段的基本工作流程是适用的,并具有以下扩展或变体:
以前曾描述过第一个构造迭代的计划,因为它是在精化阶段结束时进行的。继续进行迭代计划,划分开发团队和并行工作的能力继续依赖于体系结构的稳定性以及组件之间接口的质量和稳定性。
在构造阶段中,所注重的是分析剩余用例并确定实现这些用例的合适组件和组件协作。现有体系结构得到扩展和完成,并且体系结构的“内部行为”是完整设计和实施的。
在构造阶段中,所注重的是完成数据库设计,确保数据库和持久机制都支持所有的持久类。这项工作是与工作流程明细:优化体系结构和工作流程明细:设计组件中所做的工作并行且迭代地执行的。理想的组织是具有集成的组件团队,在持久性问题上保持跨团队协调一致,以确保良好的数据库设计。
这里的工作类似于精化阶段中的工作,但其余的详细信息会随着阶段的进展而更加完整。
系统是随着阶段的深入而逐渐建立起来的。
性能测试仍然重要,但对功能测试的注重程度有所加大。需要处理功能的完整性、现有功能的回归测试以及与预期性能的一致性。
Rational Unified Process
|