class 图中关系类型的误诊/错误识别的后果
Consequences of misdiagnosis / false identifying of the relationships types in the class diagram
我阅读了很多关于 class 图中关系的文档，但我仍然对某些关系犹豫不决。
- 我的第一个问题是确定以下关系的类型：
正如您在上图中看到的那样，我有 NetworkAgent class，其中包括用于收听和接收的 NetworkUDPReceiver 和 NetworkUDPSender 用于发送数据包。
我知道聚合是一个整体部分结构，因为部分可以共享，并且当 class 引用另一个 class 作为非整体部分结构中的成员时使用关联.
在上面的例子中，我看到了整体结构和可共享的部分。我的意见对吗？你看到聚合了吗？
- 我的第二个和更重要的问题是如果我选择了错误的关系会怎样？我知道正确答案可能取决于我的应用或问题概念。
例如，如果正确答案是Association，如果我错误地选择了Aggregation，会发生什么，或者会有什么后果？ （反之亦然）
更新问题: Bruno 正确地告诉我上图中聚合符号 <> 的位置不正确，应该颠倒。
as you could see in the above image I have NetworkAgent class which includes NetworkUDPReceiver for listening and receiving and NetworkUDPSender for sending packets.
不，图中 NetworkAgent 由 NetworkUDPReceiver 和 NetworkUDPSender 聚合，不是相反，因为 <> 不在 NetworkAgent
的一侧
what would happen if I choose the wrong relationship?
if the correct answer is Association, what would happen, or what are the consequences if I choose Aggregation incorrectly? (and vice versa)
在那种情况下，你的模型是错误的/令人困惑的，但这可能不会改变不依赖于它的相应 Java 代码（与影响实现代码的组合相反）
对我来说，如果你有这三个 类 你有组合而不是聚合，因为仍然有 NetworkUDPSender 和 NetworkUDPReceiver实例对应的NetworkAgent实例消失是没有意义的，所以NetworkAgent <*>-------NetworkUDPReceiver和NetworkAgent <*>-------NetworkUDPSender
I know Aggregation is a whole-part structure
您的图表显示了共享构图（未填充的菱形）。
页。 UML 2.5 的 110:
shared | Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite | Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
因此，为了理解 UML 建模者想要表达的内容，您需要明确要求他定义共享聚合的语义！
此图具有误导性
幸运的是，NetworkAgent 有一个嵌入式提示来帮助我们解决问题：两个属性，receiverAgent 和 senderAgent，类型为 NetworkUDPReceiver 和 NetworkUDPSender分别为：
- 这是 equivalent to having 两个协会，一个 class
NetworkUDPReceiver 的旁边是名字 receiverAgent，另一个是 NetworkUDPSender 的名字senderAgent 在它的一边。
- 为了更准确，这应该用接收方和发送方一侧的虚线表示。
- 由于此设计显然允许轻松地从代理导航到发送方或接收方，因此您可以在发送方和接收方的一侧用箭头显示可导航性。
- 假设其他 classes 表示遵循相同的逻辑，我们可以认为没有简单的导航回到代理。这可以通过代理一侧的十字来显示。
所以这几乎完全符合您圈出的关联，有一个重要的例外：错误的聚合。
聚合的东西
白色钻石确实是用来描述部分与整体的关系（钻石在整体的一边）。但是UML让语义开放了，事实上，用它代替普通的关联并没有什么优势。所以，如果你制作图表，最好的建议是避免它。
此外，我会向您提出挑战，证明代理人与 sender/receiver 之间存在部分-整体关系：发件人不是代理人的一部分。发件人仅与代理关联。
一些建模者滥用 UML 聚合来系统地表示对象组合。这从根本上说是错误的，但将实现问题与设计问题混为一谈。这样的建模者确实会在这里使用聚合，但会把它放在代理端。
关于此主题的更多信息，in-depth argumentation additional references, here。
结论
最好的办法是从图表中删除聚合。如果您决定要将其用于对象组合，请将菱形移到另一侧。
更一般地说：如果您使用关联而不是聚合，则没有影响。如果您使用聚合而不是关联，它可能会产生误导，但通常不会产生实际后果。
我阅读了很多关于 class 图中关系的文档，但我仍然对某些关系犹豫不决。
- 我的第一个问题是确定以下关系的类型：
正如您在上图中看到的那样，我有 NetworkAgent class，其中包括用于收听和接收的 NetworkUDPReceiver 和 NetworkUDPSender 用于发送数据包。
我知道聚合是一个整体部分结构，因为部分可以共享，并且当 class 引用另一个 class 作为非整体部分结构中的成员时使用关联.
在上面的例子中，我看到了整体结构和可共享的部分。我的意见对吗？你看到聚合了吗？
- 我的第二个和更重要的问题是如果我选择了错误的关系会怎样？我知道正确答案可能取决于我的应用或问题概念。
例如，如果正确答案是Association，如果我错误地选择了Aggregation，会发生什么，或者会有什么后果？ （反之亦然）
更新问题: Bruno 正确地告诉我上图中聚合符号 <> 的位置不正确，应该颠倒。
as you could see in the above image I have NetworkAgent class which includes NetworkUDPReceiver for listening and receiving and NetworkUDPSender for sending packets.
不，图中 NetworkAgent 由 NetworkUDPReceiver 和 NetworkUDPSender 聚合，不是相反，因为 <> 不在 NetworkAgent
what would happen if I choose the wrong relationship?
if the correct answer is Association, what would happen, or what are the consequences if I choose Aggregation incorrectly? (and vice versa)
在那种情况下，你的模型是错误的/令人困惑的，但这可能不会改变不依赖于它的相应 Java 代码（与影响实现代码的组合相反）
对我来说，如果你有这三个 类 你有组合而不是聚合，因为仍然有 NetworkUDPSender 和 NetworkUDPReceiver实例对应的NetworkAgent实例消失是没有意义的，所以NetworkAgent <*>-------NetworkUDPReceiver和NetworkAgent <*>-------NetworkUDPSender
I know Aggregation is a whole-part structure
您的图表显示了共享构图（未填充的菱形）。
页。 UML 2.5 的 110:
shared | Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite | Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
因此，为了理解 UML 建模者想要表达的内容，您需要明确要求他定义共享聚合的语义！
此图具有误导性
幸运的是，NetworkAgent 有一个嵌入式提示来帮助我们解决问题：两个属性，receiverAgent 和 senderAgent，类型为 NetworkUDPReceiver 和 NetworkUDPSender分别为：
- 这是 equivalent to having 两个协会，一个 class
NetworkUDPReceiver的旁边是名字receiverAgent，另一个是NetworkUDPSender的名字senderAgent在它的一边。 - 为了更准确，这应该用接收方和发送方一侧的虚线表示。
- 由于此设计显然允许轻松地从代理导航到发送方或接收方，因此您可以在发送方和接收方的一侧用箭头显示可导航性。
- 假设其他 classes 表示遵循相同的逻辑，我们可以认为没有简单的导航回到代理。这可以通过代理一侧的十字来显示。
所以这几乎完全符合您圈出的关联，有一个重要的例外：错误的聚合。
聚合的东西
白色钻石确实是用来描述部分与整体的关系（钻石在整体的一边）。但是UML让语义开放了，事实上，用它代替普通的关联并没有什么优势。所以，如果你制作图表，最好的建议是避免它。
此外，我会向您提出挑战，证明代理人与 sender/receiver 之间存在部分-整体关系：发件人不是代理人的一部分。发件人仅与代理关联。
一些建模者滥用 UML 聚合来系统地表示对象组合。这从根本上说是错误的，但将实现问题与设计问题混为一谈。这样的建模者确实会在这里使用聚合，但会把它放在代理端。
关于此主题的更多信息，in-depth argumentation additional references, here。
结论
最好的办法是从图表中删除聚合。如果您决定要将其用于对象组合，请将菱形移到另一侧。
更一般地说：如果您使用关联而不是聚合，则没有影响。如果您使用聚合而不是关联，它可能会产生误导，但通常不会产生实际后果。