创建清晰且有效的视觉模型是稳健系统设计的基石。当利益相关者和开发人员查看图表时，他们需要在无歧义的情况下理解系统的功能。用例图通过捕捉参与者与系统之间的交互来实现这一目的。然而，如果底层逻辑不严谨，创建这些图表往往会引发混淆。本指南提供了一种结构化的方法，以确保您的图表准确、易读且具有价值。
🛠️ 阶段1：定义系统边界
在绘制任何一个方框或小人图之前，您必须明确范围。系统边界定义了系统内部和外部的内容。这一区分至关重要，因为它决定了哪些元素属于功能需求，哪些是外部影响因素。
- 识别核心系统：明确标注代表系统的矩形。避免使用“系统”之类的模糊标签。应使用具体名称，例如“支付处理模块”或“库存管理系统”。
- 标记外部实体：矩形外部的任何内容都是参与者或外部系统。确保这些内容不被画在边界内，除非它们是子系统。
- 明确数据流：尽管用例图不会明确显示数据流，但边界暗示了数据进入和离开功能逻辑的位置。
如果没有清晰的边界，参与者可能会看起来与内部细节交互，而不是与提供的服务交互。这会导致模型过于详细且难以维护。
👥 阶段2：正确识别参与者
参与者代表与用例系统交互的人或系统的角色。他们是动作的发起者或输出的接收者。正确识别参与者往往是绘图中最常见的错误来源。
什么是参与者？
参与者是一个角色，不一定是某个具体的人。一个人可以扮演多个角色，一个角色也可以由多人扮演。例如，“经理”是一个参与者，而不是“约翰·史密斯”。此外，参与者也可以是另一个系统，例如外部API或遗留数据库。
- 主要参与者：他们发起交互以实现特定目标。他们是系统的用户。
- 次要参与者：这些是主系统为完成任务而交互的系统或服务。它们提供数据或服务，但不会发起用例。
- 通用与具体：避免列出具体个人。应使用基于角色的名称，如“客户”、“管理员”或“第三方服务”。
常见的参与者错误
| 错误的方法 | 正确的方法 |
|---|---|
| 标注“约翰·多伊” | 标注“注册用户” |
| 将参与者放置在系统边界内 | 将参与者放置在系统边界外 |
| 为每个屏幕创建参与者 | 为功能角色创建参与者 |
| 忽略系统间参与者 | 将外部API作为参与者包含在内 |
通过遵循基于角色的命名和正确的放置方式，即使人员变动，图表也能保持稳定。
🎯 阶段3：定义用例
用例代表一个完整的功能单元，为参与者提供价值。它不是一个单一动作，而是一系列实现目标的动作。用例的命名规范对于清晰表达至关重要。
命名规范
用例名称应为动词短语，从参与者的角度描述动作。它们应简洁明了，但又足够具体，能够独立表达含义。
- 动词-对象格式：例如“处理订单”、“生成报告”或“更新个人资料”。除非指特定文档而非动作，否则避免使用名词如“订单处理”。
- 目标导向：问问自己：“参与者想要实现什么目标？”如果答案是“支付账单”，那么用例应为“支付账单”，而不是“支付账单界面”。
- 范围一致性：确保所有用例处于同一抽象层次。不要将高层次目标（如“管理账户”）与低层次步骤（如“输入密码”）混在一起。
粒度检查
如果用例过于宽泛，就会变得模糊；如果过于狭窄，则会造成杂乱。一个良好的经验法则是，用例应能在一次会话中由参与者完成，或代表一个独立的业务事务。复杂的流程应拆分为更小的用例，并通过关系连接。
🔗 阶段4：映射关系
用例图的威力在于参与者与用例之间，以及用例彼此之间的关系。这些连线传达了系统的逻辑。
关联
连接参与者与用例的实线表示该参与者与该功能进行交互。每个参与者至少应有一个关联，每个用例也至少应有一个参与者。
- 方向性：尽管通常画成双向，但逻辑流程通常从发起请求的参与者开始。
- 多个参与者：一个用例可以与多个参与者关联。例如，“查看报告”可能与“经理”和“审计员”相关联。
包含关系
包含关系表示一个用例始终包含另一个用例的行为。被包含的用例是基础用例完成其目标所必需的。可以将其视为子程序。
- 何时使用：在多个用例之间共享通用功能时使用。例如，“用户认证”可能被包含在“登录”、“重置密码”和“更改凭证”中。
- 符号表示：通常以带标签“<<include>>”的虚线箭头表示，箭头从基础用例指向被包含的用例。
扩展关系
扩展关系表示可选行为。在特定条件下，扩展用例会向基础用例添加功能。这在错误处理或可选功能中非常有用。
- 何时使用： 用于异常或变体情况。例如，“发送通知”可能仅在支付失败时扩展“下单”用例。
- 条件性： 始终明确界定扩展点或条件。基础用例在没有扩展的情况下也能独立运行。
泛化
泛化用于继承。特定的参与者或用例会继承泛化者的行為。这可以减少图中的冗余。
- 参与者继承： 如果“高级用户”继承自“注册用户”，则无需再次绘制“注册用户”的所有关联。
- 用例继承： 如果“生成月度报告”是“生成报告”的一种特定类型，可以使用泛化来展示其层次结构。
🚫 第五阶段：避免常见陷阱
即使是经验丰富的建模者也会犯错。以下是常见错误清单及其解决方法，以确保图表质量。
| 陷阱 | 影响 | 解决方案 |
|---|---|---|
| 重叠的参与者 | 对谁做什么产生混淆 | 清晰区分参与者；如果角色相似，可使用泛化 |
| 循环依赖 | 逻辑循环导致流程中断 | 审查包含/扩展逻辑；确保基础用例是自包含的 |
| 关系过多 | 图表变得难以阅读 | 合并共性行为；使用注释说明详细逻辑 |
| 缺少参与者 | 系统视图不完整 | 审查所有功能需求；确保每个用例都有发起者 |
| 接口混淆 | 将用户界面与逻辑混为一谈 | 保持图表聚焦于功能，而非屏幕布局 |
| 未使用的用例 | 模型中的死代码 | 定期审查；删除没有参与者或依赖关系的用例 |
🔍 阶段6：验证检查清单
在最终确定图表之前，请逐一核对这份验证清单。这能确保模型稳健，并为开发团队做好准备。
- 完整性：每个用例是否至少有一个参与者？
- 一致性：所有参与者名称是否与术语表一致？
- 清晰度：系统边界是否清晰标注？
- 准确性：关系（包含/扩展）是否逻辑上符合需求？
- 可读性：布局是否整洁？线条是否不必要的交叉？
- 可扩展性：是否可以在不破坏现有结构的情况下添加新的用例？
- 一致性：图表是否与高层次的业务目标一致？
- 文档：复杂的用例是否已通过注释或描述进行记录？
🔄 阶段7：随时间管理变更
需求会不断演变，软件很少保持静态。用例图必须被视为一个动态文档，反映系统的当前状态。维护这份文档与创建它同等重要。
版本控制
跟踪变更。当用例被添加、修改或删除时，更新图表版本。这有助于审计并理解系统的演变过程。
影响分析
当需求发生变化时，分析其对图表的影响。如果引入了新参与者，检查现有用例是否需要修改。如果删除了某个用例，确保没有其他用例通过包含关系依赖它。
利益相关方评审
定期与利益相关方一起评审图表。他们可以判断模型是否仍然符合他们对系统的心理模型。这一反馈循环确保图表保持相关性。
📏 第8阶段：确保清晰性与一致性
视觉一致性有助于理解。如果图表看起来杂乱无章，其背后的逻辑也可能被视为杂乱无章。
- 对齐：对齐参与者和用例。使用网格线或间距来创建有结构的布局。
- 颜色使用：虽然在原始HTML中需要避免使用CSS样式，但在实际建模工具中，可考虑使用颜色来区分主要参与者和次要参与者，或突出显示已弃用的用例。
- 标签：确保所有标签都清晰可读。除非是行业标准术语，否则避免使用缩写。
- 间距：在元素周围留出足够的空间，以防止线条与文字重叠。
🧩 与其他模型的整合
用例图很少单独使用。当与其他建模技术结合使用时，效果最佳。
- 顺序图：使用顺序图来详细描述特定用例内的交互流程。
- 类图：使用类图来定义用例中涉及的对象。
- 状态图：使用状态图来展示参与用例的对象的生命周期。
通过将这些模型关联起来，你可以在不使用例图本身变得杂乱的情况下，全面了解系统。用例图仍然是理解功能的入口，而其他图表则提供实现细节。
🏁 最终审查步骤
在分发图表之前，进行最终的合理性检查。
- 大声朗读每个标签，以确保语法上通顺。
- 确认没有参与者是孤立的，没有连接。
- 检查是否错误地互换使用了include/extend关系。
- 确保系统边界包含了所有预期的功能。
- 确认图表能适配单页，或逻辑分页。
遵循这一结构化检查清单，可确保你的图表不仅是图片，更是有效的沟通工具。它们弥合了业务需求与技术实现之间的差距。通过聚焦角色、目标和关系，你创建的模型能够经受住时间和变化的考验。
请记住，目标是清晰。如果利益相关者能够看图就理解系统功能，你就成功了。始终聚焦于价值，保持结构逻辑清晰，并随着需求演变持续维护图表。