0

I have the following class diagrams taken from a book
UML diagrams In Figure 6.4 there is a plain line between part and purchase order
line item. Whereas in figure 6.11 there is an arrow from
purchase order line item to part
What's the difference between these two ?

bruno
  • 32,421
  • 7
  • 25
  • 37
Monu Didi
  • 7
  • 4

1 Answers1

1

In Figure 6.4 there is a plain line between part and purchase order line item

in this figure the relation is (probably) navigable in the two directions, that means Part and Purchage Order Line Item reference/know each other

Typically the class Purchage Order Line Item has an attribute of type Part, and the class Part has an attribute of type Purchage Order Line Item (the multiplicities are not indicated, let say they are both 1 else they are collection of).

This is the case E-F in figure 11.29 Examples of navigable association-owned ends page 205 of formal/2017-12-05

in figure 6.11 there is an arrow from purchase order line item to part

In this diagram the relation is navigable in only one direction, Purchage Order Line Item reference/know the Part but Part does not know/reference the Purchage Order Line Item knowing/referencing it

Typically the class Purchage Order Line Item has an attribute of type Part, but the class Part does not have an attribute of type Purchage Order Line Item (the multiplicities are not indicated, let say they are both 1 else they are collection of).

This is the case I-J in figure 11.29 Examples of navigable association-owned ends page 205 of formal/2017-12-05

bruno
  • 32,421
  • 7
  • 25
  • 37
  • For figure 6.4 does `When the PO is deleted or archived, the line items are taken along` holds ? I have taken this from the book Domain Driven Design book. But I am not sure why the design in figure 6.11 is better and how it preserves the invariant – Monu Didi Mar 17 '21 at 11:48
  • @MonuDidi `When the PO is deleted or archived, the line items are taken along` about archived it is not possible to know that, for deleted it is only sure in case of a composition, but here there is no composition in both diagram, only aggregation in the second case. The second is better at least because the PO memorizes the price through POLI (price get when the PO is made) => if later the price of an item changes the PO is unchanged as it must be – bruno Mar 17 '21 at 12:55
  • So it's like PO has it's unique copy of POLI and POLI has a unique copy of price and quantity. So the price of an item cannot change outside PO. ie. one cannot edit the item price as the reference to it is inside POLI and not available outside. So what I understand is there is a list of parts with a price for each part. And when POLI is made it includes the price at that time from the part object. Whereas in figure 6.4 it holds a reference to the part so if the part price changes it will get changes in POLI which is undesirable – Monu Didi Mar 17 '21 at 13:10
  • Yes. A part's price can change at any time at its level. In 6.4 the PO price is computed from each part price so if a part's price changes the PO price change too, this is not expected. Thanks to the copy of the part's price in POLI in second diagram that problem disappears. The goal of the aggregation in the second diagram is to say a POLI is own by a PO, so a POLI cannot be shared by several PO – bruno Mar 17 '21 at 13:19
  • Thanks. So when we talk about aggregator pattern. It seems like there is a root object that keeps a copy of child-objects and so once the root object is constructed the changes to the child-objects are not propagated inside root-object.. just like in the bottom figure. That seems like one main point of aggregator pattern.. Am I correct here ? – Monu Didi Mar 17 '21 at 17:02