Association

The general link between two classes: each object keeps its own lifecycle, and the link carries a direction and a multiplicity.

Overview

An association is the most general relationship between two classes. It says that objects of one class are connected to objects of the other: a doctor treats patients, a student takes courses, an order belongs to a customer. Neither side owns the other. Each object exists on its own, and the link can be made or broken without creating or destroying anything.

Aggregation and composition are associations with something added: a whole-part meaning, and for composition a lifecycle rule. UML 2.5.1 models this as a property of the association end called aggregation, with the values none, shared and composite. So every diamond is an association first; the diamond only adds ownership.

Objects that know about each other

Association — The objects are linked — Independent — plain line
Aggregation — One side groups the other — Independent — hollow diamond at the whole
Composition — One side owns the other — Part ends with the whole — filled diamond at the whole

Multiplicity

Multiplicity says how many objects can sit at each end of a link. UML writes it as a lower and upper bound separated by two dots; a star means no upper limit, a single number means exactly that many, and a lone star is short for zero or more.

1 — exactly one — a required field holding one reference
0..1 — optional, at most one — a field that may be empty or None
* (same as 0..*) — zero or more — a list or set, possibly empty
1..* — one or more — a non-empty collection; validate it
2..4 — between two and four — a collection with a checked size

Read the multiplicity at the far end from the class you are standing on. In the diagram above, one Customer places zero or more Orders, and each Order has exactly one Customer. Getting this wrong is a real bug: model a one-to-one where the domain is one-to-many and the second object has nowhere to go.

Direction

An association can be navigable in one direction or both. UML marks a navigable end with an open arrowhead; a line with no arrowheads means navigable both ways. Navigable means an object at one end can reach the objects at the other end efficiently, usually through a field.

One way — Only one class holds a reference — Default; the fewest things to keep consistent
Both ways — Each class holds a reference to the other — Only when both sides truly need to navigate, and then one side owns the update

Association classes and join tables

When the link itself has data, give it a class. A student's enrollment in a course has a date and a grade; those belong to the link, not to the student or the course. In a class diagram this is an association class. In a relational schema it is a join table with one row per link, and its primary key is the pair of foreign keys.

CS101 — 2
MA201 — 1

What you will be able to do

Name the three relationship kinds and place any pair of classes on that scale.
Read and write multiplicities and turn each into the right field or collection.
Choose one-way navigation by default and keep a two-way link consistent when you need one.
Introduce an association class when the link has data, and map it to a join table.
Explain how each association becomes foreign keys.

Interview questions

What is the relationship between association, aggregation and composition?
How do you keep a bidirectional association consistent?
What is multiplicity, and how does it change your code and your schema?
When should you introduce an association class?
How do associations translate to a database schema?
Should associations be one-way or two-way by default?