Understanding UML composition better

Question

The difference between Composition and Aggregation in UML (and sometimes in programming too) is that with Composition, the lifetime of the objects composing the composite (e.g. an engine and a steering wheel in a car) is dependent on the composite object. While with Aggregation, the lifetime of the objects making up the composite is independent of the composite.

However I'm not sure about something related to composition in UML.

Say ClassA is composed of an object of ClassB:

class ClassA{
    ClassB bInstance;
    public ClassA(){
        bInstance = new ClassB();
    }
}

This is an example of composition, because bInstance is dependent on the lifetime of it's enclosing object.

However, regarding UML notation - I'm not sure if I would notate the relationship between ClassA and ClassB with a filled diamond (composition) or a white diamond (aggregation).

This is because while the lifetime of some ClassB instances is dependent of ClassA instances - there could be ClassB instances anywhere else in the program - not only within ClassA instances.

---

The question is: if some ClassB objects are composed with ClassA objects (and thus are dependent on the lifetime of the ClassA objects), but some are not - would the relationship between the two classes in UML be an aggregation or a composition relationship??

Answer 1

Short answer: UML doesn't care about inner classes. Inner classes is a feature in Java and a few other languages, but not all support them. In fact, Inner classes are usually an implementation detail which is very often not shown in UML diagrams.

Now, If the sample code is Java (but it could be anything else) I would say that it could(1) be aggregation, or neither... or maybe composition

As an example of aggregation, you could have a collection class, where each item is stored in an inner class. An example of this would be the HashMap.Entry class in Java, but it's static and package protected, as it's used from other classes in java.util.

And as an example of neither would be if you want to have a helper class, but don't want to create a top level class or a anonymous inner class. For example if you want to instantiate a custom Comparator.

Last but not least, it could be an example of bad composition.

(1) I say it could be, because there are plenty of really bad examples or composition and aggregation in most of the codebases I've worked on.

Answer 2

I believe you answered your question when you said "the lifetime of the objects composing the composite (e.g. an engine and a steering wheel in a car) is dependent on the composite object." In your code example, Object B would cease to exist when Object A is gone. On the other hand,

class ClassA{
   ClassB bInstance;
  public ClassA(ClassB classB){
    bInstance = classB;
  }
}

would become an aggregate in your UML since object B can exist independently from object A.

EDIT (after your update ) I tried to imagine an instance where Class B would depend on Class A and here's what I come up with:

class ClassA{
   bool bDependsOnA = // true or false based on some logic
   ClassB bInstance;
   public ClassA(){
     if(bDependsOnA){
        bInstance = new ClassB(this);
      }else{
        bInstance = new ClassB();
    }
  }
}

class ClassB{
   ClassA aInstance;
  public ClassB()
  { 
     aInstance = null;
  }
  public ClassB(ClassA classA ){
    aInstance = classA;
  }
}

Class B is a composite of class A, ClassB has a weak association with Class A. An interesting article I found, while thinking about your question (http://aviadezra.blogspot.ca/2009/05/uml-association-aggregation-composition.html)

By the way, as great as UML is, it's not perfect. Aggregation vs composition been going on for a long time. Sometimes, it's not clear what is what. Personally, I've found that when I'm stuck trying to decide which is which, it means my design is way too complex and could be simplified :)

Answer 3

Here's another way to look at it:

As @rommik pointed out with his example, you could also pass the B object as a constructor argument, thus decoupling its lifecycle from A. Now forget about the corresponding UML diagram and think about your classes first. You have (at least these) two options:

class A { ... public A(B bInstance) { ...} }

or

class A { B bInstance = new B(); ... }

There are good reasons for either of these to be used, depending on the circumstances, and they naturally fit the aggregation and composition semantics of UML, respectively.

On the other hand, your edit proposes that class A has some instances, where the B object's lifetime depends on the A instance, and some other instances, where it doesn't.

Leave out UML and look at this simply from a general design point of view. Your class A suddenly got a lot more complicated. Of course, it is no wonder that you are having problems finding out how to depict it in a UML diagram. Heck, you'd even have problems to explain someone else what A does: "It gets B objects and does this and that with them.. oh except when it creates its own B objects..". Contrast this to explaining either of the two clear variants above.

In summary, the fact that you have two semantically different ways to model your design in UML is neither a problem of UML itself, nor your understanding of it. It is merely a pointer to remind you that your class design itself is ambiguous regarding its semantics.

Answer 4

Is your composition intended to model situations where an object is part of another object in the way a particular screw may be part of a truck? Not every screw is part of a truck. If so you should not use the composition relationship. UML2 includes another notion of a composite object which has parts making up a whole.

If class A is a composite aggregation of class B, then every instance of B must have a related instance of A which aggregates it. Not what you want.

In the situation you describe, instances of class A are composite objects which contain instances of class B as parts. This doesn't rule out the possibility of instances of B that aren't part of A objects. The relationship between A and B is neither aggregation nor composition. The terminology (composition relationship vs composite structure/part) is confusing, but we're stuck with it.

Answer 5

The question whether the relation between ClassA and ClassB is composite does not depend on whether there also instances of ClassB that are not part of any ClassA. In your example, as long as no reference to the inner ClassB-instance (the one held in your instance variable bInstance) can ever escape the containing instance of ClassA (which could happen if you have a public getter for bInstance, for instance), you are perfectly fine modelling this as a composite relationship.

In your UML model, it is the multiplicity of the container end that determines whether or not all ClassB-instances are expected to be part of some ClassA. The multiplicity of the container end can never be other than [0..1] or [1..1] in the first place, of course (otherwise this would violate the principle that an object can at most be part of a single composition); if it is [0..1] you are saying that there can also be ClassB-instances not part of a ClassA; if it is [1..1] then this is not the case.

See also https://bellekens.com/2010/12/20/uml-composition-vs-aggregation-vs-association/ for an illuminating discussion.

Answer 6

It is composition because you are modelling the relationship between

classes A and B. NOT the relationships between Class B and the rest of

the program.

Class C uses instances of class B in the diagram above, but it does

not necessarily end the lifetime of instances of Class B. They are able

to exist outside of Class C because of the getB() function. An example

might be a Album of songs. You could move the songs out of the Album into

another one then destroy the old album.

In contrast, Class A is composed of a Class B instance because there is no way for

instances of Class B can exist outside of Class A. An example is the life

of a person and their secrets. Every person has secrets. No one knows

about these secrets and when that person dies, their secrets die with

them.