用例图常见错误 10 条：为什么越画越乱（附修正方法）

用例图（Use Case Diagram）本来是用来**讲清楚“系统对外提供哪些能力”**的：谁（Actor）在什么边界内触发哪些用例（Use Case），以及这些用例之间的复用、可选扩展和泛化关系。

但很多团队一画就乱：一会儿像流程图，一会儿像组件图；线越连越多，最后谁也不想维护。

下面按“症状 → 为什么会错 → 怎么修”整理 10 个高频问题，你可以边对照边改图。

想快速把一张图画到“能评审、能交付”的程度，可以用这个生成器先出基础骨架，再按本文清单逐条检查： 手打用例图 - 在线用例图生成工具

1) 把流程步骤画成一堆用例

症状：用例图里出现“填写表单 → 校验 → 保存 → 返回列表”这类步骤链条，像活动图/流程图一样从左到右串起来。

为什么会错：用例图关注的是“对外可见的目标”，不是内部步骤。步骤属于用例说明（主成功场景/备选流程）或活动图。

怎么修：

• 把“步骤”合并成一个对外目标型用例，例如“提交申请”“创建订单”。
• 用例内部步骤写进用例文档（或在生成器里输出用例描述），而不是用例图里画箭头链。

2) Actor 选成“部门/岗位”，而不是“外部角色”

症状：Actor 写“市场部”“研发部”“财务岗A”，或者把具体人名当 Actor。

为什么会错：Actor 表示与系统交互的外部角色（人、组织角色、外部系统），强调“与系统交互的责任与目标”。部门/人名会导致同一职责被拆散，图长期不可维护。

怎么修：

• 用“角色”而不是“组织结构”命名：如“运营人员”“审核员”“客户”。
• 如果确实与权限强绑定，可在用例说明里写“前置条件：具备X权限”。

3) 系统边界不画，或边界里外内容混放

症状：整张图没有系统边界；或者边界里既有你系统的用例，又混了外部系统能力。

为什么会错：边界定义了“我们这次讨论的系统是什么”。没有边界，范围无法对齐，讨论会不断扩张。

怎么修：

• 明确系统边界名称：例如“订单系统”“客服平台”。
• 边界内只放本系统提供的用例；外部系统用 Actor（外部系统）表示，与用例做关联。

4) 一个用例写得太大：把一整条业务链当一个椭圆

症状：出现“处理售后”“管理客户”等巨大用例，所有 Actor 都连到同一个椭圆。

为什么会错：粒度过大会掩盖关键差异，评审时无法讨论“权限、触发、异常、复用”。

怎么修（一个简单判断）：

• 如果用例说明超过 2~3 页、包含多个不同目标，就该拆。
• 拆成“对外目标”层级：如“提交售后申请”“审核售后”“退款处理”。

5) 一个用例写得太小：把内部动作都拆成椭圆

症状：出现“校验手机号”“写日志”“生成ID”这种椭圆。

为什么会错：这类动作不是用户目标，也很难作为独立用例被触发与评审。

怎么修：

• 内部动作放到用例步骤/设计文档。
• 只有当“动作本身能被独立触发、对外可见且有业务意义”时，才考虑成为用例。

6) include/extend 用反：把“可选情况”画成 include

症状：例如“下单 include 使用优惠券”“注册 include 填写邀请码”。

为什么会错：

• include 表示“必定发生的复用”（被包含用例通常是公共子流程）。
• extend 表示“在特定条件下才发生的可选扩展”。

怎么修：

• “不做也能完成主目标”的，通常是 extend。
• “每次都要做、且被多个用例复用”的，才更像 include。

7) include/extend 的箭头方向画错

症状：箭头乱指，甚至从基础用例指向扩展用例。

为什么会错：方向错会直接误导读者理解依赖关系。

怎么修（记住一句话）：

• include：箭头指向被包含的用例。
• extend：箭头指向**被扩展（基础）**的用例。

如果团队容易混，建议在图上保留 «include» / «extend» 标注，并在评审时统一约定。

8) 把“顺序/依赖”用线在用例之间乱连

症状：用例之间用实线箭头表示“先做A再做B”。

为什么会错：用例图不是用来表达时序的。时序/依赖要么在用例说明里写，要么用活动图/时序图表达。

怎么修：

• 删除用例之间的“先后箭头”。
• 把“前置条件/后置结果”写到用例说明：例如“前置：用户已登录”。

9) 泛化（Generalization）滥用：该用权限/条件表达的，用继承硬画

症状：把“管理员/普通用户”画成两套 Actor 继承，或者把“线上支付/线下支付”画成用例继承，但其实只是可选分支。

为什么会错：泛化表达的是稳定的类型关系（is-a）。很多差异只是权限、渠道或条件，不是类型。

怎么修：

• Actor 只有在“角色确实是另一角色的特化，且继承其所有交互”时才用泛化。
• 用例只有在“子用例继承父用例的主要行为，并在此基础上增加/替换少量行为”时才用泛化。
• 否则用 extend（可选）或在用例说明里写条件。

10) 图里塞进数据表/接口/模块：混成架构图

症状：用例图旁边画数据库、微服务、接口箭头，或者在椭圆里写“调用XX接口”。

为什么会错：用例图的读者通常是需求、产品、测试、业务方。架构细节会分散注意力，还容易在需求阶段过早锁定实现。

怎么修：

• 用例图只保留“角色—用例—关系”。
• 实现与接口放到：系统架构图、组件图、时序图或接口文档中。

---

一页检查清单（画完用它过一遍）

你可以把下面清单当成评审会议的“过门槛”规则：

• 每个 Actor 都是“外部角色/外部系统”，命名是角色而不是部门
• 画了系统边界，边界名能让人一眼知道讨论范围
• 每个用例都能用一句话回答“用户想达成什么目标”
• 没有把步骤链条塞进用例图（步骤写在用例说明里）
• include 只用于必经复用；extend 用于条件触发的可选扩展
• include/extend 的箭头方向正确且有标注
• 没有用例之间表示顺序的乱箭头
• 泛化只在稳定的 is-a 关系下使用
• 图上元素数量可控（如果一屏塞不下，考虑分子系统/分主题）

如果你想更快把“正确的结构”起出来，再逐步补全细节，可以直接用在线生成器生成基础用例图，然后按上述 10 条逐项修正：

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