Aggregation Relationship

After leaning Association, many developers encounter another UML relationship:

Aggregation

And immediately become confused.

Team → Player

Department → Employee

Library → Book

University → Professor

Question arise:

Is this Association?

Is this Composition?

Is this something else?

Who owns whom?

What happens if the container disappears?

Many developers use Aggregation incorrectly.

Many architects avoid it entirely.

Many UML diagrams misuse it.

To understand why, we must first understand a fundamental concept:

Ownership:

Most relationships in software can be understood by asking:

Who owns whom?

Aggregation was created to model a very specific kind of ownership.

Historical Motivation

Early object-oriented designers discovered:

Not all “has-a” relationships are equal.

Example 1:

House has Rooms

Example 2:

Team has Players

At first glance both look identical.

A has B

But they behave differently.

House Example:

Destroy the house:

House destroyed

What happens?

Rooms disappear

becasue rooms belong to the house.

Team Example:

Destroy the team:

Team dissolved

What happens?

Players still exist

Players may join another team.

The industry needed a way to distinguish these situations.

Thus UML introduced:

Aggregation

and

Composition

Ownership Spectrum

Think of relationship as a spectrum.

Association
      |
      |
Weak Ownership
      |
Aggregation
      |
Strong Ownership
      |
Composition

This mental model is extremely important.

What Is Aggregation?

Definition:

Aggregation is a whole-part relationship where the whole contains part, but the part can exist independently.

Key phrase:

Parts can exist independently.

Real-World Analogy

Consider:

Team and Player

A team contains players.

But:

Player does not depend on Team for existence.

A player can:

Join Team A
Leave Team A
Join Team B

without being destroyed.

This is Aggregation.

UML Notation

Aggregation uses:

Hollow Diamond

Diagram:

Team ◇-------- Player

Diamond appears on the:

Whole side.

Meaning:

Team aggregates Players

Reading Aggregation Correctly

Example:

Department ◇------ Employee

Interpretation:

Department contains employees.

Employees exist independently.

Not:

Department owns employees.

Ownership is weak.

First C++ Example:

// Player
class Player
{
private:
    string name;

public:
    Player(string n)
        : name(n)
    {
    }
};

// Team
class Team
{
private:
    vector<Player*> players;

public:

    void addPlayer(Player* player)
    {
        players.push_back(player);
    }
};

Notice:

Team stores references.

It does not create players.

It does not destroy players.

This is weak ownership.

Lifecycle Analysis

This most important Aggregation question:

What happens when the container dies?

Player p1("John");
Player p2("Mike");

{
    Team team;

    team.addPlayer(&p1);
    team.addPlayer(&p2);
}

Team destroyed.

Players?

Still alive.

p1
p2

continue to exist.

This is Aggregation.

Aggregation vs Association

This distinction confuses many developers.

Association:

Customer -------- Order

Means: Related

Aggregation:

Team ◇-------- Player

Means: Whole-Part Relationship

Comparison:

Example:

Association:

Doctor -------- Patient

No whole-part relationship.

Aggregation:

Library ◇-------- Book

Whole-part relationship exists.