UML中的类图正确关系吗? [英] Is correct relationships of class diagram in UML?

问题描述

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

The image shows the logistics of the Warehouse. Very very simplistic. What is its concept: There are documents: ReceivingWayBill, DispatchingWaybill, ReplacementOrder.

它们与以下主要类进行交互:Warehouse，Counterparty，Item.

They interact with the main classes: Warehouse, Counterparty, Item.

和Register类:ItemRemainsInWarehouse.事实证明，文档是对操作，接收，发送等的确认. Register仅存储有关剩余商品数量的信息.

And the Register class: ItemRemainsInWarehouse. It turns out, the document is confirmation of the operation, reception, sending, and so on. The Register simply stores information about the number of remaining goods.

如果您错过了该方案的许多问题，例如:缺乏通用性，getter和setter以及其他所有内容.

If you miss a lot of problems of this scheme, such as: the lack of generalization, getters and setters and a heap of everything else.

谁能说明:类之间的关系以及到处都有具体的聚合，放置正确，还是可以以某种方式更详细地考虑关联?

Who can tell: the relationship between classes, and there is concrete aggregation everywhere, are placed correctly, or can we somehow consider the association in more detail?

推荐答案

聚集是邪恶的！

阅读有关它们引入的两个变体的UML规范(第110页):

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 :表示该属性是聚合聚合的，即，复合对象负责组成对象的存在和存储(请参见11.2.3中的部件定义).

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!).

那你该怎么办?使用多重性！这就是人们通常想要展示的东西.另一端有与类相关的0..n，1等元素.最终，您通过使用角色来明确命名这些名称.

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.

如果考虑DispatchingWaybill和ReceivingWaybill，则看起来它们是关联类.使用正确的多重性(1-* / *-1)，您可以以这种方式保留它. (编辑:请注意关联两端的小点，这些小点表明相对的类具有以角色命名的属性.)

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.

这篇关于UML中的类图正确关系吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！