聚合必须是一对多的吗？

Question

我一直避免使用聚合，因为它似乎是主观的，一对多的关系应归类为聚合。但我正在审查由其他人生成的模型，其中聚合用于多对多关系（如：一个课程由几个模块组成，一个模块可能是几个课程的一部分）。这对我来说是完全错误的，但我找不到反对它的明确规则。什么是官方裁决？

Answer 1

一个很好的网站是

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

如果您在那里搜索“共享和复合聚合”，您将阅读，共享部分可以建模为聚合。即使保留零件的复合材料将被丢弃，零件也可以存活。

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

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

Answer 2

两件事：

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

我不是UML Aggregation关系的粉丝。虽然所有权具有直观的吸引力，但实际上它太主观了。我不使用它，一般不建议使用它（虽然见脚注）。相反，请关注重要问题：

1. 什么是基数？
2. 什么是创建/删除行为？
3. 为什么这种关系存在？ （即什么商业事实/规则是关系捕获？

以上所有内容均可通过直接关联完成。如果答案是（a）它是一对多，（b）'one'结束负责创建/删除'many'结束和（c）你真正想要的，然后使用Composite关联。然而，聚合通常不会提高模型的可读性，它会增加混淆并减损表面基础规则/要求。

第h

脚注：有一种情况，聚合确实具有明确定义的语义并且可能很有用。具体来说，如果你有一个递归关系，Aggregation说结果对象结构是非循环的（即DAG）。下行是相对较少的人意识到财产 - 当然不是业务领域的专家。因此，您通常必须突出显示，例如在评论/约束中。

Answer 3

1. 我们设定条款。 Aggregation是UML标准中的元项，意味着BOTH组合和共享聚合，简称为 shared 。通常它被错误地命名为“聚合”。它是坏的，因为组合也是聚合。据我了解，您的意思是“共享”。

2. 再次，如果我们看一下UML standards（在那里寻找超结构文档），我们会发现，“共享聚合的精确语义因应用领域和建模者而异。”因此，您选择的任何策略都是可以接受的。您甚至可以针对不同的项目使用不同的策略。

3. 但是共享聚合是有用的，并且可以在两侧使用多重性，甚至空白钻石也可以在两侧。



UML中的关联是一种抽象，可以用任何语言实现，无论如何，只有实现必须符合图表。

如图所示，这种关联可以实现如下：

  

学生的每个实例都有他注册的课程列表，   并且每个课程实例都有一个已注册的列表   学生/与会者。

但这不是唯一的实现方式。可能有数组而不是列表，甚至有人可以完全没有任何正常的集合 - 只需使用C ++内存中的地址。

当然，我们可以绘制两个协会，一个用于学生的课程列表，第二个用于课程的学生列表。但是因此：

• 我们的图表变得更加复杂，因此可读性更低。
• 我们正在详细描述任何编码员在99％的情况下都会做的基本事情。
• 我们限制了编码员的自由。在1％的情况下，他们必须在不遵循图表和不进行有效编码之间做出选择。这根本不是你的工作。

所以，按你的意愿去做。禁止只是在一个项目中改变策略，并禁止其他人使用他们唯一的策略。