软件开发常常停滞的原因并非代码，而是沟通不畅。利益相关者用自然语言描述他们的需求，而开发人员则将其转化为逻辑和结构。这种转换差距常常导致目标不一致。一种有效的弥补方法是统一建模语言（UML）。具体来说，用例图是捕捉功能需求的视觉化格式的关键工具。
本指南将引导你完成将原始需求转化为结构化UML用例的过程。你将学习如何识别参与者、定义系统边界，并在不依赖特定工具的情况下映射交互关系。重点始终放在概念性工作流程以及建模背后的逻辑上。
🧠 理解基础：需求工程
在画出任何线条之前，你必须先理解输入内容。需求是系统必须满足的具体条件或能力。在UML的语境下，我们主要关注功能需求——系统所执行的操作——尽管非功能约束会影响设计。
功能需求与非功能需求
在过程早期就区分这两类需求至关重要。
- 功能需求： 这些描述了具体的行为或功能。例如：“系统应允许用户重置密码”或“系统应根据位置计算税额”。这些需求可直接映射到用例。
- 非功能需求： 这些描述了系统的质量特性，例如性能、安全性和可靠性。例如：“系统必须在2秒内响应”或“数据必须加密”。虽然这些需求不会直接成为用例，但它们限制了用例的实现方式。
在收集需求时，应访谈利益相关者并审查文档。注意动词和名词。动词通常暗示动作（用例），而名词则暗示实体（参与者或数据）。
🎭 定义用例概念
用例代表用户或外部系统通过与软件交互所实现的特定目标。它不是步骤列表，而是一段价值叙述。一个用例可能包含许多步骤，但它代表一个连贯的目标。
用例的关键组成部分
为了有效建模，你需要理解核心要素：
- 参与者： 与系统进行交互的实体。参与者可以是人类用户、其他软件系统或硬件设备。
- 系统边界： 用于定义系统内部和外部的方框。任何与系统交互但不在边界内的都是参与者。
- 用例： 代表功能的椭圆或圆角矩形。
- 关联： 连接参与者与用例的线条，表示通信关系。
🚀 分步建模工作流程
创建用例模型是一个系统化的过程。遵循以下步骤，以确保准确性和完整性。
步骤1：识别系统边界
首先明确范围：系统包含什么，外部又是什么？画一个大框来表示这个边界。所有为参与者提供价值的内容都必须在这个框内。任何在框外的都是资源或参与者。
步骤2：识别参与者
扫描你的需求以识别角色。谁在执行工作？创建一个独立角色的列表。
- 主要参与者： 那些为了实现自身目标而启动用例的人（例如，客户下订单）。
- 次要参与者： 那些为系统提供服务的人（例如，支付网关）。
提示： 如果两个用户执行相同的操作并需要相同的权限，请将他们归为一个名为“用户”或“管理员”的单一参与者角色。这可以使图表更清晰。
步骤3：定义用例
在您的需求中寻找动词。“计算”、“注册”、“批准”、“生成”。每个独特的动作通常对应一个用例。用动词短语来命名用例。
- 示例： 不要使用“登录”，而应使用“验证用户”。不要使用“报告”，而应使用“生成销售报告”。
步骤4：映射关系
将参与者与用例连接起来。如果一个参与者与某个用例交互，就画一条线。如果多个参与者与同一个用例交互，就将它们全部连接起来。这可以直观地展示谁执行了什么操作。
步骤5：通过关系进行优化
并非所有交互都是简单的关联。您可能需要使用特定关系来展示用例之间的相互关系，例如包含 和 扩展.
| 关系类型 | 符号 | 含义 | 示例 |
|---|---|---|---|
| 包含 | 带«包含»的箭头 | 基础用例必须使用被包含的行为。必须使用被包含的行为。 | “下单”包含“验证购物车”。 |
| 扩展 | 带«扩展»的箭头 | 基本用例可能在特定条件下可能使用扩展行为。 | 如果数据缺失，“查看订单”将扩展为“显示错误”。 |
| 泛化 | 带三角箭头 | 参与者或用例之间的行为继承。 | “管理员”是“用户”的泛化。 |
📝 详细示例：电子商务结账
为了说明这一工作流程，考虑一个在线商店的需求：“用户必须能够使用信用卡购买商品。系统在扣款前必须验证库存。如果库存不足，必须通知用户。如果库存为零，则无法购买该商品。”
以下是将该文本转换为模型的方法。
1. 提取参与者
- 客户：发起购买。
- 库存系统：确认库存水平的外部系统。
2. 提取用例
- 开始购买： 主要目标。
- 验证库存： 每次购买都必需。
- 处理支付： 核心交易。
- 通知库存不足： 可选的通知。
3. 定义关系
- 开始购买 包含 验证库存（必经步骤）。
- 开始购买 包含 处理付款（必经步骤）。
- 通知库存不足 扩展 开始购买（条件性）。
这种结构确保在编写任何代码之前，工作流逻辑已被捕获。
⚠️ 常见陷阱：应避免
初学者常常在抽象层次上遇到困难。以下是一些常见错误，会降低你模型的价值。
1. 建模任务而非目标
用例应代表一个目标。“点击按钮”是一个任务，而不是用例。“更新个人资料”是一个目标。如果你建模的是任务，你的图表就会变成用户手册，而不是系统规范。
2. 混合细节层次
不要在同一张图中同时包含高层次的业务目标和低层次的技术步骤。如果“搜索产品”是一个用例，那么查询数据库的内部步骤就不属于这张图。保持范围一致。
3. 忽视系统边界
确保参与者在框外。一个常见错误是将参与者画在系统边界内。如果参与者是系统逻辑的一部分，它就不是参与者，而是组件。
4. 过度使用包含和扩展
这些关系会增加复杂性。只有在行为真正共享或条件性时才使用它们。过度使用会使图表难以阅读。通常，简单的关联关系或清晰的用例描述就足够了。
🔗 可追溯性：将需求与用例连接
一旦你的图表完成，你必须确保每个需求都有归属。这被称为可追溯性。它使你能够验证在分析阶段是否遗漏了任何内容。
创建一个映射表，将你的需求ID与用例名称关联起来。
| 需求ID | 需求文本 | 已映射用例 | 状态 |
|---|---|---|---|
| REQ-001 | 系统应允许用户注册。 | 注册用户 | 已映射 |
| REQ-002 | 系统必须验证电子邮件格式。 | 注册用户（包含） | 已映射 |
| REQ-003 | 系统必须发送欢迎邮件。 | 发送欢迎邮件 | 需要映射 |
如果一个需求没有映射到用例，你就存在缺口。如果一个用例没有映射到需求，你可能会出现范围蔓延。在进入设计之前，请审查这些缺口。
🛠️ 验证技术
你怎么知道模型是正确的？使用走查和验证技术。
1. 与利益相关者进行走查
与业务所有者坐在一起，走查图表。请他们描述一个场景。“我该如何购买一件衬衫？”如果他们描述的过程不在图表中，请添加；如果他们描述了不该存在的内容，请删除。
2. 一致性检查
确保图表之间的一致性。如果您的用例图显示“管理员”为参与者，那么您的类图应反映该角色。如果您的顺序图显示了不同的流程，请进行对齐。UML是一种语言，所有图表必须使用相同的语法。
3. 完整性检查
验证所有参与者是否至少有一个用例。没有连接的参与者通常是一个错误。验证所有用例是否至少有一个参与者。没有参与者的用例是一个没有用户的函数。
📈 扩展工作流程：从静态到动态
用例图是静态的。它们展示的是结构，而不是随时间变化的行为。为了完整定义工作流程，你最终需要顺序图或活动图。然而，用例图是起点。
在你的图表中，每个用例最终都应该编写一个用例规范。该文档详细说明了事件的流程。
- 前置条件： 用例开始前必须为真的条件是什么？（例如：用户已登录）。
- 基本流程： 顺利路径。如果一切顺利，步骤的顺序。
- 备选流程： 如果出现问题会怎样？（例如：密码错误）。
- 后置条件： 用例完成后为真的条件是什么？（例如：订单已创建）。
此规范弥合了可视化图表与实际代码逻辑之间的差距。
🎯 初学者的最佳实践
为了在模型中保持清晰性和权威性，请遵循这些指南。
- 保持简洁：包含50多个用例的图表很可能过大。请将其拆分。功能繁多的系统可能需要多个图表（例如，“管理面板”与“客户门户”）。
- 使用清晰的命名：使用动词，避免使用名词。“登录”比“登录界面”更好。“计算税款”比“税款计算”更佳。
- 标准化符号：坚持使用标准的UML符号。不要自行创造形状。这能确保任何熟悉UML的人都能读懂你的工作。
- 迭代：你的第一张图表不会完美。随着你对需求了解的加深，应预期对其进行修改。模型是动态文档。
🤝 协作与反馈
建模是一项社交活动。尽早分享你的草稿，不要等到最后才展示你的工作。当利益相关者看到他们的需求被可视化时，往往能立即意识到误解。这能显著节省开发周期后期的时间和成本。
鼓励提问。如果利益相关者对某个关系箭头感到困惑，请加以解释。如果他们建议新增一个参与者，请添加上去。图表属于项目团队，而不仅仅是分析师。
📌 关键要点总结
将需求转化为用例需要纪律和细致入微的关注。通过遵循结构化的流程，可以确保所构建的软件符合用户需求。
- 识别参与者：谁与系统进行交互？
- 定义目标：每个参与者希望实现什么目标？
- 映射关系：参与者和用例之间如何连接？
- 验证：确保涵盖所有需求。
- 迭代：随着理解的加深，不断优化模型。
掌握这一工作流程不会一蹴而就，但持续的练习会带来能力的提升。专注于逻辑和所交付的价值，图表自然会变得更加清晰，成为更有效的沟通工具。
