聚合必须是一对多吗？

Question

我总是避免使用聚合，因为它看起来太主观了，一对多的关系应该被归类为聚合。但我正在回顾另一个人制作的模型，其中聚合用于多对多关系(如:一个课程由几个模块组成，一个模块可能是几个课程的一部分)。这在我看来是大错特错的，但我找不到一个明确的规则来反对它。官方裁决是什么？

Answer 1

两件事：

1. 是否允许共享聚合？根据UML规范，是的。
2. 它在实践中有用吗？一般来说，我会说不。

我不是UML聚合关系的粉丝。虽然所有权在直觉上很有吸引力，但在实践中太主观了。我不使用它，通常也不建议使用它(尽管请参阅脚注)。相反，把重点放在重要的问题上：

创建/删除关系( cardinality?

• What's /

1. )存在吗？(即，关系捕获的业务事实/规则是什么？

所有这些都可以通过直接的关联来完成。如果答案是(a)是一对多，(b) ' one‘端负责创建/删除' many’端，(c)你真的想要，那么使用复合关联。然而，聚合通常不会提高模型的可读性，它会增加混乱，并影响底层域规则/需求的浮出水面。

hth。

脚注:有一种情况下，聚合确实有定义良好的语义，并可能是有用的。具体地说，如果你有一个递归关系，聚合表示结果对象结构是非循环的(即DAG)。缺点是很少有人意识到这一点--当然不是业务领域的专家。因此，您通常必须突出显示，例如在注释/约束中。

Answer 2

一个很好的网站是

http://www.uml-diagrams.org/class-diagrams.html

如果你在那里搜索“共享和复合聚合”，你会看到，共享部分可以被建模为聚合。即使保持该部件的复合材料将被丢弃，这些部件也可以存活。

这似乎使多对多的关系成为可能。例如，为几个视图组件共享视图的一部分。为什么不..。

就我个人而言，这与我的理解相符，即UML是非常具有解释性的。

Answer 3

，

1. ，让我们来设定一下条件。聚合是UML标准中的一个元元素，表示组合和共享聚合，简称为shared。它经常被错误地命名为“聚合”。这很糟糕，因为组合也是一种聚合。据我所知，您的意思是"shared".
2. Again，如果我们查看UML standards (在那里查找上层结构文档)，我们会发现“共享聚合的精确语义因应用程序领域和建模器而异”。所以，你选择的任何策略都是可以接受的。您甚至可以对不同的项目使用不同的策略。
3. 但是共享聚合很有用，可以在两端使用多样性，甚至可以在两端都使用空菱形。

​

UML中的关联是一种抽象，可以在任何语言中实现，并且以任何方式实现，只有实现必须符合图。

这种关联，如图所示，可以通过如下方式实现：

每个学生实例都有一个注册课程的列表，每个课程实例都有一个注册学生/参与者的列表。

但这并不是实现的唯一途径。可以使用数组而不是列表，甚至有人可以在根本不需要任何常规集合的情况下创建它--只需使用C++中内存中的地址。

当然，我们可以绘制两个关联，一个用于学生的课程列表，另一个用于课程的学生列表。但是如下所示：

• 我们的图表变得更复杂，因此可读性更差。我们彻底描述了任何程序员在99%的情况下都会做的基本事情，

，

• ，我们限制了程序员的自由。在1%的情况下，他们将不得不在不遵循图表和没有有效编码之间做出选择。这根本不是你的工作。

所以，随你所愿。禁止的是只在一个项目期间改变策略，并禁止其他人使用他们唯一的策略。