UML Class Diagram – Differences Between Association, Aggregation, and Composition

class-diagramobject-orienteduml

I'm confused about some of the notations of UML class diagrams.

enter image description here

Pretty sure I know what Association means. Any relationship between instances of two classes, where an instance of one class needs to know about an instance of the second class in order to perform it's work – is an Association relationship. An Association often means class A has a reference (field) to an instance of class B.

However, I'm having trouble understanding what the Aggregation and Composition arrows mean. Part of my confusion was caused by encountering different definitions of these notations.

Two definitions of the Aggregation notation:

Definition 1: An Aggregation notation between two classes is suitable whenever an instance of class A holds a collection of instances of class B (e.g. a List, Array, whatever).

Definition 2: An Aggregation link between two classes is suitable if an instance of class A holds a reference to an instance of class B, and the B instance is dependent on the lifecycle of the A instance. Meaning: When the instance of class A get's deleted, so will the instance of class B. The instance of class B is entirely contained by the instance of class A, as opposed to the instance of class A simply owning a reference to the instance of class B (which is regular Association).

Regarding what the Composition notation means and how it differs from the Aggregation notation, I'm not sure.

Please clarify the definitions and help me understand. Concrete examples would be welcome.

Best Answer

The three links Association, Aggregation and Composition form a kind of scale on how closely two classes are related to each other.

On the one end of the scale, there is Association, where objects of the two classes can know about each other, but they do not affect each others lifetime. The objects can exist independently and which class A object knows about which class B objects can vary over time.

On the other end of the scale, there is Composition. Composition represents a part -- whole relationship such that class B is an integral part of class A. This relationship is typically used if objects of class A can't logically exist without having a class B object.

The Aggregation relation is somewhere between those two ends, but nobody seems to agree where exactly, so there is also no universally agreed definition of what an Aggregation means. In that sense, both definitions that you found are correct and if you ask 10 people, you risk getting 11 different definitions.

Related Solutions

Object-Oriented Design – Use of Association, Aggregation, and Composition

The distinction between association, aggregation and composition as you describe it is a legacy going back to the old times of manual memory management. For example in C++ the memory used by objects has to be manually released and it is thus paramount to carefully design the lifecycle of composed objects. While the distinction between aggregation and composition is still being taught by many text books, it is essentially irrelevant when programming in environments with automatic memory management. If you have garbage collection all of them are just composition, period.

Encapsulation on the other hand is a much more general principle than what you describe. It is foremost the idea of bundling data and the functions that operate on this data in one module. One way to implement this is by keeping the state of the module private and expose changes to that state through public services. So client cannot access the state on their own but have to tell the module their intend by sending messages. So encapsulation is not limited to objects but applies to services as well. Actually, one way of looking at objects is to look at them as services.

Here's an example of encapsulation

public class Counter {
    private int n = 0;
    public int inc() { return n++; }
}

or the same using lambda functions

var counter = (function() {
    var n = 0;
    var inc = function() { return n++; }
    return inc;
})();

In both cases the data, that is the variable n, is bundled together with the function inc that operates on it. And there is no way any other function could ever access n, thus we have an encapsulated module that provides counting as a service.

NB: exposing all of an object's inner state through accessors is actually a violation of encapsulation. Alas, it is such a common violation that many will confuse it with good object-oriented design.

Object-oriented – Understanding UML composition better

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.

Best Answer

Related Solutions

Object-Oriented Design – Use of Association, Aggregation, and Composition

Object-oriented – Understanding UML composition better

Related Topic