用途
  • 建立实施所将驻留的结构。
  • 为实施子系统及其内容分配职责。
 
角色:软件设计人员 
频率:至少每个迭代一次,因为发现了新的实施元素。 
步骤  
输入工件:   生成的工件:  
工具向导:  
更多信息: 

工作流程明细:  

建立实施模型结构 到页首

用途 建立实施模型的结构。 

在从“设计空间”向“实施空间”移动的过程中,首先在实施模型中制作设计模型结构的镜像。

设计包将会有相应的实施子系统,这些实施子系统将包含实施相应设计元素所需的一个或多个目录和文件(工件:实施元素)。从设计模型到实施模型的映射可能会随着每个实施子系统分配到体系结构中的特定层而发生变化。

创建一个图,以代表实施模型结构(请参阅“指南:实施图”)。

调整实施子系统 到页首

用途 调整模型的结构,以反映团队组织或实施语言约束。 

通过处理与实施环境相关的较小策略问题,决定子系统的组织是否需要更改。下面是这种策略问题的一些示例。请注意,如果您决定更改实施子系统的组织,就必须决定是否应转而更新设计模型,或者允许设计模型不同于实施模型。

  • 开发团队组织。子系统结构必须允许几个实施者或数个实施团队并行前进,而不会有过多的重叠和不安情况。建议每个实施子系统只归一个团队负责。这意味着您可能会希望将一个子系统分成两个(如果很大),并将两部分分派给两个实施者或两个实施团队来实施,特别是在这两个实施者(或实施团队)有不同的工作版本/发行版周期的情况下。
  • 类型的声明。在实施过程中,您可能会意识到,一个子系统需要从另一个子系统导入工件,因为类型是在该子系统中声明的。通常,当您使用类型化的编程语言(如 C++、Java 和 Ada)时,就会发生这种情况。在这种情况下,以及一般情况下,将类型声明抽取到单独的子系统中可能是个好想法。

示例

您将一些类型声明从子系统 D 抽取到新的子系统类型中,形成了独立于子系统 D 中公用(可视)工件的更改的子系统 A

类型声明子系统抽取图示

类型声明是从子系统 D 中抽取的

.

  • 现有的旧代码和组件系统。您可能需要并入旧代码、可重用组件库或者现成产品。如果这些尚未在设计中建模,则必须添加实施子系统。
  • 调整依赖关系。假设子系统 A 和子系统 B 相互之间有导入依赖关系。但是,您可能希望让 B 较少依赖于子系统 A 中的更改。抽取 B 导入的 A 的工件,并放到较低层的新实施子系统 A1 中。

工件分组传送图样本

工件从子系统 A 中抽取,并放到新的子系统 A1 中。

现在因为实施子系统不再对设计模型中的包/子系统进行一对一映射,您可以在设计模型中作出相应的更改(如果您已决定使设计模型与实施模型保持高度一致),或者可以跟踪实施和设计模型之间的映射(例如通过可跟踪性或实现依赖关系)。这样的映射是否完成以及如何完成,这是一个应记录在../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website工件:项目特定的指南中的流程决策。

为每个实施子系统定义导入 到页首

用途 定义子系统之间的依赖关系。 

为每个子系统定义它导入的其它子系统。这可以对整套子系统完成,使同一层中的所有子系统都可以导入更下一层的所有子系统。一般而言,实施模型中的依赖关系将反映设计模型中的依赖关系,例外情况是实施模型的结构的已调整部分(请参阅调整实施子系统)。

在组件图中展示分层的子系统结构。

决定如何处理可执行对象(以及其它派生对象) 到页首

可执行对象(以及其它派生对象)是将构建流程应用于实施子系统(或多个子系统)或其部件的结果,因此在逻辑上属于实施子系统。但是,软件设计人员与配置经理合作时需要决定将应用于实施模型的配置项结构。 

为了便于选择和引用(特别是部署的选择和引用),缺省的建议是定义单独的配置项来包含可部署的几组可执行对象(关于哪些可执行对象部署在哪些节点上,这是记录在部署模型中的)。因此,在简单的情况下,对于每个实施子系统,可部署的可执行对象都会有一个配置项,并有一个配置项包含用来生成这些对象的来源等等。可将实施子系统看作是由包含这些配置项(可能还有其它配置项,如测试资产)的组合配置项来表示的。

从建模的观点来看,由构建流程生成的可执行对象集合可以表示为一个工件:构建(是一个包),该工件包含在相关联的实施子系统(本身是一个包)中。  

决定如何处理测试资产 到页首

用途 将测试工件添加到实施模型中。 

一般而言,测试工件和测试子系统在 Rational Unified Process 中的处理与其它开发的软件并没有很大的不同。但是,测试工件和子系统通常不是部署的系统的一部分,而且常常不可交付给客户。因此,缺省的建议是让测试资产与测试目标相一致(例如,实施元素用于单元测试、实施子系统用于集成测试、系统用于系统测试),但如果项目存储库组织为一组目录或者目录层次结构,就要把测试资产放在(例如)单独的测试目录中。独特的测试子系统(用于单元测试级以上的测试)应该与其它实施子系统同样处理 - 作为独特的配置项。

对于建模,一个测试工件集合可以表示为一个工件:实施子系统(一个包)。对于单元测试,这样的测试子系统正常情况下会包含在相关联的(经测试的)实施子系统中。软件设计人员在向配置经理咨询之后,应决定该级别的测试工件应与他们测试的实施元素一起配置,还是作为单独的配置项进行配置。对于集成和系统测试,测试子系统可能是测试中的实施子系统的同级。

更新实施视图 到页首

用途 更新软件体系结构文档的实施视图。 

实施视图在软件体系结构文档的“实施视图”部分中有所描述。该部分包含的组件图显示了各层和实施子系统在各层的分配情况,以及子系统之间的导入依赖关系。

评估实施模型 到页首

请参阅检查点:实施模型

 

Rational Unified Process   2003.06.15