UML学习——用例关联

引言：

（1）具体用例（concrete use case）：由参与者发起，完成了参与者所期望的完整性为。E.g.处理销售

（2）抽象用例（abstract use case）：永远不能被自己实例化；不能独立存在，只能是其他用例的一部分（即其他用例的子功能用例）。E.g.处理信用卡支付//

（3）基础用例（base use case）：包含其他用例的用例，或者是被其他用例扩展或泛化的用例。E.g. 处理销售

（4）附加用例（addition use case）：被其他用例包含的用例，或者扩展、泛化其他用例的用例。E.g.处理信用卡支付//

~~附加用例通常是抽象用例；基础用例通常是具体用例。

一、包含关系（include）

【小结】什么时候使用包含关系？

①当两个或多个独立用例中存在重复，而你想避免这种冗余时，可以使用包含关系

②将过于冗长的用例简单地分解为子单元可以方便理解

③描述异步事件的处理时可以使用包含关系。

1.在用例文本中，使用下划线或高亮表示被包含的用例

e.g.处理销售、处理租金、向失业救济计划捐款等用例可能都包含了信用卡支付的交互行为，∴可以将信用卡支付部分单拎出来作为一个子用例功能，然后用包含关系加以指示。

注：子用例也有主成功场景和扩展等结构

2.下面谈在异步事件处理中使用包含关系：

其实，也可以在扩展部分中使用像“*a”这样的标记。

在用例图中的表示：基础用例指向被包含用例，并在虚线上标明《include》

二、扩展关系（extend）

【小结】当基础用例不能修改时，可以使用扩展关系

1.思路：创建扩展或附加用例，并且在其中描述在何处和何种条件下该用例扩展某基础用例的行为

e.g.

在下图中，扩展点是基础用例的标记，扩展用例是通过该标记引用扩展点的，∴基础用例的步骤编号可以改变，而不会影响扩展用例。

2.在扩展关系中，基础用例对扩展用例没有任何引用。即基础用例不需要定义或处理扩展用例触发的条件。e.g.处理销售用例（基础用例）自身是完备的，不需要知道处理信用卡支付（扩展用例）的信息。

3.其实，处理赠券支付附加用例也可以通过包含关系在处理销售用例中引用；

或者直接将赠券支付的场景添加在处理销售用例的扩展部分。（推荐直接更新基础用例的扩展部分，而不是使用扩展关系再写一个用例）

4.扩展在用例图中的表示：扩展用例指向基础用例；在虚线上可以表示条件和扩展点

三、泛化关系（generalization）

类似于java中的继承，e.g.支付用例，对他泛化的用例可以是信用卡支付、现金支付，就是在支付的基础上，具体化了支付方式（继承）

整理不易，亲亲点个赞呗~~