UML模型设计中的关系

在UML种，关系是非常重要的语义，它抽象出对象之间的联系，让对象构成某个特定的结构。本节将列举出UML所定义的关系，并解释它们的语义。

关联关系（association）
关联关系是用一条直线表示的，如A—B。它描述不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。这与依赖关系是不同的，依赖关系通常表示两个实例之间的临时关联关系。
我们可以使用关联关系表示一个对象了解其他对象，简单一点说，关联关系描述了某个对象在一段时间内一直“知道”另一个对象的存在。例如A对象保存了B对象的ID，因此A对象“知道”B对象的存在。
有时，对象必须相互引用才能实现交互，这时A和B互相“知道”，UML中只使用一条直线来表示关联关系。但在Rose中，为了区分相互“知道”和单向“知道”的关系，定义了关联关系的另一个变体，即单向关联关系，它是用一条带箭头的直线来表示的，如A——>B，说明A“知道”B，而B“不知道”A。
特别的，在用例模型中，单向关联关系用于连接参与者和用例，箭头由参与者指向用例，表示参与者“知道”用例的存在。当然，有些UML建模工具中，方向是不被强调的，不过我们从用例知识中了解到，总是参与者“知道”用例，而用例是“不知道”参与者的。

依赖关系（dependency）
依赖关系是用一个带箭头的虚线表示的，如A-------->B（A依赖于B）。它描述一个对象的修改会导致另一个对象的修改这样的关系。与关联关系不同的是，依赖关系除了“知道”其他对象的存在，还会“使用”其他对象的属性或方法。从这个角度将，依赖关系是一种特殊的关联关系。
举例来说，A对象保存了B对象的ID，但A 对象对B对象没有操作，这时A对象仅仅是“知道”B对象，应当用关联关系；如果A对象使用了B对象的属性或方法，则B对象的修改会导致A对象的修改，这时A依赖于B 。
同样的，依赖关系也有单项依赖关系和双向依赖关系之分。但依赖关系却不像关联关系那样有带箭头和不带箭头的区分，统统是带箭头的。这时因为在面向对象里，双向依赖是一种非常不好的结构，我们总是应当保持单项依赖，杜绝双向依赖的产生。

扩展关系（extends）
扩展关系是用一条带箭头的虚线加版型<<extends>>来表示的（A扩展出B）。它特别用于在用例模型中向基本用例中某个扩展点插入扩展用例。
一般来说，扩展用例是带有抽象性质的，它表示了用例场景中的某个“支流”，由特定的扩展点触发而被启动。所以严格来说扩展用例应当用于在概念用例模型中，通过分析业务用例场景抽象出关键的可选核心业务而形成的扩展用例。不过，在业务模型当中使用也是可以接受的，它可以更显式的表示出一个复杂业务用例的各个“分支”。
与包含关系不同的是，扩展表示的是“可选”而不是“必需”，这意味着即使没有扩展用例，基本用例也是完整的：如果没有基本用例，扩展用例是不能单独存在的；如果有多个扩展用例，同一时间用例实例也只会使用其中的一个。
在建模过程中，我们使用扩展关系可能基于以下理由：
1）表明用例的某一部分是可选（或可能可选）的系统行为。这样就可以将模型中的可选行为和必选行为分开；
2）表明只在特定条件（有时是例外条件）下才执行分流，如触发警报；
3）表明可能有一组行为段，其中的一个或多个段可以在基本用例的扩展点处插入。所插入的行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行交互；
4）表明多个基本用例中都有可能触发一个可选的分支流。从这个意义上说，扩展用例也代表了多个用例的可服用部分。
为了理解扩展关系，让我们来看一个例子。在打电话时，如果在通话过程中收到另一个呼叫，我们可以将当前通话保留而接听另一个通话。在这个场景中，保留通话用例就是打电话用例的一个扩展用例。我们可以看到，是否需要保留通话取决于打电话人的决定，而不是必需，即使没有我们没有使用保留通话功能，也不影响打电话的完整性。但是如果没有之前的打电话用例，也就不可能单独启用所谓的保留通话用例了。

包含关系（include）
包含关系是用一条带箭头的虚线加版型<<include>>来表示的（A包含B）。它特别用于用例模型，说明在执行基本用例的用例实例过程中插入的行为段。
包含用例总是带有抽象性质的，基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得的结果，但基本用例和包含用力都不能访问对方的属性。从这种意义上讲，包含用例是被封装的，它代表可在各种不同基本用例中复用的行为。因此，与扩展用例一样，包含用例也应当用在概念用例模型中，通过分析业务用例场景而抽象出关键的必选的核心业务而形成包含用例。同样，在业务模型中使用也是可以接受的，它可以显式的表示出哪些可复用的业务过程。
与扩展用例不同的是，包含用例表示的是“必需”而不是“可选”，这意味着如果没有包含用例，基本用例是不完整的，同事如果没有基本用例，包含用例是不能单独存在的。
在建模过程中使用包含用例可能基于以下理由：
1) 从基本用例中分解出这样的行为：它对于了解基本用例的主要目的并不是必需的，只有它的结果才比较重要。
2) 分解出两个或更多个用例所共有的行为。
为了理解包含关系，让我们来看一个例子。去银行办理业务，不论是取钱、转账还是修改密码，我们都需要首先核对账号和密码，因此可以将核对账号作为上述业务用例的共有行为提取出来，形成一个包含用例。我们可以看到这个包含用例就带有了可复用的意义，如果缺少了包含用例，取钱、转账等业务用例是不完整的，同事，核对账号也不能脱离开取钱、转账等业务用例而单独存在。

