系統概要设计中的UML静态建模.docVIP

4.2 UML包图 4.2.1 UML中的包图 1．UML中的包和包图（Package Diagram） 一个企业应用系统中可能包含数百个类，如何有效地管理这些类就成了一个需要解决的问题。一种有效的管理方式是将类分组，功能相似或相关的类组织在一起，形成功能模块或者子系统。在各种面向对象的编程语言中都提供了对类进行分类管理的机制——如Java语言的包（Package），而在UML中，对类或者其他的模型元素进行分组时则使用包图。 （1）包图是保持系统整体结构简明、清晰的重要工具。 在Rational Rose中对包采用类似于文件夹的符号来表示（如图4.19所示的“留言功能包”、“用户权限管理包”），并且一个包可嵌套在另一个包中形成子包。使用包图可以将相关模型元素分组，包图由包和包之间的关系构成，它是维护和控制系统总体结构（系统架构）的重要建模工具。 （2）在Rational Rose2003中的包图是通过类图来体现的。 如果某个包为其他包的子包，则应该将子包放入父包中，如图4.19所示。 图4.19 Rational Rose2003中的包图是通过类图来体现的 2．包之间的关系及其UML图示 在设计包时，首先要决定系统中应该有哪些包，比如要尽量将系统中不稳定的模型元素和相对稳定的模型元素分配到不同包中，以提高软件系统的可维护性；或者将可选功能和核心功能实现分置于不同的包或子包之中。 其次决定包之间的关系，包之间存在两种关系：依赖和泛化（继承或者构成）。下面分别介绍这两种关系，以及它们在Rational Rose中的具体实现。 （1）包之问的依赖关系。 如果对类A的修改会导致类B的改变，则称B依赖于A。如果两个包中存在具有依赖关系的两个类，则认为这两个类所属的两个包之间则存在着依赖关系。图4.19所示的“留言功能包”和“用户权限管理包”之间存在依赖。 包之间的依赖关系应尽量简单、稀疏，通常要求某一包中的模型元素只与同层及相邻下一层的模型元素之间存在依赖关系。 （2）包之间的泛化关系。 包之间的泛化关系其实更多的是指包之间的构成关系，也就是指在某个包中嵌套包含其他的包，即包中不仅可包含类等模型元素，还可以包含子包。图4．19所示的“用户权限管理包”中包含有“用户信息包”，称“用户信息包”为“用户权限管理包”中的子包。 3．包图的应用目的 （1）能够体现系统的层次关系。 使用包圈的目的是把模型元素组织成组或者集合并为其命名，以便作为一个整体进行处理。对于一个大型的软件系统，使用包来组织大量模型元素以便于系统的理解和处理，使之有很好的层次关系。 （2）通过包可以形成一个高内聚、低耦合的类的集合。 （3）在概要设计阶段，设计人员可以用包图来建立软件系统的体系架构。 4.2.2 Rational Rose2003对UML包图的支持 1．设计项目包图中的各个包 （1）新建项目中的各个包。 右击【Logical View】的节点，在弹出的快捷菜单中选择【New】，然后再选择【Package】菜单项，如图4.20所示。 图4.20新建项目中的各个包 （2）命名该包图。 输入包的名称为“表示层包”，如图4.20所示的输入图示。 （3）根据具体的应用要求设计其子包。 当然也可以在该包的基础上再产生出其子包，如图4.2l所示。 图4.21设计项目中各个包的子包 （4）分别设计其他的各个子包。 分别对各个包和对应的子包进行设计和命名，如图4.22所示。 图4.22分别设计其他的各个子包 2．设计项目中的包圈 （1）新建一个包图。 右击【Logical View】的节点，在弹出的快捷菜单中选择【New】，然后再选择【class Diagram】菜单项，如图4.23所示。 图4.23设计项目中的包圈 （2）命名该包图。 输入包图的名称为“BBS系统前台包图”，如图4.23所示。 （3）在该包图中分别添加各个不同的包。 将需要的各个包从左侧的层次树拖动到右侧的包图中，如图4 24所示。 图4.24在该包圈中分别添加各个不同的包 （4）决定各个包之问的组成关系。 根据系统层次划分的要求，分别添加各个不同的包所对应的子包，如图4.25所示。 图4.25 分别添加各个不同的包所对应的子包 （5）设计完成后的结果如图4.26所示。 图4.26项目巾的各个包及对应的包图 3．设置项目包图内各个包之问的依赖关系 包与包之间的依赖关系是由包中的类与另一个包中的类是否存在关联关系来决定的，不允许包与包之间直接发生相互依赖。因此，如果在系统层次划分的过程中发现有这样的依赖关系存在，那就说明项目系统中包的设计有问题，需要考虑将这两个包合并或重新分配包中的类。比如，如果有A包和B包，A包与B包产生泛化关系，那就不允许出现B包依赖A包的情况。 本项目