UML（统一建模语言）建模中的“保底铁三角”通常指在软件系统分析与设计阶段最基础、最常用、考试或实践中必考必用的三个核心图，掌握它们即可稳拿基础分（即“保底”），且因其高度稳定、适用广泛、标准明确，被称为“铁三角”。这三类图是：
用例图（Use Case Diagram）
→ 描述系统功能需求，从用户（Actor）视角展现“谁在什么情况下使用系统做什么”，聚焦业务场景与系统边界。
✅ 关键元素：参与者（Actor）、用例（Use Case）、关系（关联、包含、扩展、泛化）。类图（Class Diagram）
→ 描述系统的静态结构，体现类、属性、方法及类之间的关系（如关联、聚合、组合、继承、依赖）。
✅ 是面向对象设计的核心，支撑后续实现，也是代码映射最直接的UML图。时序图（Sequence Diagram，又称顺序图）
→ 描述对象间按时间顺序的交互过程，强调“消息传递的先后与生命线”，适用于细化关键用例的动态行为。
✅ 清晰表达控制流、同步/异步调用、返回、自调用、可选片段（alt）等，实战与答辩高频图。
📌 为什么称“稳定”？
- 三大图在UML 2.x规范中定义成熟、工具支持完善（如StarUML、Enterprise Architect、PlantUML）；
- 高校教学、软考（中高级）、企业需求分析/概要设计文档中长期稳定采用；
- 考试评分标准明确，绘图规范（如命名、可见性符号+/-/#、箭头类型）易掌握、易得分。
简记口诀： “用例抓需求，类图搭骨架，时序理流程” —— 铁三角，稳拿分！用例图中「包含（include）」和「扩展（extend）」是两种有向依赖关系，均用于复用用例逻辑，但语义、方向性、可选性与建模意图存在本质区别：
| 维度 | 包含（«include»） | 扩展（«extend»） |
|---|---|---|
| 语义本质 | 强制调用：基础用例必须执行被包含用例，否则不完整（类似子程序调用） | 可选增强：扩展用例仅在特定条件下插入到基础用例的扩展点，非必需（类似插件机制） |
| 方向性 | 箭头从基础用例 → 被包含用例（实线+«include»） | 箭头从扩展用例 → 基础用例（虚线+«extend»）✅ 方向易错！ |
| 可选性 | 不可省略；被包含用例无独立意义（不能单独被Actor触发） | 可省略；扩展用例可独立存在，但通常不直接由Actor发起 |
| 扩展点 | 无显式扩展点（隐含在流程中） | 必须在基础用例中明确定义扩展点（Extension Point），指明插入位置与条件 |
| 典型场景 | 通用功能复用（如“登录”“记录日志”“验证权限”） | 异常处理、可选功能、业务规则分支（如“支付时使用优惠券”“上传文件超限时提示”） |
🔹举例说明（在线购物系统）：
✅包含关系：
用例「提交订单」«include»「验证库存」
→ 每次提交订单前必须检查库存，否则流程非法；「验证库存」无法被用户直接触发，纯支撑逻辑。✅扩展关系：
用例「提交订单」定义扩展点check_promotion；
用例「应用优惠券」«extend»「提交订单」，扩展条件为[用户已登录且购物车含可用优惠券]
→ 仅满足条件时才执行优惠计算，不影响「提交订单」主流程完整性。
⚠️ 常见误区提醒：
- ❌ 把「extend」箭头画反（应从扩展用例指向基础用例）；
- ❌ 将业务主干逻辑（如“支付”）错误设为「extend」——它应是核心用例，而非可选增强；
- ❌ 在「include」中放入可选行为（如“发送邮件通知”若非强制，则应改用「extend」或「observe」）。
口诀记忆： 包含 = “没你不行”（强制嵌入）→ 基础→被包含 扩展 = “有你更好”（条件插入）→ 扩展→基础 + 扩展点
 agent和组件)