误诊/错误识别类图中关系类型的后果答案

【问题标题】：Consequences of misdiagnosis / false identifying of the relationships types in the class diagram误诊/错误识别类图中关系类型的后果
【发布时间】：2023-03-26 17:10:02
【问题描述】：

我阅读了很多关于类图中关系的文档，但我仍然对某些关系犹豫不决。

我的第一个问题是确定以下关系的类型：

如您在上图中所见，我有 NetworkAgent 类，其中包括用于侦听和接收的 NetworkUDPReceiver 和用于发送数据包的 NetworkUDPSender。

我知道聚合是一个整体结构，因为部分可以共享，并且当一个类引用另一个类作为非整体结构中的成员时使用关联。

在上面的例子中，我看到了整体结构和可共享的部分。我的意见对吗？你看到聚合了吗？

我的第二个和更重要的问题是，如果我选择了错误的关系会发生什么？我知道正确的答案可能取决于我的应用程序或问题概念。

例如，如果正确答案是关联，如果我错误地选择聚合，会发生什么情况，或者会有什么后果？（反之亦然）

更新问题：Bruno 正确告知我上图中聚合符号的位置不正确，应该颠倒过来。

【问题讨论】：

标签： uml class-diagram class-design visual-paradigm ibm-rational

【解决方案1】：

此图具有误导性

幸运的是，NetworkAgent 有一个嵌入的提示来帮助我们整理：receiverAgent 和 senderAgent 两个属性，它们的类型分别为 NetworkUDPReceiver 和 NetworkUDPSender：

这是equivalent to having 两个关联，一个带有类NetworkUDPReceiver，名称为receiverAgent，另一个带有NetworkUDPSender，名称为senderAgent。
为了更准确，应在接收方和发送方一侧用虚线表示。
由于这种设计显然可以轻松地从代理导航到发送方或接收方，因此您可以在发送方和接收方一侧使用箭头来显示可导航性。
假设其他类的表示遵循相同的逻辑，我们可以认为没有简单的导航回到 agen。这可以通过代理一侧的十字表示。

所以这几乎完全对应于您圈出的关联，但有一个明显的例外：错误的聚合。

聚合的东西

白色钻石确实是用来描述部分与整体的关系（钻石在整体的一侧）。但是 UML 让语义开放，事实上，使用它而不是正常的关联没有任何优势。因此，如果您制作图表，最好的建议是避免使用它。

此外，我还要挑战您证明代理与发送者/接收者之间存在部分-整体关系：发送者不是代理的一部分。发件人只是与代理相关联。

一些建模者滥用 UML 聚合来系统地表示对象组合。这从根本上来说并没有错，而是将实现问题与设计问题混为一谈。这样的建模者确实会在这里使用聚合，但会将它放在代理的一边。

更多关于这个话题，in-depth argumentation additional references, here。

结论

最好的方法是从图中删除聚合。如果您决定将其用于对象组合，则将菱形移至另一侧。

更一般地说：如果您使用关联而不是聚合，则不会产生任何影响。如果您使用聚合而不是关联，则可能会产生误导，但通常不会产生实际后果。

【讨论】：

当我在 Visual Paradigm 中将 ReceiverUDPAgent 设置为可共享聚合时，它会自动绘制聚合并将菱形放在零件侧，如图像。我转到 NetworkAgent 规范，打开 ReceiverAgent 规范，然后将聚合类型设置为共享。我怎样才能绘制聚合并将钻石放在整个侧面？
@hamed 好的，然后您需要将 NetworkAgent 设置为可共享聚合，因为代理是聚合（您可以将其理解为聚合共享其部分）。
不，我同意该协会，只是我想知道为什么Visual Paradigm 将Aggregation diamond 放在part 一侧？

【解决方案2】：

如您在上图中所见，我有 NetworkAgent 类，其中包括用于侦听和接收的 NetworkUDPReceiver 和用于发送数据包的 NetworkUDPSender。

不，在图中 NetworkAgent 由 NetworkUDPReceiver 和 NetworkUDPSender 聚合，而不是相反，因为 <> 未启用NetworkAgent

如果我选择了错误的关系会发生什么？

如果正确答案是“关联”，如果我错误地选择“聚合”会发生什么，或者会有什么后果？（反之亦然）

在这种情况下，您的模型是错误的/令人困惑的，但这可能不会改变不依赖于此的相应 Java 代码（与对实现代码有影响的组合相反）

对我来说，如果你有这三个类，你有组合而不是聚合，因为当相应的 NetworkAgent 时仍然有 NetworkUDPSender 和 NetworkUDPReceiver 实例> 实例消失没有意义，所以NetworkAgent <*>-------NetworkUDPReceiver 和NetworkAgent <*>-------NetworkUDPSender

【讨论】：

是的，你是对的，的位置不对。最后，你同意我关于聚合的观点吗？你能解释更多关于组合对实现代码的影响吗？完全选择聚合或关联不会影响代码？
@hamed 在不能使用聚合时使用聚合会令人困惑或相反。在您的情况下，使用组合而不是“简单”聚合似乎更好，因为当 NetworkAgent 消失时仍然有 NetworkUDPSender 和 NetworkUDPReceiver 没有感觉
我认为NETWORKUDPSENDER 和receiver 是可共享的，并且可以自己存活，最后你能解释一下组合对实现代码的影响吗？
@hamed 如果您使用套接字 (UDP/IP)，则通道是双向的，对我来说，该套接字由 NetworkAgent 管理，所以没有它，您将无法再接收或通过套接字发送。如果你有A<*>---B或者只是A<*>--->B，当A的一个实例消失时，B的相应实例也消失了，这必须由实现来完成
我不知道为什么，但我使用两个不同的套接字进行接收和发送。是的，如果我使用 1 个套接字组合是正确的，但我认为基于我在图像上显示的类并使用 2 个不同的套接字，聚合是正确的。最后，如果它是一个组合，我应该小心删除子对象，对于聚合和关联，代码没有区别？

【解决方案3】：

我知道聚合是一个整体结构

您的图表显示了一个共享的构图（未填充的菱形）。

p。 UML 2.5 的第 110 条：

共享 |表示该属性具有共享聚合语义。共享聚合的精确语义因应用领域和建模者而异。

复合 |表示Property是复合聚合的，即复合对象对复合对象的存在和存储负责（见11.2.3部分的定义）。

因此，为了理解 UML 建模者想要表达的内容，您需要明确要求他定义共享聚合的语义！

【讨论】：