用例图符号与关系一览：关联 / include / extend / 泛化（附判断规则）

很多人第一次画用例图，会卡在两件事上：

1. 图上到底有哪些“东西”（符号）要画出来？
2. 它们之间的线，到底用哪一种关系？

这篇把常见符号和四类高频关系（关联、include、extend、泛化）放在同一张“心智地图”里讲清楚，并给你一套可执行的判断规则。

如果你想更快把文本需求变成结构清晰的用例图，也可以直接用在线生成器先搭框架，再按本文规则微调：

• 生成入口：手打用例图 - 在线用例图生成工具

一、用例图里常见符号：你至少要认识这 4 个

1) 参与者（Actor）

• 画法：小人（或带 «actor» 的矩形）。
• 含义：与系统交互的“外部角色”。可以是人、组织角色、外部系统、外部设备。
• 关键点：Actor 指的是“角色”，不是“具体某个人”。

例子：

• 用户、管理员
• 支付平台（外部系统）
• 短信网关（外部服务）

2) 用例（Use Case）

• 画法：椭圆。
• 含义：系统对外提供的、对 Actor 有价值的目标。
• 命名建议：用“动词 + 名词”更清晰，例如“提交订单”“查询物流”。

3) 系统边界（System Boundary）

• 画法：把用例包起来的矩形框，框上写系统名。
• 含义：明确“哪些是系统要做的事、哪些是外部做的事”。
• 常见提醒：Actor 在边界外，用例 在边界内。

4) 关系线与标注

用例图常见关系主要是下面四类：

• 关联（Association）：Actor ↔ 用例
• include（包含）：用例 A 包含用例 B（可复用、必发生）
• extend（扩展）：用例 X 扩展用例 Y（可选、条件触发）
• 泛化（Generalization）：更一般的 Actor/用例 ← 更特殊的 Actor/用例

下面逐个讲清楚。

二、关联（Association）：Actor 和用例之间最常见的一条线

什么时候用关联？

当一个 Actor 参与某个用例（发起、触发、或在交互中承担关键步骤）时，用关联线连接即可。

画法与注意点

• 多数工具会画成实线，一般不需要箭头。
• 不要用关联线表达“先后顺序”。用例图强调“谁和系统有哪些目标”，不是流程。

快速自检

如果你能用一句话说明：

“这个角色为了达成某个目标，需要系统提供某项能力”

那大概率就是“Actor — 用例”的关联。

三、include（包含）：把必经的公共步骤抽成可复用用例

include 的核心含义

A 总是会执行 B，且 B 可以被多个用例复用。

• 典型用途：复用、拆公共能力。
• 常见例子：身份校验、计算价格、记录审计日志。

画法方向（很重要）

• 画虚线箭头，标注 «include»
• 箭头从“包含者”指向“被包含者”：
  • “下单” —«include»→ “校验库存”

判断规则（记住这一条就够用）

问自己：

1. 这个子用例是否在主用例里必定发生？
2. 它是否值得被多个用例复用？

两者都满足，优先 include。

常见误用

• 把“登录”都 include 到所有用例：
  • 如果你的系统并非每个用例都必须登录（例如“浏览商品”不需要），就不该一刀切。
  • 更好的做法是：把“需要登录”作为前置条件写在用例规约里，或在需要时用 extend（见下文）。

四、extend（扩展）：主流程能完成目标，但在特定条件下会多出一段可选行为

extend 的核心含义

主用例 Y 自己已经能完成目标；在某些条件下，扩展用例 X 会插入执行。

• 典型用途：可选流程、异常/优惠/补充步骤。
• 常见例子：使用优惠券、二次验证、失败重试、赠品策略。

画法方向（也很容易画反）

• 画虚线箭头，标注 «extend»
• 箭头从“扩展者”指向“被扩展者（主用例）”：
  • “使用优惠券” —«extend»→ “结算”

判断规则

问自己：

1. 没有这段行为，主用例还能否完成目标？
2. 这段行为是否在条件满足时才发生？

两者都满足，优先 extend。

常见误用

• 把“必做步骤”当成 extend：
  • 如果没有它就完不成目标，那就不是扩展，应该是 include 或直接并入主用例描述。

五、泛化（Generalization）：表示“更一般”与“更特殊”的继承关系

泛化既可以发生在 Actor 之间，也可以发生在用例之间。

1) Actor 的泛化

当多个角色有共同的交互能力，但又各自有特有行为时，用泛化表达继承。

例子：

• “用户”是一般角色
• “会员用户”“游客用户”是更具体的角色

2) 用例的泛化

当多个用例共享一个更一般的目标描述，但在细节上不同，也可以用泛化。

例子：

• “支付”是一般用例
• “微信支付”“支付宝支付”是更具体的用例

画法方向

• 使用带空心三角箭头的实线
• 箭头指向更一般的那个（父类）：
  • “会员用户” ——▷ “用户”
  • “微信支付” ——▷ “支付”

什么时候不建议用？

如果你的“继承”只是为了省几行文字，但图变复杂、读者反而看不懂，就不必强行上泛化。用例图的优先级是“读得懂”。

六、四类关系怎么选：一张决策清单

你可以按下面顺序做判断：

1. 这是 Actor 和用例之间吗？
   • 是 → 用“关联”
2. 这是两个用例之间吗？
   • 是 → 继续
3. 子用例是否必发生且可复用？
   • 是 → include
4. 扩展用例是否可选、条件触发？主用例无它也能完成目标？
   • 是 → extend
5. 这更像“更一般/更特殊”的继承吗？
   • 是 → 泛化

七、把线画对之后，还要避免 3 个“越画越乱”的坑

1. 把流程塞进用例图：

   • 用例图不是流程图，先后顺序、分支条件更适合放在活动图/时序图或用例规约里。

2. 用例命名太细或太粗：

   • 太细会把每个页面按钮都画成用例；太粗会变成“管理系统”这种无法讨论的椭圆。

3. 系统边界不清：

   • 外部服务（短信网关、支付平台）是 Actor，不要画成系统内部用例。

八、快速落地：从文本需求到清晰用例图（推荐做法）

1. 先写出：系统名 + 3–8 个核心用例（椭圆）
2. 列出所有外部角色（Actor），只保留“真正对系统有交互”的角色
3. 先只连关联线，保证“谁做什么”清晰
4. 发现重复步骤再抽 include；发现条件可选再加 extend
5. 需要继承关系再补泛化（能不用就不用）

如果你想把这套步骤“半自动化”，可以把用例和角色先输入生成器，再导出图后按本文规则检查方向与关系：

• 手打用例图 - 在线用例图生成工具