设计包，主要用于模型组织，并且通常用作配置管理的单元。是由类、关系、用例实现、图和其他包组成的集合。一个包中可以包含公有类，也可以包含私有类。公有类可以与任何其他类相关联。私有类只能与其所在包中包含的类相关联。
中文名设计包
方法由类、关系、用例实现
性质包内容可见性
属性用于模型组织
定义
设计包是由类、关系、用例实现、图和其他包组成的集合；它可用于将设计模型分成更小的部分，从而建立设计模型的结构。包主要用于模型组织，并且通常用作配置管理的单元。
r为了便于理解，可以将设计模型分成更小的单元。通过将设计模型元素分组，将其归入到包和子系统中，然后显示这些分组之间的相互关系，就可以更容易地了解模型的整体结构。请注意，设计子系统是一种特殊的包，它具有行为语义（即实现一个或多个接口）；有关详细信息，请参见工件：设计子系统和指南：设计子系统。设计子系统具有不同于设计包的目的，后者是静态的东西，在逻辑上类似于实施子系统。
r包内容可见性
r一个包中可以包含公有类，也可以包含私有类。公有类可以与任何其他类相关联。私有类只能与其所在包中包含的类相关联。
r包接口由包的公有类组成。包接口（公有类）隔离并实施对其他包的依赖关系。平行开发可通过这种方式得以简化，因为您可以及早建立接口，并且开发人员只需要了解其他包接口的变化。
r包分区标准
r您可以出于以下原因划分设计模型：
r您可以在完成系统后将包和子系统用作订购、配置或交付单元。
r由于资源分配以及不同开发团队的能力不同，可能要求将该项目划分给处于不同位置的不同组。通过带有明确定义的接口的子系统，可以在各团队之间以有控制、有协调的方式划分工作，从而使设计和实施能够平行地进行。
r子系统可用于按照用户类型来建立设计模型的结构。许多变更需求都来自于用户；子系统可确保来自特定用户类型的变更需求只影响系统中与该用户类型对应的部分。
r在某些应用程序中，某些特定信息应该只能由少数几个人访问。子系统使您能够在需要保守秘密的地方保守秘密。 如果您正在构建一个支持系统，就可以利用子系统和包向该支持系统提供一个与要支持的系统相似的结构。这样，您就可以使两个系统的维护实现同步。
r子系统用于代表系统所使用的现有产品和服务（例如 COTS 产品和库），正如以下几节所述。
rr将边界类打包
r在将边界类分发给各个包时，可以应用两种不同的策略。要确定选择哪种策略，取决于系统接口将来是否可能发生重大的变化。
r如果系统接口可能被替换，或者可能经历相当大的更改，就应将接口与设计模型的其他部分隔离开。在更改用户界面时，只有这些包会受到影响。这种较大更改的示例是从基于行的接口转换为基于窗口的接口。 如果主要目的是简化较大的接口更改，就应在一个（或几个）单独的包中放置边界类。
r如果不打算进行任何较大的接口更改，指导原则的就应是对系统服务进行更改，而不是对接口进行更改。然后，应该将边界类和在功能上与它们相关的实体类及控制类放置在一起。这样，如果特定的实体类或控制类发生变化，就很容易看出哪些边界类受到影响。
r如果要简化对系统服务的更改，就要将边界类和在功能上与它们相关的类打包到一起。
r对于在功能上与任何实体类或控制类都不相关的必选边界类，应将它们和属于同一接口的边界类放置在单独的包中。
r如果某一边界类与一项可选服务相关，就要在单独的子系统中将此边界类与协同提供该服务的类归为一组。该子系统将映射到在预定可选功能时所提供的可选构件上。
r将功能相关的类打包
r应该为每一组在功能上相关的类确定一个包。在判断两个类是否在功能上相关时，可以应用以下几项实用标准。这些标准按重要性递减的顺序排列：
r如果一个类的行为和（或）结构的变化使得另一个类也必须相应地变化，这两个类就在功能上相关。
相关推荐
最新文章