图片显示了仓库的物流。非常非常简单。它的概念是什么：有文档：ReceivingWayBill，DispatchingWaybill，ReplacementOrder。
它们与主要类交互：Warehouse、Counterparty、Item。
还有Register 类：ItemRemainsInWarehouse。原来，文件是操作、接收、发送等的确认。 Register 只是存储剩余商品数量的信息。
如果你错过了这个方案的很多问题，例如：缺乏泛化、getter 和 setter 以及一堆其他的东西。
谁能告诉：类之间的关系，到处都有具体的聚合，放置正确，或者我们可以更详细地考虑关联吗？
【问题讨论】：
标签： oop uml aggregation modeling staruml
很难（也许不可能）通过提供的解释来纠正整个模型。我给出了一些改进。
你应该把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 的实例作为一部分，它们就是聚合。
【讨论】：
聚合是邪恶的！
阅读关于他们引入的两个变体的 UML 规范（第 110 页）：
none：表示 Property 没有聚合语义。 [听，听！]
shared：表示 Property 具有共享聚合语义。共享聚合的精确语义因应用领域和建模者而异。
composite：表示Property是复合聚合的，即复合对象负责复合对象的存在和存储（参见11.2.3中parts的定义）。 p>
复合聚合是一种强大的聚合形式，它要求一个部分对象一次最多包含在一个复合对象中。如果一个复合对象被删除，它的所有作为对象的部分实例都会被删除。
现在，最后一句话清楚地表明您应该在哪里使用复合 (!) 聚合：在与安全相关的应用程序中。当您删除数据库中的人员记录时，您还需要删除所有相关实体。经常使用的由电机、轮胎等组成的汽车的例子并不适合。当您“删除”汽车时，轮胎不会消失。只是因为你不能删除它。更糟糕的是使用共享复合，因为它没有每个定义的定义（原文如此！）。
那你该怎么办？使用多重性！这就是人们通常想要展示的东西。有0..n、1等与对方类相关的元素。最终，您可以通过使用角色来明确命名它们。
如果您考虑DispatchingWaybill 和ReceivingWaybill，它们看起来像是关联类。使用正确的多重性 (1-* / *-1)，您可以这样保留它。 （编辑：注意关联末端的小点，说明对面的类有一个以角色命名的属性。）
或者用虚线将它们当前连接到的类之间的关联附加到。
【讨论】：