通过包含关系简化大型用例图

引言

在软件工程中，用例图有助于可视化用户（参与者）与系统之间的交互，以捕捉其功能需求。随着系统规模的扩大，用例图可能变得难以处理，充斥着重复或复杂的行为，从而掩盖了系统的核心功能。包含关系在UML中，通过将通用行为提取为可重用的模块化用例来应对这一挑战。本文深入探讨了包含关系如何简化用例图，其主要优势以及实际示例以展示其实用性。

什么是包含关系？

一个包含关系在UML中，包含关系指一个基础用例包含另一个用例（称为被包含用例）的行为。被包含用例代表一个始终作为基础用例流程一部分执行的操作序列。始终执行作为基础用例流程的一部分。在视觉上，该关系以一条带有空心箭头的虚线箭头表示，从基础用例指向被包含用例，并标注为“«包含»”这一构造型。带有空心箭头的虚线箭头指向被包含用例，标注为构造型«包含»。

包含关系类似于编程中的子程序调用：基础用例“调用”被包含用例来执行特定任务，从而促进结构化和分层建模。通过将通用或复杂的行为提取到独立的用例中，包含关系减少了重复，提高了清晰度，并增强了可维护性。

包含关系的优势

在建模大型和复杂系统时，包含关系具有多项优势：

1. 通用行为的重用：多个用例之间的共享功能可以封装在一个被包含用例中，从而消除冗余。

2. 复杂用例的简化：大型用例可以分解为更小、更易管理的模块，使图表更加清晰。

3. 强制执行：被包含用例始终作为基础用例的一部分执行，确保完整性，同时避免在主流程中堆叠过多细节。

4. 提升清晰度和可维护性：通过分离关注点，基础用例专注于其独特行为，而被包含用例负责处理可重用的序列，从而简化更新。

5. 结构化建模：包含关系支持分层设计，类似于子程序，使系统更易于理解和扩展。

包含关系的示例

为了展示包含关系的强大功能，让我们在不同领域中探讨几个实际示例。

示例1：在线购物系统

考虑一个在线购物平台，用户可以浏览商品、将商品加入购物车并结账。许多用例，如“购买商品”、“预订商品”和“赠送商品”，都需要用户在继续操作前先进行身份验证。

• 基础用例: “购买产品”，“预订物品”，“赠送物品”

• 包含用例: “用户认证”

与其在每个用例中重复认证步骤，我们将其提取为单一的“用户认证”用例。该包含用例处理诸如提示输入登录凭证并验证它们等任务。用例图将显示：

• 从“购买产品”到“用户认证”的虚线箭头，标注«include»。

• 从“预订物品”和“赠送物品”到“用户认证”的类似箭头。

这种方法减少了冗余，因为认证逻辑只需定义一次，并可在多个用例中复用，从而保持图表简洁且易于维护。

示例2：银行系统

在银行系统中，客户可以执行“取现”、“存款”和“转账”等操作。每个用例在进行前都需要验证客户账户。

• 基础用例: “取现”，“存款”，“转账”

• 包含用例: “验证账户”

“验证账户”用例检查账户状态、余额和权限。通过在每个基础用例中包含此用例，图表避免了重复验证逻辑。视觉表示中，从每个基础用例到“验证账户”的虚线箭头标注«include»。这种模块化简化了图表，并确保账户验证被一致应用。

示例3：图书馆管理系统

在图书馆系统中，用户可以“借书”、“还书”或“预约图书”。这些操作中的每一个都需要检查图书的可用性。

• 基础用例: “借书”，“还书”，“预约图书”

• 包含用例: “检查图书可用性”

“检查图书可用性”用例验证图书是否在库且未被预约。通过在基础用例中包含此用例，图表保持简洁，对可用性检查逻辑的更新（例如，集成新的库存系统）只需在一个地方进行。

示例4：医院管理系统

在医院管理系统中，患者可以“预约就诊”、“取消预约”或“重新安排预约”。每个用例都需要验证患者身份。

• 基础用例: “预约就诊”，“取消预约”，“重新安排预约”

