该图显示了仓库的物流。非常非常简单。它的概念是什么： 有文件：ReceivingWayBill, DispatchingWaybill, ReplacementOrder.
它们与主要类交互：Warehouse, Counterparty, Item.
和Register类：ItemRemainsInWarehouse。原来，文件是操作、接收、发送等的确认。Register简单地存储有关剩余商品数量的信息。
如果你错过了这个方案的很多问题，例如：缺乏泛化、getter 和 setter 以及一堆其他的东西。
谁能告诉：类之间的关系，到处都有具体的聚合，放置正确，或者我们可以更详细地考虑关联吗？
通过提供的解释来纠正整个模型非常困难（也许是不可能的）。我给出了一些改进。
你应该把你的关系的多样性。他们是如此重要。在某些关系中，您有 1 ( ReplacementOrder, Warehouse) 并且您的一些关系可能是 * ( Item, ReceivingWayBill)
你把聚合放在你的类之间，我们知道聚合是一种关联。您也可以放置关联。您可以找到许多类似的问题和答案来解释关联和聚合（以及组合）之间的差异。见问题 1、问题 2和问题 3。但我推荐这个答案。
我认为，Aggregation和Association之间没有非常显着的区别。请参阅我在这个问题中的示例。
Robert C. Martin 说（见这里）：
关联表示一个实例向另一个实例发送消息的能力。
聚合是典型的整体/部分关系。这与关联完全相同，只是实例不能具有循环聚合关系（即一部分不能包含其整体）。
因此：你的一些关系正是一个聚合。Item（与其他类之间的关系）。你Counterparty的 API 定义不好。你的其他关系是关于使用Warehouse类。我认为（只是猜测）其他类只使用Warehouse类服务（公共方法）。在这种情况下，它们可以是关联。否则，如果它们需要一个实例Warehouse作为一部分，它们就是聚合。
Aggregation is evil!
Read the UML specs about the two variants they introduced (p. 110):
none: Indicates that the Property has no aggregation semantics. [hear, hear!]
shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.
Now, that last sentence clearly indicates where you should use composite (!) aggregation: in security related appications. When you delete a person record in a database you need to also delete all related entities. That often used example with a car being composed of motor, tires, etc. does not really fit. The tires do not vanish when you "delete" the car. Simply because you can not delete it. Even worse is the use of a shared composite since it has no definition per definition (sic!).
So what should you do? Use multiplicities! That is what people usually want to show. There are 0..n, 1, etc. elements related to to the class at the other side. Eventually you name these by using roles to make it explicit.
If you consider DispatchingWaybill and ReceivingWaybill it looks like those are association classes. With the right multiplicities (1-* / *-1) you can leave it this way. (Edit: note the little dots at the association's ends which tell that the class at the opposite has an attribute named after the role.)
Alternatively attach either with a dashed line to an association between the classes where they are currently connected to.
