UML表示法-聚合/组合与“普通”关联

当你说, “普通关联”的唯一实际用途是,当您对手头问题的理解还不足以确定生命周期差异时。 和 表明关系存在,然后当您对手头的问题有了更好的理解时,您可以回来并适当地更改它。 .

这个 UML Meta-Model 将聚合和组合定义为关联的扩展。关联可以被视为域对象之间的未定义关系,就像域对象是未定义类一样。我通常在领域建模阶段使用简单的关联,并在解析详细的类模型时根据需要将其细化为组合或聚合。

事实上,UML类模型中的大多数关联既不是聚合也不是组合。例如,类之间的关联 Publisher 和 Book 将发布者发布的图书分配给此发布者既不是聚合也不是合成,因为发布者发布的图书不是此发布者的组成部分。

聚合是一种特殊的关联形式,具有部分-整体关系的预期含义,但没有精确的语义(UML规范说:“共享聚合的精确语义因应用程序区域和建模器而异”)。例如,我们可以为类之间的聚合建模 Car 和 Engine 在班级之间 Course 和 Lecture 因为发动机是汽车的一部分,讲课是课程的一部分。

组合(在UML规范中也称为“复合聚合”)是一种特殊的聚合形式,其中一个组件实例一次最多是一个聚合实例的一部分(即,它不能在多个聚合之间共享)。这意味着 小型车 和 发动机 是一个组合(因为一个引擎不能同时在两辆车之间共享),而 课程 和 讲座 不一定是作文,因为一个讲座可以在两个课程之间共享(例如数据库管理课程和软件工程课程可以共享一个关于UML的讲座)。这意味着组合的关联端在聚合端的多重性是1或0..1,而在非复合聚合的情况下,它也可以是*。

除了组合的这一主要特征(要具有独占部分),组合还可能在聚合及其组件之间具有生命周期依赖性,这意味着当删除聚合时,将删除其所有部分。然而,这只适用于组成的某些情况,而不适用于其他情况,因此它不是一个定义性特征。UML规范声明:“在删除复合实例之前,可以从复合实例中删除一个部分,因此不能作为复合实例的一部分删除。”在我们的汽车引擎组合示例中,很明显,在汽车被销毁之前,可以从汽车中删除引擎,在这种情况下,引擎不是dest可重复使用。

在类图中,您考虑的是类之间的静态关系。你可能不需要在类图上考虑这些关系的行为方面,它只是搅浑了水,是过度分析的证据。(当然是imho)

香草的联想、聚合和成分有时用以下语义来解释:

• 普通关联:一个对象“知道”一个或多个其他对象
• 聚合:一个对象“具有”一个或多个其他对象
• 组合:一个对象“由”一个或多个其他对象组成-子对象不能没有组合容器

聚合和组合的主要不同之处在于“如果主对象不存在——部分对象会发生什么?”.

因此,我们的想法是在使用这三个选项中的一个时,使用微分来描述诸如“on delete cascade”这样的完整性约束。UML为此有三个不同的符号

• 无符号-香草协会
• 菱形-聚集
• 填充金刚石-成分

这三个选项的问题是,语义对于现实生活中的情况来说不够精确,特别是当您查看随时间变化的情况时。

例如,试图回答简单的问题 “我的车有多少个轮胎轮子?” 会得出不同的答案:

• 4个固定在我车上的轮子
• 1个备用轮胎,我可能在紧急情况下使用
• 4个车轮是我的夏季或冬季车轮,在其他季节不与汽车相连

当汽车不在时,这些车轮中有多少会消失? 如果你试图用UML提供的三个符号来建模这种情况,你最终会得到很多讨论和协商你的模型真正的意义。我认为最好不要使用聚合和组合符号,而是始终将关联语义描述为 用几行文字尽可能精确。这样你就可以向阅读你的模型的人清楚地表明你真正想要什么。 我觉得写“汽车是由包括轮子在内的零件组成的……”甚至可以。

但现在您并没有使用合成符号,而是真正引用了合成某些内容的行为。

也见 http://de.wikipedia.org/wiki/Assoziation_%28UML%29#Aggregation_und_Komposition (德语)

聚合和合成都意味着关系中的一个参与者“支配”另一个参与者(在合成中,支配性更强),而正常的关联没有这个含义。因此,当两个参与者在关系中具有相同的重要性时,我使用正常的关联。