• 包含用例: “验证患者身份”

“验证患者身份”用例处理检查患者身份证或保险信息等任务。在基础用例中包含此用例，可确保身份验证一致执行，而无需在图中重复步骤。虚线«include»箭头将每个基础用例连接到“验证患者身份”，提升了清晰度。

示例5：在线学习平台

在一个在线学习平台上，学生可以“参加测验”、“提交作业”或“查看成绩”。这些操作中的每一项都需要学生登录系统。

• 基础用例：“参加测验”、“提交作业”、“查看成绩”

• 包含的用例：“登录”

“登录”用例包含了用户认证的步骤。通过将它包含在基础用例中，图表避免了重复登录步骤，使图表更易于理解和维护。视觉表示显示从每个基础用例指向“登录”的虚线箭头，标注为«include»。

UML中的视觉表示

在UML用例图中，包含关系的表示方式如下：

• 一个虚线箭头，带有开口箭头头从基础用例指向包含的用例。

• 箭头标注了构造型«include».

例如，在在线购物示例中：

• 购买产品 → «include» → 验证用户

• 该图清楚地表明，“验证用户”是“购买产品”流程中的必要部分。

这种视觉约定确保利益相关者能够快速理解用例之间的关系及其依赖关系。

与扩展关系的对比

需要注意的是包含和扩展关系之间的区别，以避免混淆：

• 包含：被包含的用例是始终执行 作为基础用例的一部分（强制性）。

• 扩展：扩展的用例是可选 仅在特定条件下执行。

例如，在在线购物系统中，“用户认证”被包含，因为它属于强制性操作，但像“应用折扣码”这样的用例可能是扩展关系，因为它属于可选操作，且取决于用户是否拥有有效代码。

使用包含关系的最佳实践

为了最大化包含关系的好处，请考虑以下几点：

1. 识别通用行为：寻找在多个用例中重复出现的操作序列，例如认证、验证或日志记录。

2. 保持包含的用例专注：确保包含的用例封装特定且可重用的行为，而不是整个流程。

3. 平衡模块化与简洁性：避免过度拆分用例，因为过多的包含用例会使图表更难理解。

4. 使用清晰的命名规范：为包含的用例命名时应反映其目的（例如，“用户认证”而非“登录流程”），以提高可读性。

5. 验证强制执行：确认包含的用例始终是必需的；否则，应考虑使用扩展关系。

优势总结

下表总结了包含关系的主要优势：

结论

包含关系是UML中有效用例建模的基石，能够实现常见且必需行为的重用和模块化。通过将共享功能提取到包含的用例中，开发人员可以创建更清晰、更易维护的图表，使其更易于理解和更新。所提供的示例——从在线购物到医院管理——展示了包含关系在不同领域中的广泛适用性。通过利用这一机制，团队可以更清晰、高效地建模复杂系统，最终提升软件设计的质量。

参考

• 在Visual Paradigm中记录用例细节
  如何在Visual Paradigm中编辑和查看用例细节的指南。
• 如何绘制用例图？——Visual Paradigm
  使用Visual Paradigm创建UML用例图的逐步说明。
• 什么是用例图？——Visual Paradigm
  用例图的概述及其在建模系统行为中的作用。
• Visual Paradigm中的用例图
  对用例图元素的详细解释，以及如何记录用例事件。
• 用例图符号指南——Visual Paradigm
  Visual Paradigm支持的UML用例图符号的全面指南。
• 使用Visual Paradigm创建用例图的全面指南
  在Visual Paradigm中识别参与者、定义用例和建模关系的详细教程。
• Visual Paradigm中UML的用例描述——Angelfire
  解释在Visual Paradigm中用例描述、调度、细化和文档生成。
• 揭开用例模型的神秘面纱：连接文本细节与视觉洞察
  讨论如何在Visual Paradigm中将用例的文本细节与视觉图表相结合。
• 用例图——UML建模工具——Visual Paradigm
  Visual Paradigm官方页面，展示用例图功能和符号支持。