UML – Composition and Aggregation
I borrowed the Fundamentals of Object Oriented Design book by Meiler Page-Jones from my campus library. I wanted to do a little reference lookup on UML class diagrams to better understand another related topic -Design Patterns. The author has a fantastic and simple style and it is one of those books that can distinguish the relevant from the irrelevant. I particularly liked his subtle sense of humour and also his respect for history as he devotes three full pages to the men and women who have made significant contributions to this field, albeit from their bathtubs as the author likes to put it! I would have never heard or Larry Constantine (coupling and cohesion), O J Dhal and Nygaard(Class concept), Alan Kay, Adele Goldberg et al(SmallTalk@Xerox), Barbara Liskov (ADT) and Jean Ichbiah(ADA) but for this book.
I was blown away by the author’s clear exposition of the differences between composition and aggregation. Composition and aggregation are used to model whole/part relationships. The similarities stop here. They have very specific definitions and they are usually not interchangeable if the system is well designed. Composition is used when an object(composite) is made up of other objects(components). The whole refers to the composite object and the part refers to the components. For example, a pen consists of a refill and a holder for the refill. The pen is the composite object and the components are the refill and the holder. Composition has the following three essential properties
- A compostion does not exist without the components. A pen without a refill has no significance.
- At any given time each component object can be in only one composite. A refill cannot be in two pens at the same time
- The components are heteromeric. This means that there is no relationship between the components. We cannot associate a meaninful relationship between refills and holders.
Composition is represented in UML by a association line with a solid diamond on the composite end. Unless otherwise specified the multiplicity is assumed to be one. Navigation is usually from the composite to the components though reverse navigation can also be established Aggregation is used in a completely differenct context. An aggregation represents a group/member relationship. The inherent understanding here is that all members are alike with respect to their general properties. The group is the whole and the members are the parts. For example a department is an aggregation of employees. Aggregation has the following three characteristics
- An aggregate can exist without the parts. For example a department can exist without any employees assigned to it as yet. This can be violated in some special cases. Consider the case of a sentence as an aggregation of words. Can a sentence exist without any words? (ask a zen master…)
- A member can belong to more than one aggregation at any point in time. An employee can belong to more than one department.
- All members of an aggregation are homeomeric. A fancy way to say that they are alike.
Aggregation is represented in UML as an association line with a hollow diamond on the aggregate end. It is mandatory to mention multiplicity as there can be no valid assumptions made like in the case of composition. The following table is a repetition but a one glance summary of the above content
|The whole cannot exist without the parts||The whole can exist without the parts|
|A part can belong to only one whole at a time||A part can belong to more than one whole at a time|
|The parts are not alike||The parts are alike|
|Representation is a association line with solid diamond||Representation is a association line with hollow diamond|