| 词条 | 实施模型 |
| 释义 | 中科永联高级技术培训中心（www.itisedu.com） 实施模型是构件及其所在的实施子系统的集合。构件中既有可交付构件（例如可执行文件），又有用来生成可交付文件的构件（例如源代码文件）。 一、实施模型的目的 实施模型为组装的综合工件，包括在运行时环境中构建和管理系统时所需的所有工件。 二、实施模型的特征 特征名 简要说明 UML 表示 简介 用作模型的简要介绍的文本说明 标注值，属于“短文本”类型 实施子系统 模型中的子系统，代表一个层次结构 通过元关联关系“represents”拥有，或通过元聚合关系“owns”递归拥有。 构件 模型中的构件，由子系统拥有 通过元聚合关系“owns”而递归拥有 关系 模型中的关系，由子系统拥有 - " - 图 模型中的图，由子系统拥有 - " - 实施视图 模型的实施视图，它是子系统和层的构架视图 视图中的元素和图通过元聚合关系“owns”递归拥有 三、实施模型的时机 实施模型结构是在精化阶段中建立的，并根据需要在构建阶段中进行改进。 四、实施模型的职责 构架设计师负责实施模型的完整性，确保： 作为一个整体，实施模型是正确、一致和可读的。当实施模型实现了用例模型中所述的功能时，它就是正确的模型。 实施视图中所述的实施模型的构架可实现其目的。实施视图单独用一个工件进行说明，请参见工件：软件构架文档中。 注意，构架设计师不负责实施子系统和构件，它们应该由相应的实施员负责。 五、实施模型的定制 您必须决定如何将设计模型中的类和包映射到实施模型中的构件和子系统中。 六、建立实施模型 创建最初的实施模型结构 目的 建立实施模型的初始结构。 “设计空间”向“实施空间”转换的过程是以在实施模型中反映设计模型的结构开始的。 设计包都有相应的实施子系统，其中包括一个或几个构件以及实施此构件所需的所有相关文件。将每一个实施子系统分配给结构中的某一特定层时，从设计模型到实施模型的映射可能会随之改变。注意，设计模型中的类和可能包括的设计子系统都将映射为实施模型中的构件－虽然不必一一对应（请参见概念：从设计到代码的映射以及工件：设计子系统）。 创建构件图来表示实施模型结构。下面显示了一个简单的构件图： 简单自动柜员机的构件图例 调整实施子系统 目的 修改模型结构使之反映团队组织或者实施语言的约束。 通过处理与实施环境相关的小战术问题，确定是否需要修改子系统的组织。以下是这类战术问题的一些示例。注意，如果决定要改变实施子系统的组织，您还必须确定是否应当回过头去更新设计模型，或者允许设计模型与实施模型之间存在差别。 开发团队组织。子系统的结构必须能允许几个实施员或实施员团队并行工作，而他们的工作不会过份重叠，也不会造成混淆。因此建议每一个实施子系统由一个且只由一个团队负责。这意味着最好将一个子系统分成两个部分（如果它太大的话），并将它们分配给两个实施员或两个实施员团队去具体实施，尤其当这两个实施员（或团队）有各自不同的构建／发布周期时更应如此。 类型声明。由于在某个子系统中已经声明类型，因此在实施过程中您将会意识到该子系统需要从另一个子系统中导入构件。通常，当您使用类型化编程语言（如 C++、Java 和 Ada）时，将会出现上述情况。一般而言，在这种情况下，提取类型声明生成一个独立的子系统是一种明智的做法。 示例 从子系统 D 中提取出某些类型声明生成一个新的子系统类型，使得子系统 Ａ 不受子系统 D 中公有（可见的）构件变更的影响。 从子系统 Ｄ 中提取类型声明 . 现有的遗留代码和构件系统。您最好将遗留代码、可复用的构件库或者是市售的产品合并起来。如果在设计时没有建立它们的模型，则此时必须加入对应的实施子系统。 调整依赖关系。假定子系统 A 和子系统 B 相互之间有导入依赖关系。然而，您最好减少子系统 B 对子系统 A 变化的依赖性。可以提取出系统 B 从系统 A 中导入的构件，并在较低层中建立新的实施子系统 A1 。 从子系统 A 中提取构件，并将它们放置在新的子系统 A1 为每个实施子系统定义导入 目的 定义子系统间的依赖关系。 为每个子系统定义它所导入的其他子系统。可以为整个子系统集定义导入，即允许某一层的所有子系统导入较低层的所有子系统。一般而言，实施模型的依赖关系将反映设计模型的依赖关系，除非实施模型的结构已经过调整（请参见调整实施子系统）。 用构件图表示子系统的分层结构。 确定如何处理可执行文件（以及其他派生的对象） 可执行文件（以及派生的对象）是将构建流程应用于一个（或多个）实施子系统或系统某一部分得到的结果，因此它们在逻辑上应属于实施子系统。无论如何，构架设计师将和配置经理一道共同确定将要应用于实施模型的配置项结构。 为了便于选择和参考，尤其是为了方便部署，默认的推荐方案是定义独立的配置项以包含可部署的可执行文件集。因此，在简单的情况下，每一个实施子系统都有两个配置项：一个用于包含可配置的可执行文件，另一个用于包含生成这些文件所使用的原始资料。实施子系统可以视为包含这些配置项（也许还有其他配置项，比如测试资产等）的复合配置项。 从建模的角度看，构建流程中生成的可执行文件的集合可以表示为包含在相关实施子系统（本身是一个包）内的工件：工作版本（也是一个包）。 确定如何处理测试资产 目的 将测试工件添加到实施模型中。 一般而言，Rational Unified Process 处理测试构件和测试子系统的方式与其他开发软件并没有大的区别。然而，测试构件和子系统一般不构成部署系统的一部分，而且通常不能交付给客户。因此，默认的推荐方案是将测试资产与测试目标（例如，单元测试针对的构件、集成测试针对的实施子系统、系统测试针对的系统）结合起来，但需要将测试资产保存在不同的目录中（如果项目储存库按照一组目录或者分层目录结构进行组织）。不同的测试子系统（用于单元测试级别以上的测试）应当和其他实施子系统一样，被视为不同的配置项。 从建模角度看，测试构件的集合可以表示为工件：实施子系统（一个包）。对于单元测试，这类测试子系统通常应当包含在相关的（被测试的）实施子系统中。与配置经理商议后，构架设计师应决定是否将该级别的测试构件与它们测试的构件一起配置，或者作为独立的配置项进行配置。对于集成测试和系统测试，测试子系统和被测试的实施子系统是对等的。 更新实施视图 目的 更新软件构架文档的实施视图。 实施视图在软件构架文档的“实施视图”部分中进行说明。此部分包含的构件图显示了各个层和将实施子系统分配到层的分配形式，以及子系统之间的导入依赖关系。© 1987 - 2001 Rational Software Corporation。版权所有。 |
| 随便看 |
百科全书收录594082条中文百科知识，基本涵盖了大多数领域的百科知识，是一部内容开放、自由的电子版百科全书。