UML中的类图正确关系吗？

Question

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

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

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.

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?

Answer 1

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, ie, 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.

Answer 2

It is so hard (maybe impossible) to correct your whole model with provided explanation. I give some improvements.

1. You should put Multiplicity of you relationships. They are so important. In some relationship, you have 1 ( ReplacementOrder , Warehouse ) and some of your relatioships are maybe * ( Item , ReceivingWayBill )

2. You put Aggregation between your classes and we know that Aggregation is type of Association. You can put Associations too. You can find a lot of similar questions and answers that explain differences between Association and Aggregation (and Composition). see Question 1 , Question 2 and Question 3 . But I recommend this answer .

I think, there is NOT a very significant difference between Aggregation and Association . See my example in this question .

Robert C. Martin says (see here ):

Association represents the ability of one instance to send a message to another instance.

Aggregation is the typical whole/part relationship . This is exactly the same as an association with the exception that instances cannot have cyclic aggregation relationships (ie a part cannot contain its whole).

Therefor : some of your relationships are exactly an Aggregation. (relationship between Item and other classes). Your Counterparty has not good API definition. Your other relationships is about using Warehouse class. I think (just guess) the other classes only use Warehouse class services (public methods). In this case, they can be Associations. Otherwise, if they need an instance of Warehouse as a part, they are Aggregations.