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

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

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

如上图所示，我拥有NetworkAgent类，其中包括用于侦听和接收的networkudprecever和用于发送数据包的NetworkUDPSender

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

在上面的示例中，我看到了一个完整的部件结构和可共享的部件。我的意见正确吗？你看到了吗

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

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

更新问题：Bruno正确地通知我，上图上的聚集标志位置不正确，应将其反转

如上图所示，我拥有NetworkAgent类，其中包括用于侦听和接收的NetworkUDPSender和用于发送数据包的NetworkUDPSender

否，在图中，NetworkAgent由NetworkUDPSender和NetworkUDPSender聚合，而不是相反，因为

不在NetworkAgent一侧

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

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

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

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

NetworkAgent--------NetworkUDPSender

和

NetworkAgent--------NetworkUDPSender

我知道聚合是一个完整的部分结构

您的图表显示了共享的合成（未填充的菱形）

p。UML 2.5的第110部分：

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

复合|表示属性是复合聚合的，即复合对象负责组合对象的存在和存储（参见11.2.3中的部分定义）

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

这个图表有误导性 幸运的是，

NetworkAgent

有一个嵌入式提示来帮助我们进行分类：两个属性，

receiverAgent

和

senderAgent

，分别属于

networkudpreciver

和

NetworkUDPSender

类型：

• 这是两个关联，一个是类

  networkudpreciver

  ，其名称为

  receiverAgent

  ，另一个是

  NetworkUDPSender

  ，其名称为

  senderAgent

• 更准确地说，这应该用接收器和发送器侧面的虚线端来表示
• 由于这种设计显然允许轻松地从代理导航到发送方或接收方，因此您可以在发送方和接收方的侧面使用箭头显示导航能力
• 假设其他类以相同的逻辑表示，我们可以认为没有简单的导航返回到阿让。这可以通过代理一侧的十字表示

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

聚合的问题 白钻石确实是用来描述一种局部-整体的关系（钻石是整体的一面）。但是UML允许语义开放，事实上，使用它比使用正常的关联没有任何优势。因此，如果你做了这个图表，最好的建议是避免它

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

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

有关此主题的更多信息，请参阅

结论 最好是从图中删除聚合。如果您决定将其用于对象合成，则将菱形移动到另一侧

---

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

是的，您是对的，的位置不正确。最后，你同意我的观点吗？您能解释一下组合对实现代码的影响吗？完全选择聚合或关联不会对代码产生影响？@hamed如果聚合不能是正反两种情况，那么使用聚合会令人困惑。你的情况似乎是b