Click here to Skip to main content
15,904,155 members
Articles / Web Development / ASP.NET

Really Understanding Association, Aggregation, and Composition

Rate me:
Please Sign up or sign in to vote.
4.92/5 (22 votes)
6 Apr 2015CPOL8 min read 34.8K   41   11
This is an alternative for "Understanding Association, Aggregation, and Composition", correcting three flaws, one in each of the three explanations, contained in the original article.


I'm writing this alternative article as an attempt to correct three flaws, one in each of the three explanations, contained in the original article, Understanding Association, Aggregation, and Composition (as of February 25, 2015). The explanations of the author are not reflecting the common understanding of these terms by the OO community based on the definitions of the UML.


In this section, I summarize the UML definitions of association, aggregation and composition, based on the explanations given in my tutorial book Building Front-End Web Apps with Plain JavaScript.

Notice that in the UML, both aggregation and composition are defined as special forms of associations, more precisely, as special forms of part-whole-associations. Since already the concept of associations is quite difficult to understand, not just for developers (as I try to explain in my article, Why are associations so difficult to understand, not just for developers?), it's no wonder that there is quite some confusion about the meaning of the UML concepts of aggregation and composition.


A uni-directional functional association corresponds to a (single-valued) reference property of a class in OO programming languages, and to a foreign key of a table in SQL.

Class diagram with reference property Committee::chair referencing the class ClubMemberWe can illustrate this correspondence with the help of two class diagrams. In the first diagram, on the right, the class Committee has a single-valued reference property chair, referencing the class ClubMember.

Class diagram with a chair association between classes Committee and ClubMember In the second diagram, on the right, the single-valued reference property chair is represented visually in the form of a corresponding functional uni-drectional association between the classes Committee and ClubMember. Notice the dot at the association end annotated with 'chair'. This dot indicates that the association end is owned by Committee, which is equivalent to the previous model where chair is a reference property of Committee.

In general, associations are relationship types with two or more object types participating in them. An association between two object types is called binary. In this article, we only discuss binary associations. For simplicity, we just say 'association' when we actually mean 'binary association'.

An association between object types classifies relationships between objects of those types. For instance, the association Committee-has-ClubMember-as-chair, which is visualized as a connection line in the class diagram shown above, may classify the relationships FinanceCommittee-has-PeterMiller-as-chair, RecruitmentCommittee-has-SusanSmith-as-chair and AdvisoryCommittee-has-SarahAnderson-as-chair, where the objects PeterMiller, SusanSmith and SarahAnderson are of type ClubMember, and the objects FinanceCommittee, RecruitmentCommittee and AdvisoryCommittee are of type Committee.


An aggregation is a special form of a part-whole association, where the parts of a whole can be shared with other wholes. For instance, we can model an aggregation between the classes DegreeProgram and Course, as shown in the following diagram, since a course is part of a degree program and a course can be shared among two or more degree programs (e.g. an engineering degree could share a C programming course with a computer science degree).

enter image description here

However, the concept of an aggregation with shareable parts doesn't mean much, really, so it does not have any implications on the implementation and many developers therefore prefer not to use the white diamond in their class diagrams, but just model a plain association instead. The UML spec says: "Precise semantics of shared aggregation varies by application area and modeler".

The multiplicity of an aggregation's association end at the whole side may be any number (*) because a part may belong to, or shared among, any number of wholes.


It's amazing how much confusion exists about the distinction between the part-whole-association concepts aggregation and composition. The main problem is the widespread misunderstanding (even among expert software developers and among the authors of UML) that the concept of composition implies a life-cycle dependency between the whole and its parts such that the parts cannot exist without the whole. But this view ignores the fact that there are also cases of part-whole-associations with non-shareable parts where the parts can be detached from and survive the destruction of the whole. 

