Loading learning content...
In object-oriented design, the relationships between objects are just as important as the objects themselves. A Customer object that exists in isolation is meaningless—it's the connections to Order, Address, PaymentMethod, and ShoppingCart that give it purpose and define its role in the system.
UML class diagrams provide a precise, standardized way to represent these relationships visually. Among all the relationship types, association is the most fundamental and frequently used. Understanding association notation—particularly multiplicity—is essential for reading, creating, and communicating object-oriented designs effectively.
By the end of this page, you will understand what associations represent in UML, how to draw and interpret association lines correctly, how multiplicity notation precisely specifies relationship cardinality, and how navigability arrows indicate direction of access between objects.
An association in UML represents a structural relationship between two (or more) classes, indicating that objects of one class are connected to objects of another class in some meaningful way. Unlike transient interactions (dependencies), associations represent persistent, ongoing relationships that form part of the system's structure.
The essence of association:
When we say class A is associated with class B, we mean:
If a Student object stores a reference to their enrolled Courses, that's an association—it's part of the Student's structure. If a ReportGenerator temporarily uses a Student object to produce a report, that's a dependency—a transient usage, not a structural relationship.
Real-world association examples:
| Domain | Association | Why It's Structural |
|---|---|---|
| E-commerce | Customer → Order | Customer stores reference to their orders |
| Banking | Account → Transaction | Account maintains transaction history |
| Education | Student → Course | Student tracks enrolled courses |
| Social Media | User → Post | User owns and manages their posts |
| Healthcare | Patient → Appointment | Patient has scheduled appointments |
In each case, the association reflects a persistent connection where one object maintains awareness of another as part of its state.
In UML class diagrams, an association is represented by a solid line connecting two classes. This is the simplest relationship notation, yet it carries significant semantic weight.
Basic association visualization:
Key elements of association notation:
Example with full notation:
Association names are typically written as verbs or verb phrases. Read them from left to right or top to bottom. A Student 'enrolls in' a Course. Some UML tools use a small filled triangle to indicate the reading direction when it might be ambiguous.
Multiplicity is one of the most critical aspects of association notation. It specifies how many objects of one class can be associated with objects of another class. Getting multiplicity right is essential—it directly affects database schema design, code implementation, and system behavior.
Multiplicity notation fundamentals:
Multiplicity appears at each end of an association line as a number, range, or special symbol. The value answers: "For one object at this end, how many objects at the other end can (or must) be associated?"
Standard multiplicity indicators:
| Notation | Meaning | Example Context |
|---|---|---|
| 1 | Exactly one (mandatory) | Each Employee has exactly 1 SSN |
| 0..1 | Zero or one (optional) | Person may have 0 or 1 Passport |
| 0..* | Zero or more (unbounded optional) | Author may have 0 or more Books |
| 1..* | One or more (at least one required) | Order must have at least 1 LineItem |
| Many (equivalent to 0..*) | Customer has many Orders | |
| n | Exactly n | Car has exactly 4 Wheels |
| n..m | Range from n to m | Team has 5..11 Players |
In UML, a lone asterisk () means 'zero or more' (i.e., 0..), not '1 or more'. This is a common source of confusion. When you need 'at least one', you must explicitly write 1..*.
Reading multiplicity correctly:
Multiplicity is always read from the perspective of the opposite end. Consider this association:
Department [1] ←→ [1..*] Employee
Reading the multiplicity:
[1] near Department means: For each Employee, there is exactly 1 Department[1..*] near Employee means: For each Department, there is 1 or more EmployeesThis interpretation can be confusing at first, but it's crucial: the multiplicity indicates how many objects on THAT side exist for ONE object on the opposite side.
Determining the correct multiplicity requires careful domain analysis. Ask these questions for each association:
Multiplicity analysis example: Library System
Let's analyze the relationships in a library management system:
Notice how domain rules shape multiplicity. If the library required every Member to have at least one active Loan to remain a Member, the multiplicity would change from 0..* to 1..*. Always validate multiplicity against actual business requirements.
Navigability specifies whether objects of one class can access (navigate to) objects of the associated class. By default, an association line without arrows implies bidirectional navigability—both classes can access each other.
Navigability notation:
| Symbol | Meaning | Implementation Implication |
|---|---|---|
| → (open arrowhead) | Navigable in arrow direction | Source class has reference to target |
| — (no arrows) | Bidirectional (default) | Both classes have references to each other |
| × (cross) | Non-navigable in that direction | No reference stored on that end |
Unidirectional vs Bidirectional associations:
Unidirectional Association
Only one class maintains a reference to the other.
Order → LineItem
Bidirectional Association
Both classes maintain references to each other.
Teacher ↔ Course
As a rule, prefer unidirectional associations unless bidirectional navigation is genuinely required by use cases. Bidirectional associations introduce synchronization complexity and increase coupling. Always ask: 'Do I really need to navigate in both directions?'
Role names provide additional context about how each class participates in the association. They're especially useful when the relationship isn't obvious from class names alone, or when the same two classes have multiple associations.
When role names add clarity:
Without role names, two lines between Person and Company would be ambiguous. Role names clarify that one association represents employment while another represents shareholding.
Association classes:
When an association itself has attributes or behaviors, we use an association class. This is shown as a class box connected to the association line by a dashed line.
Example: Course Registration
The Registration association class captures attributes that belong to the relationship itself—not to Student nor to Course. The enrollment date and grade are properties of a specific Student's enrollment in a specific Course.
When to use association classes:
In code, association classes typically become full-fledged classes that reference both associated classes. The Registration class would have Student and Course attributes, plus its own enrollDate and grade fields.
Certain association patterns appear repeatedly across different domains. Recognizing these patterns accelerates both design and communication.
*Pattern 1: One-to-Many (1 — )
The most common relationship pattern. One object on the "one" side owns or contains multiple objects on the "many" side.
| One Side | Many Side | Multiplicity |
|---|---|---|
| Order | LineItem | 1 — 1..* |
| Department | Employee | 1 — * |
| Author | Book | 1 — * |
| Playlist | Song | 1 — * |
Pattern 2: Many-to-Many ( — )
Both sides can have multiple related objects. Often resolved with an association class or junction table in implementation.
| Side A | Side B | Junction/Association Class |
|---|---|---|
| Student | Course | Enrollment |
| Actor | Movie | Role |
| User | Group | Membership |
| Doctor | Patient | Appointment |
Pattern 3: Self-Association (Reflexive)
A class associated with itself. Common in hierarchical or network structures.
Here, an Employee can have zero or one manager (who is also an Employee), and can have zero or more direct reports. Role names are essential for clarity in self-associations.
Experienced designers recognize these patterns instantly. When modeling a new domain, ask yourself: 'Is this a 1-to-many? Many-to-many? Reflexive?' Identifying the pattern quickly narrows down the correct notation.
We've covered the foundational concepts of UML associations. Let's consolidate the key takeaways:
What's next:
Now that we understand basic associations, we'll explore specialized relationship types that convey stronger semantic meaning. The next page examines aggregation—the "has-a" relationship where one class represents a whole composed of parts, but the parts have independent lifecycles.
You now understand how to represent and interpret association relationships in UML class diagrams. Mastering multiplicity notation is essential for accurate design communication. Next, we'll examine aggregation—a specialized form of association indicating whole-part relationships.