Modeling Aggregation and Composition
Many modelers overuse aggregation. Remember that the aggregation and composition notation do not generate any unique code. Use the notation to convey your intent to the implementers.
Composition:
As we know, inheritance gives us an 'is-a' relationship. To make the understanding of composition easier,
we can say that composition gives us a 'part-of' relationship. Composition is shown on a UML diagram as a filled diamond (see figure below).
Aggregation:
If inheritance gives us 'is-a' and composition gives us 'part-of', we could argue that aggregation gives us a 'has-a' relationship. Within aggregation, the lifetime of the part is not managed by the whole. To make this clearer, we need an example. For the past 12 months I have been involved with the implementation of a CRM system, so I am going to use part of this as an example. The CRM system has a database of customers and a separate database that holds all addresses within a geographic area. Aggregation would make sense in this situation, as a
It would nor make sense to say that an Address is 'part-of' the Customer, because it i not.
Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist.
Aggregation is shown on a UML diagram as an unfilled diamond (see figure below).
Customer 'has-a' Address.
It would nor make sense to say that an Address is 'part-of' the Customer, because it i not.
Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist.
Aggregation is shown on a UML diagram as an unfilled diamond (see figure below).
