Posted inUnified Modeling Language Use Case Modeling Visual Paradigm

UML用例图中包含和扩展关系的全面指南

统一建模语言（UML）用例图是建模系统功能需求的强大工具。它们展示了参与者（用户或外部系统）如何通过用例与系统交互，用例代表特定功能。用例图中的两个关键关系——包含和扩展——通过结构化和模块化行为来帮助管理复杂性。本教程详细解释了这些关系的目的、特征和实际应用，并附有示例以确保清晰易懂。

什么是包含和扩展关系？

在UML用例图中, 包含和扩展关系允许您将复杂的用例分解为更小的、可重用的或可选的组件。这些关系增强了模块化，减少了冗余，并提高了图表的清晰度。

Include” and “Extend” Use Cases - Visual Paradigm Blog

  • 包含关系（<<include>>)：表示作为基础用例的一部分始终执行的强制性行为。它将多个用例之间共享的通用功能提取为可重用组件。

  • 扩展关系（<<extend>>)：表示在特定条件下扩展基础用例的可选或条件性行为，使基础用例保持对其核心功能的关注。

两种关系均使用虚线箭头连接用例，并用标签标明<<include>>或<<extend>>。箭头的方向至关重要，因为它反映了用例之间的依赖关系。

包含关系（<<include>>)

目的

该包含包含关系用于将多个用例中的公共且必需的行为提取到一个可重用的用例中。这促进了重用性，并通过避免功能重复来简化基础用例。

特性

  • 强制性：当执行基础用例时，包含的用例总是会被执行。

  • 可重用：包含的用例是一个独立且连贯的功能，可以被多个基础用例使用。

  • 简化图示：通过提取公共步骤，基础用例保持简洁且专注。

  • 方向：箭头从基础用例指向包含的用例，表明基础用例依赖于包含的用例。

符号表示

  • 一条标有<<包含>>的虚线箭头将基础用例连接到包含的用例。

示例1：在线购物系统

考虑一个在线购物系统，其中客户可以下单或取消订单。这两个用例都要求客户登录到系统。

  • 基础用例: 下单, 取消订单

  • 包含用例: 登录

  • 说明: 登录是下单和取消订单的必经步骤。为了避免在两个用例中重复实现登录功能，该功能被提取为一个独立的登录用例，由两者包含。

图示表示:

[下单] ----<<包含>>----> [登录]
[取消订单] ----<<包含>>----> [登录]

示例2：图书馆管理系统

在图书馆系统中，用户可以借书或还书。两个过程都需要验证用户.

  • 基础用例: 借书, 还书

  • 包含用例: 验证用户

  • 说明: 验证用户身份（例如检查其借书证）是借书和还书过程中的必经步骤。该验证用户 用例被包含以避免冗余。

图形表示:

[借书] ----<<包含>>----> [验证用户]
[还书] ----<<包含>>----> [验证用户]

何时使用

  • 当多个用例共享一个共同的必选步骤时。

  • 当你希望通过提取可重用功能来简化用例描述时。

  • 当被包含的用例可以独立有意义时（例如，登录 或 验证用户 可以被理解为独立的功能）。

扩展关系（<<扩展>>)

目的

该扩展扩展关系用于建模仅在特定条件下执行的可选或条件性行为。它使基础用例能够专注于其核心功能，同时以模块化方式添加可选行为。

特征

  • 可选/条件性：扩展用例仅在满足某些条件时才执行。

  • 依赖性：扩展用例本身没有意义，必须依赖于基础用例。

  • 扩展点：基础用例可以定义特定的插入点，用于插入扩展行为。

  • 方向：箭头从扩展用例指向基础用例，表示扩展用例向基础用例添加行为。

符号表示

  • 一条标有<<extend>> 将扩展用例连接到基础用例，通常附有说明条件或扩展点的注释。

示例 1：ATM 系统

在 ATM 系统中，基础用例是取现。一个可选行为，打印凭条，如果用户请求凭条，则可能发生。

  • 基础用例: 取现

  • 扩展用例: 打印凭条

  • 条件：用户在取现后选择打印凭条。

  • 说明：打印凭条不是强制性的，只有在用户明确请求时才会发生。打印凭条 用例在“用户请求凭条”这一扩展点上扩展了取现。

图示表示:

[打印凭条] ----<<extend>>----> [取现]rn（注：条件 = 用户请求凭条）

示例 2：在线课程平台

