6

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

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

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

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

4

5 回答 5

3

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

Publisher 和 Book 之间的关联模型

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

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

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

于 2014-08-04T13:59:17.367 回答
2

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

  • 香草关联：一个对象“知道”一个或多个其他对象
  • 聚合：一个对象“拥有”一个或多个其他对象
  • 组合：一个对象“由”一个或多个其他对象组成 - 子对象不能没有组合容器

聚合和组合的主要区别在于“如果主对象消失了 - 部分对象会发生什么？”这个问题。

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

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

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

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

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

汽车的轮子

看

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

但是现在您不是在使用组合符号，而是在真正引用组合某些东西的行为。

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

于 2014-08-04T17:46:11.083 回答
1

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

于 2009-07-16T23:18:38.513 回答
1

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

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

于 2009-10-07T15:39:02.757 回答
0

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

于 2009-07-16T19:56:42.320 回答