2、需求建模入门：用例图的核心要素与绘制实战

好，咱们进入第二个章节。需求建模，说白了就是把客户脑子里的想法，变成一张张能看懂、能讨论的图。我见过太多项目，需求文档写了几十页，结果开发一看——「这到底要我做啥？」。用例图就是来解决这个问题的。

你想想看，一个系统再复杂，最终都是给人用的。用例图的核心思想就一句话：谁，能用系统做什么事。就这么简单。

2.1 用例图的核心三要素

我习惯把用例图拆成三个东西来记：参与者、用例、关系。记住这三个，你就掌握了80%。

2.1.1 参与者（Actor）

参与者不是「人」，而是角色。举个例子，一个学生可以同时是「借书者」和「选课学生」，这是两个不同的角色。

• 主参与者：直接使用系统的人。比如「顾客」在电商系统里下单。
• 副参与者：为系统提供支持的人或系统。比如「支付网关」处理付款。

2.1.2 用例（Use Case）

用例就是一个完整的、有意义的业务目标。注意两个关键词：

• 完整：从开始到结束，用户能感知到结果。比如「提交订单」是一个用例，但「点击提交按钮」不是——那只是操作步骤。
• 有意义：对用户来说有价值。比如「查询余额」有价值，「输入密码」没有独立价值。

我一般用动词+名词的格式命名用例。比如「注册账号」、「导出报表」、「修改密码」。别用「处理数据」这种模糊说法，你想想看，谁看得懂？

2.1.3 关系（Relationship）

关系有三种，我当年学的时候也容易搞混，咱们一个一个说清楚：

关系类型	符号	含义	例子
关联	实线	参与者和用例之间的连接	「顾客」——「下单」
包含	虚线箭头 + <<include>>	一个用例必然包含另一个用例	「下单」包含「验证库存」
扩展	虚线箭头 + <<extend>>	可选情况下才执行	「下单」可扩展「使用优惠券」

2.2 如何绘制用例图——我的四步法

画用例图，我有一套固定的流程。用了十几年，没出过大问题。你跟着走一遍：

1. 找参与者：问自己「谁会使用这个系统？」。把角色列出来。
2. 找用例：对每个参与者问「他要用系统做什么？」。每个回答就是一个用例。
3. 画关系：把参与者和用例连起来。看看哪些用例是公共的（用包含），哪些是可选的（用扩展）。
4. 检查完整性：每个用例是不是有明确的开始和结束？有没有遗漏的业务场景？

嗯，这里要注意：别一开始就画图。我习惯先用便签纸写用例，贴在白板上调整。等关系理清了，再用工具画。你想想看，橡皮擦来擦去多麻烦？

一个简单的例子

假设我们要做一个「在线书店」系统。我快速走一遍流程：

• 参与者：顾客、管理员、支付系统
• 用例：浏览图书、搜索图书、下单、支付、管理库存、处理退款
• 关系：
  • 「顾客」关联「浏览图书」、「搜索图书」、「下单」
  • 「下单」包含「支付」（必须付了钱才算下单成功）
  • 「下单」扩展「使用优惠券」（可选）
  • 「管理员」关联「管理库存」、「处理退款」

你看，就这么简单。一张图就能说清楚谁做什么。

2.3 用例描述模板——把图变成文档

光有图还不够。图是给开发看的，但需求文档是给所有人看的。我一般会为每个核心用例写一个用例描述。模板如下：

用例名称：下单
参与者：顾客
前置条件：顾客已登录，购物车非空
后置条件：订单状态为「待支付」，库存扣减

基本流程：
1. 顾客点击「结算」按钮
2. 系统显示订单确认页面（含商品列表、总价）
3. 顾客选择支付方式
4. 系统调用支付接口
5. 支付成功，系统生成订单
6. 系统发送订单确认通知

扩展流程：
2a. 商品库存不足
    - 系统提示「库存不足」，返回购物车
4a. 支付超时
    - 系统提示「支付超时」，保留订单30分钟

业务规则：
- 同一商品最多购买10件
- 订单总金额超过500元免运费

我见过最糟糕的用例描述，把SQL语句都写进去了。你想想看，产品经理看得懂吗？客户看得懂吗？用例图是沟通工具，不是技术文档。

2.4 常见误区与我的建议

做了这么多年，我总结几个新手容易踩的坑：

• 用例太多：一个系统别超过20个用例。超过说明你拆得太细了。合并一些。
• 用例太少：少于5个，说明你太粗了。比如「管理系统」——这算一个用例？拆开！
• 把操作步骤当作用例：「点击按钮」不是用例，「完成支付」才是。
• 忽略副参与者：别忘了那些外部系统，比如短信网关、支付接口。

最后说一句：用例图不是画完就完的。我每次画完都会找业务方过一遍。指着图问：「这个角色，能做这些事，对吗？」。往往能发现很多遗漏的需求。嗯，这才是用例图真正的价值。