?? ? ?包图是在 UML 中用类似于文件夹的符号表示的模型元素的组合。系统中的每个元素都只能为一个包所有，一个包可嵌套在另一个包中。使用包图可以将相关元素归入一个系统。一个包中可包含附属包、图表或单个元素。
一个"包图"可以是任何一种的UML图组成，通常是UML用例图或UML类图。 包是一个UML结构，它使得你能够把诸如用例或类之类模型元件组织为组。 包被描述成文件夹，可以应用在任何一种UML图上。 虽然包图并非是正式的UML图，但实际上他们是很有用处的， 创建一个包图是为了∶
描述你的需求高阶概述。
描述你的设计的高阶概述。
在逻辑上把一个复杂的图模块化。
组织Java源代码。
指南∶
类包图
创建类包图，以在逻辑上组织你的设计
创建UML组件图，以在物理上组织你的设计
把子包放置在母包的下面
垂直地分层类包图
用例包图
创建用例包图，以组织你的需求
在用例包图上包含角色
水平地排列用例包图
包
包的命名要简单、具有描述性
应用包是为了简化图
包应该连贯
在包上用版型注明架构层
避免包间的循环依赖
包依赖应该反映内部关系
一、类包图
1.创建类包图，以在逻辑上组织你的设计
??图１描述了一个组织成包的UML类图。 除了以下介绍的包原则之外，应用下列的规则来把UML类图组织到包图里：
?
把一个框架的所有类放置在相同的包中。 一般把相同继承层次的类放在相同的包中。 彼此间有聚合或组合关系的类通常放在相同的包中。 彼此合作频繁的类，信息能够通过UML顺序图和UML合作图反映出来的类，通常放在相同的包中。
图1.一个类包图。
2.创建UML组件图，以在物理上组织你的设计。
??如果你的组件比较接近技术，例如那些通过Enterprise Java Beans ( EJB)或Visual Basic的组件，你应该优先选择UML组件图来描述物理设计，而不是包图。 图１的版本源自于组件图章节中。就像你看到的，这个图最适用于物理设计。 永远记住遵循敏捷建模(AM) ( Ambler 2002)的实践－－应用合适的Artifact，为工作挑选最好的模型。
3.把子包放置在母包的下面。
??图１描述了包间的继承，你可以看到，继承的包显示在母包支下。 这和UML类图中的在超类下面放置子类的指南是一致的。
4.垂直地分层类包图。
??包间的依赖表明，从属的包的内容依赖于另一个包的内容，或结构上依赖于其它包的内容。 在图１中你可以看到图中的??类交互，领域类又使用基础结构类，基础结构类访问数据库。传统的，这种分层的顺序是以从上到下的方式描述的。
二、用例包图
??用例通常是面向对象开发方法学中的最主要的需求artifact，当你的方法是统一过程(Kruchten 2000; Ambler 2000)实例是尤其如此。而且对于大的项目包图来说，通常是创建用来组织使用需求的。
1.创建用例包图，以组织你的需求
??除了以下介绍的包原则之外，应用下列的规则来把UML用例图组织到包图里：
??把关联的用例放在一起∶included、extending、和inheriting的用例放在相同的包中，就像base/parent用例一样。
??组织用例应该以主要主角的需要为基础。 例如，在图2中，Enrollment包包含与登记班级的学生有关的用例，一个大学提供的重要服务集合。
图2.一个包含主要的包的UML用例包图。
2.在用例包图上包含角色
??图2包含包图上的角色，这有助于把包放在上下文中理解，这样包图就会更容易为读者所理解。
3.水平地排列用例包图
??用例包图的主要受众是项目干系人。因此图的组织应该能够反映他们的需求。 图2中的包是水平放置的，从左到右画出的依赖关系反映了西方文化的阅读习惯。
三、包
??本节中出现的建议可应用到任何一种UML图的包应用上，并非只是包图上。
1.包的命名要简单、具有描述性
??在图１和图２中，包都有简单的、描述性的名称，例如Shipping、Customer、Enrollment和Manage Student Loans和Grants，这样包包含了些什么就非常的清楚了。
2.应用包是为了简化图
??通常在一个图变得笨重，单一页中打印不下的时候引入包。换句话说，遵循通用指南－－把大的图重新组织为较小的图，你需要对模型使用分而治之的方法。
3.包应该连贯
??你插入包中的任何东西都应该有意义，都需要考虑包中的其余内容。 为了确定一个包是否连贯，一个好的经验法则是你是否能够用一个短的，描述性的名称为包命名。 如果你做不到这一点，你或许就已经把几个不相关的事务放到包中了。
4.在包上用版型注明架构层
??我们通常会把设计组织到架构层次中，例如user interface、business/domain、persistence/data、和infrastructure/system。 在图１中你可以看到例如user interface、domain、infrastructure和database的版型应用包中，以反映通用的层。
5.避免包间的循环依赖
??包A依赖于包B，包B依赖于包C，而包C依赖于包A，这就形成了一个循环：A－B－C- A， Knoernschild ( 2002)建议尽量避免出现这种情况。 因为包之间彼此紧密耦合，将来的维护和改进将变得困难。 循环依赖是一个很好的信号，意味着你需要重构一个或多个的包，把导致循环依赖的因素从包中除掉。
6.包依赖应该反映内部关系
??当一个包依赖于另一个是，这意味着两个包的内容间存在着一个或多个的关系。 例如：如果是一个用例包图，那么就有可能两个用例之间存在includes、 extends、或继承关系，而两个用例分别处于不同的包中。
