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

Question

图像显示了仓库的物流。非常非常简单。它的概念是什么:有单据:< code > receiving lubril ，< code > dispatchinglirl ，< code>ReplacementOrder。

它们与主要类交互：仓库、交易对手和项目。

以及< code>Register类:< code > ItemRemainsInWarehouse 。原来，文件是操作、接收、发送等的确认。< code>Register仅存储关于剩余商品数量的信息。

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

谁能判断：类之间的关系，以及到处都是具体的聚合，是否放置正确，或者我们是否可以更详细地考虑关联？

Answer 1

聚合是恶！

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

none：指示属性没有聚合语义。[听到了，听到了！

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

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

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

现在，最后一句清楚地指出了应该在哪里使用composite(！)聚合:在安全相关的应用中。删除数据库中的人员记录时，还需要删除所有相关的实体。经常使用的例子是汽车由发动机、轮胎等组成。不太合适。当你“删除”汽车时，轮胎不会消失。因为你不能删除它。更糟糕的是使用共享组合，因为它没有每个定义的定义(原文如此！).

那你该怎么办？使用乘数！这是人们通常想要展示的。有0..n、1等元素与另一侧的类相关。最终，您可以通过使用角色来明确这些角色。

如果您考虑＜code＞DispatchingWaybill＜/code＞和＜code＞ReceivingWaybill＞，看起来它们是关联类。使用正确的乘法（1-*/*-1），您可以这样做。（编辑：注意关联末尾的小点，它们告诉对面的类有一个以角色命名的属性。）

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

Answer 2

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

>

你应该把你的关系的多重性。它们太重要了。在某些关系中，你有1个（替换订单，仓库），你的一些关系可能是*（项目，接收WayBill）

您将聚合放在类之间，我们知道聚合是关联类型。您也可以放置关联。您可以找到许多类似的问题和答案，这些问题和答案解释了关联和聚合（以及组合）之间的差异。请参阅问题 1、问题 2 和问题 3。但我推荐这个答案。

我认为，聚合和关联之间没有非常显著的区别。请看这个问题中我的例子。

罗伯特·C·马丁说（见这里）：

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

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

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