In the UML specification document, the definition of the term "composition" has always implied non-shareable parts, but it has not been clear what is the defining characteristic of "composition", and what is merely an optional characteristic. Even in the new version (as of 2015), UML 2.5, after an attempt to improve the definition of the term "composition", it remains still ambiguous and doesn't provide any guidance how to model part-whole-associations with non-shareable parts where the parts can be detached from, and survive the destruction of, the whole as opposed to the case where the parts cannot be detached and are destroyed together with the whole. They say


If a composite object is deleted, all of its part instances that are objects are deleted with it.

But at the same thime they also say


A part object may be removed from a composite object before the composite object is deleted, and thus not be deleted as part of the composite object.

This confusion points to an incompleteness of the UML definition, which does not account for lifecycle dependencies between components and composites. It's therefore important to understand how the UML definition can be enhanced by introducing a UML stereotype for <<inseparable>> compositions where components cannot be detached from their composite, and, thus, have to be destroyed whenever their composite is destroyed.

As Martin Fowler has explained, the main issue for characterizing composition is that "an object can only be the part of one composition relationship" (this is also explained in the excellent blog post UML Composition vs Aggregation vs Association by Geert Bellekens). In addition to this defining characteristic of a composition (to have exclusive, or non-shareable, parts), a composition may also come with a life-cycle dependency between the composite and its components. In fact, there are two kinds of such dependencies:

  1. Whenever a component must always be attached to a composite, or, in other words, when it has a mandatory composite, as expressed by the "exactly one" multiplicity at the composite side of the composition line, then it must either be re-used in (or re-attached to) another composite, or destroyed, when its current composite is destroyed. This is exemplified by the composition between Person and Heart, shown in the diagram below. A heart is either destroyed or transplanted to another person, when its owner has died.
  2. Whenever a component cannot not be detached from its composite, or, in other words, when it is inseparable, then, and only then, the component has to be destroyed, when its composite is destroyed. An example of such a composition with inseparable parts is the composition between Person and Brain.

enter image description here

In summary, life-cycle dependencies only apply to specific cases of composition, but not in general. They are, therefore, not a defining characteristic. The UML spec states: "A part may be removed from a composite instance before the composite instance is deleted, and thus not be deleted as part of the composite instance." In the example of a Car-Engine composition, as shown in the following diagram, it's clearly the case that the engine can be detached from the car before the car is destroyed, in which case the engine is not destroyed and can be re-used. This is implied by the zero or one multiplicity at the composite side of the composition line.

enter image description here

The multiplicity of a composition's association end at the composite side is either 1 or 0..1, depending on the fact if components have a mandatory composite (must be attached to a composite) or not. If components are inseparable, this implies that they have a mandatory composite.

Error Correction

Error 1: Associations are about objects using each other but having their own object life time

There is no need for the objects that participate in an association to "use each other". In fact, an association between two classes is not established via some method parameters, as suggested by the examples presented in the article, but rather via reference properties (class attributes), the range/type of which are the associated classes. If the type of a method parameter is a class, this does not establish an association, but a dependency relationship.

Associations do not imply, nor do they preclude, any lifecycle dependencies between associated/linked objects.

Error 2: In an aggregation, a child object belongs to a single parent

In the UML, an aggregation is defined as a special form of association with the intended meaning of a part-whole-relationship, where the parts of a whole can be shared with other wholes. Consequently, a "child object" may belong to many "parent objects". This is illustrated in the following example of an aggregation, where a course can belong to many degree programs.

Aggregation example

Error 3: In a composition, a child object has the owner's life time

This is a widespread misunderstanding.

The defining characteristic of a composition is to have exclusive (or non-shareable) parts. A composition may come with a life-cycle dependency between the whole and its parts implying that when a whole is destroyed, all of its parts are destroyed with it. However, this only applies to some cases of composition, and not to others, and it is therefore not a defining characteristic. An example of a composition where the parts (or components) can be detached from the whole (or composite) and therefore survive its destruction, is the following:

Comremoved example where components can survive

An engine, as a component of a car, can be detached from its composite, the car, Therefore, in this case, the component does not have the same life time as its composite. It can be re-used in another car after its previous owner's life time has ended.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
Instructor / Trainer
Germany Germany
Researcher, developer, instructor and cat lover.

