【UML】第8篇 用例图（3/3）

不是非要把电影改成连续剧，给大家播，确实是时间和精力有限。

用例图，虽然简单，其实可说的内容也不少。

看前2篇，地址在这里：

【UML】第6篇 用例图（1/3）-CSDN博客

【UML】第7篇 用例图（2/3）-CSDN博客

一、用例的关系

用例之间的关系，主要包括泛化、包含和扩展三种。

1.1 泛化（Generalization）关系

用例的泛化关系可以理解为同一业务目的的不同实现路径。

这就是泛化关系，我们说过，泛化感觉有点别扭，是的，就是要从具体指向一般。可以理解为继承。

支付是父用例，不用管具体的支付实现，定义好属性和接口即可。

1.2 包含（include）关系

如上图，这是一个典型的包含关系，提现了包含关系的两种情况。

1. 反复可能被用到的用例，适合单独拿出来，作为一个独立的用例来分析和看待，但是可以在表达时，被其他用例包含。比如上图的身份验证。这是一个让用户无感的功能，因此可以不从参与者直接连线，但是身份验证非常重要，预借图书、?归还图书，都要用到，因此用包含的方式，一举两得。
2. 查询图书，是参与者要具体执行的目标，因此要单独列为用例。同时，这个用例也被预借图书用例包含，因此用包含符号表示。

注意，包含符号，带有<<include>>构造型。

1.3? 扩展关系

扩展关系中，基本用例是完整的，执行基本用例不一定执行扩展用例；但包含关系中的基本用例不完整，执行基本用例必须执行包含用例。

扩展关系使用带构造型的虚线箭头表示。箭头由扩展用例指向基本用例。

例如：<<extend>>

这里一定要注意，是谁指向了谁，扩展用例去指向基本用例。没有扩展用例，基本用例也是能独立工作的。扩展用例，可以理解为是基本用例的特殊情况。

例如缴纳罚款，就是扩展用例，归还图书，是基本用例。因为归还图书，不一定要缴纳罚款。?

二、用例表示例

如图，这是一个标准的用例文档描述。

用例图部分完，敬请关注，后续更精彩。

?