用例图栏目 ·

用例图参与者（Actor）怎么定义：人、角色、外部系统怎么区分

用例图参与者（Actor）定义不清，会导致用例边界混乱、关系线乱。本文用 6 条判断规则讲清：人/岗位/系统算不算 Actor、同一个人是否要拆多个角色、外部系统如何命名，并给出可直接套用的检查清单与示例。

在用例图里，参与者（Actor）不是“谁在用系统”的简单名单，而是与系统发生交互的外部角色：它代表一类行为一致的用户或外部系统。参与者定义得对，用例才会清晰；定义得乱，常见结果就是：同一个人画出三四个重复 Actor、或者把系统内部模块也画成 Actor，越画越大。

下面用一套可复用的规则，把“人 / 角色 / 外部系统怎么区分”讲清楚，并给你一份画完就能自检的清单。

1）先记住一句话：Actor = 系统边界外的“交互方”

判断一个对象能不能当 Actor，先问两个问题：

  1. 它在系统边界外吗？（外部的人、组织、系统、设备都可能在外部）
  2. 它会与系统发生可观察的交互吗？（发起请求、接收结果、触发事件、提供数据）

只要同时满足，通常就可以作为 Actor。

反过来：

  • 系统内部模块（如“订单服务”“权限模块”）不属于 Actor，它们在边界内。
  • 纯“数据对象”（如“订单”“用户表”）也不是 Actor，它不主动交互。

2）人 vs 角色：用“职责”而不是“姓名”来建 Actor

一个常见误区：把“张三、李四”画成 Actor。这样图很快就失效，因为人员会变动。

更稳妥的方法是：Actor 用角色/职责命名，比如：

  • “客户”
  • “客服专员”
  • “仓库管理员”
  • “财务审核员”

你可以用这个判断：

  • 如果换了人，系统交互方式不变 → 这是一个角色 Actor。
  • 如果同一个人因为不同职责，交互方式不同 → 可能需要拆成多个 Actor（下一节讲）。

3）同一个人要不要拆多个 Actor？看“交互目标是否不同”

同一个自然人可能在不同场景扮演不同角色。是否要拆成多个 Actor，可以用两条规则：

  • 交互权限/入口不同：例如“用户（买家）”和“商家（卖家）”登录同一系统，但菜单、权限、目标完全不同，建议拆。
  • 主要目标不同：例如同一个员工既是“申请人”又是“审批人”，对应的用例目标不同，也建议拆。

不建议为了“看起来更细”而拆太多。拆到最后，Actor 数量过多会反过来降低可读性。

4）岗位/部门算不算 Actor？部门通常不算，岗位/角色通常算

  • “销售部”“财务部”这类组织单位，通常不是 Actor（它不直接操作系统）。
  • “销售专员”“财务出纳”“财务审核员”这类岗位/职责，通常是 Actor。

如果你的需求文档里只有部门层级，建议先把部门翻译成可执行职责：

  • “财务部” → “财务审核员 / 出纳 / 会计”
  • “客服部” → “客服专员 / 质检”

这样画出来的用例更接近真实操作。

5）外部系统能不能当 Actor？能，而且经常需要

只要外部系统与本系统发生交互，它就可以是 Actor，比如：

  • “支付平台”（回调支付结果、查询交易状态）
  • “短信网关”（发送验证码）
  • “ERP 系统”（同步库存、接收出库单）
  • “单点登录 SSO”（提供认证）

这里有个关键：外部系统 Actor 的命名要“可识别且稳定”。

建议：

  • 用行业通用名或你们内部约定名，例如“支付平台”“物流平台”。
  • 如果必须体现供应商，可用“支付平台（XX）”这种写法，但避免把供应商当成业务角色。

6）设备/定时任务/传感器算不算 Actor？看它是否在边界外并触发交互

有些场景里，交互方不是人：

  • “定时任务（Scheduler）”触发对账
  • “扫码枪”向系统输入条码
  • “IoT 传感器”上报温湿度

它们是否当 Actor，取决于你要表达什么：

  • 如果你需要强调“是谁触发了用例”或“系统要对谁做出响应”，把它画成 Actor 会更清晰。
  • 如果只是系统内部实现细节（比如你们内部的某个 Job），通常可以不画。

7）参与者命名的 4 个小规范

让图更好读的习惯：

  1. 用名词短语：客户、管理员、支付平台。
  2. 避免动词：不要叫“提交订单的人”。
  3. 避免过度技术化：不要直接写“OAuth2 Client”，除非读者就是技术团队。
  4. 必要时加限定词：例如“门店店员（收银）”“门店店员（盘点）”用于区分职责。

8）常见错误与修正示例

错误 A：把系统内部模块当 Actor

  • ❌ Actor：订单服务、库存模块
  • ✅ 修正：把这些放在系统边界内；Actor 应该是“客户 / 仓库管理员 / ERP 系统”等。

错误 B：把数据对象当 Actor

  • ❌ Actor：订单、商品
  • ✅ 修正：订单/商品是领域对象；Actor 应该是“客户 / 商家 / 运营人员”。

错误 C：一个 Actor 包含多个互相冲突的职责

  • ❌ Actor：后台人员（既上架商品又审核退款）
  • ✅ 修正：拆为“运营人员”“退款审核员”，或者在图上清楚标注权限边界。

9）画完就能用的自检清单（建议贴到评审里）

你可以按下面 7 条逐项检查：

  • 每个 Actor 都在系统边界外
  • Actor 名称是角色/职责，而不是具体人名
  • 同一人如果有不同目标/权限，已合理拆分为不同 Actor
  • 外部系统交互（回调、同步、查询）已被建模为 Actor
  • 没有把内部模块/数据库/表当 Actor
  • Actor 数量控制在“读得懂”的范围（一般 5–12 个更友好）
  • 每个 Actor 至少连接到一个有意义的用例（避免孤立 Actor）

10）想快速生成一张可用的用例图草稿？

如果你手上只有一段需求描述（或 PRD），先把“谁”和“外部系统有哪些”梳理出来，再补用例，速度会快很多。

你也可以用这个工具把需求文本转成用例图初稿，再按本文规则调整参与者与边界：

如果你已经有 Actor 列表，想检查是否需要拆分/合并，也可以把清单直接粘进去做一次校对：