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

Posted 2023-03-29

【中文标题】UML 表示法 - 聚合/组合与“普通”关联

【英文标题】：UML Notation - Aggregations/Compositions vs "Vanilla" Associations

【发布时间】：2010-11-11 09:57:48

【问题描述】：

我最近花了很多时间对我编写的各种 SW 组件进行详细的 UML 设计。回顾我最近完成的内容并将其与我第一次学习 UML 时进行比较，我发现我现在几乎严格使用聚合和组合关系，并且实际上已经放弃了“普通”的非定向/定向关系。当然，我仍然使用泛化和实现，但它们与上述明显不同，不被视为此问题的一部分。

在我看来，聚合/组合意味着“普通”关联的相同含义，等等。聚合和组合自然暗示了一个方向，任何现代 UML 程序仍然允许您在聚合/组合关系上定义多重性，并将动词应用于关系。在那一点上，我认为普通联想没有什么意义。

我知道有些人很难理解聚合和组合之间的区别。早期，我有点难以理解它们的不同之处，我相信混乱是我使用香草联想的部分原因。我现在看到很少或根本没有使用香草关联，实际上不喜欢看到它们被使用，因为我相信它们会留下一些问题（特别是两个对象之间的强或弱生命周期关系）。我相信香草关联的唯一实际用途是当您对手头问题的理解尚未发展到足以确定聚合和组合之间的生命周期差异时。在这种情况下，最好至少表明关系存在，然后当你对手头的问题有了更好的理解时，你可以回来并适当地改变它。

长话短说，我相信绝大多数时候人们使用香草联想，它们可以更准确地描述为聚合，有时也可以描述为组合。我的信仰是否大错特错？我错过了什么吗？让我听听！

【参考方案1】：

聚合和组合都暗示关系中的参与者“支配”另一个（在组合中支配性更强），而正常的关联没有这种暗示。因此，当两个参与者在关系中具有相同的重要性时，我会使用正常的关联

【参考方案2】：

在类图上，您正在考虑类之间的静态关系。您可能真的不需要考虑类图上这些关系的行为方面，它只会使水变得混乱，并且是过度分析的证据。 （当然恕我直言）

【参考方案3】：

当你说，“香草关联”唯一的实际用途是当你对手头问题的理解还没有发展到足以确定生命周期差异时，你已经击中了头和表明这种关系存在，当你对手头的问题有了更好的理解时，你可以回来并适当地改变它。

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

【讨论】：

很好解释但简洁的答案。说得通。谢谢马丁！

这个论点是完全错误的：聚合和组合扩展了 UML 中的关联概念这一事实并不能证明“关联是域对象之间的一种未细化的关系”的观点是正确的。在很多情况下，关联既不是聚合也不是组合。请参阅下面的答案。

【参考方案4】：

事实上，UML 类模型中的大多数关联情况既不是聚合也不是组合。例如，Publisher 和 Book 类之间用于将出版商出版的书籍分配给该出版商的关联既不是聚合也不是组合，因为出版商出版的书籍不是该出版商的部分或组件。

聚合是一种特殊形式的关联，它具有部分-整体关系的预期含义，但没有精确的语义（UML 规范说：“共享聚合的精确语义因应用领域和建模者而异”）。例如，我们可以对 Car 和 Engine 类之间以及 Course 和 Lecture 类之间的聚合建模，因为引擎是汽车的一部分，而讲座是课程的一部分。

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

除了组合的主要特征（具有独占部分）之外，组合还可能在聚合及其组件之间具有生命周期依赖关系，这意味着当删除聚合时，它的所有部分都将被删除用它。然而，这仅适用于某些组合情况，而不适用于其他情况，因此它不是一个定义特征。 UML 规范声明：“可以在组合实例被删除之前从组合实例中移除一部分，因此不会作为组合实例的一部分被删除。”在我们的 Car-Engine 组合示例中，很明显可以在汽车被破坏之前将引擎从汽车上移除，在这种情况下，引擎不会被破坏并且可以重复使用。

【讨论】：

您对组合的理解（或至少您对 UML 规范的引用）是错误的。请参阅UML Superstructure Specification, v2.4.1，第 38 页，其中说“..复合聚合是一种强大的聚合形式，需要一次在最多一个复合中包含一个部件实例..”。它在哪里说“..是最多一个聚合的一部分..？”

@xmojmr：我的理解和引用都没有错。我刚刚使用“聚合”作为“复合”的同义词。所以，请取消你不合理的反对票。

那里 IS 您将“聚合”一词用作“复合”的同义词有问题。它们不是同义词，您得出的结论给人的印象是您引用了 UML 规范。然后，您使用错误的报价作为拒绝***.com/a/25236323/2626313 的理由，而您的简化同义词“报价”不适用。如果您推翻您的投票并改进您的论点，我可以推翻我的投票。您正在从根本不包含您的报价的书中“引用”某些内容。在您发表评论后，我已经查看了我的答案。你能做到吗？

【参考方案5】：

Vanilla Associations、Aggregation 和 Compositions 有时用以下语义来解释：

普通关联：一个对象“知道”一个或多个其他对象 聚合：一个对象“拥有”一个或多个其他对象 组合：一个对象“包含”一个或多个其他对象 - 子对象不能没有组合容器

聚合和组合的主要区别是围绕“如果主对象消失 - 部分对象会发生什么？”的问题。

因此，我们的想法是使用三个选项之一的差异来描述一些完整性约束，例如“删除级联”。 UML为此提供了三种不同的符号

没有符号 - 香草协会 钻石 - 聚合 填充钻石 - 成分

这三个选项的问题在于语义对于现实生活中的情况不够精确，尤其是当您查看随时间变化的情况时

例如试图回答一个简单的问题“我的车有多少个轮胎***？” 会导致不同的答案：

4 个***永久固定在我的车上 1 个备用轮胎，我可能会在紧急情况下使用 4 个***是我的夏季或冬季***，在其他季节不固定在汽车上

见

UML diagram on diagrams.bitplan.com PlanUml markup for diagram

当汽车消失时，这些***中有多少会消失？ 如果您尝试使用 UML 提供的三个符号对这种情况进行建模，您最终会遇到大量讨论和协商您的模型的真正含义。我认为永远不要使用聚合和组合符号要好得多，而是总是将关联语义描述为 尽可能精确地用几行文本。这样你就可以让阅读你的模型的人清楚你真正想要什么。 我觉得还可以。写“汽车是包括车轮在内的零件的组合......”

但是现在你不是在使用组合符号，而是真正引用组合的行为。

另见 http://de.wikipedia.org/wiki/Assoziation_%28UML%29#Aggregation_und_Komposition（德语）