本文澄清 uml 2.5 规范中组合（composition）与聚合（aggregation）的正确定位：二者是并列的、语义明确的关联类型，而非包含关系；所谓“组合是聚合的子集”源于过时的 uml 早期规范，已不适用于现代建模实践。
在面向对象建模中，尤其是使用 UML 类图时，关联（Association）、聚合（Aggregation）和组合（Composition） 常被用来表达对象间的结构性关系。初学者常被某些教程图示误导——例如将组合画作聚合的一个子类或子集（如部分网站或旧版教材中的韦恩图），进而误以为“组合是一种特殊的聚合”。这种理解虽直观，但不符合现行 UML 标准（UML 2.5 及以后）。
根据 UML 2.5 规范第 110 页 对 Property 元素中 aggregation 枚举属性的明确定义，聚合语义仅有三种取值：
- none ：无聚合语义（即普通关联） - shared ：共享聚合（shared aggregation） - composite：组合（composite aggregation）
关键在于：shared 和 composite 是同一枚举类型的两个互斥选项，地位完全平等。规范特别指出：
"shared" indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler."composite" indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects.
这意味着：
- composite（组合）具有严格语义：整体对象完全拥有部分对象的生命周期控制权（创建、销毁）与内存管理责任；
- shared（聚合）并无统一、强制的语义约束——它仅表示一种松散的“整体–部分”关系，其具体含义依赖上下文（如领域模型约定或团队规范），甚至可被忽略；
- none 则回归到基础关联，不暗示任何“整体–部分”含义。
因此，在 UML 2.5 中，组合 不是 聚合的子集，而是与共享聚合（shared）并列的第三种独立聚合语义选项。所谓“组合 ⊂ 聚合”的图示，实为对 UML 1.x 时期模糊定义的历史遗留误读。彼时规范曾尝试将聚合作为上位概念，但因语义不清、难以落地而被 UML 2.0 起彻底重构——将三者解耦为正交的建模范畴。
? 实践建议与注意事项：
- ✅ 在绘制类图时，优先使用标准 UML 2.5 符号：空心菱形（◇）表示 shared，实心菱形（◆）表示 composite，避免添加易引发歧义的“包含”式层级图示；
- ⚠️ 若团队沿用旧术语（如称“聚合”泛指所有整体–部分关系），务必在建模规范中明确定义，防止沟通偏差；
- ❌ 不要依赖 IDE 或绘图工具的默认标签（如 PlantUML 旧版本可能混淆 aggregation 关键字），应以 UML 规范为准绳校验语义；
- ? 记住设计本质：组合强调强所有权与生命周期绑定（如 Car 拥有 Engine），聚合强调弱引用与独立存在性（如 Department 包含 Employee，但员工可属于多个部门或独立存在）。
总之，组合与聚合的关系，不是“子集”而是“并列”；不是“强弱程度之分”，而是“语义契约之别”。坚守 UML 2.5 的精确性，方能写出可验证、可协作、可持续演进的高质量模型。
