UML: Class & Object Diagrams

Associations & Multiplicity

18 min Lesson 3 of 10

Associations & Multiplicity

A class diagram without relationships is just a list of isolated boxes. The real power of the notation emerges when you draw the associations that connect classes and annotate those lines with multiplicity values that state exactly how many instances of one class relate to how many instances of another. Mastering associations and multiplicity is the skill that turns a rough class list into a precise, communicable model.

What Is an Association?

An association is a structural relationship meaning that objects of one class are connected to objects of another class in some lasting way. In UML, an association is drawn as a plain solid line between two class boxes. You can add:

An association name (verb phrase, e.g., places, treats) optionally with a reading direction arrow.
Role names at each end (e.g., patient, doctor) to clarify how each class participates.
Multiplicity values at each end to specify cardinality.
An arrow head (open arrowhead) to indicate navigability — which direction queries can be navigated in code.

Reading Multiplicity Notation

Multiplicity is written as a range min..max placed near the end of the association line, adjacent to the class it describes. The four patterns you will use constantly are:

1 — exactly one. A booking must belong to exactly one patient.
0..1 — zero or one (optional). An employee may have zero or one assigned parking space.
1..* — one or more (at least one). A course must have at least one enrolled student.
* (shorthand for 0..*) — zero or more. An author may have written many books, or none yet.

How to read a multiplicity pair: stand at one end of the line and read the number at the opposite end — it tells you how many of that class one instance of your class is associated with. A Patient–(1)—(*)–Appointment line means: one Patient has zero-or-more Appointments, and one Appointment belongs to exactly one Patient.

Diagram 1 — Clinic Booking System

The following diagram models a simple clinic. A Patient books one or more Appointments. Each Appointment is attended by exactly one Doctor. A Doctor may conduct many appointments but must have at least one (otherwise they are not practicing). Study the multiplicity at each end of every line.

Clinic booking: Patient–Appointment–Doctor associations with multiplicity labels.

Diagram 2 — Online Store: Order & Line Items

An Order in an online store contains one or more OrderItem entries (you cannot place an empty order). Each OrderItem references exactly one Product. A Product may appear in many OrderItems across all orders, or in none (a newly added product). An Order is associated with exactly one registered Customer, who may have many orders or none.

Online store: Customer, Order, OrderItem, and Product with precise multiplicity at every association end.

Bi-directional vs. Navigable Associations

By default, an association line is bi-directional — both objects can navigate to each other. You can restrict navigation by adding an open arrowhead at one end, indicating that only the source class holds a reference to the target. A small cross (×) at an end means navigation in that direction is explicitly forbidden.

In practice, analysts leave most associations bi-directional during analysis and let developers decide navigability during design. What matters most at analysis time is correct multiplicity and meaningful association names.

Self-Association (Reflexive)

A class can be associated with itself. The classic example is an Employee who may manage other Employees: one manager supervises zero-or-more subordinates (0..*), and each subordinate has zero or one manager (0..1) — the top-level CEO has no manager. Draw this as a looping line from the class back to itself.

Why multiplicity precision matters: writing * when you mean 1..* looks small, but it changes the business rule. An order that can have zero items is legally meaningless. An appointment that can belong to zero patients is an orphaned record. Your multiplicity is a formal business rule — stakeholders should review and sign off on it.

Common Mistakes to Avoid

Swapping ends. The multiplicity near a class describes how many of that class participates, not how many of the other class. Always double-check by reading both directions aloud.
Forgetting the zero. Is the association mandatory? If a new Product can exist before any OrderItem references it, the OrderItem side is * (zero-or-more), not 1..*.
Duplicate associations. If two classes already have an association, do not draw a second line for each operation. Operations and navigability are modeled separately; the structural line is drawn once.
Unnamed association on a busy diagram. When a diagram has more than three classes, name every association or add role names so readers are not guessing the semantics.

Association vs. Dependency: an association implies an ongoing structural link (one object holds a reference to another). A dependency (dashed arrow) is a weaker, transient relationship — a class uses another in a method parameter but does not store it. Do not draw a solid association line for a dependency.

Building Associations from Requirements

When reading a requirements document or interviewing stakeholders, listen for:

Verb phrases between nouns → candidate associations ("a librarian issues a loan").
Ownership and containment words → multiplicity clues ("each invoice must have at least one line item" → 1..*).
Optional/mandatory language → zero-or-one vs. exactly-one ("a customer may optionally supply a delivery address" → 0..1 on DeliveryAddress).

Associations and their multiplicity values are often the most contested part of a domain model in stakeholder reviews — and rightly so, because they encode concrete business rules. Getting them right early prevents expensive database schema changes later.