UML Association Aggregation Composition notation

UML Composition vs Aggregation vs Association

, ,

What makes a UML Composition different from an Aggregation or a regular 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 leads 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.5) meta model?

UML 2.5 Associations Meta Model

This is a the part of the UML meta model 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 UML specifications 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).

But a bit further, in the semantics section of Properties we find the same explanation except for a small addendum

  • shared
    […] 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.

memberEnd->exists(aggregation <> AggregationKind::none) implies (memberEnd->size() = 2 and memberEnd->exists(aggregation = AggregationKind::none))

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.

And the second part of the OCL constraint tells us that only one of the two ends can play the whole part, so the other end must play the part part.

Looking further in the specs we find in the semantics section of the Property the following

Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.

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

  • that requires a part object be included in at most one composite
    object at a time
    So a part cannot play the role of part in two compositions at the same time. This implies that the multiplicity of a composite association can only be [0..1] or [1..1] on the composite end.
  • If a composite object is deleted, all of its part instances that are objects are deleted with it.
    This is one of the parts where v 2.5 is different from previous versions. Previous versions of the UML specifications had the phrase “are normally deleted with it”. By leaving the “normally” out there no more ambiguity. Deleting the whole will always result in deleting the part in a composition.

But there still a loophole for the delete story.

NOTE. A part object may (where otherwise allowed) be removed from a composite object before the composite object is deleted, and thus not be deleted as part of the composite object.

So before the whole is deleted we can remove the part to avoid having to delete the part as well.

And then there a last paragraph that deals with Compositions

Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an object in one part of the graph will also result in the deletion of all objects of the  subgraph below that object. The precise lifecycle semantics of composite aggregation is intentionally not specified. The order and way in which composed objects are created is intentionally not defined. The semantics of composite aggregation when the container or part is typed by a DataType are intentionally not specified.

  • 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.
  • […]are intentionally not specified
    This is simply sad… These few sentences basically tell us again nothing at all, except that we shouldn’t look for a specification of these aspects in the UML specifications.

So 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” should be deleted when the “whole” is deleted (except when we move them to another “whole” first)

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 should not be deleted when a Group is deleted.

To summarize

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.