Co-Founder of and the educational simulation website

Comments and Discussions

GeneralMy vote of 5 Pin
Kranti Madineni15-Sep-17 18:50
Kranti Madineni15-Sep-17 18:50 
GeneralAbout Composition Pin
Ranjan.D5-Apr-15 14:47
professionalRanjan.D5-Apr-15 14:47 
GeneralRe: About Composition Pin
Gerd Wagner6-Apr-15 6:54
professionalGerd Wagner6-Apr-15 6:54 
GeneralRe: About Composition Pin
Ranjan.D6-Apr-15 7:11
professionalRanjan.D6-Apr-15 7:11 
GeneralRe: About Composition Pin
Gerd Wagner6-Apr-15 7:45
professionalGerd Wagner6-Apr-15 7:45 
GeneralRe: About Composition Pin
Ranjan.D6-Apr-15 9:47
professionalRanjan.D6-Apr-15 9:47 
Yes your interruption about my thinking was right. First of all thanks for your time in explaining. Here's the program that I came up, relates to your second model, where I am trying to add engine as a reference. When I am disposing a car, you can notice I am also removing the engine reference. But the engine will not get destroyed. That's said, it has its own life cycle. But wait, there's more interesting thing I wanted to discuss.

Below are the entities for Car and Engine.
public class Car : IDisposable
    public Car()
    public string Color { get; set; }
    public Engine CarEngine { get; set; }
    // To detect redundant calls
    private bool disposedValue;
    // IDisposable
    protected virtual void Dispose(bool disposing)
        if (!this.disposedValue) {
            if (disposing) {
                CarEngine = null;
        this.disposedValue = true;
    public void Dispose()
        // Do not change this code.  Put cleanup code in Dispose(ByVal disposing As Boolean) above.
public class Engine
    public int CylinderCapacity { get; set; }
    public int Cylinders { get; set; }
As per your second model, Below is the main program where I am building an engine and a car instance and trying to add a reference.
public static void Main()
     Console.WriteLine("Construct Engine");
     Engine oEngine = new Engine();<br />
     oEngine.Cylinders = 4;
     oEngine.CylinderCapacity = 80;
     Console.WriteLine("Construct Car");
     Car oCar = new Car();
     oCar.Color = "Red";
     Console.WriteLine("Add Engine");
     oCar.CarEngine = oEngine;
     Console.WriteLine("Dispose Car");
     Console.WriteLine(string.Format("Do we still have an Engine? {0} ", (oEngine == null ? "No" : "Yes")));
     Console.WriteLine("Press any key...");
I agree about the car and the engine's life cycle is purely independent in this case. You might think this one is a best suited example for modeling a composition but I would argue that it's not a composition but an association. The reason being, the moment you make the car's engine as a reference type by pointing it to the engine instance, it is no longer a composition but it becomes an association. There is a clear sign of "Knows A" relationship in this model and more than that, you can see a weak relationship.


modified 6-Apr-15 16:59pm.

GeneralRe: About Composition Pin
Gerd Wagner6-Apr-15 22:34
professionalGerd Wagner6-Apr-15 22:34 
GeneralRe: About Composition Pin
Ranjan.D7-Apr-15 0:29
professionalRanjan.D7-Apr-15 0:29 
Question[My vote of 1] You have misread and this is really poor way of correcting things. Pin
Shivprasad koirala3-Apr-15 8:13
Shivprasad koirala3-Apr-15 8:13 
AnswerRe: [My vote of 1] You have misread and this is really poor way of correcting things. Pin
Gerd Wagner6-Apr-15 6:45
professionalGerd Wagner6-Apr-15 6:45 
AnswerRe: [My vote of 1] You have misread and this is really poor way of correcting things. Pin
Gerd Wagner18-Jun-15 10:19
professionalGerd Wagner18-Jun-15 10:19 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.