详解UML中的关系（泛化、实现、依赖、关联【聚合、组合】）

参考:

https://en.wikipedia.org/wiki/Class_diagram

http://www.uml-diagrams.org/class-reference.html

http://umich.edu/~eecs381/handouts/UMLNotationSummary.pdf

 

主要的六种关系:

• 三角: 继承(extends),实现(implements)
• 菱形: 组合(Composition),聚合(Aggregation)
• 箭头: 关联(Association),依赖(Dependency)

---

[下面为转载整理]

 

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

 

一、泛化（继承generalization），Java的extends关键字：

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

    

       

 

实现（realization），Java的implements关键字：

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

    

      

 

二、依赖（dependency）：

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

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

   

      

 

关联（association）：实线（或带箭头）指向关联类。

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

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

 

三、组成型

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

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

 

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

       

 

 

 总结：

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

2.聚合和组合,表现为成员变量（has-a）

3.依赖和关联,表现为函数中的参数(use a)。

 

注：依赖和关联的区别：

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

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

 

另外，还要说明一下，所谓的这些关系只是在某个问题域才有效，离开了这个问题域，可能这些关系就不成立了，例如可能在某个问题域中，我是一个木匠，需要拿着锤子去干活，可能整个问题的描述就是我拿着锤子去钉桌子、钉椅子、钉柜子等；既然整个问题就是描述这个，我和锤子就不仅是偶然的依赖关系了，我和锤子的关系变得非常的紧密，可能就上升为聚合关系。这个例子举得可能不是太合适，但也说明一个道理，就是关系和类一样，它们都是在一个问题领域中才成立的，离开了这个问题域，可能就改变了。因此，不要拘泥不化。

UML也不是完美的，它是为了把思维逻辑给图形化，更易于事情的把握和操作。因此重点在表意，不要囿于形式。

 

 

--------------------------------------------------------------------------

文章参考自：

http://blog.csdn.net/gyb2013/article/details/8036969

http://blog.chinaunix.net/uid-26874207-id-4115795.html