UML中的“关系”总结

UML中，事物之间的联系方式，无论是物理上的，还是逻辑上的，都用“关系（relationship）”来建模。在面向对象的建模中，将“关系”细分为三种：依赖、泛化、关联。下面分别说明。

 

1、 依赖（dependency）

依赖是一种使用关系。它表示一个事物的变化会影响到所有使用它的事物的行为。在UML图形表示法中，依赖用一个带方向的虚线来表示，箭头指向被依赖的事物。

            

 针对面向对象的“类”来说，如果一个类A使用另外一个类B作为其函数的参数，或者作为本地变量，那么就说A依赖于B。

事实上，“依赖”关系不仅仅在类之间存在，UML中的“包”之间也经常存在这种关系。

 

2、 泛化

泛化是一种“is-a”的关系，它表示一般事务（父类）和该事物的更具体更特殊的类（子类）之间的一种关系。

在图形上，泛化用一条带有空心大箭头的有向实线来表示，箭头方向指向父类。

 

作为延伸，或者说是一种特殊的“泛化”, 出现了事务之间的另外一种关系，即“实现（realization）”。在类的实现关系中，一个类描述了另外一个类必须实现的契约，即接口。

也有人说，实现是一种和泛化、依赖都不同的另外一种关系，但不可否认的是，实现和泛化、依赖有着千丝万缕的联系，它是泛化和依赖在语义上的结合；从某种程度上说，可以认为实现是一种泛化，也可以认为实现是一种“依赖”。因此，在图形上，实现就用泛化和依赖的结合形式来表示：用带有空心大箭头的虚线来表示，箭头指向描述契约的那个类。

 

以上这种形式是实现的规范描述形式，另外针对实现关系，还有一种省略方式：用接口的棒棒糖型表示法——你看到那个大大的棒棒糖了吗？

 

 

3、 关联（association）

关联表示的是一种结构关系。它描述了一个事物与另外一个事物的对象之间的拥有关系。例如Library类和Book类之间具有一个一对多的关联关系，它表明一个Library可以有多个Book，但是一个Book仅仅只能被一个Library所拥有。

在图形上，关联使用细的实线来表示。

一般地，用细实线连接起来的两个类是双向导航的，也就是说可以从一个类导航到另外一个类。举例来说，Person类和Company类就是双向导航的。但是，有时也可以讲导航限制为单项的，例如User类和Password类——我们可以从User类导航到Password类，但是不能从Password类导航到User类。这种单向的导航关系，在图形上用带有箭头的实现来表示，箭头的方向表示导航的方向。

        

    上述的简单关联，表示被关联的两个类在概念上其地位是相等的，谁也不比谁中要。然而，有些类之间具有“整体/部分”的关系，也就是说，一个大的整体由较小的部分组成。在UML中，表示这种“组成”关系的建模方式有两种：聚合和组合。

 

聚合（aggregation）

    聚合表示一种has-a的关系，暗示着较大的对象拥有这较小的对象，然而这种拥有关系不是那种一损俱损的强拥有关系，也就是说，“大对象”的生命期结束的时候，“小对象”的生命期并不受影响。举例来说，机场和飞机就是这种聚合关系。

    在图形上，聚合用一个空心的菱形加上实线来表示，菱形放置在表示整体的类的那端。

 

组合（composition）

    组合关系是对聚合关系的加强，它说明大对象不仅仅拥有小对象，而且他们是一个有机体，具有共同的生命周期，一损俱损。例如汽车和车轮就是这种关系。

    在图形上，组合使用实心的菱形和实线来表示。