两个实体之间的两个（或多个）聚合关系答案

【问题标题】：Two (or more) aggregation relationships between two entities两个实体之间的两个（或多个）聚合关系
【发布时间】：2014-05-31 02:34:01
【问题描述】：

考虑以下（抽象）情况：

两个实体。两个实体之间有两种聚合关系。

图表如下所示：

我知道这可能听起来很模糊，但是这张照片有什么问题吗？

我的意思是，这种设计是否会出现任何（明显的）问题？

或者我是偏执狂，两个实体之间的两个（或多个）聚合关系绝对没有错？

【问题讨论】：

SHARED 聚合，或 SHARED，不是聚合本身。
(UML 标准 2.9, p.109) 聚合可以是 3 种：无（无菱形）、共享（空菱形）、复合（黑色菱形）。将共享聚合与聚合混合使用是不正确的。例如，您可以轻松地在每个中拥有两个或多个共享聚合的并行关联，并且只有一个与复合聚合的关联。
@Gangnus，我亲爱的朋友，我们知道您已经将自己提交给 UML 演讲，但请注意，像我这样的其他人仍然希望说自然的英语，因此我们更喜欢使用 UML 术语“聚合" 和 "composition"，它是与不可共享部分的聚合。
@gwag 谢谢你的好话，朋友。但我恐怕不能同意。 1. 广泛使用的错误仍然是错误。呼吁多数派是一个错误的论点。 2. 在三个最常用的 UML 工具中，只有一个使用“聚合”而不是“共享”。它不是最常用的 EA。因此，您在专业人士中确实是少数。所以，即使你的谬论也是错误的。

【解决方案1】：

对我来说，这样的设计并没有错。您的 Entity2 将在每个上下文中扮演不同的角色。

【讨论】：

【解决方案2】：

只要关系扮演着真正不同的角色（正如您通过编号所指示的那样），我认为这是一种很好的方法，因为您将它们明确化。

否则你可以利用基数：

【讨论】：

【解决方案3】：

图表没有错。这是一个更有意义的例子。

-贤治

【讨论】：

我不认为你的例子很有意义。在何种意义上，您认为交易是客户的一部分？我认为作为业务对象的客户参与到作为业务事件的事务中。通常，对象参与事件。但事件不是对象的一部分！
好的，你是对的。那么，我将类名 Customer 更改为 Transaction Manager 怎么样？
关系1:1的共享聚合是什么意思？最好承认当前存在多个交易。
@gwag 1.事务不是一个事件，它是一个动作，有开始和结束，可以持续很长时间。 2. 钻石是空的。并且共享聚合不假设项目（如您所说的部分）-容器关系。
@Gangnus：请注意，动作只是一种特殊类型的事件，因此交易也是事件，无论它是否是瞬时的。此外，只需查找（在一本好的字典或更好的哲学百科全书中，例如SEP）什么是部分-整体（或部分）关系。