You use an association class when a relationship between two classes has its own information and must exist only as part of that relationship; this page is for modelers designing UML class diagrams in MDriven Designer.
What an association class represents
An association connects two classes. An association class, also called a link object, is a class attached to that association. It represents one occurrence of the relationship and stores facts about that occurrence.
For example, a Person can rent many House objects, and a House can have many tenants. A LeaseContract association class can hold information that belongs to the specific Person–House relationship:
ApartmentNumberEndDateRent
Those values do not describe the Person alone or the House alone. They describe that person's rental of that house.
Association, relation, and link are closely related terms in UML. An association has two ends; each end has a name and a cardinality. Read the UML basics and cardinality rules in Training:Short introduction to UML– class diagram.
When to use an association class
Use an association class when both of these rules are part of the domain:
| Rule | Meaning | Person–Flight example |
|---|---|---|
| Lifetime control | The link object is created when the association is made and removed when the association is removed. You do not create it as an independent object. | Associating a Person with a Flight creates the Booking; removing that passenger from that flight removes the Booking.
|
| Uniqueness | One pair of objects can occur only once in the association. | The same Person cannot be added to the same Flight twice, so there cannot be two Bookings for the same Person–Flight pair. |
The association class communicates these rules to people reading and working with the model. It says that Booking is the relationship itself, not an independently managed business object.
Although association classes are common on many-to-many associations, they can be used on an association of any cardinality. Choose them because the relationship has the lifetime and uniqueness semantics above, not because of cardinality alone.
Association class versus an ordinary class
Consider Person, Flight, and Booking.
Association-class model
Model Booking as the association class on the Person–Flight association when a Booking exists only because that Person is associated with that Flight. The pair is unique: one Person has at most one Booking for the same Flight.
The intended object-level behavior is expressed as adding and removing the association:
aPerson.Flights.Add(aFlight);
aPerson.Flights.Remove(aFlight);
Adding the Flight creates the corresponding Booking link object. Removing the Flight removes it.
Ordinary Booking-class model
You can instead model Booking as a regular class with associations to Person and Flight. This can result in a similar relational database layout, but it conveys different object-oriented meaning: Booking is now a separate class that can be handled independently of making or removing the Person–Flight association.
Do not choose between these alternatives by looking only at tables. Choose the model that matches the business rules and lifecycle you need to express.
Database mapping perspective
When a many-to-many Person–Flight association has a Booking association class, object-relational mapping produces storage for Person, Flight, and Booking. Booking identifies the related Person and Flight and also stores its own attributes.
A many-to-many association without an association class also requires a linking table in relational storage. That table identifies the two related rows, even when it has no modeled attributes of its own.
This similarity in database shape does not make the models equivalent. The association-class model explicitly carries the UML rules that the link object follows the association's lifetime and that a pair is unique.
Add an association class in MDriven Designer
Create the two classes and their association first. For the example, create Person and House, then create the association whose ends describe the domain, such as RentedApartments and Tenants.
- In MDriven Designer, select the Drag-out new association class connection tool. Confirm the tool name in its tooltip.
- Drag from the association line to create the association-class connection. The association class is shown with a dotted line to the association.
- Name the association class for the relationship it represents, for example
LeaseContract. - Add attributes to the association class, for example
Rent,EndDate, andApartmentNumber. - Name both association ends so that the diagram reads in the language of the domain. See Training:Short introduction to UML– class diagram for how to read endpoint names and cardinalities.
- Review the relationship: confirm that the link object should be created and removed with the association and that one object pair must not appear twice.
To remove an association class from an association, select the association line and use the Property Inspector to set its association class to no class. Removing the association-class connection from a diagram does not necessarily remove it from the model.
Diagram and model gotcha
In MDriven Designer, Delete removes the selected item from the current diagram only. Ctrl+Delete removes it from the model. Use Delete when you only want to simplify a diagram view; use Ctrl+Delete only when you intend to remove the modeled element.
If an association or association class was removed from a diagram view, you can restore it from the class context menu using Introduce&Remove. The bootcamp exercise demonstrates diagram-only deletion, reintroduction, and moving association ends: Training:Bootcamp:Chapter 2.
Work with the link object
The association class is available as an implicit link in OCL. This is useful when the relationship facts are needed rather than only the related object. In the rental example, you can navigate from a House to its LeaseContract objects and use values such as rent or end date.
Use Documentation:Part 8 Link Objects association classes for a deeper walkthrough of link objects, including adding and working with them. For an example of EAL that helps add a link object, see Documentation:Part 8 Link Objects association classes.
Checklist
Before modeling a link object as an association class, ask:
- Does the relationship have attributes of its own?
- Should the link object be created only when the two objects are associated?
- Should it be removed automatically when that association is removed?
- Must each pair of related objects be unique?
If the answers to the lifecycle and uniqueness questions are yes, use an association class. If the relationship must be independently created, retained, or repeated for the same pair, model the business concept as an ordinary class and associations instead.