用例关系是什么
UML 用例之间有 include、extend 与泛化三种关系。include 表示基础用例必然执行被包含的公共行为；extend 表示在满足条件时才把可选行为插入基础用例。两者箭头方向相反：include 由基础用例指向被包含用例，extend 由扩展用例指向被扩展的基础用例。关系用错会让用例图退化成流程图。
三种关系
| 关系 | 语义 | 箭头方向 | 示例 |
|---|---|---|---|
| include | 必然执行的公共子行为 | 基础用例 → 被包含用例 | 下单 include 身份校验 |
| extend | 条件触发的可选扩展 | 扩展用例 → 基础用例，虚线箭头 | 超时提醒 extend 下单流程 |
| 泛化 | 参与者或用例的继承替换 | 子类型 → 父类型 | VIP 用户泛化自普通用户 |
典型使用场景
- 多条用例共用同一步骤（身份校验、审计留痕）时抽成 include
- 表达可选业务规则（促销、超时、异常补偿）时用 extend
- 描述角色共性与差异时用参与者泛化
- 用例评审时逐条核对箭头方向，纠正语义误用
为什么容易混用
用例描述的是参与者从系统获得的一项完整价值，而不是步骤序列。把流程步骤当成 include，会让每个用例只剩一步，用例图失去业务视角。判断标准很简单：被 include 的行为单独执行时对参与者没有价值，只是公共复用；被 extend 的行为本身是一条独立的可选业务规则，只是触发条件依附于基础用例。
建模检查点
- 去掉被 include 的用例后基础用例是否仍然完整，若完整说明其实不该 include
- 扩展点的条件是业务规则还是界面动作
- 是否存在一个操作被拆成三条只为凑数量的用例
- 参与者是否真的从系统中获得可观测的结果
很多团队把 include 当成流程的下一步使用，用例图因此退化成流程图；只有真正复用的公共行为才用 include。
扩展点的条件应写业务规则，例如「订单超时」，而不是界面动作，例如「点击按钮」；extend 的扩展用例通常不能独立触发，必须在基础用例的某个扩展点被激活。