Page 1 ?
UML及软件建模
主讲人, 李 唯
clx7000@163.com
Page 2 ?
第十二章 模型管理视图
什么 是 模型管理视图
模型管理视图包含哪些图
如何 应用 模型管理视图中 的图
Page 3 ?
1、概述
任何大的系统都必须被分成几个小的单元，使得人们可以一次只处理有
限的信息，并且分别处理这些信息的工作组之间不会互相干扰。模型管
理由包及包之间的依赖关系组成。
模型管理视图对模型自身组织建模。一系列由模型元素（如类、状态机
和用例）构成的包组成了模型。一个包 (package)可能包含其他的包，因
此，整个模型实际上可看成一个根包，它间接包含了模型中的所有内容
。包是操作模型内容、存取控制和配置控制的基本单元。每一个模型元
素包含于包中或包含于其他模型元素中。
模型是从某一观点以一定的精确程度对系统所进行的完整描述。从不同
的视角出发，对同一系统可能会建立多个模型，例如有系统分析模型和
系统设计模型之分。模型是一种特殊的包。
子系统是另一种特殊的包。它代表了系统的一个部分，它有清晰的接口
，这个接口可作为一个单独的构件来实现。
模型管理信息通常在类图中表达。放置在不同节点上，部署视图可以展
示出执行过程中的瓶颈。
Page 4 ?
2,包
包是模型的一部分，模型的每一部分必须属于某个包。建模者可以将模型
的内容分配到包中。但是为了使其能够工作，分配必须遵循一些合理的原
则，如公用规则、紧密耦合的实现和公用观点等。 UML对如何组包并不强
制使用什么规则，但是良好的解组会很大地增强模型的可维护性。
包包含顶层的模型元素，即任何不被其他元素所包含的元素，如类和它们
之间的关系、状态机、用例图、交互和协作。有些元素如属性、操作、状
态、生命线和消息被其他元素包含，而不在包中直接出现。每个顶层元素
都有一个包，它在这个包中被声明，该包被称作元素的“家”包。可能被
别的包引用，但是其所有权属于家包。在一个好的配置控制系统中，建模
者必须能够对家包进行访问以修改元素的内容，这为处理大的模型提供了
访问控制机制。包也是任何版本出版机制的单元。
Page 5 ?
? 一个包可以包含其他的包，根包可间接地包含系统的整个模型。组织
中的包有几种可能的方式，可以用视图、功能或建模者选择的其他基
本原则来规划包。包是 UML模型中一般的层次组织单元。它们可以被
用来进行存储、访问控制、配置管理和构造可重用模型部件库。
? 如果包的规划比较合理，那么它们能够反映系统的高层构架 — 有关系
统由子系统和它们之间的依赖关系组合而成。包之间的依赖关系概述
了包的内容之间的依赖关系。
Page 6 ?
2.1、包图
一个最古老的软件方法问题是,怎样将大系统拆分成小系统 。 解决这个
问题的一个思路是将许多类集合成一个更高层次的单位,形成一个高内
聚, 低耦合的类的集合 。 这个思路被松散地应用到许多对象技术中 。
UML中这种分组机制叫包 (Package） 。
包用附有标签的矩形表示
包图
包图名
Page 7 ?
依赖关系在独立元素之间出现，但是在任何规模的系统中，应从更高的
层次观察它们。包之间的依赖关系概述了包中元素的依赖关系，即包间
的依赖关系可从独立元素间的依赖关系导出。
包间依赖关系的存在表示存在一个自底向上的方法（一个存在声明），
或允许过后存在于一个自顶向下的方法（限制其他任何关系的约束）中
，对应的包中至少有一个独立元素之间给定种类的依赖关系的关系元素
。这是一个“存在声明”，并不意味着包中的所有元素都有依赖关系。
这对建模者来说是表明存在更进一步的信息的标志，但是包层依赖关系
本身并不包含任何更深的信息，它仅仅是一个概要。
自顶向下方法反映了系统的整个结构，自底向上方法可以从独立元素自
动生成。在建模中两种方法有它们自己的地位，即使是在单个的系统中
也是这样。
2.2、包间的依赖关系
Page 8 ?
依赖关系用虚线箭头表示
下图显示了订票系统的包结构图。外部包外部。 Seat selection 的两个变更
之间存在依赖关系，子系统和的任何一个实现都将只包括其中一个变更。
独立元素之间属于同一类别的多个依赖关系被聚集到包间的一个独立的包层
依赖关系中，独立元素包含在这些包中。如果独立元素之间的依赖关系包含
构造型（如几种不同的使用），为了产生单一的高层依赖关系，包层依赖关
系中的构造型可能被忽略。
Page 9 ?
Page 10 ?
2.3、访问与引入依赖关系
通常，一个包不能访问另一个包的内容。包是不透明的，除非它们被访
问或引入依赖关系才能打开。访问依赖关系直接应用到包和其他包容器
中。在包层，访问依赖关系表示提供者包的内容可被客户包中的元素或
嵌入于客户包中的子包所引用。提供者中的元素在它的包中要有足够的
可见性，使得客户可以看到它。通常，一个包只能看到其他包中被指定
为具有公共可见性的元素。具有受保护可见性的元素只对包含它的包的
后代包具有可见性。可见性也可用于类的内容（属性和操作）。一个类
的后代可以看到它的祖先中具有公共或受保护可见性的成员，而其他的
类则只能看到具有公共可见性的成员。对于引用一个元素而言，访问许
可和正确的可见性都是必须的。所以，如果一个包中的元素要看到不相
关的另一个包的元素，则第一个包必须访问或引入第二个包，且目标元
素在第二个包中必须有公共可见性。
Page 11 ?
嵌套在另一个包中的包是包容器的一部分，而且可以完全访问包容器的内
容。然而，对包容器顺体来说，如果不访问嵌套包，则不能看到嵌套包的
内部，其内容被封装了起来。
请注意访问依赖关系不改变客户的命名空间或以任何其他方式自动建立引
用，它仅仅授予建立引用的权限。引入依赖关系用来将名字加入到客户包
的名字域作为路径名的别名。
Page 12 ?
2.4、模型和子系统
模型是从某一个视角观察到的对进行系统完全描述的包。它从一个视
点提供一个系统的封闭的描述。它对其他包没有很强的依赖关系，如
实现依赖或继承依赖。跟踪关系表示某些连接的存在，是不同模型的
元素之间的一种较弱形式的依赖关系，它不用特殊的语义说明。
通常，模型为树形结构。根包包含了存在于它体内的嵌套包，嵌套包
组成了从给定观点出发的系统的所有细节。
子系统是有单独的说明和实现部分的包。它表示具有对系统其他部分
存在干净接口的连贯模型单元，通常表示按照一定的功能要求或实现
要求对系统进行的。模型和子系统都用具有构造型关键字的包表示 。
Page 13 ?
2.5、包的内容
在下图中,"系统内部 "包由 "保险单 "包和 "客户 "包组成 。 这里称 "保险单 "包和 "
客户 "包为 "系统内部 "包的内容 。 当不需要显示包的内容时,包的名字放入主
方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内 。 包的内
容可以是类的列表,也可以是另一个包图,还可以是一个类图 。
Page 14 ?
UML及软件建模
主讲人, 李 唯
clx7000@163.com
Page 2 ?
第十二章 模型管理视图
什么 是 模型管理视图
模型管理视图包含哪些图
如何 应用 模型管理视图中 的图
Page 3 ?
1、概述
任何大的系统都必须被分成几个小的单元，使得人们可以一次只处理有
限的信息，并且分别处理这些信息的工作组之间不会互相干扰。模型管
理由包及包之间的依赖关系组成。
模型管理视图对模型自身组织建模。一系列由模型元素（如类、状态机
和用例）构成的包组成了模型。一个包 (package)可能包含其他的包，因
此，整个模型实际上可看成一个根包，它间接包含了模型中的所有内容
。包是操作模型内容、存取控制和配置控制的基本单元。每一个模型元
素包含于包中或包含于其他模型元素中。
模型是从某一观点以一定的精确程度对系统所进行的完整描述。从不同
的视角出发，对同一系统可能会建立多个模型，例如有系统分析模型和
系统设计模型之分。模型是一种特殊的包。
子系统是另一种特殊的包。它代表了系统的一个部分，它有清晰的接口
，这个接口可作为一个单独的构件来实现。
模型管理信息通常在类图中表达。放置在不同节点上，部署视图可以展
示出执行过程中的瓶颈。
Page 4 ?
2,包
包是模型的一部分，模型的每一部分必须属于某个包。建模者可以将模型
的内容分配到包中。但是为了使其能够工作，分配必须遵循一些合理的原
则，如公用规则、紧密耦合的实现和公用观点等。 UML对如何组包并不强
制使用什么规则，但是良好的解组会很大地增强模型的可维护性。
包包含顶层的模型元素，即任何不被其他元素所包含的元素，如类和它们
之间的关系、状态机、用例图、交互和协作。有些元素如属性、操作、状
态、生命线和消息被其他元素包含，而不在包中直接出现。每个顶层元素
都有一个包，它在这个包中被声明，该包被称作元素的“家”包。可能被
别的包引用，但是其所有权属于家包。在一个好的配置控制系统中，建模
者必须能够对家包进行访问以修改元素的内容，这为处理大的模型提供了
访问控制机制。包也是任何版本出版机制的单元。
Page 5 ?
? 一个包可以包含其他的包，根包可间接地包含系统的整个模型。组织
中的包有几种可能的方式，可以用视图、功能或建模者选择的其他基
本原则来规划包。包是 UML模型中一般的层次组织单元。它们可以被
用来进行存储、访问控制、配置管理和构造可重用模型部件库。
? 如果包的规划比较合理，那么它们能够反映系统的高层构架 — 有关系
统由子系统和它们之间的依赖关系组合而成。包之间的依赖关系概述
了包的内容之间的依赖关系。
Page 6 ?
2.1、包图
一个最古老的软件方法问题是,怎样将大系统拆分成小系统 。 解决这个
问题的一个思路是将许多类集合成一个更高层次的单位,形成一个高内
聚, 低耦合的类的集合 。 这个思路被松散地应用到许多对象技术中 。
UML中这种分组机制叫包 (Package） 。
包用附有标签的矩形表示
包图
包图名
Page 7 ?
依赖关系在独立元素之间出现，但是在任何规模的系统中，应从更高的
层次观察它们。包之间的依赖关系概述了包中元素的依赖关系，即包间
的依赖关系可从独立元素间的依赖关系导出。
包间依赖关系的存在表示存在一个自底向上的方法（一个存在声明），
或允许过后存在于一个自顶向下的方法（限制其他任何关系的约束）中
，对应的包中至少有一个独立元素之间给定种类的依赖关系的关系元素
。这是一个“存在声明”，并不意味着包中的所有元素都有依赖关系。
这对建模者来说是表明存在更进一步的信息的标志，但是包层依赖关系
本身并不包含任何更深的信息，它仅仅是一个概要。
自顶向下方法反映了系统的整个结构，自底向上方法可以从独立元素自
动生成。在建模中两种方法有它们自己的地位，即使是在单个的系统中
也是这样。
2.2、包间的依赖关系
Page 8 ?
依赖关系用虚线箭头表示
下图显示了订票系统的包结构图。外部包外部。 Seat selection 的两个变更
之间存在依赖关系，子系统和的任何一个实现都将只包括其中一个变更。
独立元素之间属于同一类别的多个依赖关系被聚集到包间的一个独立的包层
依赖关系中，独立元素包含在这些包中。如果独立元素之间的依赖关系包含
构造型（如几种不同的使用），为了产生单一的高层依赖关系，包层依赖关
系中的构造型可能被忽略。
Page 9 ?
Page 10 ?
2.3、访问与引入依赖关系
通常，一个包不能访问另一个包的内容。包是不透明的，除非它们被访
问或引入依赖关系才能打开。访问依赖关系直接应用到包和其他包容器
中。在包层，访问依赖关系表示提供者包的内容可被客户包中的元素或
嵌入于客户包中的子包所引用。提供者中的元素在它的包中要有足够的
可见性，使得客户可以看到它。通常，一个包只能看到其他包中被指定
为具有公共可见性的元素。具有受保护可见性的元素只对包含它的包的
后代包具有可见性。可见性也可用于类的内容（属性和操作）。一个类
的后代可以看到它的祖先中具有公共或受保护可见性的成员，而其他的
类则只能看到具有公共可见性的成员。对于引用一个元素而言，访问许
可和正确的可见性都是必须的。所以，如果一个包中的元素要看到不相
关的另一个包的元素，则第一个包必须访问或引入第二个包，且目标元
素在第二个包中必须有公共可见性。
Page 11 ?
嵌套在另一个包中的包是包容器的一部分，而且可以完全访问包容器的内
容。然而，对包容器顺体来说，如果不访问嵌套包，则不能看到嵌套包的
内部，其内容被封装了起来。
请注意访问依赖关系不改变客户的命名空间或以任何其他方式自动建立引
用，它仅仅授予建立引用的权限。引入依赖关系用来将名字加入到客户包
的名字域作为路径名的别名。
Page 12 ?
2.4、模型和子系统
模型是从某一个视角观察到的对进行系统完全描述的包。它从一个视
点提供一个系统的封闭的描述。它对其他包没有很强的依赖关系，如
实现依赖或继承依赖。跟踪关系表示某些连接的存在，是不同模型的
元素之间的一种较弱形式的依赖关系，它不用特殊的语义说明。
通常，模型为树形结构。根包包含了存在于它体内的嵌套包，嵌套包
组成了从给定观点出发的系统的所有细节。
子系统是有单独的说明和实现部分的包。它表示具有对系统其他部分
存在干净接口的连贯模型单元，通常表示按照一定的功能要求或实现
要求对系统进行的。模型和子系统都用具有构造型关键字的包表示 。
Page 13 ?
2.5、包的内容
在下图中,"系统内部 "包由 "保险单 "包和 "客户 "包组成 。 这里称 "保险单 "包和 "
客户 "包为 "系统内部 "包的内容 。 当不需要显示包的内容时,包的名字放入主
方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内 。 包的内
容可以是类的列表,也可以是另一个包图,还可以是一个类图 。
Page 14 ?
