UML用户指南（Chapter5--关系）

  在UML中，事物之间相互联系的方式（无论是逻辑上的还是物理上的）都被创建为关系。在面向对象的建模中，有3种最重要的关系：依赖、关联和泛化。

1. 依赖（dependency）是使用关系。例如，水管依赖热水器，对它们所运送的水进行加热。
2. 关联（association）是实例之间的结构关系。例如，房间是由墙和一些其他事物组成的，墙上可以镶嵌门和窗，管道可以穿过墙体。
3. 泛化（generalization）把一般类连接到较为特殊的类，也称为超类/子类关系或父/子关系。例如，观景窗是一种带有固定的大窗格的窗户，庭院窗是一种带有向两边开的窗格的窗户。

  这3种关系覆盖了大部分事物之间相互协作的重要方式。显然，这3种关系也能很好地映射到大多数面向对象编程所提供的连接对象的方式。

 

 

术语和概念

 

  关系（relationship）是事物之间的联系。在面向对象的建模中，最重要的3中关系是依赖、泛化和关联。在图形上，把关系画成一条线，并用不同的线区别关系的种类。

 

  依赖

 

  依赖（dependency）是一种使用关系，说明一个事物（如类Window）使用另一个事物（如类Event）的信息和服务，但反之未必。在图形上，把依赖画成一条有向的虚线，指向被依赖的事物。当要指明一个事物使用另一个事物时，就选用依赖。

  在大多数情况下，在类与类之间用依赖指明一个类使用另一个类的操作，或者它使用其他类所定义的变量和参量。这的确是一种使用关系，如果被使用的类发生变化，那么另一个类的操作也会受到影响，因为这个被使用的类此时可能表现出不同的接口或行为。在UML中，也可以在很多其他的事物之间创建依赖，特别是注解和包。

 

 泛化

  泛化（generalization）是一般事务（称为超类或父类）和该事物的较为特殊的种类（称为子类或子）之间的关系。有时也称泛化为“is-a-kind“关系：一个事物（如类BayWindow）是更一般的事物（如类Window）的“一个种类”。泛化意味着子类的对象可以被用在父类的对象可能出现的任何地方，反之则不然。换句话说，泛化意味着子类可以替换父类的声明。子类继承父类的特性，特别是父类的属性和操作。通常（但不总是），子类除了具有父类的属性和操作外，还具有更多的属性和操作。若子类的一个操作的实现覆盖了父类的同样一个操作的实现，则这种情况称为多态性。其共同之处是，两个操作必须具有相同的特征标记（相同的名字和参数）。在图形上，把泛化画成一条带有空心三角形大箭头的有向实现，指向父类。当要表示父/子关系时，就使用泛化。

  一个类可以有0个、1个或多个父类。没有父类并且最少有一个子类的类称为根类或基类；没有子类的类称为叶子类。如果一个类只有一个父类，则说它使用了单继承；如果一个类有多个父类，则说它使用了多继承。

  在大多数情况下，用类或接口之间的泛化来表明继承关系。在UML中，也可以在其他的类目之间创建泛化，比如结点之间。

 

 

关联

  关联（association）是一种结构关系，它指明一个事物的对象与另一个事物的对象间的联系。给定一个连接两个类的关系，可以从一个类的对象联系到另一个类的对象。关联的两端都连到同一个类是完全合法的。这意味着，从类的给定对象能连接到该类的其他对象。恰好连接两个类的关联叫作二元关联。尽管不太常见，但可以有连接多于两个类的关联，这种关联叫作n元关联。在图形上，把关联画成一条连接相同类或不同类的实线。当要表示结构关系时，就使用关联。

  除了这种基本形式外，还有4种应用于关联的修饰。

名称

  关联可以有一个名称，用以描述该关系的性质。为了消除名称的歧义，可提供一个指出读名称方向的三角形，给名称一个方向。

角色

  当一个类参与了一个关联时，它就在这个关系中扮演了一个特定的角色。角色是关联中靠近它的一端的类对另一个端的类呈现的面孔。可以显示地命名一个类在关联中所扮演的角色。把关联端点扮演的角色称为端点名（在UML中称为角色名）。

多重性

  关联表示了对象间的结构关系。在很多建模问题中，说明一个关联的实例中有多少个相互连接的对象是很重要的。这个”多少“被称为关联角色的多重性，它表示一个整数的范围，指明一组相关对象的可能个数。将多重性写成一个表示取值范围的表达式，其最大值和最小值可以相同，用两个圆点把它们分开。声明了关联的一端的多重性，这说明：对于关联另一端的类的每个对象，本端的类可能有多少个对象出现。对象数目必须是在给定的范围内。可以精确地表示多重性为：一个（1）、零个或一个（0..1）、多个（0..*）、一个或多个（1..*）。可以给出它的一个整数范围（如2..5），甚至可以精确地指定多重性为一个数值（如3与3..3等价）。

  下图所示，每个公司对象可以雇佣一个或多个人员对象（多重性为1..*）；每个人员对象受雇于0个或多个公司对象（多重性为*，它等价于0..*）。

聚合

  两个类之间的简单关联表示了两个同等地位类之间的结构关系，这意味着这两个类在概念上是同级别的，一个类并不比另一个类更重要。有时要对”整体/部分“关系建模，其中一个类描述了一个较大的事物（”整体“），它由较小的事物（”部分“）组成。这种关系称为聚合，它描述了”has-a“关系，意思是整体对象拥有部分对象。其实聚合只是一种特殊的关联，它被表示为在整体的一端用一个空心菱形修饰的简单关联。

 

 其他特征

  简单而未加修饰的依赖、泛化以及带有名称、多重性和角色的关联是创建抽象时所需要的最常见的特征。事实上，对于创建的大多数模型，这3种关系的基本形式足以表达关系的最重要的语义。然而，有时需要可视化或详述其他特征，如组合聚合、导航、判别式关联类、特殊种类的依赖和泛化。这些以及很多其他的特征都可以用UML表达，但它们都被称为高级概念处理。

 

提示和技巧

  在用UML对关系建模时，要遵循如下策略：

• 仅当被角膜的关系不是结构关系时，才使用依赖。
• 仅当关系是”is-a-kind-of“关系时，才使用泛化。往往可以用聚合代替多继承。
• 小心不要引入循环的泛化关系。
• 一般要保持泛化关系的平衡；继承的层次不要太深（大约多于5层就应该想一想），也不要太宽（代之以寻找可能的中间抽象类）。
• 关联主要用于对象间有结构关系的地方。不要用关联来表示暂时关系，例如过程的参数或局部变量。

 

在用UML绘制关系时，要遵循如下策略：

• 要一致地使用平直的线或斜线。平直的线给出的可视化提示强调了相关事务之间的连接都集中到一个共同事物。在复杂的图中斜线则经常有更好的空间效果。在同一个图中使用两种线形，有助于把人们的注意力引导到不同的关系组上。
• 除非绝对必要，否则要避免连线交叉。
• 仅显示对理解特定的成组事物必不可少的关系。避免使用多余的关系（特别是多余的关联）。