37 replies
  1. 317s37
    317s37 says:

    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.


    Thanks for this, and for making it clear what OMG actually defines.

    If I replace the aggregation between Group and user with an association , retaining everything else about the relationship, the same – what information do I Lose in the diagram?


    • geertbellekens
      geertbellekens says:


      I guess it depends on the purpose and audience of you model.
      If you are modeling a technical PSM level model with an audience of programmers, then the Aggregation won’t really contribute that much.
      If you are modeling a PIM or CIM level model with an audience of functional or business analysts, the Aggregation might be a useful distinction to make. It tells something about the functional nature of the relationship.

  2. Milan Kratochvil
    Milan Kratochvil says:

    A good post, thank you for the metamodel explanation. I agree the distinction is mainly functional, and making a PIM or CIM a little more comprehensible (I wrote a similar discussion about all three, from an analyst viewpoint, in UML Xtra Light, p. 54-56).
    At the PSM level on the other hand, the distinction doesn’t pay off much. As an extreme example, if the backbone of the platform happens to be just plain “kernel” SQL (no object handling, no Hibernate/no ORDB mapper framework whatsoever), then all three are stored as associations (using foreign key) plus rules of referential integrity – and those rules are all that differs; for example, the rule “On delete set null” is typical of associations whereas “On delete cascade” is mandatory in composition (it’s actually a SQL translation of what the UML metamodel says about instances in compositions).

  3. afro54
    afro54 says:

    Hi all,

    I found a couple of quotes on another website. I can’t confirm the source but, it must be an excellent book.

    Aggregation uses instances of objects created outside of this class.

    Composition uses instances of objects that are created as part of this object.

    It’s a semantic argument but, it’s more important than that!

    When is it more important? It’s more important when transforming the UML model, as I am attempting to do automatically (using profiles in VS2010).
    Aggregation heavily implies that the aggregate object already exists, to be grouped in the calling object.
    Composition heavily implies that the composite object should be created by the calling object.

    I guess this is the bit that should cause arguments – the modeller should be aware of this distinction, as it will influence the transformation and/or coding of the object classes. For modelling to a business audience, the choice of association type will make little difference.

    I can’t find an argument against this distinction, but would love to hear one.

  4. Putcha V. Narasimham
    Putcha V. Narasimham says:

    Geert: What you call cardinality is referred to as “multiplicity” in UML with lower limit l and higher limit h (l..h). You said that the multiplicity at the “whole-end” can be (0..1). That means that the number of “wholes” can be none or one. Is that possible? If so what does it mean? Does it NOT mean “some, say 3, parts make a “zero whole” or “no whole”? I recall that the “whole” can be one and only one, that is (1..1)—NOT (0..1).

    I request Geert or other members participating in this discussion to cite other examples and explanations.

    • geertbellekens
      geertbellekens says:


      That for pointing that out. I’ looked it up, and it seems that the cardinality is the actual number of objects on a link, where the multiplicity defines the limits of the cardinality.

      Except for that linguistic point, I think there rest still stands. The UML specification clearly states that an element can be removed from its composite and therefore the lower limit of the multiplicity is 0.
      What that means in the real world, is that a car plays the role of the “whole” in a composite association with a wheel.
      But I could take the wheels of a car and put them on a shelf. Then there are 0 cars, or 0 “wholes” to the wheel part.

      • Putcha V. Narasimham
        Putcha V. Narasimham says:

        Geert: Regarding cardinality and multiplicity here a complete description with reasons from There are some publications which oversimplify the concepts and definitions leading to avoidable confusion.

        Cardinality/Optionality: Both cardinality and optionality are conveyed by characters in the form: ..

        … where the denotes the optionality (nearly always 0 or 1, although conceivably it could be something else), and the denotes the cardinality. The may be either an asterisk (*) for the generic “more than one”, or it may be an explicit number.

      • Putcha V. Narasimham
        Putcha V. Narasimham says:

        Geert: Continuing after quoting the definition of multiplicity, optionality and cardinality, let’s examine how they apply to the case of car–the whole here. It is my observation that UML definitions and explanations are incomplete necessitating this kind of discussions. Some authors like Craig Larman have elaborated on some of these definitions.

        On similar lines I state that the WHOLE can be one and only one represented by 1..1 at the whole-end of a composite association. This multiplicity at the whole-end does NOT refer to the number of KINDS of parts nor the number of PARTS of EACH kind. Therefore your explanation of the lower limit being 0 when the wheels are removed is not applicable and not valid. There can be at least ONE and at most ONE whole (car in our case) in a composition association PROVIDED the multiplicity specified at all the part-ends are satisfied.

        The multiplicity of parts is specified at the part-end of the association FOR EACH KIND of part. In the case of wheel-kind of part, a normal whole car has four and only four wheels (4..4). There is no option on wheels. Four wheels are mandatory represented by 4 as the lower limit of multiplicity. For other parts like child-car-seat or overhead carrier the multiplicity limits can be (0..1) for each. For steering-wheel it is (1..1) and so on.

        Here the whole and parts are all instances not classes. The wholes which are thus composed are integral units and can be represented as a class of cars (without showing its parts).

        I believe this to be the intent of composition definition and graphic representation, though it is not spelt out this way in the UML standard. If this convention is applied closely, no explanation is necessary for every drawing.

  5. Putcha V. Narasimham
    Putcha V. Narasimham says:

    Number of “Kinds of parts” composing a whole

    Can a “whole” be made up of parts of “only one kind” particularly if “the whole” is a composition (NOT aggregation)? If so, is there a UML convention to represent this minimality condition on the number of KINDS of parts that can make up a “composite whole”?

    The multiplicity limits on each “part-end of one-kind” can be shown with minimum essential or optional 0 and maximum essential). For the whole “normal car” the multiplicity would be (1..1). It wheels (4..4), Engine (1..1), Doors (2..4) etc. As clarified in the main article all the parts are instances from the defining classes of Wheel, Engine, Door… but NOT Classes. This must also apply to the whole “car”. Is this interpretation correct?

  6. Putcha V. Narasimham
    Putcha V. Narasimham says:


    In “class Linkedin” you have shown “types of posts or discussions” as “multiple wholes” made of a singl kind of “discussion” at the part-end of a composition association.

    Similarly, “post” is shown as a part of “discussion”.

    Are you showing classes or instances in the compostion diagram?

    Discussion or Promotion or Job are three different sub-classes of a post.

    If such diagrams as “class Linkedin” can be drwan, what clarity do they (UML diagrams)provide about the whole and its parts, classes and sub-classes?

    If there can be multiple groups G1, G2, G3….. each of which can have members form a set of all members {m1, m2, m3, m4, ……….m 100} of which there could be different intersecting sub-sets {m1, m2, m3}, {m2, m3, m4, m5} and non-intersecting sub-sets {m6, m7} and {m8, m9, m10} of members, is there a CLEAR way of showing the associations in any UML Diagram or combination of UML Diagrams? If not how does one represent such associations diagrametically?

    • geertbellekens
      geertbellekens says:


      The LinkedIn example show classes, not instances (instances would need to be underlined).
      The classes Discussions, Promotions, and Jobs are actually the sections the discussions can be placed in.
      For the sake of the argument (to show the possibility of having multiple composite relationships) I’ve modeled them as separate classes (rather then subclasses of something like “Section”).
      But, even though Discussion has three composite relations, it can be part of only one composite relationship at a time (as I mentioned in the text). So there are no intersections between the set of discussions for each “Section”.
      I do not see the ambiguity in this diagram.

      • Rolf Lampa
        Rolf Lampa says:

        True, there’s no ambiguity in the diagram.

        While I agree on that, and regarding that there is no UML element or syntax for clarifying such cases, I do use the convention of adding a small note (with a link to all the three single-ends in your model) with the clarifying text: [“One of”]

        Such a small note will do away with anyone missing the intent in cases like this.

        // Rolf Lampa

  7. Putcha V. Narasimham
    Putcha V. Narasimham says:

    Geert: The Linkedin shows whole-part composition which holds only between instances as explained in your blog correctly. The authors may know the distinction of what they want to convey but the UML diagram DOES NOT convey that distinction clearly. If the relation is class-subclass between “discussion” and “job”, why is filled dimond shown at the Job-end, which is a “part” but not a “whole”?. If the concept of “section” is used, why is it now named as such? The basic representation of “composition” DOES NOT seem to be applied as per the UML standard.

    The question is “can the conventions of UML diagrams be more clear without critical dependence on comments / explanation?”. If not, all text explanation if written carefully will be clear enough.

    One way to maintain clarity is to separately show the class diagram (inter-class diagram to be more precise) and Composition Diagram (but they are shown together).

    • geertbellekens
      geertbellekens says:


      I must have not made myself clear enough.
      I never tried to say there’s a class/subclass relationship between Discussion and Job (there is actually no Job class, only a “Jobs” class, which might be a subclass of Section along with Promotions and Discussions.

      I specifically did not include the class “Section” because that would make the diagram too crowned and would distract from the point I was trying to make.

      I’m pretty sure this diagram is UML standard and not ambiguous if you use the UML standard to interpret it.

  8. geertbellekens
    geertbellekens says:

    Putcha V. Narasimham :

    On similar lines I state that the WHOLE can be one and only one represented by 1..1 at the whole-end of a composite association. This multiplicity at the whole-end does NOT refer to the number of KINDS of parts nor the number of PARTS of EACH kind. Therefore your explanation of the lower limit being 0 when the wheels are removed is not applicable and not valid. There can be at least ONE and at most ONE whole (car in our case) in a composition association PROVIDED the multiplicity specified at all the part-ends are satisfied.


    That is your interpretation of your reality. In my interpretation there is a [0..1] multiplicity on the Car end of the composition because a wheel doesn’t need a car in order to exist.
    I think I’ll leave it to that. Sometimes its best to agree to disagree.
    Thank you very much for your input.


  9. Putcha V. Narasimham
    Putcha V. Narasimham says:


    I appreciate your effort to clarify instead of commenting on my understanding—very polite of you. I mis-spelt “now” for “not” “dimond” for “diamond”… sorry.

    I did NOT say NOR imply that YOU said that there is class/sub-class relation between Discussion and Job.

    I made that conditional statement because I observed that Class/Sub-class relation exists between “discussion” and “job” in Linkedin Group contents. I was questioning why a filled diamond is shown at the bottom of “Jobs” box in the Linkedin class diagram. That implies that “discussions” are parts of the whole “Jobs”, which is not valid from the general meaning of these words used in Linkedin. In comparison my conditional statement is closer to the fact.

    Coming to naming of a class, it IS a CONVENTION (not a LAW) to name a class as a SINGULAR noun—NOT PLURAL as you seem to prefer. The multiplicity takes care of none, singular or plural aspect of number of members of the class participating in the relation or association under discussion.

    I (and many others) found that various versions of UML are not clear enough on many of the definitions and diagrams and the interpretations in spite of 800+ pages of the current version. This discussion is an indication of it. None other than Ivar Jacobson and Steve Cook are writing (or have written) “The Road Ahead for UML” to make it more usable. I hope these blogs and posts will give us better UML soon.

  10. Leslie
    Leslie says:

    After many years of discussion on clarification of this topic, my understanding is that there is 1..1 cardinality on the Whole part of a composition. A 0..1 cardinality implies an aggregation.

    Furthermore, in a composition relationship the whole Whole is responsible for creation and deletion of its parts, so I could not imagine any situation where the relationship would not exist.


  11. Rémi Bastide (@bastide)
    Rémi Bastide (@bastide) says:

    @Leslie, consider :
    Car —-> Door <—- House
    i.e. a Car is composed of a Door, and a House is composed of a door as well (among other things, of course…).

    Obviously, the cardinality on the “Car” and on the “House” side has to be 0..1, since a Door cannot possibly belong both to a House and a Car

  12. Putcha V. Narasimham
    Putcha V. Narasimham says:

    Remi and other readers of this blog:

    In an explanation given by Guarino and others, it was clarified that ONLY particular number of instances of a Class Door can be members of a Compostion of a Whole (house or car). There they used the example of “engine” which could be in boat or car.

    In any case the same kind of doors may not be suitable at all positins of car or home. So gross count of doors is NOT useful in a composition relation.)

    It is NOT like an association between two Classes of an (Inter) Class Diagram and the lower limit “0” is NOT valid for composition at the Whole-end.

    If a Class to Class relatin is declared between Class Car and Class Door, one may state that

    A car “is supported by” min 3 wheels to max 8 Wheels and
    A wheel “supports” min 1 and max 1 car

    Even here the min multiplicity limit at the car-end is 1 for the association: wheel “supports” car.

    A wheel may exist alone independently in which case the association “supports” is not involved.

    • geertbellekens
      geertbellekens says:


      I don’t think you can choose when the “supports” association is involved or not, that is exactly what the lower limit of 0 is for.
      So if in your context the wheel can exist independently of the car, then the multiplicity on the car side is 0..1.
      This is different when the part cannot exist without the whole.
      Think Order-OrderLine. An OrderLine cannot exist independently, it must always be part of an order. Therefore the multiplicity on the order side is 1..1

      I’m amazed that such a basic concept in UML has so many different interpretations.

  13. jurgen reza
    jurgen reza says:

    The specification says: “Composition is represented by the isComposite attribute on the part end of the association being set to true.” isn’t this wrong? shouldn’t be on the whole end?

    • geertbellekens
      geertbellekens says:


      I just checked the UML 2.4.1 superstructure document it definitely says “part end”.
      I must admit, that I’ve never noticed that, and it seems wrong to me to. I would expect (as I wrote later on in the blog post) that the attribute isComposite would be found on the whole end of the association, which is also how it works in EA.
      Could it be that this sentence in the specs is wrong? In that case we should maybe send a bug report to the OMG.


  14. jurgen reza
    jurgen reza says:

    That was very interesting Geert. I guess the guys at Sparx did not implement the exact specification of UML.

    As another example, EA treats enumerations as classes. To define enumerations you should add attributes and mark them as isLiteral, whereas in the UML Specification enumerations cannot have properties and operations but only EnumerationLiterals and enumeration is not a class

    • jurgen reza
      jurgen reza says:

      Quickly correcting myself: enumerations are data types and can own operations and properties but that doesn’t change the fact that literals are not properties.

  15. Alex
    Alex says:

    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.

    • geertbellekens
      geertbellekens says:


      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.

  16. Gerd Wagner
    Gerd Wagner says:

    I’m refering to your excellent post in my StackOverflow answer, 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.

    • Geert Bellekens
      Geert Bellekens says:

      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.

      • putchavn
        putchavn says:


        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.


    • Gerd Wagner
      Gerd Wagner says:

      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.

  17. Mark W
    Mark W says:


    Your post explains the differences quire well, but I am struggling with one of your statements regarding the final diagram. You state:

    “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.”

    I cant see how the diagram makes this clear. Can you please elaborate. I cant see how the constraint ‘they cannot be part of two sections at the same time’ is portrayed.


    • Geert Bellekens
      Geert Bellekens says:


      The fact that you cannot share an “part” is what makes the aggregation different from the composition. The definition states: “Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time.” So if yo model the relation using a composition this is a given constraint that you do not have make explicit otherwise.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.