Are UML Aggregation and Composition Good Concepts?Apr 4, 2006 · 2 minute read · Comments
Yesterday a work collegue made the remark that the notions of aggregation and composition were not very clear. I was a bit surprised at first. But I actually almost always use just associations relations, sometimes composition, I was not sure anymore about the difference between aggregation and association and the one between composition and aggregation. I had to look up in a book to remember what it was all about.
The French book we looked at was really bad. In the end we did not understand fully the differences except a notion of “stronger coupling”, some kind of “asymetry”!?! The difference between aggregation and composition was more explicit since in a composition, the “child” can only have one parent.
The UML Distilled book is much more explicit and I recommend that book to anybody doing UML:
- Aggregation is strictly meaningless ; as a result, I recommend that you ignore it in your own diagrams .If you see it in other people’s diagrams, you’ll need to dig deeper to find out what they mean by it . Different authors and teams use it for very different purposes.
- Composition is a good way of showing properties that own by value, properties to value objects (page 73), or properties that have a strong and somewhat exclusive ownership of particular other components.
Bertrand Meyer prefers to describe relationships using only two concepts, client and heir, basically UML association and specialization and therefore avoids the distinction between aggregation and composition and association:
- B is a client of A if every object of type B may contain information about one or more objects of type A.
- B is an heir of A if B denotes a specialized version of A.