An association (also called a link) connects two classes in an MDriven model. Use associations to model how objects relate to one another—for example, a Person rents a House—and to define the corresponding relationship in the underlying database.

Model an association

In MDriven Designer, draw an association between the two classes, then define each end of the association. An association end describes the role that the objects at that end play in the relationship.

For example, a model can connect Person and House:

Class	Association-end role	Meaning
Person	RentedApartments	The houses rented by a person.
House	Tenants	The people who rent a house.

The role names are the names you use when navigating the relationship. Choose names that describe the collection or object reached from the class at the opposite end. For a single related object, use a singular name; for a collection, use a plural name. For example, a Booking relates to one Person, so the role should be Person, not Persons.

Set cardinality at both ends

Cardinality states how many objects may participate at each association end. Set it on the association ends in the diagram or in the Object Inspector.

Example cardinality	Interpretation
1	Exactly one related object is required.
0..1	Zero or one related object is allowed.
*	Any number of related objects is allowed.

For example, if a house can have many tenants and a person can rent many houses, set the association as many-to-many. If each booking belongs to one person and one flight, model the ends accordingly.

Use association names and role names consistently

An association has two ends. Each end has its own name property, which identifies the role at that end. Clear names make the model readable and make navigation expressions understandable.

When an association has a link class, also set the link names used for that relationship, including InnerLinkName and LinkRoleName. This is especially important when you need to work with the created link object in OCL or EAL. See Documentation:Adding a link object for a worked example.

Navigate an association

An association gives you navigation between related objects. In the Person–House example, you can navigate from a person to that person's rented houses through RentedApartments, and from a house to its people through Tenants.

Use the association-end role name in expressions. The exact result depends on the cardinality:

• A single-valued end gives one related object, or no object when the end is optional.
• A many-valued end gives a collection of related objects.

Use names that make this distinction visible. Tenants communicates a collection, while Person communicates one object.

For meta-level OCL that inspects the model's association ends rather than business data, use Documentation:OCLOperators associationEnds or Documentation:OCLOperators associationEndsWithType.

Ordered associations

An association can be ordered. Ordering records the order in which objects at the other end of the association are returned when no other sorting is applied.

For example, if a Person has an ordered RentedApartments association, navigation returns the related houses in the association's stored order unless your expression applies another sort. Do not use association ordering as a substitute for an explicit business sort when the required order is based on a value such as date or name.

Understand database mapping

MDriven's OR-mapping transforms the object model into database tables, fields, primary keys, and foreign keys. The association cardinality and embed setting affect where the relationship is represented.

Association shape	Usual foreign-key placement
One-to-many	At the many end.
Many-to-many	In a link class, which may be implicit.
One-to-one	At either end; the embed setting determines the placement.

The embed flag at an association end can be understood as the choice of which table contains the foreign key. For a one-to-many association, the many end is normally the appropriate location. If Embed=false is set on the many end, MDriven creates an implicit association class to hold the keys. For the full rules and implications, see Documentation:Embed.

Add information to the relationship

Use an association class—also called a link object—when the relationship itself needs attributes or behavior.

For example, a Person and a Flight can be connected by a Booking association class. The booking can hold information that belongs to that specific person-flight relationship, such as an apartment number, end date, or rent in a tenancy example. Association classes are not limited to many-to-many associations; they can be used on an association of any cardinality.

An association class also expresses two important rules:

• Lifetime control: the link object is created when the association is added and destroyed when the association is removed.
• Uniqueness: the same pair cannot be added to the relationship twice.

For example, adding a flight to a person's flights creates the corresponding booking; removing the flight removes that booking. Read Training:Association classes and Documentation:Part 8 Link Objects association classes before choosing between an association class and a regular class with two separate associations.

When you add through an association with a link class and need to update the created link object, use the patterns in Documentation:Adding a link object.

Keep diagrams readable

Removing an association from a diagram does not have to remove it from the model:

1. Select the association in the diagram.
2. Press Delete to remove it from that diagram only.
3. Use Ctrl+Delete only when you intend to delete the association from the model completely.

You can restore an association that was removed from a diagram with the diagram's re-introduction options. See Documentation:State Diagrams for diagram layout, association visibility, and association-name display options.

Related association features

Associations can also be calculated rather than stored. Use Documentation:Let and Derived associations when you need a derived association, and review the linked page for the distinctions and implementation approach.

See also

• Documentation:Embed
• Documentation:Let and Derived associations
• Documentation:Adding a link object
• Documentation:Part 8 Link Objects association classes
• Training:Association classes
• Documentation:State Diagrams

Define association ends and cardinality

An association, also called a link, is the connection between classes and therefore between the objects and data tables in the underlying database.

Relations have two endpoints. Each endpoint has a name. When reading a class diagram, use the name at the far side of the relation. For example, if a relation from Car to Brand has the endpoint name BrandOfTheCar, it can be read as: a car has a brand of the car.

Relation endpoints also have cardinality. Cardinality is a rule on the endpoint that describes how related instances may occur.

Associations can be ordered. Ordering adds information about the order in which objects at the other end of the association should be returned when no other sorting is used.

When to use an association class

Use an association class when the relationship itself needs additional information. Although association classes are often used for many-to-many relationships, they can be used on an association of any cardinality.

For example, a Booking association class can represent the relationship between Person and Flight. In OR-mapping, this model becomes three tables: one for Person, one for Flight, and one for Booking.

Association classes provide lifetime control and uniqueness in the relation. A booking is created as a consequence of associating a person with a flight, and it is removed when that association is removed. A person cannot be added to the same flight twice in that relation.

See also

• Training:Short introduction to UML– class diagram
• Training:Association classes
• Documentation:Association