PlantUML 用例图：从需求到评审

用例图是 UML 里最容易被低估的一张图：它不画代码，但能精确地描述系统对外提供什么价值，谁来用，怎么用。

一句话定义

用例图描绘一组参与者 + 一组用例 + 它们之间的关系，加上一个系统边界包住用例。

@startuml
left to right direction
skinparam actorStyle awesome

actor "访客" as Guest
actor "会员" as Member
Member <<Human>>

rectangle "电商系统" {
  usecase "浏览商品" as UC1
  usecase "下单" as UC2
  usecase "支付" as UC3
  usecase "查看订单" as UC4
  usecase "申请退款" as UC5
}

Guest --> UC1
Member --> UC1
Member --> UC2
Member --> UC4

UC2 ..> UC3 : <<include>>
UC3 ..> UC5 : <<extend>>
@enduml

元素清单

元素	关键字	渲染
参与者	`actor`	小人
用例	`usecase "名称"`	椭圆
系统边界	`rectangle "系统名" { ... }`	大矩形
参与者-用例连线	`-->`	实线
用例-用例依赖	`..> : <<include>>` / `<<extend>>`	虚线

include vs extend 怎么区分

这是评审里最容易混的两条关系。

@startuml
actor 用户
rectangle "银行系统" {
  usecase "查询余额" as Bal
  usecase "用户登录" as Login
  usecase "转账" as Trans
}

用户 --> Bal
用户 --> Trans
用户 --> Login

Trans ..> Bal : <<include>>
Bal ..> Login : <<include>>
@enduml

<<include>>：「执行用例 A 必然要执行用例 B」。

例子：转账必然要查余额——少了查余额转账就是风险操作。

@startuml
actor 用户
rectangle "电商系统" {
  usecase "下单" as Place
  usecase "使用优惠券" as Coupon
  usecase "使用积分" as Points
}

用户 --> Place
Coupon ..> Place : <<extend>>  
Points ..> Place : <<extend>>
@enduml

<<extend>>：「执行 A 时，可选执行 B」。

例子：下单可选使用优惠券——可选行为。

关系	含义	例子
`<<include>>`	必须做	转账 / 查余额
`<<extend>>`	可选做	下单 / 优惠券
关联 `-->`	参与者跟用例的连线	用户 / 下单

实战：电商系统

@startuml
left to right direction
skinparam actorStyle awesome
skinparam rectangle {
  BorderColor #2F4858
  BackgroundColor #FAFAFA
}

actor "游客" as Guest
actor "会员" as Member
actor "管理员" as Admin
Member <<Human>>
Admin <<Human>>

rectangle "电商系统" {
  usecase "注册账号" as Reg
  usecase "登录" as Login
  usecase "浏览商品" as Browse
  usecase "搜索商品" as Search
  usecase "加入购物车" as Cart
  usecase "下单" as Place
  usecase "支付" as Pay
  usecase "查看订单" as Orders
  usecase "申请退款" as Refund
  usecase "管理商品" as MgmtProd
  usecase "查看报表" as Reports
}

Guest --> Browse
Guest --> Search
Guest --> Reg
Guest --> Login

Member --> Browse
Member --> Cart
Member --> Place
Member --> Pay
Member --> Orders
Member --> Refund
Member --> Login

Admin --> MgmtProd
Admin --> Reports
Admin --> Login

Reg ..> Login : <<include>>
Pay ..> Login : <<include>>
Refund ..> Orders : <<extend>>
Place ..> Cart : <<include>>
@enduml

多系统边界

一个组织有多个系统时：

@startuml
left to right direction

actor "客户" as C

rectangle "前台系统" {
  usecase "浏览商品" as Front
  usecase "提交订单" as Submit
}

rectangle "支付系统" {
  usecase "扣款" as Charge
  usecase "退款" as Refund
}

rectangle "物流系统" {
  usecase "出库" as StockOut
  usecase "派送" as Deliver
}

C --> Front
C --> Submit

Submit ..> Charge : <<include>>
Charge ..> Front : <<include>>
Refund ..> Deliver : <<include>>
@enduml

每个矩形一个系统，跨边界的关系用 ..>。

复杂关系的避免

用例图不是越复杂越好。5-15 个用例是合适的，超过就分组。

@startuml
left to right direction

actor 用户

package "账号" {
  usecase "注册" as Reg
  usecase "登录" as Login
  usecase "登出" as Logout
}

package "内容" {
  usecase "看文章" as View
  usecase "写文章" as Write
  usecase "评论" as Comment
}

package "设置" {
  usecase "改密码" as Pwd
  usecase "改邮箱" as Email
  usecase "实名认证" as KYC
}

用户 --> Reg
用户 --> Login
用户 --> View
用户 --> Write
用户 --> Comment
用户 --> Pwd
用户 --> Email
用户 --> KYC

Logout ..> Login : <<extend>>
@enduml

package 把用例按主题分组，渲染成大圆角矩形。

评审 checklist

参与者全部命名？
用例用动宾短语（下单、支付、注册账号）而不是名词？
系统边界清晰——只画一个系统的用例？
<<include>> 和 <<extend>> 没有混用？
不画得太多——5-15 个用例？

实战技巧

描述用例的「场景」

用例图只能告诉读者「做什么」，不告诉「怎么做」。配合活动图：

@startuml
left to right direction
usecase "下单" as Place

note right of Place
  场景：
  1. 用户选商品加入购物车
  2. 用户填写收货地址
  3. 用户选支付方式
  4. 系统提示下单成功
end note

@enduml

note right of 用作用例的详细描述。复杂用例一个 note 一个。

分时段评审

用例图也分版本：

第一版：3-5 个用例，5 分钟跟产品/老板过一遍
第二版：8-12 个用例，开发评审
第三版：完整版本，进文档库

一句话总结

用例图用动宾短语的椭圆描述系统做什么，用 <<include>> / <<extend>> 表达用例之间的「必然/可选」关系，配合参与者形成完整的需求图。比文字规范快，比活动图精炼。