1. 什么是UML用例建模？
UML用例建模是软件开发中最基础也最重要的需求分析技术之一。简单来说，就是用图形化的方式描述系统该做什么，而不是怎么做。我第一次接触用例图是在大学软件工程课上，当时觉得这些"小人"和"椭圆"特别抽象，直到后来参与实际项目才发现它的价值。
用例图的核心在于回答三个问题：谁使用系统？系统提供哪些功能？这些功能之间有什么关系？比如在一个电商系统中，顾客可以浏览商品、下单购买，管理员可以管理商品和订单。这些就是最基础的用例。
与流程图不同，用例图不关心具体操作步骤，而是关注系统边界和功能范围。这就像盖房子前先确定有几个房间、每个房间的用途，而不是纠结墙面用什么材料。在实际项目中，我经常看到开发团队跳过用例建模直接写代码，结果后期频繁返工，就是因为没搞清楚系统到底该做什么。
2. 用例图的核心元素
2.1 执行者(Actor)
执行者就是与系统交互的角色，不一定是人。我刚开始做项目时犯过一个错误：把所有用户角色都画成执行者。实际上，执行者应该代表一类"角色"，而不是具体职位。比如"仓库管理员"是合适的执行者，但"张经理"就不是。
执行者主要有三类：
- 真实用户：比如系统的操作员、管理员
- 外部系统：比如支付系统、物流系统
- 时间事件：比如定时任务、传感器触发
在绘制时，我习惯用不同颜色区分这三类执行者：蓝色表示人，绿色表示系统，灰色表示自动事件。这个小技巧能让图更易读。
2.2 用例(Use Case)
用例是系统提供的功能单元，要用"动词+名词"的形式命名，比如"创建订单"、"生成报表"。新手常犯的错误是把操作步骤当成用例，比如"点击保存按钮"就不是好用例。
好的用例应该：
- 代表一个完整的目标
- 对执行者有价值
- 粒度适中（通常2-10步完成）
我常用的检验方法是：能否用一句话描述这个用例的价值？比如"顾客可以通过这个用例完成支付"就是合格的描述。
3. 四种关键关系详解
3.1 关联关系
这是最基本的连线，表示执行者和用例之间的交互。画法很简单：用直线连接执行者和用例。但要注意箭头方向：如果执行者主动发起交互，箭头指向用例；如果是系统通知执行者，则相反。
3.2 泛化关系
类似于面向对象中的继承。比如"管理员"可以泛化为"超级管理员"和"普通管理员"。我建议只在确实存在父子关系时才使用泛化，不要为了用而用。在库存系统案例中，可以把"操作员"作为父执行者，"入库员"和"出库员"作为子执行者。
3.3 包含关系
表示一个用例必须包含另一个用例的行为。比如"入库"必须包含"登录"。包含关系用虚线箭头加<>表示。实际项目中，我常用包含关系提取公共功能，避免重复定义。
3.4 扩展关系
表示在某些条件下才会触发的行为。比如"入库"可能会扩展"新增商品"。扩展点要明确标注条件，用虚线箭头加<>表示。注意扩展用例是可选的，不像包含关系是强制的。
4. 实战：库存管理系统用例建模
4.1 识别执行者
以库存管理系统为例，经过分析我们确定以下执行者：
- 仓库管理员（人）
- 采购系统（外部系统）
- 每日报表任务（时间事件）
特别注意不要遗漏自动触发的执行者。我曾经做过一个项目，就因为漏掉了"月末结算"这个时间执行者，导致财务模块设计不完整。
4.2 定义基础用例
核心用例包括：
- 商品管理（添加、修改、删除）
- 库存操作（入库、出库、调拨）
- 报表查询（当前库存、操作记录）
- 系统管理（用户、权限）
每个用例都要明确前置条件和后置结果。比如"入库"的前置条件是"用户已登录且商品信息存在"，后置结果是"库存数量增加"。
4.3 处理用例关系
在这个系统中：
- 所有操作都<>"登录"
- "入库"可能<>"新增商品"
- "管理员"泛化为"库存管理员"和"系统管理员"
画图时我习惯先用直线连接所有基础关系，再单独处理特殊关系，最后检查是否有遗漏的<>或<>。
5. 常见问题与优化技巧
5.1 用例粒度过细或过粗
新手常犯的错误是要么把每个按钮点击都画成用例，要么把整个模块作为一个用例。我的经验法则是：一个用例应该对应一个完整的用户目标，通常需要2-10个步骤完成。
5.2 关系滥用
不要为了使用高级关系而用。我曾经见过一个用例图中到处都是<>，实际上大部分应该是<>。记住：<>表示必须的，<>表示可选的。
5.3 图形布局技巧
好的布局能大幅提升可读性：
- 把主要执行者放在左侧
- 核心用例放在中间
- 次要元素放在右侧
- 相关用例尽量靠近
- 避免交叉线
我通常会用工具的分组和排列功能先规划整体结构，再细化每个部分。
6. 工具推荐与实操步骤
6.1 常用工具对比
| 工具 | 优点 | 缺点 |
|---|---|---|
| Visio | 微软生态兼容性好 | 收费且功能单一 |
| Lucidchart | 在线协作方便 | 需要网络 |
| PlantUML | 代码生成图 | 学习曲线陡 |
| Draw.io | 免费功能强大 | 本地保存略复杂 |
我个人最喜欢用Draw.io，因为它完全免费且支持导出多种格式。对于团队协作，Lucidchart是不错的选择。
6.2 具体绘制步骤
- 新建UML用例图
- 拖入系统边界框
- 添加执行者到边界外
- 在边界内添加用例
- 连接基础关联关系
- 处理特殊关系
- 添加注释和约束
- 优化布局
整个过程我建议先画草图再精修。在最近的一个电商项目中，我们迭代了5版用例图才最终定稿，每次评审都能发现需要改进的地方。
7. 从用例图到需求文档
用例图只是开始，完整的用例建模还包括用例规约。我通常会给每个用例补充以下信息：
- 简要说明
- 前置条件
- 基本流程
- 备选流程
- 异常情况
- 后置条件
比如"入库"用例的规约会详细描述扫码、验货、确认等步骤。这部分工作看似繁琐，但能大幅减少开发阶段的沟通成本。
