首页/开发/系统分析与架构设计速查/用例图(UML Use Case Diagram)
需求分析与建模61 条

用例图(UML Use Case Diagram)

用例图展示参与者、用例与系统边界的关系,用于划定系统范围并对齐功能清单;它不表达交互顺序,顺序需由描述或顺序图补充。

用例图是什么

用例图展示参与者、用例与系统边界之间的关系,用于划定系统范围并对齐功能清单。参与者用火柴人表示(可以是人,也可以是外部系统或定时任务),用例用椭圆表示,系统边界用矩形框住用例。用例图只表达“谁能做什么”,不表达步骤、条件与顺序,因此评审关键流程时必须配合用例描述或活动图。

基本信息

元素参与者、用例(椭圆)、系统边界(矩形)
常见关系参与者与用例的关联、参与者与用例的泛化、include、extend
include 含义被包含用例是必经步骤,如“提交订单”包含“校验库存”
extend 含义扩展用例在特定条件下才发生,如余额不足时触发“转人工审批”
用途范围界定、功能盘点、与业务方沟通系统边界

Mermaid 示例

Mermaid 示例
flowchart LR
  U([用户]) --- UC1((提交订单))
  U --- UC2((查询订单))
  A([运营]) --- UC3((处理退款))
  UC1 --- UC4((校验库存))
  S([定时任务]) --- UC5((关闭超时订单))
  subgraph 订单系统
    UC1
    UC2
    UC3
    UC4
    UC5
  end

常见画法问题

现象问题改进方向
一张图上百个用例超出阅读负荷,评审无法有效讨论按子系统或角色拆成多张图
用例名写成功能模块“订单模块”不是用例改为“提交订单”“查询订单”这类目标
关系箭头全部标 include把可选步骤当成必经步骤仅必经步骤用 include,条件性用 extend
遗漏外部系统参与者对接边界不清晰把支付网关、短信平台等登记为参与者

典型使用场景

  • 立项阶段划范围:明确哪些用例在本期实现、哪些明确不做
  • 需求盘点:检查参与者的功能是否覆盖完整,找出遗漏角色
  • 与业务方沟通:用一张图代替名词解释,快速对齐系统边界
  • 对外集成梳理:把外部系统作为参与者,明确各自职责
  • 测试范围参考:以用例为单位划分功能测试模块
  • 权限设计输入:参与者与用例的关联关系可映射为角色权限矩阵
用例图无法表达步骤与条件,评审关键流程时务必配合用例描述或活动图,否则容易把复杂分支当成一次点击。
把用例图当成系统设计图,用箭头表达调用关系或数据流向,会让读者误判职责边界。

易错点

  • 图里只画人,漏掉外部系统与定时任务参与者,集成边界在开发阶段才暴露
  • 用用例图表达调用顺序与数据流,超出 UML 语义,评审结论不可靠
  • 用例粒度混乱,既有“系统管理”这类粗颗粒又有“填写手机号”这类细操作
  • 不画系统边界矩形,读者分不清哪些在本次范围内、哪些属于外部系统
  • include 与 extend 混用,必经步骤与条件步骤无法区分

数据来源与参考

  • OMG UML 2.5.1 规范
  • Alistair Cockburn《Writing Effective Use Cases》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