Associations represent structural relationships between
objects of different classes; they represent connections between instances of two or more classes that exist for some
duration. Contrast this with transient links that, for example, exist only for the duration of an operation. These
latter situations can instead be modeled using collaborations, in which the links exist only in particular limited
You can use
associations to show that objects know about another objects. Sometimes, objects must hold references to each other to
be able to interact, for example send messages to each other; thus, in some cases associations may follow from
interaction patterns in sequence diagrams or communication diagrams.
Most associations are binary (exist between exactly two classes), and are drawn as solid paths connecting pairs of
class symbols. An association may have either a name or the association roles may have names. Role
names are preferable, as they convey more information. In cases where only one of the roles can be named, roles are
still preferable to association names so long as the association is expected to be uni-directional, starting from the
object to which the role name is associated.
Associations are most often named during analysis, before sufficient information exists to properly name the roles.
Where used, association names should reflect the purpose of the relationship and be a verb phrase. The name of the
association is placed on, or adjacent to the association path.
In an ATM, the Cash Drawer provides the money that the Cash Dispenser dispenses. In order for the Cash
Dispenser to be able to dispense funds, it must keep a reference to the Cash Drawer object; similarly, if
the Cash Drawer runs out of funds, the Cash Dispenser object must be notified, so the Cash Drawer
must keep a reference to the Cash Dispenser. An association models this reference.
An association between the Cash Dispenser and the Cash Drawer, named supplies Value.
Association names, if poorly chosen, can be confusing and misleading. The following example illustrates good and bad
naming. In the first diagram, association names are used, and while they are syntactically correct (using verb
phrases), they do not convey much information about the relationship. In the second diagram, role names are used, and
these convey much more about the nature of the participation in the association.
Examples of good and bad usage of association and role names
Each end of an association is a role specifying the face that a class plays in the association. Each role
must have a name, and the role names opposite a class must be unique. The role name should be a noun indicating the
associated object's role in relation to the associating object. A suitable role name for a Teacher in an
association with a Course Section would, for instance, be lecturer; avoid names like "has" and
"contains", as they add no information about what the relationships are between the classes.
Note that the use of association names and role names is mutually exclusive: one would not use both an association name
and a role name. Role names are preferable to association names except in cases where insufficient information
exists to name the role appropriately (as is often the case in analysis; in design role names should always be used).
Lack of a good role name suggests an incomplete or ill-formed model.
The role name is placed next to the end of the association line.
Consider the relationships between classes in an order entry system. A Customer can have two different kinds of
Addresses: an address to which bills are sent, and a number of addresses to which orders may be sent. As a result, we
have two associations between Customer and Address, as shown below. The associations are labeled with the
role the associated address plays for the Customer.
Associations between Customer, Address, and Order, showing both role names and multiplicities
For each role you can specify the multiplicity of its class, how many objects of the class can be associated
with one object of the other class. Multiplicity is indicated by a text expression on the role. The expression is a
comma-separated list of integer ranges. A range is indicated by an integer (the lower value), two dots, and an integer
(the upper value); a single integer is a valid range, and the symbol '*' indicates "many", that is, an unlimited number
of objects. The symbol '*' by itself is equivalent to '0..*', that is, any number including none; this is the default
value. An optional scalar role has the multiplicity 0..1.
In the previous example, multiplicities were shown for the associations between Order and Customer, and between
Customer and Address. Interpreting the diagram, it says that an Order must have an associated Customer (the
multiplicity is 1..1 at the Customer end), but a Customer may not have any Orders (the multiplicity is 0..* at the
Order end). Furthermore, a Customer has one billing address, but has one or more shipping address. To reduce notational
clutter, if multiplicities are omitted, they may be assumed to be 1..1.
The navigability property on a role indicates that it is possible to navigate from a associating class to the
target class using the association. This may be implemented in a number of ways: by direct object references, by
associative arrays, hash-tables, or any other implementation technique that allows one object to reference another.
Navigability is indicated by an open arrow, which is placed on the target end of the association line next to the
target class (the one being navigated to). The default value of the navigability property is true.
In the order entry example, the association between the Order and the Customer is navigable in
both directions: an Order must know which Customer placed the Order, and the
Customer must know which Orders it has placed. When no arrowheads are shown, the association is assumed
to be navigable in both directions.
In the case of the associations between Customer and Address, the Customer must know its
Addresses, but the Addresses have no knowledge of which Customers (or other classes, since many
things have addresses) are associated with the address. As a result, the navigability property of the Customer
end of the association is turned off, resulting in the following diagram:
Updated Order Entry System classes, showing navigability of associations.
Sometimes, a class has an association to itself. This does not necessarily mean that an instance of that class has an
association to itself; more often, it means that one instance if the class has associations to other instances of the
same class. In the case of self-associations, role names are essential to distinguish the purpose for the association.
Consider the following self-association involving the class Employee:
In this case, an employee may have an association to other employees; if they do, they are a manager, and the other
employees are members of their staff. The association is navigable in both directions since employees would know their
manager, and a manager knows her staff.
Drawing two associations between classes means objects are related twice; a given object can be linked to different
objects through each association. Each association is independent, and is distinguished by the role name. As shown
above, a Customer can have associations to different instances of the same class, each with different role names.
When the multiplicity of an association is greater than one, the associated instances may be ordered. The
ordered property on a role indicates that the instances participating in the association are ordered; by default
they are an unordered set. The model does not specify how the ordering is maintained; the operations that update
an ordered association must specify where the updated elements are inserted.
The individual instances of an association are called links; a link is thus a relationship among instances.
Messages may be sent on links, and links may denote references and aggregations between objects. See Guideline: Communication Diagram for more information.
An association class is an association that also has class properties (such as attributes, operations, and
associations). It is shown by drawing a dashed line from the association path to a class symbol that holds the
attributes, operations, and associations for the association. The attributes, operations, and associations apply to the
original association itself. Each link in the association has the indicated properties. The most common use of
association classes is the reconciliation of many-to-many relationships (see example below). In principle, the name of
the association and class should be the same, but separate names are permitted if necessary. A degenerate association
class just contains attributes for the association; in this case you can omit the association class name to
de-emphasize its separateness.
Expanding the Employee example from before, consider the case where an Employee (a staff-person) works for another
Employee (a manager). The manager performs a periodic assessment of the staff member, reflecting their performance over
a specific time period.
The appraisal cannot be an attribute of either the manager or the staff member alone, but we can associate the
information with the association itself, as shown below:
The association class Appraisal captures information relating to the association itself
Qualifiers are used to further restrict and define the set of instances that are associated to another instance; an
object and a qualifier value identify a unique set of objects across the association, forming a composite key.
Qualification usually reduces the multiplicity of the opposite role; the net multiplicity shows the number of instances
of the related class associated with the first class and a given qualifier value. Qualifiers are drawn as small boxes
on the end of the association attached to the qualifying class. They are part of the association, not the class. A
qualifier box may contain multiple qualifier values; the qualification is based on the entire list of values. A
qualified association is a variant form of association attribute.
Consider the following refinement of the association between Line Item and Product: a Line Item
has an association to the Product which is ordered. Each Line Item refers to one and only one Product, while a
Product may be ordered on many Line Items. By qualifying the association with the qualifier ProductCode we
additionally indicate that each product has a unique product code, and that Line Items are associated with
Products using this product code.
The association between Line Item and Product has the qualifier ProductCode.
An n-ary association is an association among three or more classes, where a single class can appear more than once.
N-ary associations are drawn as large diamonds with one association path to each participating class. This is the
traditional entity-relationship model symbol for an association. The binary form is drawn without the diamond for
greater compactness, since they are the bulk of associations in a real model. N-ary associations are fairly rare and
can also be modeled by promoting them to classes. N-ary associations can also have an association class; this is shown
by drawing a dashed line from the diamond to the class symbol. Roles may have role names but multiplicity is more
complicated and best specified by listing candidate keys. If given, the multiplicity represents the number of instances
corresponding to a given tuple of the other N-1 objects. Most uses of n-ary associations can be eliminated using
qualified associations or association classes. They can also be replaced by ordinary classes, although this loses the
constraint that only one link can occur for a given tuple of participating objects.