Saturday, October 10, 2009

Composite and Aggregate and what they imply

Associations between classes are easy enough to understand; Car has 4 wheels


But in the information system we build it may be obvious that a Car owns all its Wheels; the car and all its wheels can be looked at as a complete entity of its own -  a composite. If the Car is scrapped, the wheels are also implicitly thrown away. A Composite in UML is created by decorating the association with a filled diamond:


For any well behaving MDD tool this decoration should imply a cascading delete of all associated wheels when the Car is deleted.

A composite also signals to the UML reader that the Car and Wheels are created at the same time, and that they may not be meaningful on their own. So some will argue that the model should be changed from “0..1 Car” to “1 Car” (i.e wheel must always belong to exactly one car):


On the other hand this might not be the best idea for just the domain we are modeling now. If the system we build is one that describes a garbage sorting facility we may want to say: “Yes a car often has wheels, and the car and its wheels can be looked as an entity of its own (a composite), but we sometimes want to take this composite apart and treat the parts separated”. If this is the case the  aggregate decoration can be used:


The aggregation symbol signals to the UML reader that the connection between Car and Wheel is “strong and common” and that “Car owns wheels” is more appropriate to the domain than “Wheel owns Car” (this also applies to the composite symbol) .

A well behaving MDD tool should probably prohibit the deletion of a Car until the Wheels are gone. So that the scrap yard guys does not delete a car while the valuable wheels are still on it.

To sum it up: Composite is stronger than Aggregate; both symbols imply that the domain sometimes look on the classes as a bigger unit. The symbols help the UML reader to understand the larger compositions in the domain. The symbols imply specific destruction behavior to good behaving model driven development frameworks (MDD-Frameworks).

What does ECO and Gaffr do

Each Association end in ECO has the “Delete Action” property:


The DeleteAction can be set to one of these values:


DeleteAction on the Wheels association Calling Car.AsIObject().Delete()
Allow will work even if you have wheels left on the car, but the wheels will be left dangling
Prohibit will not work as long as you have wheels on the car
Cascade will delete any remaining wheels
<Default> If the association end is Composite treat as Cascade, if the association end is Aggregate treat as Prohibit, if the association end has aggregation==none treat as Allow

The recommendation is to leave the DeleteAction on <Default> and use the Aggregation setting to control the delete action AND help UML readers to understand the domain.


Blogger Peter Leslie Morris said...

Your explanation is correct but I think a different example would be better. A wheel can exist without the car, the car without the wheel, and you would want to identify a specific wheel (especially the tyres).

The components which make up an engine might be a better choice. Very few people would refer to the parts within their engine, only the engine itself. Or maybe you could think of organs in a body, where they may be referenced in discussions (associations added to them) it makes no sense (ordinarily) that they exist beyond the life of the body in which they reside.

The physical words written on a piece of paper perish when the paper is destroyed, but the pen lives on and so (hopefully) does the author :-)

October 10, 2009 at 12:38 PM  
Blogger Hans Karlsen said...

Thanks! Good and relevant comments as always Pete!

October 10, 2009 at 1:51 PM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home

Contact Us | Terms of Use | Privacy Statement © 2009 CapableObjects