类图中箭头的含义

 

关系

后面的例子将针对某个具体目的来独立地展示各种关系。虽然语法无误，但这些例子可进一步精炼，在它们的有效范围内包括更多的语义。

 

依赖（Dependency）

实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例（图D）。 更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所 示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。也可利用“依赖”来表示包和包之间的关系。由于包中含有类，所以你可根据那些包中的 各个类之间的关系，表示出包和包的关系。

 图D

依赖详解：

     假如A依赖B，那么依赖在类中的写法就是，将B类当做A中一个方法的参数。

关联（Association） 

实体之间的一个结构化关系表明对象是相互连接的。箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。在Java中，关联（图E） 转换为一个实例作用域的变量，就像图E的“Java”区域所展示的代码那样。可为一个关联附加其他修饰符。多重性（Multiplicity）修饰符暗示 着实例之间的关系。在示范代码中，Employee可以有0个或更多的TimeCard对象。但是，每个TimeCard只从属于单独一个 Employee。

 图E

详细解释：

      关联associations：是类之间的词法连接，使一个类知道另一个类的公开属性和操作。关联有单向和双向之分。如果两个类是双向关联的，rose将属性放进彼此类中。单向关联如下图所示，则person知道house的公开属性和操作，而house不知道person的。交互图中person可以向house发消息，而house不可以向person发消息。 

聚合（Aggregation）

聚合（图F）是关联的一种形式，代表两个类之间的整体/局部关系。聚合暗示着整体在概念上处于比局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别。聚合也转换成Java中的一个实例作用域变量。 7MIrrhk
yC7lR#N8j0
关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。聚合还暗示着实例图中不存在回路。换言之，只能是一种单向关系。

 图F

合成（Composition）

合成 （图G） 是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。合成也是非共享的。所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局 部的存活状态，要么负责将其销毁。局部不可与其他整体共享。但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。

Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。

 图G

泛化（Generalization）

泛化（图H）表示一个更泛化的元素和一个更具体的元素之间的关系。泛化是用于对继承进行建模的UML元素。在Java中，用extends关键字来直接表示这种关系。空心箭头+实线

 图H

实现（Realization）

实例（图I）关系指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。空心尖头+虚线

 图I

 

首先要说明的是概念。《设计模式》一书中没有使用“组合”这个概念，而UML表示中一般没有使用“相识”这个概念。但是两者实际上存在如下的对应关系：
/
《设计模式》 UML 表示的意义
聚合 组合 聚合/组合 对象和其所有者具有相同的生命周期
相识 聚合 一个对象仅仅知道另一个对象
/
不过，这个对应关系也不是绝对的。

1、 UML中还有一种关系叫“关联”，《设计模式》中对这种关系的说明很准确：“OMT还定义了类间的关联（association）关系，以类间的一条线来表示。关联关系是双向的。虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。”也可以说“关联”到代码的映射是一对多的，并且这种一对多的关系会影响到模式的选择。
2、 UML中“组合”“聚合”的概念是用来表示对象的静态结构的，因此我们可以这样认为：“组合”就是用成员变量实现的，而“聚合”就是用指向某个对象的指针来实现的。当然，这里略去了对成员函数的参数的考虑。
3、 《设计模式》中对“聚合”和“相识”的关系描述如下：“C++中，聚合可以通过定义表示真正实例的成员变量来实现，但更通常的是将这些成员变量定义为实例指针或引用；相识也是以指针或引用来实现。”“从根本上讲，是聚合还是相识是由你的意图而不是由显式的语言机制决定的。”通过这两个说明，可以看到《设计模式》中认为“聚合”和“相识”关系是运行时的动态特性，从这点上来说和UML有本质的区别。另外，《设计模式》中对这两者动态特性描述如下：“聚合关系使用较少且比相识关系更持久；而相识关系则出现频率较高，但有时只存在于一个操作期间，相识也更具动态性，使得它在源代码中更难被辨别出来。”显然，这种描述只是说到了量的问题，而没有说到质的问题，从这里还是看不出“聚合”和“相识”到底在运行时有什么本质不同。