Associations

Associations represent structural relationships between classes of objects. An association symbolizes a piece of information with a lifecycle that is non-negligible in comparison to the general dynamics of object instances of the associated classes. Most associations are binary; i.e. they connect two classes. Associations are represented by drawing a line between the associated classes.

Associations may be represented by straight or diagonal lines, according to the preference of the user. Experience recommends staying limited as far as possible to a single presentation style for lines in order to simplify the reading of diagrams within a project.

Association Naming

Associations may be named; in the diagram below, the name of the association appears in the middle of the line that symbolizes the association. In general it can be on, above or below the line.

Associations may be named in order to facilitate model understanding

Without making it a systematic rule, experience recommends naming associations using a verbal form — either active, like 'works for', or passive, like 'is employed by'.

In both cases, the direction in which the name should be read may be indicated using a small triangle pointing towards the class designated by the verbal construct, and positioned close to the name of the association. In order to simplify things, the small triangle may be replaced by the symbols

<
and
>
, which are available in any

Associations between classes mainly express the static structure, so naming them using verbal constructs that evoke a behavior is somewhat in conflict with the general spirit of class diagrams. Naming association ends (described below) makes it possible to clarify diagrams, just like naming associations, but in a more passive way that is more in agreement with the static tone of class diagrams.

Role Naming

The end of an association is called the role. Each binary association has two roles, one at each end. The role describes how a class sees another class via an association. A role is named using a noun. Visually, the name of a role can be distinguished from the name of an association as it is positioned near to one end of the association.

The person sees the company as their employer, and the company sees the person as its employee.

Either associations or roles may be named, but it is rare to name both on a single association. It is usual to start by labeling an association with a verb, and then to use that verb at a later stage to build a suitable noun to name the role.

When two classes are linked by a single association, the name of the classes is often sufficient to identify the role; role naming is most beneficial when many associations connect two classes. In this case, there is no default correlation between the objects that participate in the two relationships. Each association expresses a different concept. In the following example, there is no relationship between the passengers and the pilot.

The presence of a large number of associations between two classes may be suspicious. Each association augments the coupling between the associated classes, and strong coupling may indicate a bad decomposition. It is also common for beginners to represent the same association more than once, by naming each association with the name of one of the recurring messages between object instances of the associated classes.

Example of confusion between associations and messages — a single 'owns' association is sufficient to enable a person to drive, start, wash, and stop their car.

Multiplicity of Associations

Each role of an association has a multiplicity value that indicates how many objects of the given class may be linked to an object of the other class. Multiplicity is a piece of information carried by the role, and it corresponds to a bounded integer expression.

1
One and only one
0..1
Zero or one
M..N
From M to N (natural integers)
*
From zero to any positive integer
0..*
From zero to any positive integer
1..*
From one to any positive integer

A multiplicity value greater than 1 implies an collection of objects. This collection is unbounded in the case of a value of

*
, meaning that simply that 'several' objects participate in the relationship, without restricting the total possible number of objects. The term 'collection', which is more general than 'list' or 'set', is used to avoid any assumptions concerning the data structure that contains the objects.

Multiplicity values express constraints linked to the application domain that are valid for the whole of the object's existence. The multiplicities must not be considered during transient states, such as the creation or the destruction of objects. A multiplicity of 1 indicates that during normal operation, an object has an obligatory link to another object; however, this should not result in an attempt to deduce the parameter lists of the constructors. Multiplicity values do not imply anything specific with respect to the object creation order. The following example shows two classes connected by an association where both roles have a multiplicity of 1, without assuming anything about the parameter profile of the object constructors. It is not necessary to have a car in order to build an engine, or vice-versa.

When determining the optimal multiplicity, is very important to find the proper balance between flexibility and extensibility on the one hand, and between complexity and efficiency on the other. As far as analysis is concerned, only the multiplicity is important, but at design time, it is necessary to choose data structures (stack, file, set...) in order to implement collections that correspond to multiplicities of type

1..*
or
0..*
. Overestimating the multiplicity results in overpricing the storage size and limiting the search speed. Similarly, a multiplicity that starts with zero implies that the various operations must contain code to test the presence or the absence of links within the objects.

Multiplicity values are often used to describe associations in a generic fashion. The most common types are the 1 to 1, 1 to N, and N to N associations represented in the following figure.