在在线课程平台中，用户可以参加测验。一个可选行为，请求提示，如果用户在回答问题时遇到困难则发生。

  • 基础用例: 参加测验

  • 扩展用例: 请求提示

  • 条件：用户在测验过程中请求提示。

  • 说明：请求提示是可选的，取决于用户的需求。该请求提示用例在扩展点“用户需要帮助”处扩展参加测验在扩展点“用户需要帮助”处。

图示表示:

[请求提示] ----<<扩展>>----> [参加测验]
（注：条件 = 用户需要帮助）

何时使用

  • 当行为是可选的，或取决于特定条件时。

  • 当你希望保持基础用例专注于其主要功能时。

  • 当扩展用例在没有基础用例的情况下没有意义时（例如，打印收据在没有取现).

Include 与 Extend 的主要区别

下表总结了Include与扩展关系以指导其使用：

标准

包含（<<包含>>)

扩展（<<扩展>>)

该行为是否为强制性的？

是的，始终作为基础用例的一部分执行

否，仅在特定条件下执行

该行为能否独立存在？

是的，它是一个连贯且可重用的功能

否，它依赖于基础用例

它是否出现在多个用例中？

是的，多个用例共享

通常仅针对一个用例

目的

促进重用并简化基础用例

模块化地添加可选或异常行为

箭头方向

基础 → 包含的用例

扩展 → 基础用例

实际示例：餐厅管理系统

让我们在餐厅管理系统中应用这两种关系，以说明它们在实际场景中的应用。

场景

餐厅系统允许顾客点餐和预订桌位。系统还处理其他行为，例如支付账单和请求外带.

用例

  • 点餐：顾客从菜单点餐。

  • 预订桌位：顾客预订桌位用于就餐。

  • 验证顾客身份：验证顾客身份（例如通过会员账户）。

  • 支付账单：顾客支付订单费用（对于点餐).

  • 请求外带：可选请求，将订单打包用于外带。

关系

  • 包含：两者都包含点餐和预订桌位都需要验证顾客身份来验证顾客身份。点餐还包含支付账单因为下单后支付是强制性的。

  • 扩展: 点餐可以被扩展为请求外带如果顾客选择外带食物。

图示表示

[点餐] ----<<包含>>----> [验证顾客]
[点餐] ----<<包含>>----> [支付账单]
[预订桌位] ----<<包含>>----> [验证顾客]
[请求外带] ----<<扩展>>----> [点餐]
(注：条件 = 顾客请求外带)

说明

  • 验证顾客被包含在以下两者中：点餐和预订桌位因为它是在访问系统前的必经步骤。

  • 支付账单被包含在点餐因为完成订单需要支付。

  • 请求外带扩展了点餐因为它是一种可选行为，仅在顾客请求外带时才会发生。

使用包含和扩展的最佳实践

  1. 谨慎使用包含：只有当某个行为被多个用例共享，或能显著简化基础用例时，才将其提取为包含的用例。过度使用包含会使图表变得杂乱。

  2. 为扩展明确定义扩展点：明确指定扩展行为在基础用例中的适用条件或位置，以避免歧义。

  3. 保持用例的聚焦：确保基础用例保持简单，并专注于其主要目标，使用包含表示必选步骤，而扩展表示可选步骤。

  4. 验证包含关系的可重用性：被包含的用例应在不同上下文中具有意义且可重用。

  5. 避免过度复杂化图表：仅在能增加清晰度时使用包含和扩展，复杂的关联可能会让利益相关者感到困惑。

常见陷阱及避免方法

  1. 混淆包含与扩展:

    • 陷阱：使用包含表示可选行为，或使用扩展表示必选行为。

    • 解决方案：始终确认该行为是否为必选（使用包含），或为条件性行为（使用扩展).

  2. 过度使用关联关系:

    • 陷阱: 创建过多的包含或扩展关系，使得图表难以阅读。

    • 解决方案: 仅在这些关系能够减少冗余或提高清晰度时才使用。

  3. 模糊的扩展条件:

    • 陷阱: 未指定扩展关系的条件，扩展导致混淆。

    • 解决方案: 始终包含对条件或扩展点的说明或描述。

  4. 包含不可重用的行为:

    • 陷阱: 创建一个仅被一个基础用例使用的包含用例。

    • 解决方案: 确保包含的用例是可重用的，或能显著简化基础用例。

结论

UML用例图中的包含和扩展关系对于管理复杂性和确保模块化至关重要。包含 关系通过提取必需的、共享的行为来促进重用，而扩展 关系通过建模可选或条件行为来保持基础用例的专注性。通过理解它们的目的、特征和最佳实践，您可以创建清晰、可维护且有效的用例图，向利益相关者传达系统功能。

参考