UML建模风格之UML包图

本文和大家重点讨论一下UML包图，一个"包图"可以是任何一种的UML图组成，通常是UML用例图或UML类图。 并且包被描述成文件夹，可以应用在任何一种UML图上。

 UML建模风格之UML包图

一个"包图"可以是任何一种的UML图组成，通常是UML用例图或UML类图。 包是一个UML结构，它使得你能够把诸如用例或类之类模型元件组织为组。 包被描述成文件夹，可以应用在任何一种UML图上。 虽然包图并非是正式的UML图，但实际上他们是很有用处的， 创建一个UML包图是为了∶

◆描述你的需求高阶概述。

◆描述你的设计的高阶概述。

◆在逻辑上把一个复杂的图模块化。

◆组织Java源代码。

一、类包图

1.创建类包图，以在逻辑上组织你的设计

图1描述了一个组织成包的UML类图。 除了以下介绍的包原则之外，应用下列的规则来把UML类图组织到包图里：
把一个框架的所有类放置在相同的包中。一般把相同继承层次的类放在相同的包中。彼此间有聚合或组合关系的类通常放在相同的包中。彼此合作频繁的类，信息能够通过UML顺序图和UML合作图反映出来的类，通常放在相同的包中。
图1.一个类包图。

2.创建UML组件图，以在物理上组织你的设计。

如果你的组件比较接近技术，例如那些通过Enterprise java Beans ( EJB)或Visual Basic的组件，你应该优先选择UML组件图来描述物理设计，而不是UML包图。 图1的版本源自于组件图章节中。就像你看到的，这个图最适用于物理设计。 永远记住遵循敏捷建模(AM) ( Ambler 2002)的实践－－应用合适的Artifact，为工作挑选最好的模型。

3.把子包放置在母包的下面。

图1描述了包间的继承，你可以看到，继承的包显示在母包支下。 这和UML类图中的在超类下面放置子类的指南是一致的。

4.垂直地分层类UML包图。

包间的依赖表明，从属的包的内容依赖于另一个包的内容，或结构上依赖于其它包的内容。 在图1中你可以看到图中的包反映了架构的合理的层次布局，用户界面和领域类交互，领域类又使用基础结构类，基础结构类访问数据库。传统的，这种分层的顺序是以从上到下的方式描述的。

二、UML用例包图

用例通常是面向对象开发方法学中的最主要的需求artifact，当你的方法是统一过程(Kruchten 2000; Ambler 2000)实例是尤其如此。而且对于大的项目包图来说，通常是创建用来组织使用需求的。

1.创建用例包图，以组织你的需求

除了以下介绍的包原则之外，应用下列的规则来把UML用例图组织到UML包图里：
把关联的用例放在一起∶included、extending、和inheriting的用例放在相同的包中，就像base/parent用例一样。
组织用例应该以主要主角的需要为基础。 例如，在图2中，Enrollment包包含与登记班级的学生有关的用例，一个大学提供的重要服务集合。
图2.一个包含主要的包的UML用例包图。

2.在用例包图上包含角色

图2包含包图上的角色，这有助于把包放在上下文中理解，这样包图就会更容易为读者所理解。

3.水平地排列用例包图

用例包图的主要受众是项目干系人。因此图的组织应该能够反映他们的需求。 图2中的包是水平放置的，从左到右画出的依赖关系反映了西方文化的阅读习惯。

三、UML包图

本节中出现的建议可应用到任何一种UML图的包应用上，并非只是UML包图上。

1.包的命名要简单、具有描述性

在图1和图2中，包都有简单的、描述性的名称，例如Shipping、Customer、Enrollment和ManageStudentLoans和Grants，这样包包含了些什么就非常的清楚了。

2.应用包是为了简化图

通常在一个图变得笨重，单一页中打印不下的时候引入包。换句话说，遵循通用指南－－把大的图重新组织为较小的图，你需要对模型使用分而治之的方法。

3.包应该连贯

你插入包中的任何东西都应该有意义，都需要考虑包中的其余内容。为了确定一个包是否连贯，一个好的经验法则是你是否能够用一个短的，描述性的名称为包命名。如果你做不到这一点，你或许就已经把几个不相关的事务放到包中了。

4.在包上用版型注明架构层

我们通常会把设计组织到架构层次中，例如userinterface、business/domain、persistence/data、和infrastructure/system。在图1中你可以看到例如userinterface、domain、infrastructure和database的版型应用包中，以反映通用的层。

5.避免包间的循环依赖

包A依赖于包B，包B依赖于包C，而包C依赖于包A，这就形成了一个循环：A－B－C-A，Knoernschild(2002)建议尽量避免出现这种情况。因为包之间彼此紧密耦合，将来的维护和改进将变得困难。循环依赖是一个很好的信号，意味着你需要重构一个或多个的包，把导致循环依赖的因素从包中除掉。