实施子系统

实施子系统是构件和其他实施子系统的集合，通过将其分成数个小部分来建立实施模型结构。

解释

对于包含数百个构件的实施模型，要降低其复杂性，一种基本方法就是使用实施子系统。

子系统采用目录的形式，并带有附加的结构或管理信息。例如，子系统可以创建为文件系统中的目录或文件夹，也可以创建为 C++ 或 Ada 的 Rational/Apex 中的子系统，还可以创建为使用 Java 的包。

实施子系统实际上就类似于设计包。实施模型和实施子系统是实施视图的目标，因此在开发时非常重要。

导出构件

实施子系统控制其内容的外部可见性。如果某个构件被其声明子系统定义为可见的（“导出”），该构件就可以由该子系统外的构件引用。

默认情况下，子系统中的所有构件（以及被包含的子系统）在子系统外部都是可见的。这意味着该子系统外的任何构件都可引用该子系统内的所有构件。例如，在 C++ 中，这就意味着外部的构件可以对子系统内的所有构件执行 #include 操作。

使用

实施模型可以在某种程度上接近于设计模型，其接近程度取决于您如何将设计包映射到实施模型中的实施子系统。

最好保持一对一的映射关系，即一个设计包应映射到一个实施子系统。这样做的主要目的是为了实现从设计到代码的无缝可追踪性。

在某些情况下，您需要让实施中的子系统不同于设计中的包。有关详细信息，请参见活动：建立实施模型。

您应确定设计模型与实施模型之间的关系，并且应在项目专用的设计指南中记录这种关系。

您可以出于多种原因而将系统划分为多个子系统。设计中的相同标准同样适用于实施。有关详细信息，请参见指南：设计包。

目的

以下人员将使用实施子系统：

构架设计师使用它来建立实施模型结构。
设计系统下一个版本的人员利用它来了解实施模型的结构。
系统其他部分的实施员利用它来了解可如何使用它们的功能。
子系统测试人员利用它来制定测试计划活动。
项目经理将它用作分配实施工作的依据。
实施子系统实际上就类似于设计包。实施模型和实施子系统是实施视图的目标，因此在开发时非常重要。

特征

特征名	简要说明	UML 表示
名称	子系统名称	模型元素上的“名称”属性
简要说明	对子系统的角色和目的的简要说明	标注值，属于“短文本”类型
构件	直接包含在子系统中的构件	通过元聚合关系“owns”而拥有
关系	直接包含在子系统中的关系	- " -
图	直接包含在子系统中的图	- " -
实施子系统	直接包含在子系统中的子系统	- " -
导入依赖关系	从一个子系统到另一个子系统的导入依赖关系	通过元聚合关系“owns”由所属子系统拥有

时机

构架设计师在精化阶段定义子系统，并将子系统分配到个人（或团队）。然后才启动类实施，这样可以并行地开发子系统。

职责

实施员负责子系统，确保：

子系统满足对其制定的需求。
说明从子系统生成的导入依赖关系，从而能够估计将来进行变更时所要产生的效果。
子系统的直属内容（包括其构件和子系统）的存在是合理的，并始终保持一致。
子系统与设计模型的对应部分保持一致。
负责实施子系统的实施员还负责子系统的公有（可见）构件。

我们建议：负责实施子系统的实施员也负责该子系统中包含的所有构件。有关详细信息，请参见工件：构件。

如果实施员团队开发了一个实施子系统，则团队中的一名成员应该负责该子系统。

定制