UML Composition vs Aggregation vs Association

The concepts of Association, Aggregation and Composition exist in UML since the first published versions, but the exact  meaning of these concepts, especially the Aggregation still lead to heated debates among UML experts.

But before we go into the details, let’s have a look at how these concepts are defined in UML.

I guess every UML user is familiar with the graphical notation

But how do these concepts look like in the UML (v 2.3) meta model?

This is a the part of the UML metamodel that defines Association. (I’ve hidden the elements not relevant to the subject for clarity)

What we see is that an Association has at least two Properties in the role of memberEnd. A property has an attribute aggregation of type AggregationKind. It’s this AggregationKind that specifies the difference between a regular Assocation, an Aggregation and a Composition.

The three possible values for AggregationKind are defined in the superstructure as follows:

  • none
    Indicates that the property has no aggregation.
  • shared
    Indicates that the property has a shared aggregation.
  • composite
    Indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts).

And then below that we find one little sentence that is the main cause for all these discussions:

Precise semantics of shared aggregation varies by application area and modeler.

So basically the OMG is saying: We don’t know what it means, make up your own definition.

Looking for more clues in the definition of Association we find the constraint:

Only binary associations can be aggregations.
self.memberEnd->exists(aggregation <> Aggregation::none) implies self.memberEnd->size() = 2

OK, that doesn’t really help us. All it states is that the Aggregations and Compositions can only exist in Associations that have maximum two members, but that’s like the “normal” Association for most of us. I haven’t seen many Associations with more then two members yet.

Looking further we find in the the semantics section of the Association:

An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.
Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.
Composition is represented by the isComposite attribute on the part end of the association being set to  true.

So that paragraph already tells us a little bit more about the nature of Aggregation and Composition. Let’s dissect this paragraph and figure out what to remember

  • Aggregations and Compositions are whole/part relations:
    So any member of an Association that has aggregationKind <> none should be considered the whole, where the other end is the part
  • If the whole has aggregationKind = composite then the part can be included in at most one composite at a time:
    So a part cannot play the role of part in two compositions at the same time. This implies that the cardinality of a composite association can only be [0..1] or [1..1] on the composite end.
  • If a composite is deleted, all of its parts are normally deleted with it:
    This part seems clear, although the word normally indicates that this isn’t necessarily the case.
  • Compositions may be linked in a directed acyclic graph with transitive deletion characteristics:
    Now this is a difficult one. The directed acyclic graph part tells us that, when following the links from whole to part, we will not visit the same element twice. Combined with the “at most one composite at a time” constraint this even means that composite relations form a hierarchical tree. The transitive deletion part means that deleting one element from the tree would then delete the whole branch under this element. Unfortunately the word may in the sentence means that this again is no hard constraint, but merely an indication of how it can be used.

And that’s about all  the UML specification has to say about the different types of aggregation. All other constraints you find in books and on the internet are purely interpretations and added semantics of the authors.

Now let’s have a look at some typical examples of Composition and Aggregation (or aggregationKind = shared and aggregationKind = composite as we learned from the specifications)

This example shows the class structure of the popular social networking site LinkedIn

On the right we see the Group structure as a set of Compositions because
a) each “whole” can be considered as a grouping of “parts”
b) each “part” can belong to only one “whole” at a time
c) the “parts” would normally be deleted when the “whole” is deleted

Note that discussions can be moved from one section to another (Usually from Discussions to Jobs or Promotions), but they cannot be part of two sections at the same time.

The relation between Group and User however is an Aggregation because
a) a Group can be considered a “grouping” of users
b) a User can be part of multiple Groups at the same time
c) a User would normally not be deleted when a Group is deleted.

In short, the Composition is a type of Association with real constraints and impact on development, whereas the Aggregation is purely a functional indication of the nature of the Association with no technical impact.

35 thoughts on “UML Composition vs Aggregation vs Association

  1. UML did not created the concepts of aggregation and composition. UML is just agnostic to its interpretation/hard use – as it is for a lot of other things, since it is just a notation and not a method. Go see the old papers of the 70’s that first defined what were aggregation/composition relationships (The Smiths’s paper “Database abstractions- aggregation and generalization” for a good start). UML specification is not THE BIBLE, the source of truth. There was object orientation before UML, and sometimes I find that UML lost connection with those roots (roots= “An Object Modeling Technique for Conceptual Design” by Rumbaugh). If a book writer gives throws some light over the cumbersome UML specification, it is something good, not bad.

    • Alex,

      I guess you are probably right, and that indeed concepts with the same name existed before UML. But I’m talking about these concepts as defined in UML, not elsewhere.
      In fact the UML specification IS the Bible with regards to UML. Unfortunately there is no standard specification of OO. So the UML specification is the only official specification to go by.
      I’m all for shedding light on UML,but in the end the only authority remains the UML specification as published by the OMG.

  2. I’m refering to your excellent post in my StackOverflow answer http://stackoverflow.com/questions/734891/aggregation-versus-composition/27889087#27889087, where I try to destroy the widespread false belief that the UML composition concept is defined via the lifecycle dependency of the components on the composite. My fight against this false belief provides a story in the sociology of opinion dynamics because mayn people seem to think that I must be wrong because most others do hold this (lifecycle dependency) belief. I’m glad that there are a few experts like you who arrive at their own conclusion based on their own analysis, and do not parot what others have said.

    • Hi Gerd. I’m glad you like the article.
      One of the reasons I wrote is was because I found different opinions all over the web that didn’t necessarily comply with what I found in the UML specifications.
      The problem is that few people actually read the UML specs (can you really blame them) and thus have to get their info elsewhere. And a lot of UML books actually provide a practical implementation view of UML instead of the theoretical.
      There’s nothing wrong with practical implementation of course. Each implementation of UML in a concrete modelling method should have these, but one should know when this is the case and where you are diverting from the UML standard.

      • Geert:

        I went through the entire chain in which I too participated actively.

        You are right that “a lot of UML books actually provide a practical implementation view of UML”. As you say “There is nothing wrong with practical implementation of course” but I would add “THEY MUST BE CONSISTENT WITH the principles and recommendations of the standard”.

        We can insist on it only if the “standard is well-drafted, verified and validated and worthy of compliance”. Unfortunately UML specification which technically is NOT a standard has fallen short of such respect and adherence. In the first place there is NO glossary and the same term is defined in different parts of the UML spec with emphasis on different aspects without any coherence and consistency. There is no clarity on what is essential (mandatory) and what is optional. The UML spec continues to bloat without consolidating around some “core” or “kernel” (suggested by Ivar Jacobson and Steve Cook in 2009. Ivar Jacobson is pushing his kernel proposal through SEMAT (having given up on UML of OMG, it seems) but I do not know if those efforts are successful.

        What you say “few people actually read the UML specs” is true but the problem is that UML is spec is NOT readable—particularly by busy professionals who seek some clarity and help without having to wade through 800+ pages of bloated mass of text and sophisticated graphics.

        20JAN15

    • Your rephrasing just reflects your own private understanding of these terms, but it is not compatible with the official UML definitions (in particular, the UML definition of composition.does not imply any lifecycle dependencies). While you are free to choose using your own private language, this choice is certainly not a good one if you want to communicate with other developers who use/accept UML.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s