上一篇文章里，有小白留言说：“看了用例图的例子，感觉很直观，但还是不知道自己怎么画”。其实我刚学的时候也一样，光看成品图没思路，跟着步骤一步步画才慢慢找到感觉。
今天这篇就带大家实操——以“个人用户微信支付下单”这个最常见的场景为例，3步画出能直接对接需求的用例图。全程避开复杂术语，用大白话讲清楚，你跟着做就能学会。
一、先搞懂：用例图的4个核心元素，用支付场景举例讲透
画用例图不用记太多复杂概念，只要掌握4个核心元素就行，每个元素都用“个人用户微信支付下单”场景举例，一看就懂：
1. 参与者：谁参与这个支付场景？
参与者就是“参与业务的角色或系统”，不一定是人，也可以是其他系统。比如这个场景里，参与者有4个：
- 个人用户（花钱买东西、发起支付的人）；
- 商户（提供商品/服务，接收支付的主体）；
- 微信支付网关（处理支付验证、扣款的系统）；
- 系统后台（商户用来查询订单、处理售后的后台系统）。
用例图里，参与者用“小人图标”表示，记住：只要是和场景有交互的角色/系统，都要归为参与者。
2. 用例：每个参与者要做什么？
用例就是“参与者在场景里要完成的具体操作”，比如“下单”“发起支付”“查询订单”。还是这个场景，核心用例有这些：
- 个人用户：下单、发起微信支付、查询订单状态、申请退款；
- 商户：查询订单详情、审核退款申请；
- 微信支付网关：验证支付信息、处理支付扣款、返回支付结果；
- 系统后台：同步订单数据、存储支付记录。
用例图里，用例用“椭圆图标”表示，注意：用例要写“动词+名词”（比如“发起支付”），别写模糊的“支付相关操作”。
3. 关系：参与者和用例、用例和用例之间怎么关联？
关系是用例图的核心，也是小白最容易混淆的部分，重点记4种，用支付场景举例说明：
-
关联关系：最基础的关系，“参与者和用例之间有交互”就用关联。比如“个人用户→发起微信支付”，用一条直线连接就行；
-
包含关系：一个用例“必须包含”另一个用例才能完成。比如“发起微信支付”必须先“验证支付信息”，没有验证就没法发起支付，这就是包含关系，用“虚线+箭头”表示，箭头指向被包含的用例（发起微信支付→验证支付信息）；
-
扩展关系：一个用例“可选包含”另一个用例，不影响主用例完成。比如“查询订单状态”后，用户可能会“申请退款”，也可能不申请，这就是扩展关系，用“虚线+箭头+extend”表示，箭头指向主用例（申请退款→查询订单状态）；
-
泛化关系：多个用例/参与者有共性，提炼出“父用例/父参与者”。比如“查询订单状态”和“查询支付记录”，都属于“查询交易相关信息”，可以提炼一个父用例；不过这个场景比较简单，暂时用不到，后面复杂场景再讲。
4. 系统边界：这个场景的范围是什么？
系统边界就是“我们要梳理的业务范围”，用“矩形框”表示，把场景内的用例框起来，参与者放在框外。比如这个场景，系统边界就是“个人用户微信支付下单及售后相关操作”，把“下单”“发起支付”等用例框进去，参与者（用户、商户等）放在外面。
二、业务需求拆解：“个人用户微信支付下单”场景到底要梳理什么？
画用例图前，先把需求拆透，不然画的时候容易遗漏。我们按“谁参与→做什么→怎么关联”的逻辑，拆解“个人用户微信支付下单”场景：
1. 明确参与者（4个）：
个人用户、商户、微信支付网关、系统后台（前面已经梳理过）。
2. 拆解核心用例（按参与者分类）：
- 个人用户：下单（选商品后创建订单）→ 发起微信支付（点击支付按钮）→ 查询订单状态（想知道订单是不是支付成功）→ 申请退款（支付后想退货）；
- 商户：查询订单详情（看用户下单信息）→ 审核退款申请（用户退款后商户确认）；
- 微信支付网关：验证支付信息（核对用户支付账户、金额是否正确）→ 处理支付扣款（从用户微信账户扣钱）→ 返回支付结果（告诉用户和商户支付成功/失败）；
- 系统后台：同步订单数据（把订单信息存到数据库）→ 存储支付记录（留存支付流水，方便后续对账）。
3. 梳理交互关系：
- 个人用户“发起微信支付”后，必须经过“微信支付网关验证支付信息”（包含关系）；
- 个人用户“申请退款”前，通常会先“查询订单状态”（扩展关系）；
- 微信支付网关“处理支付扣款”后，会向“系统后台同步订单数据”（关联关系）；
- 商户“审核退款申请”后，会通过“微信支付网关返回退款结果”（关联关系）。
需求拆到这一步，画用例图的素材就全齐了，接下来开始实操。
三、实操3步走：画出“个人用户微信支付下单”用例图
这里用“DrawIO”工具演示（前面推荐过，小白易上手），按“Step1识别参与者→Step2梳理核心用例→Step3定义关系”的步骤来，每一步都配简化示意图（可直接渲染查看）。
Step1：先把参与者和系统边界画出来
操作步骤：
- 打开DrawIO，拖4个“参与者（小人）”图标，分别命名“个人用户”“商户”“微信支付网关”“系统后台”；
- 拖一个“矩形框”作为系统边界，命名“个人用户微信支付下单系统”；
- 把参与者放在矩形框外面，位置均匀分布（避免后续线条交叉）。
graph TD
A[个人用户]
B[商户]
C[微信支付网关]
D[系统后台]
subgraph 个人用户微信支付下单系统
end
classDef actor fill:#f9f,stroke:#333,stroke-width:2px
class A,B,C,D actor
绘制要点：参与者命名要准确，别写“用户”“后台”这种模糊的名字；系统边界要把后续的用例都框住，大小适中。
Step2：在系统边界内添加核心用例
操作步骤：
- 拖6个“椭圆”图标到系统边界内，分别命名核心用例：下单、发起微信支付、查询订单状态、申请退款、查询订单详情、审核退款申请；
- 再拖3个椭圆，添加微信支付网关和系统后台的用例：验证支付信息、处理支付扣款、同步订单数据；
- 用例按“参与者对应关系”摆放（比如用户相关的用例放在个人用户旁边），避免混乱。
graph TD
A[个人用户]
B[商户]
C[微信支付网关]
D[系统后台]
subgraph 个人用户微信支付下单系统
E((下单))
F((发起微信支付))
G((查询订单状态))
H((申请退款))
I((查询订单详情))
J((审核退款申请))
K((验证支付信息))
L((处理支付扣款))
M((同步订单数据))
end
classDef actor fill:#f9f,stroke:#333,stroke-width:2px
classDef useCase fill:#9ff,stroke:#333,stroke-width:2px
class A,B,C,D actor
class E,F,G,H,I,J,K,L,M useCase
绘制要点：用例只列“核心操作”，别把“输入手机号”“确认支付密码”这种细节加进去（细节属于流程步骤，不用写在用例图里）；用例命名统一“动词+名词”格式。
Step3：添加关系，连接参与者和用例
这是最后一步，也是最关键的一步，按前面梳理的关系添加，操作步骤：
- 添加关联关系：用“直线”连接参与者和对应的用例（比如个人用户→下单、个人用户→发起微信支付；商户→查询订单详情、商户→审核退款申请等）；
- 添加包含关系：用“虚线+箭头”连接“发起微信支付”和“验证支付信息”，箭头指向“验证支付信息”（表示发起支付必须包含验证）；
- 添加扩展关系：用“虚线+箭头+extend”连接“申请退款”和“查询订单状态”，箭头指向“查询订单状态”（表示申请退款是查询订单的可选扩展）；
- 补充其他关联：微信支付网关→处理支付扣款、处理支付扣款→同步订单数据、审核退款申请→微信支付网关。
最终完整用例图如下，可直接渲染查看：
graph TD
A[个人用户]
B[商户]
C[微信支付网关]
D[系统后台]
subgraph 个人用户微信支付下单系统
E((下单))
F((发起微信支付))
G((查询订单状态))
H((申请退款))
I((查询订单详情))
J((审核退款申请))
K((验证支付信息))
L((处理支付扣款))
M((同步订单数据))
end
%% 关联关系
A --> E
A --> F
A --> G
A --> H
B --> I
B --> J
C --> K
C --> L
L --> M
D --> M
J --> C
%% 包含关系
F -.->|包含| K
%% 扩展关系
H -.->|extend| G
classDef actor fill:#f9f,stroke:#333,stroke-width:2px
classDef useCase fill:#9ff,stroke:#333,stroke-width:2px
class A,B,C,D actor
class E,F,G,H,I,J,K,L,M useCase
完整图解读：这张图把“个人用户微信支付下单”场景的“谁参与、做什么、怎么关联”全梳理清楚了——个人用户的操作、商户的操作、支付系统的处理流程，以及哪些操作是必须的、哪些是可选的，一眼就能看明白。把这张图给开发、产品看，能快速对齐需求，避免沟通偏差。
四、小白必看：用例图绘制3个核心技巧+避坑指南
1. 3个核心技巧，画出来的用例图更专业
-
技巧1：聚焦核心需求，不贪多。只画“关键操作”，比如“发起支付”是核心用例，“输入支付密码”是步骤细节，不用加进去；加太多细节会让图变混乱，失去梳理逻辑的意义；
-
技巧2：参与者识别要全面。别漏了“系统参与者”（比如微信支付网关、系统后台），很多小白只关注“人”，忽略了系统之间的交互，导致用例图不完整；
-
技巧3：关系定义要准确。记住“包含是必须的，扩展是可选的”，别搞反了（比如把“申请退款→查询订单”写成包含关系就错了，因为不查询也能直接申请退款）。
2. 小白最易踩的2个坑，附修正方法
-
坑1：用例画太细，把步骤当作用例。比如把“下单”拆成“选商品→填收货地址→提交订单”，这三个都是“下单”的步骤，应该合并成一个用例“下单”；修正方法：问自己“这个操作是不是一个独立的业务目标？”，是就保留，不是就合并；
-
坑2：关系混淆，乱用包含和扩展。比如把“查询订单→申请退款”写成包含关系；修正方法：用“有没有它不影响主用例完成”判断——没有“申请退款”，“查询订单”照样能完成，所以是扩展关系。
3. 用例图在支付需求中的核心价值
最后再强调一下：用例图不是“画来好看的”，核心价值有3个：
- 梳理需求：帮我们把混乱的支付需求拆清楚，避免遗漏参与者和操作；
- 高效沟通：给开发、产品、商户看，不用长篇大论，一张图就能对齐认知；
- 明确边界：知道这个支付场景的范围是什么，哪些操作不属于这个场景（比如“商户提现”就不属于“个人用户支付下单”场景，不用加进去）。
今天的实操就到这里，你可以跟着步骤，用DrawIO画一遍“个人用户微信支付下单”的用例图，画完之后会发现，梳理支付需求的思路清晰多了。
