想象这些类，其中SeasonPoints 通过组合聚合到Team 和Season，其中在许多Seasons 中播放的Team 可以有多个SeasonPoints，而Season 可以有许多Teams 可以有多个来自不同Teams 的SeasonPoints。
请注意，为了让SeasonPoints 存在，它需要一个得分的球队和一个得分得分的赛季，所以我看不到其他制作此图表的方法：
1 n n 1
|Team|<comp>----|SeasonPoints|-----<comp>|Season|
问题激增是因为这样你可以销毁Team 或Season 和SeasonPoints 仍然存在（在另一个未被销毁的类中），这意味着容器可以在不销毁的情况下被销毁它包含的类，组合表示如果容器被销毁，包含的类也应该被销毁。
【问题讨论】：
标签： oop uml class-diagram
规格说明如下：
有时，Property 用于对使用一个实例将一组实例组合在一起的情况进行建模；这称为聚合。为了表示这种情况，Property 具有 AggregationKind 类型的聚合属性；代表整个组的实例由 Property 的所有者分类，代表分组的个人的实例由 Property 的类型分类。 AggregationKind 是具有以下文字值的枚举：
none：表示 Property 没有聚合语义。
shared：表示 Property 具有共享聚合语义。共享聚合的精确语义因应用领域和建模者而异。
composite：表示Property是复合聚合的，即复合对象对复合对象的存在和存储负责（参见11.2.3部分的定义）。 p>
复合聚合是一种强大的聚合形式，它要求一个部分对象一次最多包含在一个复合对象中。如果一个复合对象被删除，它的所有作为对象的部分实例都会被删除。
所以基本上你的模型是完全错误的（根据最后一句话）。
但是 - 你最好忘记聚合，因为它们引入的模糊比实际添加的语义更多。关于这个有很多讨论。汽车是否由车轮组成，即使上述规格在示例中也显示了它？你知道，一个轮子可以独立存在，当汽车被摧毁时，它不会被“摧毁”。当您为数据库建模时，这可能很有用（删除相关信息）或当您必须对内存建模（复合元素的可用空间）时。但几乎在所有情况下，与多样性的简单关联就足够了。
【讨论】：
SeasonPoints 建模为关联类（它实际上是）。