UML与系统分析设计 第09章 包图

《UML与系统分析设计 第09章 包图》由会员分享，可在线阅读，更多相关《UML与系统分析设计 第09章 包图（30页珍藏版）》请在金锄头文库上搜索。

1、在对一个大型的软件系统建立模型时往往需要面对和处理大量的模型元素，如对象类、接口、组件、节点、图等。 UML的包是一种对模型元素进行成组组织的通用机制，它把语义上相近的可能一起变更的模型元素组织在同一个包里，便于理解复杂的系统，控制系统结构各部分间的接缝。 包是一种概念性的模型管理的图形工具，只在软件的开发过程中存在。 包可以用于组织一个系统模型。一个系统的框架、模型、子系统等也都可以看作是特殊的包。 第 9章 包 图 Home 第 9章 包 图 9.1 包 9.2 包的联系 9.3 包图 9.4 包图的应用 Home 9.1 包 Home 9.1.1 包的语义和表示 9.1.2 包的嵌套 9

2、.1.3 标准构造型 包（ Package）是一种对模型元素进行成组组织的通用机制。 包用于定义一个名字空间（ Namespace）或容器（ Container），它本身是 UML的一种模型元素。 运用包可以把语义上相近的可能一起变更的模型元素组织在同一个包里，对包中的元素作为一个整体对待，并且控制它们的可视性和存取。 包的图标是一个大矩形（内容框）的左上角带一个小矩形（名字框），如图 9.1所示。 包的名字可是一个简单名或路径名。在包名之后或之下，可用括在花括号中的文字（约束）说明包的性质，如 “ abstract”、 “ version”等。 9.1.1 包的语义和表示 Home 图 9.

3、1 简单包和扩展包示例 一个包可以拥有一个或多个模型元素，包括对象类、接口、组件、节点、协同、 Use Case、图等，甚至拥有其他包。 所有 UML的模型元素都可以放入包内。通常，一个包拥有的是对象类或其他的包。 包与它所含的模型元素之间的关系是一种组合联系，即一个包由一个或多个模型元素组成，每一个模型元素在该包中声明。 一个模型元素只能为一个包唯一地拥有。一个包消失了，它所拥有的全部模型元素也随之消失。 不同包的模型元素可以同名，但在同一个包中的模型元素不能同名。 9.1.1 包的语义和表示 Home 包的模型元素名前可以有可视性标记，分别用 “ +”、 “ #”、 “ -”表示可视性为

4、“ 公共 ” 、 “ 保护 ” 、 “ 私用 ” ，如图 9.2所示。 包只是一种组织模型元素的容器，它没有实例，只有内含的内容，即对象类、接口等模型元素。 包纯粹是一种概念性的建模工具，它与组件不同。包只在软件的开发过程中存在，它类似一个有标签的文件夹，其中包含有包的名字和内容。而组件是系统的组成部分，既存在于软件的开发过程中，也存在于系统的运行期间。 包内的模型元素具有较强的内聚性，不同的包的元素之间的耦合性很弱。 9.1.1 包的语义和表示 Home 图 9.2 包中元素的可视性 包可以拥有其他包作为包内的元素，子包又可以拥有自己的子包，这样可以构成一个系统的嵌套结构，以表达系统模型元素

5、的静态结构关系。 包的嵌套可以清晰地表现系统模型元素之间的相互关系。但嵌套不宜过深，包的嵌套层数一般以 2 3层为宜。 例：图 9.3是包的嵌套的一个示例，它表示一个通用图形编辑器的组织结构。 包与它的元素的组成关系可以用树形结构表示，这对于表达概念模型是有用的。例如，图 9.4是图 9.3的树形表示，只不过它不能表达子包之间的依赖联系。 对于一个包可视的元素，对于该包的内嵌套子包也是可视的。 9.1.2 包的嵌套 Home 例：包的嵌套示例，如图 9.3所示。 9.1.2 包的嵌套 Home 图 9.3 包的嵌套示例 例：包中元素的树形结构示例，如图 9.4所示。它是图 9.3的树形表示。

6、9.1.2 包的嵌套 Home 图 9.4 包中元素的树形结构 对于一个包可以加上构造型或标记值说明其特定的性质，如说明包的开发者，包所提供的服务等。 UML预定义的用于包的构造型有： 、 、 、 等。 构造型 说明一个包仅仅是其他一些包的视图。 构造型 说明一个包代表模型架构。 构造型 说明一个包是另一个包的公共内容的服务代理。 构造型 说明一个包代表系统模型的一个独立部分，即子系统。 构造型 说明一个包代表系统模型。 构造型 和 特别有助于管理大型系统模型。 9.1.3 标准构造型 Home 9.2 包的联系 Home 9.2.1 依赖与输入依赖 9.2.2 泛化 9.2.3 合并 包与包

7、之间的联系主要有两种：依赖（尤其是输入依赖）和泛化。 两个模型元素之间存在着依赖是指一个元素的定义的改变会引起另一个元素发生相应改变。 对于对象类来说，依赖联系有多种情况，如一个类以另一个类作为其数据的一个部分，一个类用另一个类作为操作的参数等。 两个包之间存在着依赖通常是指这两个包所含的模型元素之间存在着一个或多个依赖。 9.2.1 依赖与输入依赖 Home 对于由对象类组成的包，如果在两个包的任何对象类之间存在着任何一种依赖，则这两个包之间存在着依赖。 包的依赖联系同样是用一条虚箭线表示，虚箭线从依赖包（源）指向独立包（目标）。 包的依赖联系没有传递性。 例： “ 订货 ” 包与 “ 顾客

