虽然平时也画了不少UML建模图，但是对其中一些关系的理解感觉还是不是很到位，对大多数初学者来讲泛化和实现容易理解，依赖和关联相对有点模糊。通过这篇文章的整理希望能对UML关系有进一步的理解，在以后的建模设计中能够比较合理准确的进行建模。

UML定义的关系主要有六种：泛化、实现、依赖、关联、聚合和组合。下面我们一一来解释下：

一、泛化（继承generalization）：

泛化是一种特殊与一般关系，特殊元素(子元素)的对象可替代一般元素(父元素)的对象，用这种方法，子元素共享了父元素的结构和行为。在语言实现中就是继承，子类和父类，子接口和父接口之间的关系。在类图中用用一条实线加空心箭头来表示。

二、实现（realization）：

实现在UML中主要体现两点：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。在图形上把一个实现关系画成一条虚线加空心箭头来表示。

三、依赖（dependency）：

依赖是两个事物间的语义关系，其中一个事物(独立事物)发生变化会影响另一个事物(依赖事物)的语义。在图形上把一个依赖画成一条单箭头方向的虚线。

可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面就是A中的某个方法把B的对象作为参数使用(假设A依赖于B)。

四、关联（association）：

1.聚合关联（Aggregation）：体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与cpu、公司与员工的关系等。部分可以离开整体独立存在。

2.组合关联（Composition）：体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑。部分不能离开整体独立存在。

3.单向关联：C1—>C2：表示相识关系，指C1知道C2，C1可以调用C2的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。单向关联的代码就表现为C1有C2的实例引用，而C2对C1一无所知。

4.双向关联：C1—C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。

看一个能体现这几种关系的综合类图：

总结：

1.泛化和实现表现为is-a关系。

2.依赖表现为函数中的参数(use a)。

3.关联（聚合、组合）表现为成员变量（has-a）。

依赖和关联的区别：

A.依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“use”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系，就是“我在某个方法中偶然用到了它，但在现实中我和它并没多大关系”。例如我和锤子，我和锤子本来是没关系的，但在有一次要钉钉子的时候，我用到了它，这就是一种依赖，依赖锤子完成钉钉子这件事情。

B.关联是一种结构关系，表现为一个对象能够获得另一个对象的实例引用并调用它的服务，比如：我们MVC模型中view层拥有bmo层的service实例引用，bmo层拥有dao层实例引用等这种关系就是关联。依赖是一种使用关系，表现为一个对象仅仅是调用了另一个对象的服务。