UML 2.5 用例图实战：3个真实项目案例解析关联、包含与扩展关系

UML 2.5 用例图实战3个真实项目案例解析关联、包含与扩展关系在软件开发的需求分析阶段用例图Use Case Diagram作为UML中最直观的需求建模工具能够清晰展现系统功能与外部参与者的交互关系。但许多工程师在实际绘制时常陷入知道概念却不会应用的困境——何时该用包含关系扩展关系与泛化如何区分本文将通过电商登录、在线支付、内容审核三个典型场景拆解四种核心关系的实战应用逻辑。1. 电商登录系统的关联与泛化设计某跨境电商平台需要重构登录模块支持以下功能基础账号密码登录短信验证码登录第三方社交账号登录微信、Google登录失败处理登录后推荐个性化商品参与者识别前端用户Primary Actor短信网关Secondary Actor社交平台APISecondary Actor推荐系统Supporting Actor关键用例建模startuml left to right direction actor 用户 as User actor 微信 as WeChat actor 短信网关 as SMS rectangle 登录系统 { usecase 基础登录 as Login usecase 短信登录 as SMSLogin usecase 社交登录 as SocialLogin usecase 处理失败 as HandleFailure usecase 推荐商品 as Recommend User -- Login User -- SMSLogin User -- SocialLogin Login |-- SMSLogin : 泛化 Login |-- SocialLogin : 泛化 SocialLogin . WeChat : 关联 SMSLogin . SMS : 关联 Login extends HandleFailure Login includes Recommend } enduml关系决策树当不同登录方式共享核心验证逻辑但实现细节不同时 → 使用泛化关系当需要调用外部系统服务时 → 使用关联关系当失败处理是可选分支流程时 → 使用扩展关系当商品推荐是登录成功后的必要步骤时 → 使用包含关系经验泛化关系适合is-a场景如短信登录是一种登录方式而包含/扩展更适合has-a场景。关联关系要谨慎使用避免变成系统架构图。2. 在线支付系统的包含与扩展实战一个SaaS平台的支付模块需要处理信用卡支付支付宝/微信支付支付失败重试支付结果通知风控拦截核心用例分解表主用例子用例类型关系触发条件发起支付验证支付方式包含每次支付必须执行信用卡支付3D认证扩展当银行要求额外认证时触发处理支付结果发送通知包含支付成功后必执行支付流程风控检查扩展当交易金额超过阈值时触发典型误区和修正错误做法将支付失败处理设为扩展关系问题所有支付都可能失败应作为包含关系修正方案startuml usecase 发起支付 as Pay usecase 验证支付方式 as Verify usecase 处理失败 as Fail usecase 3D认证 as 3DAuth Pay -- Verify : include Pay -- Fail : include Pay .. 3DAuth : extend note on link: amount 500USD enduml风控模块的扩展点设计定义扩展点RiskCheck// 伪代码示例 public class Payment { public void process() { verifyPaymentMethod(); // 包含关系 if (needsRiskCheck()) { // 扩展条件 triggerRiskCheckExtension(); } completePayment(); } }在用例图中用注释标注触发条件扩展关系应明确标注触发条件 如extend : transactionRisk 0.73. 内容审核系统的混合关系应用某UGC平台的内容审核系统包含自动AI审核人工复审敏感词过滤违规内容处置申诉处理复杂关系建模startuml actor 用户 as User actor 审核员 as Moderator actor AI系统 as AI usecase 提交内容 as Submit usecase 自动审核 as AutoReview usecase 人工复审 as ManualReview usecase 过滤敏感词 as Filter usecase 封禁用户 as Ban usecase 处理申诉 as Appeal User -- Submit Submit -- AutoReview : include AutoReview -- Filter : include AutoReview .. ManualReview : extend note right: 当AI置信度80% ManualReview -- Ban : include Ban .. Appeal : extend note left: 用户发起申诉时 enduml关系选择验证矩阵场景候选关系最终选择理由提交内容后必须进行审核包含 vs 扩展包含是核心业务流程的必要步骤AI审核后可能转人工扩展 vs 泛化扩展是条件触发的分支流程封禁与申诉的关联包含 vs 扩展扩展申诉是封禁后的可选反向流程敏感词过滤与自动审核包含 vs 关联包含过滤是审核的内部子步骤性能优化技巧对高频执行的包含关系用例如敏感词过滤采用缓存策略扩展关系对应的条件判断应前置避免不必要的资源消耗泛化关系的父用例要保持抽象不包含具体实现代码4. 高级应用组合关系与边界划分当系统复杂度上升时需要运用包图来组织用例电商平台用例分组示例com.example.ecommerce ├── account │ ├── Login │ ├── Register │ └── ProfileManagement ├── payment │ ├── CreditCardPayment │ ├── Refund │ └── CouponRedemption └── inventory ├── StockCheck ├── AutoReplenishment └── SupplierNotification系统边界划分原则每个子系统对应一个矩形边界框跨边界通信通过关联关系表示基础服务如日志、监控不纳入业务用例图外部系统使用特殊颜色标注常见反模式过度使用扩展关系导致流程图支离破碎泛化层次过深超过3层将系统内部实现细节暴露在用例图中关联关系形成网状结构应控制在星型拓扑内