8、 ” 包之间存在着依赖，如图 9.5所示。 9.2.1 依赖与输入依赖 Home 例：包的嵌套与泛化示例，如图 9.5所示。 9.2.1 依赖与输入依赖 Home 图 9.5 包的嵌套与泛化示例 包的依赖联系可以加上许多构造型规定它的语义，其中最常见的一种依赖是输入依赖。 输入依赖（ Import Dependency）是包与包之间的一种存取（ Access）依赖关系。输入（ Importing）是指允许一个包中的元素存取另一个包中的元素。输入依赖是单向的。输入依赖没有传递性。 包的公共部分，即其可视性为“公共”的模型元素，称为包的输出（ Export）。包的输出只对另一个与它有输入依赖的包才

9、是可视的、可存取的。 输入依赖的表示方法是在虚箭线上标有构造型，箭头从输入方的包指向输出方的包。 注意，存取依赖联系的另一个构造型 ，与的含义略有差别。 9.2.1 依赖与输入依赖 Home 例：包的输入依赖示例，如图 9.6所示。 9.2.1 依赖与输入依赖 Home 图 9.6 包的输入依赖示例 泛化联系表达事物的一般与特殊的关系。如果两个包之间存在有泛化联系，意指其中的特殊性包必须遵循一般性包的接口。 实际上，对于一般性包可以加上一个性质说明“ abstract”，表明它只不过是定义了一个接口，该接口可以由多个特殊包实现。 与类的继承相同，特殊包从一般包继承其所含的公共类，并且可以重载和

10、添加自己的类。特殊包可以代替一般包，用在一般包使用的任何地方。 例如，在图 9.5中包 “ 数据库接口 ” 与包 “ Oracle接口 ” 、 “ Sybase接口 ” 之间存在泛化联系。其中， “ 数据库接口 ” 包是一般包， “ Oracle接口 ” 包和 “ Sybase接口 ” 包是特殊包。 9.2.2 泛化 Home 包之间的合并联系也是一种依赖关系，它用一条带有构造型的虚箭线表示，从接受合并包（ Receiving Package）指向被合并包（ Merged Package）。 包合并联系允许被合并包的内容与接受合并包的内容合并，即（在概念上而非物理上）把被合并包中的全部元素合并

11、加入到接受合并包中，而被合并包与接受合并包中的那些具有相同名称的元素则合并成一个唯一的元素，它拥有两者的特征。 当定义在不同的包中的模型元素具有相同的名称并且表达相同的概念时，就需要使用包合并联系。 例：在图 9.7中，包 P和 Q与包 W之间存在合并联系，如图 9.7（ a）所示。它的含义是（在概念上）包 P和 Q中的全部模型元素 类 A、B、 C合并到包 W中，其中合并后包 W的类 A的内容是包 P和 Q各自的类 A与包 W中原来的类 A（可分别记作 P:A、 Q:A和 W:A）合并的结果，类 W:A的属性和操作来自 P:A、 Q:A和 W:A，如图 9.7（ b）所示。 9.2.3 合并

12、 Home 例： 包 P和 Q中的类 A、 B、 C合并到包 W中 ，如图 9.7所示。 9.2.3 合并 Home W A Sno:Int Sname:String Deptno:Int Op1( ) Op2( ) C B D P A Sno:Int Sname:String Op1( ) B A Deptno:Int Op2( ) Q C W D A (a) (b) 图 9.7 包合并示例 包图由包和包之间的联系构成。包图的图形节点是包，节点之间用弧（依赖或泛化）连接。 包图是维护和控制系统总体结构的重要建模工具。 包在很多方面与对象类相似，但是在建立系统模型时特别要注意区别包与类。 对象

13、类是问题领域或解决方案中的事物的抽象，包是把这些事物组织成模型的一种机制。 包可以没有标识，因为它没有实例，在运行系统中不可见；类必须有标识，它有实例，类的实例（对象）是运行系统的组成元素。 9.3 包图 Home 例：一个常规的信息管理系统的包图，如图 9.8所示。 9.3 包图 Home 图 9.8 一个信息管理系统的包图 9.4 包图的应用 Home 9.4.1 包图的建立 9.4.2 系统建模 9.4.3 开发跟踪 使用包的目的是把模型元素组织成组，为其命名，以便作为整体处理。 对于一个大型的复杂的系统，常需要把系统设计模型中的大量的模型元素组织成包和子系统（子系统是特殊的包），给出它

14、们之间的联系，以方便理解和处理整个模型。 建立包图的具体的做法如下 ： （ 1） 分析系统模型元素 （ 通常是对象类 ） ， 把概念上或语义上相近的模型元素纳入一个包 。 （ 2） 对于每一个包 ， 标出其模型元素的可视性：公共 、 保护或私用 。 （ 3） 确定包与包之间的依赖联系 ， 特别是输入依赖 。 （ 4） 确定包与包之间的泛化联系 ， 确定包元素的多态性与重载 。 （ 5） 绘制包图 。 （ 6） 包图精化 。 Home 9.4.1 包图的建立 一个包应当具有高内聚性，包中的对象类都应功能相关。 以下几点可作为分析对象类的功能相关性的参考： 如果一个类的行为和 /或结构的变更要求另一个类作相应的变更 ，则这两个类是功能相关的 。 如果删除了一个类后 ， 另一个类便变成是多余的 ， 则这两个类是功能相关的 。 这说明该剩余的类只为那个被删除的类所使用 ， 它们之间有依赖联系 。 如果两个类之间有大量的频繁交互或通信 ， 则这两个类是功能相关的 。 如果两个类之间有一般 /特殊关系 ， 则这两个类是功能相关的 。 如果一个类激发创建另一个类的对象 ， 则这两个类是功能相关的 。 如果两个类不涉及同一个外部活动者，则这两个类不应放在同一个包内。 Home 9.4.1 包图的建立 利用包图可以对系统建模。 系统的结构可以