Uml 聚合是否必须是一对多？

我一直避免使用聚合，因为哪种一对多关系应该被归类为聚合似乎太主观了。但我正在回顾一个由其他人制作的模型，其中聚合用于多对多关系（例如：一门课程由几个模块组成，一个模块可能是几个课程的一部分）。我觉得这显然是错误的，但我找不到一个明确的规则来反对它。官方规定是什么？

这是一个很好的网站

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

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

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

两件事：

是否允许共享聚合？根据UML规范，是的

它在实践中有用吗？一般来说，我会说不

我不喜欢UML聚合关系。虽然所有权在直觉上很吸引人，但在实践中却过于主观。我不使用它，通常也不建议使用它（尽管见脚注）。相反，关注重要的问题：

基数是多少

创建/删除行为是什么

为什么存在这种关系？（即关系捕获的业务事实/规则是什么

如果答案是（a）一对多，（b）“一”端负责创建/删除“多”端，以及（c）但是，聚合通常不会提高模型的可读性，它会增加混乱，并有损于呈现底层域规则/需求

嗯

脚注：有一种情况下，聚合确实具有定义良好的语义，并且可能很有用。特别是，如果您具有递归关系，聚合表示生成的对象结构是非循环的（即DAG）。缺点是，相对而言，很少有人意识到这一点——当然不是商业领域的专家。因此，你通常必须突出显示，例如在评论/约束中

让我们设置术语。聚合在UML标准中是一个元术语，它意味着组合和共享聚合，简单地称为共享。通常它被错误地命名为“聚合”。这是不好的，因为组合也是一个聚合。据我所知，你的意思是“共享”

同样，如果我们看一下（在那里查找上层结构文档），我们会发现“共享聚合的精确语义因应用程序区域和建模者而异”。因此，您选择的任何策略都是可以接受的。您甚至可以对不同的项目使用不同的策略

但是共享聚合是有用的，可以用于两侧的多重性，甚至空菱形也可以用于两侧

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

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

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

<> p>但这不是唯一的实现方式。可以有数组而不是列表，甚至有人可以在没有任何正常集合的情况下完成它——只使用C++中的地址。 当然，我们可以画两个协会，一个是学生名单，另一个是学生名单。因此：

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

---

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

谢谢。有用的回答-确认我自己的理解和经验。谢谢。这证实了我自己的经验，即聚合是非常主观的。