活动:
|
用途
|
|
角色:软件设计人员 | |
频率:至少每个迭代一次,因为发现了新的实施元素。 | |
步骤 | |
输入工件: | 生成的工件: |
工具向导: | |
更多信息: |
工作流程明细: |
用途 | 建立实施模型的结构。 |
在从“设计空间”向“实施空间”移动的过程中,首先在实施模型中制作设计模型结构的镜像。
设计包将会有相应的实施子系统,这些实施子系统将包含实施相应设计元素所需的一个或多个目录和文件(工件:实施元素)。从设计模型到实施模型的映射可能会随着每个实施子系统分配到体系结构中的特定层而发生变化。
创建一个图,以代表实施模型结构(请参阅“指南:实施图”)。
用途 | 调整模型的结构,以反映团队组织或实施语言约束。 |
通过处理与实施环境相关的较小策略问题,决定子系统的组织是否需要更改。下面是这种策略问题的一些示例。请注意,如果您决定更改实施子系统的组织,就必须决定是否应转而更新设计模型,或者允许设计模型不同于实施模型。
示例
您将一些类型声明从子系统 D 抽取到新的子系统类型中,形成了独立于子系统 D 中公用(可视)工件的更改的子系统 A。
类型声明是从子系统 D 中抽取的
.
工件从子系统 A 中抽取,并放到新的子系统 A1 中。
现在因为实施子系统不再对设计模型中的包/子系统进行一对一映射,您可以在设计模型中作出相应的更改(如果您已决定使设计模型与实施模型保持高度一致),或者可以跟踪实施和设计模型之间的映射(例如通过可跟踪性或实现依赖关系)。这样的映射是否完成以及如何完成,这是一个应记录在工件:项目特定的指南中的流程决策。
用途 | 定义子系统之间的依赖关系。 |
为每个子系统定义它导入的其它子系统。这可以对整套子系统完成,使同一层中的所有子系统都可以导入更下一层的所有子系统。一般而言,实施模型中的依赖关系将反映设计模型中的依赖关系,例外情况是实施模型的结构的已调整部分(请参阅调整实施子系统)。
在组件图中展示分层的子系统结构。
可执行对象(以及其它派生对象)是将构建流程应用于实施子系统(或多个子系统)或其部件的结果,因此在逻辑上属于实施子系统。但是,软件设计人员与配置经理合作时需要决定将应用于实施模型的配置项结构。
为了便于选择和引用(特别是部署的选择和引用),缺省的建议是定义单独的配置项来包含可部署的几组可执行对象(关于哪些可执行对象部署在哪些节点上,这是记录在部署模型中的)。因此,在简单的情况下,对于每个实施子系统,可部署的可执行对象都会有一个配置项,并有一个配置项包含用来生成这些对象的来源等等。可将实施子系统看作是由包含这些配置项(可能还有其它配置项,如测试资产)的组合配置项来表示的。
从建模的观点来看,由构建流程生成的可执行对象集合可以表示为一个工件:构建(是一个包),该工件包含在相关联的实施子系统(本身是一个包)中。
用途 | 将测试工件添加到实施模型中。 |
一般而言,测试工件和测试子系统在 Rational Unified Process 中的处理与其它开发的软件并没有很大的不同。但是,测试工件和子系统通常不是部署的系统的一部分,而且常常不可交付给客户。因此,缺省的建议是让测试资产与测试目标相一致(例如,实施元素用于单元测试、实施子系统用于集成测试、系统用于系统测试),但如果项目存储库组织为一组目录或者目录层次结构,就要把测试资产放在(例如)单独的测试目录中。独特的测试子系统(用于单元测试级以上的测试)应该与其它实施子系统同样处理 - 作为独特的配置项。
对于建模,一个测试工件集合可以表示为一个工件:实施子系统(一个包)。对于单元测试,这样的测试子系统正常情况下会包含在相关联的(经测试的)实施子系统中。软件设计人员在向配置经理咨询之后,应决定该级别的测试工件应与他们测试的实施元素一起配置,还是作为单独的配置项进行配置。对于集成和系统测试,测试子系统可能是测试中的实施子系统的同级。
用途 | 更新软件体系结构文档的实施视图。 |
实施视图在软件体系结构文档的“实施视图”部分中有所描述。该部分包含的组件图显示了各层和实施子系统在各层的分配情况,以及子系统之间的导入依赖关系。
请参阅检查点:实施模型。
Rational Unified Process
|