本文澄清 uml 规范中组合（composition）与聚合（aggregation）的本质关系，指出“组合是聚合的子集”这一说法源于过时的 uml 1.x 定义，而根据现行 uml 2.5 标准，二者是并列的、语义明确的独立关系类型。
在面向对象建模中，组合与聚合常被统称为“整体-部分”（whole-part）关系，但它们在语义强度、生命周期责任和实现约束上存在本质差异。许多入门教程或网络图示（如 AlgoDaily 所展示的示意图）仍将组合画作聚合的一个子类，这容易引发误解——实际上，该层级结构并非来自当前 UML 标准，而是对早期 UML 1.x 规范的历史沿袭。
根据 UML 2.5 规范第 110 页（Section 9.5.3, “aggregation” attribute of Property），aggregation 是一个枚举型属性，仅可取以下三个互斥值之一：
aggregation : AggregationKind = none | shared | composite
- none：无聚合语义（即普通关联）；
- shared：表示共享聚合（Shared Aggregation），但 UML 2.5 明确声明：“其精确语义因应用领域和建模者而异，标准未作强制定义”；
- composite：表示组合（Composite Aggregation），具有严格语义：整体对象完全负责部分类对象的创建、存在性与内存管理（即强所有权、生命周期绑定）。
关键在于：shared 和 composite 是同一枚举类型的两个平行选项，而非父子继承关系。UML 2.5 已彻底废除了“聚合包含组合”的层级模型。所谓“组合是聚合的一种”，仅存在于 UML 1.3 及更早版本中——当时 aggregation 被定义为二元（aggregate / none），而组合被非正式地视作“更强的聚合”。这一历史包袱虽已从规范中移除，却仍在大量教学材料与工具图标中延续。
✅ 正确理解应为：
- 聚合（shared） ≈ “有归属感的使用关系”（如部门 拥有 多名员工，但员工可属于多个部门；离职后员工实例仍存在）；
- 组合（composite） ≈ “不可分割的生命共同体”（如汽车 由 发动机组成，发动机不能脱离汽车独立存在；汽车销毁时，发动机实例必须同步销毁）。
⚠️ 实践注意事项：
- 在 PlantUML、StarUML 或 Visual Paradigm 等工具中，务必检查所用 UML 版本配置；默认启用 UML 2.5 时，shared 与 composite 应以并列菱形（空心 vs 实心）表达，而非嵌套；
- 编码实现时，组合通常体现为成员变量的直接实例化 + 析构清理（C++/Rust），或依赖容器管理（Java ArrayList
配合 final 引用 + 显式 dispose()）；聚合则多通过构造器/Setter 注入已有对象，不干预其生命周期； - 若团队建模规范仍沿用旧图示，请在文档中显式注明：“此处‘聚合’泛指广义整体-部分关系，具体语义以 composite/shared 标签为准”。
总之，组合不是聚合的子集，而是与其并列的、语义更严格的另一种整体-部分关系。回归 UML 2.5 的权威定义，是写出清晰、可维护、跨团队一致的模型的第一步。