实现关系（realize）
实现关系是用一条带空心箭头的虚线来表示的（A实现B）。它特别用于在用例模型中链接用例和用例实现，说明基本用例的一个实现方式。
实现所代表的含义是，基本用例描述了一个业务目标，但是该业务目标有多种可能的实现途径，每一种途径可以用用例实现（或称用例实例）来表示，而用例实现与基本用例之间就构成了实现关系。换言之，每个实现途径都实现了基本用例的业务目标。
我们用如下图所示的交纳电话费业务作为例子，可以看到，交纳电话费是一个业务目标，实现途径可能有营业厅交费、银行交费、预存话费等，每一个用例实现都是同一业务目标的不同实现过程，因此他们之间是实现的关系。

精化关系（refine）
精化关系是用一条带箭头的虚线加版型<<refine>>来表示的（A精化了B）。它特别用于用例模型，一个基本用例可以分解出许多更小的关键精化用例，这些更小的精化用例更细致的展示了基本用例的核心业务。精化关系用来链接基本用例和精化用例，说明精化用例是由基本用例精化得来的。
精化关系也可以用于模型与模型之间，表示某个模型是通过精化另一个模型而的来的。比如说，我们认为设计类是通过精化分析而的来的，我们可以用XX设计类<<refine>>XX分析类来表示它们之间的关系。
与泛化关系不同的是，精化关系表示由基本对象可以分解为更明确、精细的子对象，这些子对象并没有增加、减少、改变基本对象的行为和属性，仅仅是更加细致和明确化了。在泛化关系中，基本对象被泛化成为子对象后，子对象集成了基本对象所有的特征，并且子对象可以增加、改变基本对象的行为和属性。
另一方面精化关系仅仅用于建模阶段，在实现语言中是没有精化这一语义的。泛化则等同于实现语言中的继承语义。
在概念用例中，我们了解概念模型是用于获取业务模型中的关键概念的，从业务模型中分析出实现业务目标的那些核心行为和实体，从而描述出一个关键的业务结构以得到一个易于理解的业务框架。这些关键概念就是对业务用例的精化。它们表示为概念用例到业务用例的精化关系。
作为例子，下图展示了预存话费以恶恶用例被精化称了四个核心的概念用例，这些概念用例合在一起就满足了实现业务目标的所有关键过程。我们可以根据这些精化结果建立业务框架。

泛化关系（generalization）
泛化关系是用一条带空心箭头的直线表示的（A继承自B）。泛化关系可用于建模过程中的任意一个阶段，说明两个对象之间的继承关系。对面向对象中的继承读者应该不会陌生，泛化关系表示一个类对另一个类的继承。继承而得的类称为后代。被继承的类称为祖先。继承意味着祖先的定义（包括任何特征，如属性、关系或对其对象执行的操作）对与后代的对象也是有效的。泛化关系是从后代类到其祖先类的关系。
特别需要说明的是，笔者并布赞同在用例之间使用泛化关系，尽管UML认为它是合法的。原因是用例带有原子特性，每个用例都应当是独一无二的。用例描述了参与者完成一个目标的整个过程，如果采用泛化关系，很难描述子用例继承了基本用例的什么。是过程，还是业务实体？如果仅仅为了将用例之间的可服用部分或用例的可扩展部分描述出来，那么使用包含关系和扩展关系就足够了。

聚合关系（aggregation）
聚合关系是用一条带空心菱形箭头的直线表示的（A聚合到B上，或者说B由A组成）。
聚合关系用于类图，特别用于表示实体对象之间的关系，表达整体由部分构成的语义。例如一个部门由许多人员构成。
与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，仍然存在。例如部门撤销以后，人员不会因此而消失，它们依然存在。

组合关系（composition）
组合关系是用一条带实心菱形的直线表示的（A组合成B，或者说B由A构成）。需要特别说明的是，在Rose中没有采用实心菱形箭头这一标准的UML图形，而是采用了带箭头的空心菱形。箭头指向组合的子对象，表示子对象属于母对象。
组合关系用于类图，特别用于表示实体对象关系，表达整体拥有的部分语义。例如母公司拥有许多子公司。
组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也将小王。例如母公司解体了，子公司也将不再存在。

文章转载自：http://www.itpro.net.cn/2019/08/uml模型设计中的关系/