UML中类图的关系是不是正确？

Posted 2023-03-29

【中文标题】UML中类图的关系是不是正确？

【英文标题】：Is correct relationships of class diagram in UML?UML中类图的关系是否正确？

【发布时间】：2018-06-24 10:30:36

【问题描述】：

图片显示了仓库的物流。非常非常简单。它的概念是什么：有文档：ReceivingWayBill，DispatchingWaybill，ReplacementOrder。

它们与主要类交互：Warehouse、Counterparty、Item。

还有Register 类：ItemRemainsInWarehouse。原来，文件是操作、接收、发送等的确认。 Register 只是存储剩余商品数量的信息。

如果你错过了这个方案的很多问题，例如：缺乏泛化、getter 和 setter 以及一堆其他的东西。

谁能告诉：类之间的关系，到处都有具体的聚合，放置正确，或者我们可以更详细地考虑关联吗？

【参考方案1】：

很难（也许不可能）通过提供的解释来纠正整个模型。我给出了一些改进。

你应该把Multiplicity你的关系。他们是如此重要。在某些关系中，您有 1 个（ReplacementOrder，Warehouse），而您的一些关系可能是 *（Item，ReceivingWayBill）

您将聚合放在类之间，我们知道聚合是关联的类型。您也可以放置关联。您可以找到许多类似的问题和答案来解释关联和聚合（和组合）之间的差异。见Question 1、Question 2 和Question 3。但我推荐this answer。

我认为，聚合和关联之间没有非常显着差异。请参阅this question 中的示例。

Robert C. Martin 说（见here）：

关联表示一个实例向另一个实例发送消息的能力。

聚合是典型的整体/部分关系。这与关联完全相同，但实例除外 不能有循环聚合关系（即一部分不能 包含它的全部）。

因此：你的一些关系正是一种聚合。 （Item 和其他类之间的关系）。您的 Counterparty 没有很好的 API 定义。您的其他关系是关于使用Warehouse 类。我认为（只是猜测）其他类只使用Warehouse 类服务（公共方法）。在这种情况下，它们可以是关联。否则，如果它们需要Warehouse 的实例作为一部分，它们就是聚合。

【讨论】：

我的回答或@ThomasKilian 的出色回答有什么问题？请评论您的想法以进行对话并提供更好的答案。我认为用评论投反对票会有所帮助。

没错。不幸的是，这里有更多的巨魔只是投反对票，而不关心做出好的答案。我很少投反对票（通常是因为我有一些错误）。但有时我会发现一个“不方便的地方”——比如这个。

感谢您的回答。它帮助了我）

【参考方案2】：

聚合是邪恶的！

阅读关于他们引入的两个变体的 UML 规范（第 110 页）：

none：表示 Property 没有聚合语义。 [听，听！]

shared：表示 Property 具有共享聚合语义。共享聚合的精确语义因应用领域和建模者而异。

composite：表示Property是复合聚合的，即复合对象负责复合对象的存在和存储（参见11.2.3中parts的定义）。 p>

复合聚合是一种强大的聚合形式，它要求一个部分对象一次最多包含在一个复合对象中。如果一个复合对象被删除，它的所有作为对象的部分实例都会被删除。

现在，最后一句话清楚地表明您应该在哪里使用复合 (!) 聚合：在与安全相关的应用程序中。当您删除数据库中的人员记录时，您还需要删除所有相关实体。经常使用的由电机、轮胎等组成的汽车的例子并不适合。当您“删除”汽车时，轮胎不会消失。只是因为你不能删除它。更糟糕的是使用共享复合，因为它没有每个定义的定义（原文如此！）。

那你该怎么办？使用多重性！这就是人们通常想要展示的东西。有0..n、1等与对方类相关的元素。最终，您可以通过使用角色来明确命名它们。

如果您考虑DispatchingWaybill 和ReceivingWaybill，它们看起来像是关联类。使用正确的多重性 (1-* / *-1)，您可以这样保留它。 （编辑：注意关联末端的小点，说明对面的类有一个以角色命名的属性。）

或者用虚线将它们当前连接到的类之间的关联附加到。

【讨论】：

那么，亲爱的反对者：这个答案有什么问题？

类关联怎么样。我在某处读到，这种方式不容易实现。你怎么看？

嗯。你是指哪种方式？你的意思是实现一个关联类？