Constraints on Associations

Many kinds of constraints may be defined on an association or on a group of associations. The multiplicity introduced in the previous section is a constraint on the number of links that may exist between two objects. Constraints are represented in diagrams by expressions delimited with braces.

The constraint

{ordered}
may be placed on the role to specify an ordered relationship describing the objects that are part of the collection. In this case, the model does not specify how the elements are ordered, but only the fact that the order must be maintained during, for example, the addition or the removal of objects.

The constraint

{subset}
indicates that a collection is included in another collection. The following example illustrates how the representatives of schoolchildren's parents are also parents of schoolchildren.

The constraint

{exclusive or}
indicates that, for a given object, only a single association among a group of associations is valid. This constraint prevents the introduction of artificial subclasses in order to represent exclusivity.

An association may also link a class to itself, as is the case in recursive structures. This type of association is called a reflexive association. Again, role naming becomes most important to distinguish the instances that take part in the relationship. The following example illustrates the

Person
class and the relationship that links parents to their children:

Every person has between zero and two parents, and between zero and several children. Role naming is key to the diagram's clarity.

Association classes

An association may be represented by a class to add attributes and operations to that association. A class of this type is a class like any other, and as such it can participate in other relationships within the model. The notation uses a dashed line to attach a class to an association. In the following example, the association between classes

A
and
B
is represented by the class
C
, which is itself associated to class
D
.

An association that contains attributes but does not participate in relationships with other classes is called an attributed association. In this case, the class attached to the association does not carry a specific name.

N-ary Associations

Most associations are referred to as 'binary', since they link two classes. A class may be linked to more than one other class, however, by means of an n-ary association. This is represented using a diamond, pointed to by the various components of the association.

Example of a ternary relationship that represents a course

N-ary associations can generally be represented by promoting the association to the rank of a class, and by adding a constraint that expresses the fact that the various branches of the association are instantiated simultaneously, in a single link. In the following example, the constraint is expressed using a stereotype that indicates that the

Course
class implements a ternary association.

Just as for binary associations, the ends of an n-ary association are called roles and may have a name. If it is difficult to find a different name for each role of an n-ary association, it is often a sign that the association is between the wrong number of classes.

Location of Attributes According to Multiplicity Values

The process of giving attributes to associations is most beneficial in the case of N to N associations. For 1 to 1 associations, association attributes can always be moved into one of the classes that participate in the association. For 1 to N associations, the movement is generally possible into the class on the N side, although it is common to promote the association to the rank of a class, in order to increase its readability, or to accommodate the presence of associations with other classes. The following example illustrates the various cases:

Examples of attribute placement according to multiplicity

The association between the

Student
and
Assignment
classes is of type N to N. The
Assignment
class describes the topic; the solution given by the student is not retained.

In the case of tests, each student works individually on a given assignment, and the mark obtained cannot be stored either in a particular student (as he performs many different assignments in his career), or in a given assignment (since there are as many marks as there are students). The mark is an attribute of the association between the student class and the assignment class.

At the end of the year, each student receives a diploma with a grade that depends on the individual student's performance. The relationship between the diploma and the student is unique, since a diploma only applies to a given student. The grade becomes an attribute of the diploma. The grade is not stored in the

Student
for two reasons: it does not specify a student, and a student may obtain several diplomas.

Each student has a room, and multiple students do not share a room. The association between students and rooms is of type 1 to 1. The number is an attribute of the

Room
class, since a number specifies a room.

Association Qualifiers

The qualification of an association consists of selecting a subset of objects from the set of objects that participate in an association. The restriction is implemented by means of a particular attribute or set of attributes (known as a qualifier) and used jointly with an object of the source class. The qualifier is represented at the end of the association, in a rectangular box. The qualifier belongs to the association and not to the associated classes.

Each instance of the class

A
, accompanied by the value of the qualifier, identifies a subset of the instances of
B
that participate in the association. The restriction reduces the association's multiplicity; very often, multiplicity is reduced to
1
.

An association may be restricted by combining the values of the various attributes that make up the qualifier.

Combination of a line and a column to identify a square on the chessboard.

© 1997 Editions, Eyrolles, Paris, France . All rights reserved.