UML建模实战指南：从零到一构建用例图

1. 用例图基础：为什么它是UML建模的敲门砖

刚接触UML建模时，我总被各种图形搞得头晕眼花——直到发现用例图是最友好的入门选择。这个看似简单的图形，其实是开发者和业务人员沟通的通用语言。想象一下，你要给朋友描述"在线点外卖"的过程：用户打开APP、浏览餐厅、选择菜品、支付订单。这些动作就是最原始的用例雏形。

用例图的核心价值在于可视化系统边界。去年我参与一个电商项目时，产品经理拿着密密麻麻的需求文档和开发团队争论不休。当我们把主要功能画成用例图后，所有人突然就理解了"用户到底能在系统里做什么"。椭圆形的用例和火柴人状的参与者，比文字描述直观十倍。

这里有个新手容易混淆的概念：用例(Use Case)不是功能列表。比如"用户登录"是个功能，而"通过第三方账号快速登录"才是一个合格的用例——因为它描述了完整的交互场景和可观测结果。记住这个区别能少走很多弯路。

2. 在线商城案例：手把手识别系统参与者

现在我们来实战演练"在线商城系统"的参与者识别。很多教程一上来就教画图工具，但根据我的踩坑经验，前期分析比绘图技巧重要十倍。拿张白纸回答三个问题：

1. 谁会主动使用系统？（主动型参与者）
2. 系统需要和哪些外部系统交互？（被动型参与者）
3. 不同用户角色是否有层级关系？

在我们的商城系统中：

• 明显有"顾客"和"管理员"两类主动参与者
• 支付网关和物流系统是必须交互的外部系统
• 顾客可能细分为"游客"和"注册会员"

这里有个实用技巧：给每个参与者写用户故事。比如：
"作为注册会员，我希望收藏商品以便后续购买"
"作为物流系统，我需要接收订单配送信息"

这种描述能帮你发现隐藏参与者。我曾漏掉"客服人员"这个角色，导致售后流程在用例图中完全缺失，后来不得不返工重画。

3. 定义核心用例的黄金法则

识别出参与者后，就该定义用例了。新手常犯两个错误：要么把用例拆得太细（比如"点击按钮"），要么合并得太粗（比如"完成购物"）。我的经验法则是：一个用例应该对应一个完整的业务价值。

以"提交订单"为例，完整的用例应该包括：

1. 用户进入结算页
2. 系统计算总价（含优惠券抵扣）
3. 用户选择配送方式
4. 系统生成待支付订单

注意这里没有"用户登