UML建模风格之包图

document.body.oncopy = function() { if (window.clipboardData) { setTimeout(function() { var text = clipboardData.getData("text"); if (text && text.length>300) { text = text + "\r\n\n本文来自CSDN博客，转载请标明出处：" + location.href; clipboardData.setData("text", text); } }, 100); } } function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}

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

1. 描述你的需求高阶概述。
2. 描述你的设计的高阶概述。
3. 在逻辑上把一个复杂的图模块化。
4. 组织Java源代码。

指南∶

类包图

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

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

把子包放置在母包的下面

垂直地分层类包图

用例包图

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

在用例包图上包含角色

水平地排列用例包图

包

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

应用包是为了简化图

包应该连贯

在包上用版型注明架构层

避免包间的循环依赖

包依赖应该反映内部关系

一、类包图

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

图1描述了一个组织成包的UML类图。 除了以下介绍的包原则之外，应用下列的规则来把UML类图组织到包图里：

把一个框架的所有类放置在相同的包中。一般把相同继承层次的类放在相同的包中。彼此间有聚合或组合关系的类通常放在相同的包中。彼此合作频繁的类，信息能够通过UML顺序图和UML合作图反映出来的类，通常放在相同的包中。

图1.一个类包图。

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

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

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

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

4.垂直地分层类包图。

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

二、用例包图

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

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

除了以下介绍的包原则之外，应用下列的规则来把UML用例图组织到包图里：

把关联的用例放在一起∶included、extending、和inheriting的用例放在相同的包中，就像base/parent用例一样。

组织用例应该以主要主角的需要为基础。 例如，在图2中，Enrollment包包含与登记班级的学生有关的用例，一个大学提供的重要服务集合。

图2.一个包含主要的包的UML用例包图。

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

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

3.水平地排列用例包图

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

三、包

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

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

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

2.应用包是为了简化图

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

3.包应该连贯

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

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

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

5.避免包间的循环依赖

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

6.包依赖应该反映内部关系

当一个包依赖于另一个是，这意味着两个包的内容间存在着一个或多个的关系。 例如：如果是一个用例包图，那么就有可能两个用例之间存在includes、 extends、或继承关系，而两个用例分别处于不同的包中。