Loading learning content...
Not all "has-a" relationships are created equal. Consider the difference between a university and its professors versus a human and their organs. If a university closes, the professors don't cease to exist—they find employment elsewhere. But if a human dies, the organs don't simply carry on independently.
This distinction matters profoundly in software design. A Department contains Employees, but those employees exist beyond the department—they can move to other departments, or even exist before being assigned. An Order contains LineItems, but those items are meaningless without their order—they're created with it and destroyed with it.
UML provides precise notation for this critical difference: aggregation (hollow diamond) versus composition (filled diamond). This page focuses on aggregation.
By the end of this page, you will understand what aggregation represents in domain modeling, how to draw aggregation using the hollow diamond notation, the key difference between aggregation and composition (independent vs dependent lifecycles), and when to use aggregation in your designs.
Aggregation is a specialized form of association that represents a whole-part relationship where the parts can exist independently of the whole. It's a "has-a" relationship with a crucial characteristic: the lifecycle of the parts is not controlled by the whole.
The defining characteristics of aggregation:
Aggregation in code terms:
When a whole has an aggregation relationship with its parts, the whole holds references to parts that were created elsewhere and will continue to exist independently:
public class Team {
private List<Player> players; // Aggregation
public void addPlayer(Player player) {
players.add(player); // Player already exists
}
public void removePlayer(Player player) {
players.remove(player); // Player still exists after removal
}
}
The Team doesn't create Player objects—they exist independently. When a player is removed from the team, they continue to exist (perhaps joining another team or remaining as a free agent).
Ask yourself: 'If the whole is destroyed, do the parts make sense on their own?' If yes, it's likely aggregation. A Team can be disbanded, but Players still exist. A Library can close, but Books can be transferred elsewhere.
In UML, aggregation is represented by a solid line with a hollow (unfilled) diamond at the "whole" end. The diamond is attached to the class that represents the aggregate—the container or owner in the whole-part relationship.
Basic aggregation visualization:
Key elements of aggregation notation:
| Element | Description |
|---|---|
| Hollow diamond (◇) | Attached to the "whole" (aggregate) class |
| Solid line | Connects whole to part |
| Multiplicity | Still applies at both ends |
| Navigability | Can be unidirectional or bidirectional |
| Association name | Optional label describing the relationship |
Complete aggregation example with multiplicity:
The diamond is always placed at the 'whole' end—the aggregate side. Common mistake: placing the diamond at the 'part' end. Remember: the diamond marks the container, not the contained.
Since aggregation is a specialized association, you might wonder when to use each. The key difference is semantic intent—aggregation explicitly communicates whole-part structure, while plain association indicates a general relationship.
When to use aggregation vs plain association:
Example comparison:
| Relationship | Type | Reasoning |
|---|---|---|
| Library — Book | Aggregation | Library contains books (whole-part) |
| Customer — Order | Plain Association | Customer places orders, but doesn't 'contain' them |
| Playlist — Song | Aggregation | Playlist is composed of songs |
| Author — Publisher | Plain Association | Peer relationship, neither contains the other |
| University — StudentClub | Aggregation | University contains student clubs |
| Doctor — Patient | Plain Association | Peer relationship through appointments |
In practice, the distinction between aggregation and plain association is often subtle and debated. Some methodologists argue aggregation adds little value over plain association. The key is consistency within your team—decide on conventions and apply them uniformly.
Identifying aggregation relationships from business requirements requires asking the right questions. Here's a systematic approach:
The aggregation identification checklist:
Practical example: Event Management System
Let's analyze relationships in an event management system:
The same relationship might be aggregation in one system and composition in another. A Session might be aggregation in a speaker management system (speakers give the same session everywhere) but composition in a specific event planning system (sessions exist only for that event).
A distinctive feature of aggregation (compared to composition) is that parts can be shared between multiple wholes. This reflects real-world scenarios where the same entity participates in multiple containing structures.
Shared aggregation example: Course Offerings
Analysis of shared aggregation:
Instructor can belong to multiple Departments (joint appointments, cross-department teaching)Course can be offered by multiple Departments (interdisciplinary programs)When shared aggregation occurs:
| Domain | Whole | Shared Part | Example |
|---|---|---|---|
| Academia | Research Group | Researcher | One researcher in multiple groups |
| Organization | Committee | Employee | Employee on multiple committees |
| Content | Playlist | Song | Same song in multiple playlists |
| Real Estate | Building Complex | Amenity | Pool shared by multiple buildings |
| Manufacturing | Assembly | Component | Standard part in multiple products |
Shared aggregation is often implemented with many-to-many relationships (junction tables in databases). When one whole is deleted, the shared parts remain because other wholes still reference them. This requires careful cleanup logic—only delete orphaned parts if business rules dictate.
Translating aggregation from UML to code requires understanding how the relationship manifests in practice.
Object references vs containment:
In aggregation, the whole holds references to parts—it doesn't own them in a memory management sense. The parts are typically created elsewhere and passed to the whole.
12345678910111213141516171819202122232425262728
public class Playlist { private String name; private List<Song> songs; // Aggregation - holds references public Playlist(String name) { this.name = name; this.songs = new ArrayList<>(); } // Songs are created externally and added public void addSong(Song song) { if (song != null && !songs.contains(song)) { songs.add(song); } } // Removing doesn't delete the song public void removeSong(Song song) { songs.remove(song); // song still exists - can be added to other playlists } // Playlist can be cleared without destroying songs public void clear() { songs.clear(); // All songs still exist in the system }}Database representation:
In relational databases, aggregation typically manifests as:
| Pattern | Implementation | Example |
|---|---|---|
| One-to-many aggregation | Foreign key in part table | Employee.department_id |
| Many-to-many aggregation | Junction table | playlist_songs table |
| Cascading rules | ON DELETE SET NULL | Department deleted → Employee.department_id = NULL |
In aggregation, the foreign key in the part table is typically nullable. An Employee can exist without a Department (between assignments). When a Department is deleted, Employees have their department_id set to NULL rather than being cascade-deleted.
Certain aggregation patterns recur across different domains. Recognizing these accelerates design decisions.
Pattern 1: Collection Aggregation
A container groups items that exist independently. The container organizes but doesn't own the items.
| Container (Whole) | Item (Part) | Purpose |
|---|---|---|
| Playlist | Song | Organize songs into listening sequences |
| Folder | Document | Group documents for organization |
| ShoppingCart | Product | Temporarily collect products for purchase |
| Team | Member | Group people for collaboration |
Pattern 2: Structural Aggregation
A larger structure is composed of smaller structures that have independent existence.
| Structure (Whole) | Substructure (Part) | Characteristic |
|---|---|---|
| Building | Room | Rooms can be repurposed, renumbered |
| Network | Node | Nodes exist independently of network topology |
| Fleet | Vehicle | Vehicles can transfer between fleets |
| Curriculum | Course | Courses exist independently, can be shared |
Pattern 3: Hierarchical Aggregation
Aggregation with self-referencing to create tree or graph structures.
When you encounter a new domain, look for these patterns. 'Is this a collection gathering independent items? A structure composed of substructures? A hierarchy?' Pattern recognition dramatically speeds up the modeling process.
We've explored aggregation as a specialized form of association. Let's consolidate the key takeaways:
What's next:
Now we understand aggregation—whole-part with independent lifecycles. But what about when parts are truly inseparable from their containing whole? When destroying the container must destroy the contents? The next page explores composition—the filled diamond—representing the strongest form of whole-part relationship where parts cannot exist independently.
You now understand aggregation as a whole-part relationship with independent lifecycles, represented by a hollow diamond. Next, we'll examine composition—where parts have dependent lifecycles and cannot exist without their containing whole.