区分关联、依赖和聚集关系

    Rational Rose的帮助文档上是这样定义“依赖”关系的：“依赖描述了两个模型元素之间的关系，如果被依赖的模型元素发生变化就会影响到另一个模型元素。典型的，在类图上，依赖关系表明客户类的操作会调用服务器类的操作。”
　　Martin Fowler在《Reducing Coupling》一文中这样描述耦合：“如果改变程序的一个模块要求另一个模块同时发生变化，就认为这两个模块发生了耦合。” [Fowler 2001]
　　从上面的定义可以看出：如果模块A调用模块B提供的方法，或访问模块B中的某些数据成员（当然，在面向对象开发中一般不提倡这样做），我们就认为模块A依赖于模块B，模块A和模块B之间发生了耦合.

    依赖关系的特征

    对于两个相对独立的系统，当一个系统负责构造另一个系统的实例，或者依赖另一个系统的服务时，这两个系统之间主要体现为依赖关系，例如生产零件的机器和零件，机器负责构造零件对象。再例如充电电池和充电器，充电电池通过充电器来充电。再例如自行车Bicycle和打气筒Pump，自行车通过打气筒来充气。在现时生活中，通常不会为某一辆自行车配备专门的打气筒，而是在需要充气的时候，从附近某个修车棚里借个打气筒打气。

    Bicycle类与Pump类的依赖关系

    关联关系的特征
    对于两个相对独立的系统，当一个系统的实例与另一个系统的一些特定实例存在固定的对应关系时，这两个系统之间为关联关系。例如客户和订单，每个订单对应特定的客户，每个客户对应一些特定的订单；再例如公司和员工，每个公司对应一些特定的员工，每个员工对应一特定的公司；再例如自行车和主人，每辆自行车属于特定的主人，每个主人有特定的自行车。而充电电池和充电器之间就不存在固定的对应关系，同样自行车和打气筒之间也不存在固定的对应关系。
    主人和自行车的关联关系

    当系统A被加入到系统B中，成为系统B的组成部分时，系统B和系统A之间为聚集关系。例如自行车和它的响铃、龙头、轮胎、钢圈以及刹车装置就是聚集关系，因为响铃是自行车的组成部分。而人和自行车不是聚集关系，因为人不是由自行车组成的，如果一定要研究人的组成，那么他应该由头、躯干和四肢等组成。由此可见，可以根据语义来区分关联关系和聚集关系。

聚集关系和关联关系的区别还表现在以下方面：

（1) 对于具有关联关系的两个对象，多数情况下，两者有独立的生命周期。比如自行车和他的主人，当自行车不存在了，它的主人依然存在；反之亦然。但在个别情况下，一方会制约另一方的生命周期。比如客户和订单，当客户不存在，它的订单也就失去存在的意义。

(2) 对于具有聚集关系（尤其是强聚集关系）的两个对象，整体对象会制约它的组成对象的生命周期。部分类的对象不能单独存在，它的生命周期依赖于整体类的对象的生命周期，当整体消失，部分也就随之消失。比如小王的自行车被偷了，那么自行车的所有组件也不存在了，除非小王事先碰巧把一些可拆卸的组件（比如车铃和坐垫）拆了下来。