从“借书”到“退票”：聊聊UML用例图里那些容易被误解的「包含」与「扩展」关系（附避坑指南）
从“借书”到“退票”：UML用例图中「包含」与「扩展」关系的实战辨析
在软件系统建模过程中，用例图作为描述系统功能需求的核心工具，其关系的准确表达直接影响后续开发的质量。然而，即便是经验丰富的工程师，在面对「包含」(include)和「扩展」(extend)这两种看似简单的依赖关系时，也常常陷入判断困境。本文将通过图书借阅和航空退票两个典型场景，揭示这两种关系的本质区别，并提供一套可落地的判断方法论。
1. 关系本质：从概念到实例的深度解构
1.1 包含关系：不可分割的业务原子
包含关系体现的是一种强制的、不可省略的行为组合。当基用例执行时，被包含用例必须被执行，且这种调用是基用例正常完成的必要条件。这种关系类似于化学中的"化合物"——各元素通过化学键紧密结合，无法单独分离而不改变物质性质。
以电商系统的"创建订单"与"选择商品"为例：
@startuml left to right direction actor 用户 as User usecase "创建订单" as CreateOrder usecase "选择商品" as SelectProduct User --> CreateOrder CreateOrder ..> SelectProduct : <<include>> @enduml关键特征：
- 选择商品是创建订单的必经步骤，没有商品选择的订单创建毫无意义
- 包含用例的执行结果直接影响基用例的后续流程（如商品库存不足会导致订单创建失败）
- 从业务角度看，被包含用例通常是基用例的子流程或前置条件
1.2 扩展关系：条件触发的功能增强
扩展关系描述的是一种可选的、有条件的行为补充。基用例可以独立完成核心功能，扩展用例仅在特定条件满足时才会被触发，且基用例对扩展行为的存在并不知情。
典型场景是用户注册过程中的实名认证：
@startuml left to right direction actor 用户 as User usecase "注册账号" as Register usecase "检查实名信息" as VerifyRealName User --> Register Register <.. VerifyRealName : <<extend>> @enduml判断要点：
- 独立性：注册功能可以不依赖实名验证独立完成
- 触发条件：只有当用户选择"高级认证"选项时才会执行验证
- 单向感知：注册流程不关心验证结果（系统可能仅在后台记录验证状态）
2. 经典场景对比：图书借阅 vs 航空退票
2.1 图书管理系统的包含关系实践
在图书馆借书场景中，"借书"用例必然包含"验证会员资格"和"记录借阅信息"两个子行为：
| 主用例 | 包含用例 | 必要性分析 | 业务影响 |
|---|---|---|---|
| 借书 | 验证会员资格 | 非会员无法借书 | 直接决定借阅权限 |
| 借书 | 记录借阅信息 | 不记录则无法管理库存 | 影响图书流通状态 |
@startuml left to right direction actor 会员 as Member usecase "借书" as BorrowBook usecase "验证会员资格" as CheckMember usecase "记录借阅信息" as RecordBorrowing Member --> BorrowBook BorrowBook ..> CheckMember : <<include>> BorrowBook ..> RecordBorrowing : <<include>> @enduml2.2 航空退票系统的扩展关系设计
航空退票场景中，"退订机票"可能在不同条件下触发不同扩展行为：
条件分支分析表：
| 触发条件 | 扩展用例 | 业务规则 |
|---|---|---|
| 当月首次退票 | 无扩展 | 正常退款流程 |
| 当月二次退票 | 修改信用等级 | 信用分扣减20分 |
| 使用优惠券 | 回收优惠券 | 返还至用户账户 |
@startuml left to right direction actor 注册用户 as User usecase "退订机票" as RefundTicket usecase "修改信用等级" as UpdateCredit usecase "回收优惠券" as RevokeCoupon User --> RefundTicket RefundTicket <.. UpdateCredit : <<extend>> RefundTicket <.. RevokeCoupon : <<extend>> @enduml3. 避坑指南：四步判断法实战演练
3.1 第一步：必要性测试
问题：该行为是否是主用例完成的必要条件？
- 包含：必须回答"是"（如支付必须验证支付密码）
- 扩展：通常回答"否"（如支付后可选择开具发票）
3.2 第二步：条件测试
检查点：行为触发是否需要特定条件？
# 伪代码示例：扩展关系条件判断 def refund_ticket(user): process_refund() # 基础退票逻辑 if user.monthly_refunds >= 2: update_credit(user) # 条件触发的扩展行为 if used_coupon: revoke_coupon(user) # 另一个扩展行为3.3 第三步：方向性测试
箭头原则：
- 包含：基用例→被包含用例（箭头指向被包含方）
- 扩展：扩展用例→基用例（箭头指向被扩展方）
3.4 第四步：业务一致性验证
检查清单：
- [ ] 包含关系是否体现了核心业务流程？
- [ ] 扩展点是否明确标注了触发条件？
- [ ] 所有参与者是否都能理解这种关系划分？
4. 需求评审中的沟通策略
4.1 面向非技术人员的表达技巧
类比说明法：
- 包含关系："就像做蛋糕必须要有面粉"（必需材料）
- 扩展关系："就像蛋糕可以选加巧克力装饰"（可选配件）
4.2 常见质疑与回应策略
场景：产品经理质疑为何"检查库存"不作为"下单"的扩展回应框架：
- 业务影响：无库存则订单无法履行
- 用户预期：下单成功应隐含库存保障
- 系统约束：库存检查是交易系统的刚性要求
4.3 可视化辅助工具
推荐使用决策树辅助关系判断：
开始 │ ├─ 行为是否必需？ → 包含关系 │ ├─ 是：包含 │ └─ 否： │ ├─ 是否有明确触发条件？ → 扩展关系 │ │ ├─ 是：扩展 │ │ └─ 否：重新分析用例粒度 └─ 行为是否增强现有功能？ → 扩展关系在实际项目评审中，我们团队发现最有效的沟通方式是先用便签纸写出所有可能的用例关系，然后通过业务场景 walkthrough 逐一验证。例如在电商系统中，"提交订单"必须包含"计算运费"，但可能扩展"使用积分抵扣"——这种实物演示比单纯绘图更易达成共识。