在合作中对包图验收没有通过，对包图的理解不深刻，整幅图中，在包与包之间，只用了两种关系：实现和import。因此需要重新修改，可是修改起来比较费劲儿，于是查资料，跟霍亚静师傅和连江伟师傅交流，对包图有了更深一步的认识。下面跟大家说说我对包图理解的过程。有理解不正确的地方，还请指出。
我给两位师傅发出了这样的疑问：
师傅，关于包图有一些疑问，在网上查了些资料，但是看不懂。。。
包图的关系理得不清楚。四种关系：use，import，access，trace。什么叫命名空间合并。什么是元素间的依赖和包间的依赖。
还附带两个链接：
http://www.doc88.com/p-5826867675960.html
http://blog.csdn.net/ggibenben1314/article/details/8570162
霍师傅给的回复是：
包图是如何引用出来的？它的出现究竟起到了什么作用？
霍师傅从包图的来源意义让我从整体上去理解包图。
一个"包图"可以是任何一种UML图组成，大家都知道，UML图共九种：用例图、类图、对象图、顺序图、协作图、状态图、活动图、构件图、部署图。也就是说一个包图可以是用例图打包构成的，叫做用例包图。一个包图可以是类图打包构成的，叫做类包图。常用的就是这两种包图。用例图是用来描述系统需求的，因此用例包图是为了组织需求。类图是用来描述对系统设计的，因此类包图是在逻辑上组织系统设计。
在机房合作中应用的是类包图。
百度百科中讲到——应用下列的规则来把UML类图组织到包图里：
1、把一个框架的所有类放置在相同的包中。
2、一般把相同继承层次的类放在相同的包中。
3、彼此间有聚合或组合关系的类通常放在相同的包中。
4、彼此合作频繁的类，信息能够通过UML顺序图和UML合作图反映出来的类，通常放在相同的包中。
自己的理解：
1、机房中是七层框架，U层的类放在U层包中，B层的类放在B层包中，其他层都是如此。
2、3、4，目前还没有见过实例，或者是见到了还没有识别。希望大家可以分享一下自己的理解。
应用包图的过程中要注意：
1、避免包间的循环依赖
2、包的命名要简单，具有描述性。这跟我们写代码是一样的准则，让名字有意义。
连师傅给的回复是针对我问的包图间的关系。根据师傅给的资料（简直太棒了！）
http://yunli.blog.51cto.com/831344/188692/
理解到：
包之间的关系网上有两种说法：
（1）use（使用），import（引入），access(访问)，trace（跟踪）
（2）Dependency（依赖）（包含import dependency），Abstraction（泛化），Nesting（嵌套）
EA软件中的可选关系比较细致，上边提到的都囊括了：
import VS access：
包引入（package import）是一种允许采用非限定性名称访问来自于另一个命名空间中的元素的关系。假如我们有一个包A和一个包B，如果包A没有引入包B，那么包A在访问包B时，必须采用限定性名，比如B::Integer。当包A引入了包B以后，则可以采用非限定性名称进行访问，此时A可以直接用Integer来访问包B中的Integer。对于包的引入，其如同C#/C++语言中的using namespace关键字，也如同于Java语言中的import关键字。
我们都知道类中有public,private等修饰符来描述类的方法和变量。同样，包图中也有这一属性值，用public和private来描述可见性。public 对应import 关系，private对应access关系。这两个都是引入。但是，举个例子：
包A<----<<access>>----包C；
包B<----<<import>>----包C；
包C<----<<import>>----包D。
则在C中可以采用非限定性名访问包A和包B，而在D中可以采用非限定性名访问包B和包C，而不能采用非限定性名访问包A。<<import>>关系是可传递的，但<<access>>关系则不可以。
Dependency：
对于由对象类组成的包，也就是如果两个包中的任意两个类存在依赖关系，则成为包之间存在依赖关系。
Abstraction：
泛化关系表示事物的一般和特殊的关系。如果两个包之间存在泛化关系，就是指其中的特殊性包必须遵循一般性包的接口。就像类的继承一样，包可以替换一般的元素，并可以增加新的元素。
Nesting：
包可以将其他包作为包内的元素，子包又可以拥有自己的子包，这样就可以构成一个系统的嵌套结构，以表达系统模型元素的静态结构关系。嵌套不宜过深，一般以2到3层为宜。
整理到现在，感觉对包图的知识了解一些，但是依旧理解不深刻。过两天就忘了，还得需要多实践才行。
