UML: Class & Object Diagrams

Association Classes & Dependencies

18 min Lesson 6 of 10

Association Classes & Dependencies

Most associations in a class diagram are simple: a line connecting two classes, perhaps with multiplicity labels. But what happens when the relationship itself carries data? And how do you show that one class merely uses another without owning or knowing it permanently? This lesson introduces two powerful but often under-used notations: the association class and the dependency arrow.

When the Relationship Has Attributes

Consider a clinic's appointment system. A Patient can book many Doctor appointments, and a Doctor can have many patient appointments. That is a straightforward many-to-many association. But an appointment has its own data: date, time, reason, and status. Where do those attributes live?

They do not naturally belong to Patient (a patient does not have a single date — each booking does). They do not belong to Doctor either. They belong to the relationship between Patient and Doctor for a specific booking. UML captures this with an association class: a class box connected to an association line by a dashed line, holding the attributes that describe the link itself.

Rule of thumb: If you find yourself adding attributes like enrollmentDate or discountRate to one of the participating classes but they only make sense in the context of the link, you need an association class.

The Appointment association class attaches to the line between Patient and Doctor, capturing attributes that only exist in the context of a specific booking.

Reading an Association Class

The dashed line from the association class box to the association line means: "this class describes that link." In implementation, an association class typically becomes a join table in a relational database (e.g. an appointments table with foreign keys to both patients and doctors) or a dedicated entity object in code.

Another example from an online store: a Customer can be enrolled in many LoyaltyProgram tiers, and a program tier can have many customers. The enrollment has its own attributes — enrollmentDate, pointsEarned, and tier. These live in an association class called Enrollment attached to the Customer-to-LoyaltyProgram association.

Naming convention: Association classes are usually named after the event or role the relationship represents — Appointment, Enrollment, Rental, OrderLine. A gerund or noun that describes the act of linking the two parties is a reliable guide.

Dependency Arrows

UML defines a dependency as a relationship where a change in one element (the supplier) may affect another element (the client). It is drawn as a dashed open-headed arrow pointing from the client toward the supplier.

Dependencies are weaker and more transient than associations. An association implies that one object holds a reference to another (a field in its definition). A dependency means only that a class uses another — perhaps as a method parameter, a local variable, or a call to a static utility. The client class does not permanently know the supplier; it just needs it in a moment.

Common scenarios for dependency arrows in a clinic or library system:

A BookingService creates an EmailNotification object temporarily to send a confirmation — it does not store the notification long-term.
An InvoiceReport class calls a TaxCalculator utility with amounts and gets results back — the report does not own the calculator.
A PatientController (web layer) depends on a PatientRepository interface but does not permanently reference specific implementations.

Dashed open-headed arrows show that BookingService uses EmailNotification and InvoiceReport transiently, while InvoiceReport uses TaxCalculator as a utility — none of these are permanent ownership relationships.

Association vs. Dependency: The Key Distinction

The difference is permanence and ownership:

Association (solid line): Object A holds a reference to object B as a field. If you printed object A's state, you would see B listed. Examples: an Order has a Customer; a Doctor has a list of Appointment objects.
Dependency (dashed arrow): Object A only knows about B during a method call — as a parameter, a local variable, or a return value. If A's method returns, the link is gone. Examples: a ReportGenerator receives a DateRange parameter; a Controller instantiates a temporary Validator and discards it.

Over-dependency is a design smell: If you draw dependency arrows from one class to many others, that class is doing too much — it is a violation of the Single Responsibility Principle. A well-designed system has few, narrow dependencies. During design review, count dependency arrows pointing out of each class; more than four or five is a warning sign.

Stereotypes on Dependency Arrows

UML allows you to label a dependency with a stereotype in guillemets to clarify its nature. The most common ones analysts and architects use are:

«use» — the client class calls methods on the supplier (the default assumption).
«create» — the client instantiates objects of the supplier class.
«call» — the client calls a specific operation of the supplier.
«instantiate» — like create, but emphasizes a factory pattern.

In practice, most business-analysis-level diagrams simply draw the dashed arrow without a stereotype and rely on context. Stereotypes become important when handing the diagram to architects or developers who need to know the exact mechanism.

Practical Workflow: Spotting Association Classes

Identify every many-to-many association in your draft class diagram.
Ask: "Does this link carry data of its own, or does it have a meaningful lifecycle (it is created, modified, archived)?"
If yes — promote the link to an association class and name it.
Ask stakeholders: "What information do you record about this relationship event?" Their answer fills the association class attributes.

In a library system: Member borrows many Book copies, and a book copy can be borrowed by many members over time. The borrowing link has borrowDate, dueDate, returnDate, and fineAmount. That is the Loan association class.

Summary

An association class is a class box attached to an association line by a dashed line; it holds attributes and operations that belong to the relationship, not to either participating class.
Association classes most commonly arise from many-to-many relationships where the link itself has data — bookings, enrollments, loans, order lines.
A dependency is a dashed open-headed arrow showing that one class uses another transiently — as a method parameter, local variable, or utility call — without holding a permanent reference.
Association = permanent ownership (field). Dependency = momentary use (method scope).
Stereotype labels («use», «create») on dependency arrows add precision when needed.