分层架构中各层之间关系如何界定，期待大家来讨论
引言：今天小崔问了我一个问题，把我问中了，包与包之间都有哪几种关系，为什么用依赖而不用关联，我感觉是用依赖，但是却说出为什么不用关联，所以专门上网找了一下，正好搜到的是学长的博客，我就直接转过来了，以供大家参考。
正文：
下午开会讨论了关于系统架构设计问题，也引申出关于架构图中包间关系的思考。
其实，主要分歧点是在UML关系中的关联关系和依赖关系，有种观点，认为在架构图（包图关系）中，有一种包间关系叫做关联。
我们大家都知道，在UML中存在5中关系，而从RationalRose2007中支持的UML标准来看，包与包之间，只支持依赖和泛化这两种关系，在Enterprise Architect 7.5 中对包间关系支持的要丰富一些，有Package Merge和Package Import两种关系(可能还要多，希望大家指正)。并且，这两种建模工具中关于包间关系符号，都是基于虚线箭头的表示，唯一区别的就是个别的一些文字标识了。
如下图中4个包图，在做架构的时候，我们应该如何对待这样十分具有指导意义的设计呢？
包图间关系对于指导开发人员做好时序图、交互图，有着一定的作用。那么，如何分辨他们各种关系呢？
对于架构层次的东西，接触的不多，以前一直按照自己的想法来做，并没有太认真的对待他们，今天乍一认真看待，发现这其中关系有点认识不足。
先温故一下概念。
依赖
可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用；
关联
他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；
(关联、依赖解释，摘自：http://www.iteye.com/topic/632059 )
为了更好的区分这两个关系，我们一切从代码实现说起，这样更容易理解一些。
我理解，依赖和关联最大的实现区别就是，一个作用域的问题，也就是上面说到得，类B在类A中的某个方法中使用；类B以类属性(成员变量)的形式关联在类A中。前者的作用于小于后者，于是，我便以此作为分析的基础。(本人拙见，希望指正。)
在ROSE中，包间关系只有依赖和泛化，是正确的。UI和BLL之间存在依赖关系，从根本上可以说，UI中每个界面类的实例对象中都会在每个事件方法中引入相应的BLL类，实例成对象进而完成相应的功能。若，考虑到系统优化、节省资源等，或许我们可以把这其中的UI界面类和BLL中相应类的关系描述为关联，这样岂不是UI和BLL之间会是关联关系？
不是这样的，我的理解，UI和BLL的包中各类之间的关系可能有依赖、有泛化，但是基于包层关系，还是要从基本的规范、出发点开始，也就是对于BLL中相应类，都单独引入到UI类实体对象的方法中去，这样就是依赖关系，而非关联。
在EA中，包间关系，有Package Import，也就是包与包之间(层与层之间的引用，更偏向于实现一些就是引入命名空间，进而能够实例该层类、调用类方法)的引用。
从包的层次角度来看待之间的关系，我更倾向于EA中这种对包间关系的表述。
并且，ROSE下，设计架构图，包间关系没有关联这种关系，而是应该为依赖或泛化(继承)。
如下，我比较认可EA中的这种关系表述：
