在软件工程的系统架构设计中，UML 用例图（Use Case Diagram）是捕捉系统功能需求最直观的工具之一。它帮助开发者和利益相关者理解系统“做什么”，而不是“怎么做”。然而，仅仅列出功能是不够的，理解功能之间的依赖关系——特别是哪些是强制性的，哪些是可选的——对于构建健壮的系统逻辑至关重要。
本文将深入探讨如何使用 Visual Paradigm 的 AI 辅助代码编辑器（VPasCode）来编写 PlantUML 代码，从而构建一个包含 include（包含）和 extend（扩展）关系的复杂用例图。我们将通过一个典型的“在线商店”场景，逐步拆解代码逻辑，揭示系统架构背后的设计哲学。
1. 场景分析：在线商店的业务逻辑
在开始编写代码之前，我们需要明确业务场景中的核心逻辑。假设我们有一个“在线商店”系统，其核心业务流程如下：
- 核心行为： 顾客（Customer）需要“下订单”（Place order）。
- 强制性依赖： 无论订单金额多少，下订单总是需要“支付授权”（Authorize payment）。这是一个系统必须执行的基础步骤，没有它，订单无法完成。
- 可选性扩展： “应用促销”（Apply promotion）是一个可选的行为。只有当顾客输入了有效的促销代码时，这个步骤才会被触发。
这种逻辑关系正是 UML 用例图中 <<include>> 和 <<extend>> 关系所设计的初衷。
2. 代码构建：从 VPasCode 编辑器开始
Visual Paradigm 的 VPasCode 编辑器允许我们使用纯文本代码来定义图形。这种方式不仅便于版本控制，还能通过 AI 辅助快速生成复杂的图表。让我们逐行解析这段 PlantUML 代码。
2.1 定义基础元素与布局
首先，我们需要设定图表的方向，并定义参与者（Actor）和系统边界（System Boundary）。
@startuml
left to right direction
actor Customer
rectangle "Online Store" {
usecase "Place order" as Place
usecase "Authorize payment" as Payment
usecase "Apply promotion" as Promotion
}
@enduml@startuml</code> 和 <code>@endumlleft to right direction：这是一个布局指令，强制图表从左向右排列，使逻辑流向更符合阅读习惯。actor Customer：定义了一个名为“Customer”的参与者，代表系统的外部用户。rectangle "Online Store" { ... }：定义了一个名为“Online Store”的矩形框，作为系统边界。在这个框内部定义的元素属于系统内部的功能。
2.2 建立关联关系
接下来，我们定义参与者与用例之间的连接，以及用例之间的内部逻辑关系。
Customer --> Place
Place ..> Payment : <<include>>
Promotion ..> Place : <<extend>>这里展示了三个关键连接：
Customer–> Place：实线箭头表示“Customer”与“Place order”之间的关联关系。这是用户与系统的直接交互入口。Place ..> Payment : <<include>>：虚线箭头指向“Place order”，并带有<<include>>标签。这意味着“Place order”用例必须包含“Authorize payment”的行为。如果“下订单”发生，那么“支付授权”必然发生。Promotion ..> Place : <<extend>>：虚线箭头指向“Place order”，并带有<<extend>>标签。这意味着“Apply promotion”用例扩展了“Place order”。它不是必须的，只有在特定条件下（如输入了促销码）才会被触发。
3. 深度解析：Include 与 Extend 的区别
理解 include 和 extend 的区别是掌握用例图建模的关键。在 VPasCode 生成的图表中，这两种关系通过箭头的方向和标签清晰地表达出来。
3.1 Include（包含）：强制性的子功能
include 关系表示基础用例（Base Use Case）总是需要执行被包含用例（Included Use Case）的功能。在代码中，箭头从基础用例指向被包含用例（Place ..> Payment）。
- 语义： “下订单”包含了“支付授权”。
- 条件： 无条件，总是执行。
- 设计目的： 提取公共逻辑，避免重复。例如，如果“下订单”和“取消订单”都需要“支付授权”，我们可以将“支付授权”提取为一个
include用例。
3.2 Extend（扩展）：可选的增强功能
extend 关系表示在特定条件下，扩展用例（Extension Use Case）可以插入到基础用例中。在代码中，箭头从扩展用例指向基础用例（Promotion ..> Place）。
- 语义： “应用促销”扩展了“下订单”。
- 条件： 有条件，例如“顾客输入了有效的促销代码”。
- 设计目的： 处理可选流程或异常流程。它允许我们在不修改主流程的情况下，添加额外的行为。
4. 最佳实践与文档化
仅仅画出图表是不够的，优秀的系统架构师会在图表之外补充必要的逻辑说明。对于 extend 关系，明确触发条件（Condition）是至关重要的。
在 VPasCode 或 Visual Paradigm 中，你可以通过添加注释（Note）来描述这些条件。例如，对于“Apply promotion”用例，你应该在文档中注明：
条件说明： 仅当顾客在结账页面输入了有效的促销代码（Valid Promotion Code）时，系统才会执行“应用促销”逻辑。
这种文档化的做法确保了开发人员不会遗漏逻辑判断，同时也让测试人员能够明确测试场景。
5. 总结
通过本教程，我们利用 VPasCode 成功构建了一个包含 include 和 extend 关系的 UML 用例图。这不仅展示了如何使用代码驱动设计（Code-Driven Design）来生成图表，更重要的是，它清晰地传达了“在线商店”系统中核心业务流程与可选功能的逻辑关系。
掌握这些建模概念，将帮助你设计出更加清晰、灵活且易于维护的软件系统架构。