UML参考手册
第二部分 基 本 概 念
第10章 模型管理视图
10.1 概述
任何大的系统都必须被分成几个小的单元，使得人们可以一次只处理有限的信息，并且分别处理这些信息的工作组之间不会互相干扰。模型管理由包及包之间的依赖关系组成。
10.2 包
包是模型的一部分，模型的每一部分必须属于某个包。建模者可以将模型的内容分配到包中。但是为了使其能够工作，分配必须遵循一些合理的原则，如公用规则、紧密耦合的实现和公用观点等。UML对如何组包并不强制使用什么规则，但是良好的解组会很大地增强模型的可维护性。
包包含顶层的模型元素，即任何不被其他元素所包含的元素，如类和它们之间的关系、状态机、用例图、交互和协作。有些元素如属性、操作、状态、生命线和消息被其他元素包含，而不在包中直接出现。每个顶层元素都有一个包，它在这个包中被声明，该包被称作元素的“家”包。可能被别的包引用，但是其所有权属于家包。在一个好的配置控制系统中，建模者必须能够对家包进行访问以修改元素的内容，这为处理大的模型提供了访问控制机制。包也是任何版本出版机制的单元。
一个包可以包含其他的包，根包可间接地包含系统的整个模型。组织中的包有几种可能的方式，可以用视图、功能或建模者选择的其他基本原则来规划包。包是UML模型中一般的层次组织单元。它们可以被用来进行存储、访问控制、配置管理和构造可重用模型部件库。
如果包的规划比较合理，那么它们能够反映系统的高层构架—有关系统由子系统和它们之间的依赖关系组合而成。包之间的依赖关系概述了包的内容之间的依赖关系。
10.3 包间的依赖关系
依赖关系在独立元素之间出现，但是在任何规模的系统中，应从更高的层次观察它们。包之间的依赖关系概述了包中元素的依赖关系，即包间的依赖关系可从独立元素间的依赖关系导出。
包间依赖关系的存在表示存在一个自底向上的方法（一个存在声明），或允许过后存在于一个自顶向下的方法（限制其他任何关系的约束）中，对应的包中至少有一个独立元素之间给定种类的依赖关系的关系元素。这是一个“存在声明”，并不意味着包中的所有元素都有依赖关系。这对建模者来说是表明存在更进一步的信息的标志，但是包层依赖关系本身并不包含任何更深的信息，它仅仅是一个概要。
自顶向下方法反映了系统的整个结构，自底向上方法可以从独立元素自动生成。在建模中两种方法有它们自己的地位，即使是在单个的系统中也是这样。
独立元素之间属于同一类别的多个依赖关系被聚集到包间的一个独立的包层依赖关系中，独立元素包含在这些包中。如果独立元素之间的依赖关系包含构造型（如几种不同的使用），为了产生单一的高层依赖关系，包层依赖关系中的构造型可能被忽略。
包用附有标签的矩形表示，依赖关系用虚线箭头表示。
图10-1显示了订票系统的包结构图。外部包外部。Seat selection 的两个变更之间存在依赖关系，子系统和的任何一个实现都将只包括其中一个变。
图10-1 包和包间的关系
10.4 访问与引入依赖关系
通常，一个包不能访问另一个包的内容。包是不透明的，除非它们被访问或引入依赖关系才能打开。访问依赖关系直接应用到包和其他包容器中。在包层，访问依赖关系表示提供者包的内容可被客户包中的元素或嵌入于客户包中的子包所引用。提供者中的元素在它的包中要有足够的可见性，使得客户可以看到它。通常，一个包只能看到其他包中被指定为具有公共可见性的元素。具有受保护可见性的元素只对包含它的包的后代包具有可见性。可见性也可用于类的内容（属性和操作）。一个类的后代可以看到它的祖先中具有公共或受保护可见性的成员，而其他的类则只能看到具有公共可见性的成员。对于引用一个元素而言，访问许可和正确的可见性都是必须的。所以，如果一个包中的元素要看到不相关的另一个包的元素，则第一个包必须访问或引入第二个包，且目标元素在第二个包中必须有公共可见性。
嵌套在另一个包中的包是包容器顺的一部分，而且可以完全访问包容器顺的内容。然而，对包容器顺体来说，如果不访问嵌套包，则不能看到嵌套包的内部，其内容被封装了起来。
请注意访问依赖关系不改变客户的命名空间或以任何其他方式自动建立引用，它仅仅授予建立引用的权限。引入依赖关系用来将名字加入到客户包的名字域作为路径名的别名。
10.5 模型和子系统
模型是从某一个视角观察到的对进行系统完全描述的包。它从一个视点提供一个系统的封闭的描述。它对其他包没有很强的依赖关系，如实现依赖或继承依赖。跟踪关系表示某些连接的存在，是不同模型的元素之间的一种较弱形式的依赖关系，它不用特殊的语义说明。
通常，模型为树形结构。根包包含了存在于它体内的嵌套包，嵌套包组成了从给定观点出发的系统的所有细节。
子系统是有单独的说明和实现部分的包。它表示具有对系统其他部分存在干净接口的连贯模型单元，通常表示按照一定的功能要求或实现要求对系统进行的。模型和子系统都用具有构造型关键字的包表示（如图10-1）。
