0

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?

class diagram

ChrisF
  • 134,786
  • 31
  • 255
  • 325
John Brown
  • 11
  • 1
  • 6

2 Answers2

0

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

enter image description here

Alternatively attach either with a dashed line to an association between the classes where they are currently connected to.

enter image description here

Community
  • 1
  • 1
qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • What about classes associations . I somewhere read , that this way is not easy to be realized. What do you think about it? – John Brown Jan 16 '18 at 13:37
  • Hmm. Which way do you you mean? You mean implementing an association class? – qwerty_so Jan 16 '18 at 13:40
  • @qwerty_so *“the little dots at the association's ends which tell that the class at the opposite has an **attribute named** after the role”.* What if the type of the `counterPartyName` (in the class of `DispatchingWaybill`) is `std::unique_ptr` instead of `CounterParty`? – John Apr 20 '22 at 09:40
  • @John　as said I'm not firm with generics. I would rather write it with the angle brackets. But no guarantee. Someone might answer your other question... – qwerty_so Apr 20 '22 at 10:08
0

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 (i.e. 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.

Gholamali Irani
  • 4,391
  • 6
  • 28
  • 59
  • 1
    What is the problem with my answer, or with @ThomasKilian 's remarkable answer? Please comment your ideas to make conversation and provide better answers. I think downvote with comment can help. – Gholamali Irani Jan 16 '18 at 10:52
  • 1
    Exactly. Unfortunately there are more trolls here which just down-vote and don't care about making good answers instead. I get few down-votes (and usually because I had some error). But sometimes I spot an "un-conveniant place" - like this one. – qwerty_so Jan 16 '18 at 12:32
  • Thanks for your answer.It helped me ) – John Brown Jan 16 '18 at 13:34