30.153
Specifying and Interpreting Multiplicity in UML

Introduction

The Class Diagram is one of thirteen diagrams of the Unified Modeling Language (UML). It is the diagram used to depict the classes (or entities) in a system or domain. UML Class Diagrams are a common visual notation for ontologies and conceptual data/information models.

This short lesson explains how to specify the correct multiplicities between classes in a UML Class Diagram by viewing them as mapping between sets of objects. Multiplicities are a type of domain constraint and they express business rules.

While there are several different kinds of relationships in UML Class Diagrams, multiplicity constraints only apply to association, aggregation, and composition. Most notably, they are not specified for generalization.

So, the ensuing discussion only applies to association, aggregation, and composition as those are relationships between instances of classes (objects) rather than a static relationship between classes.

---

The diagrams presented in this tutorial were drawn using LucidChart and can be accessed at this link.

---

Review of Class Diagrams

In class diagrams, information architects define:

• Classes (a concept, things, object, role, event, person; equivalent of entity in an ERD in database design)
• Attributes of a class representing property along with the data type and possible default value
• Methods (or operations) representing its behavior

In UML, a class is represented with a three-compartment rounded-corner box, as shown below. In class diagrams depicting an ontology (or conceptual model), the third compartment sometimes contains a definition rather than methods. The attribute that uniquely identifies each instance is often tagged using the UML stereotype «key».

An abstract class (one which exist solely to organize a class hierarchy and is not instantiable) is indicated visually with either the stereotype «abstract» or by italicizing the class name. The example diagram below illustrates the two styles. To be meaningful, abstract classes must have at least two subclasses.

Review of Relationship Types

Relationships which are grouped into two categories:

• Relationships between objects (instances of classes) differentiated into Dependency, Association, Aggregation and Composition

• Relationships between classes of two kinds in terms of Generalization/Inheritance and Realization/Implementation

Relationships are always bi-directional. It is equally valid to say that A is linked to B as it is to say that B is linked to A.

Aggregation and composition are special types of associations, which means that all properties of an association (such as having a label and multiplicities) apply, by definition, to aggregation and composition. Further, composition is a special kind of aggregation.

The UML meta-model below shows the relationships between “relationships”:

Association

An association is a simple semantic relationship between two classes that indicates a link between them. For example, “a portfolio is owned by an investor” is an example of an association. The two classes are linked but neither is part of the other or a kind of the other. As the association is bi-directional, it can be inverted, so it is equally valid to say that “An investor owns a portfolio”. The actual phrase is generally found through domain analysis.

Multiplicity Constraints

The multiplicity bounds are generally as text string in the format:

<lower-bound> ‘..’ <upper-bound>

where <lower-bound> is an integer and <upper-bound> is a of type unlimited natural with the restriction that <lower-bound> ≤ <upper-bound>.

If the multiplicity is associated with a multiplicity whose notation is a text string (such as an attribute), the multiplicity string is placed within square brackets ([ ]) as part of that text string.

Unbounded Upper Bound with *

The star character (*) is used as part of a multiplicity specification to represent an unlimited upper bound.

While a multiplicity constraint of “*” is valid and implies a lower bound of 0, it is recommended to specify a lower bound explicitly (e.g., 0..* or 1..*) as the implied lower bound of “0” may not be known to the reader of a UML Class Diagram.

Equal Upper and Lower Bounds

If the lower bound is equal to the upper bound, then an alternate notation is to use a string containing just the upper bound. For example, “1” is semantically equivalent to “1..1” multiplicity. A multiplicity with zero as the lower bound and an unspecified upper bound may use the alternative notation containing a single star “*” instead of “0..*” multiplicity.

The specific notation for the ordering and uniqueness specifications may vary depending on the specific kind of multiplicity element. A general notation is to use a textual annotation containing “ordered” or “unordered” to define the ordering, and “unique” or “non-unique” to define the uniqueness.

Examples of Multiplicity Definitions

Example Multiplicity	Semantics
0..1	no more than one, but possibly none
1..10	at least one but no more than 10
0..*	no specific upper bound and possibly none
5..*	at least five, but no upper limit
1..1	exactly 1; same as 1
10	exactly 10; same as 10..10
1..[C.n]	at least one but no more than the value of the (integer) attribute n in the class or object \(C\)

Label Direction vs Navigation Direction

An association is represented as a line (without arrows) between two classes. The classes are often referred to as the source and the target. A verb-phrase label is often added to assist in understanding the nature of the relationship along with an arrow (▶) indicating the reading direction of the label. The label is optional. The example below depicts the association between an investor and a portfolio in an finance or investment domain.

A few notes to keep in mind:

• the line should not have an arrow at one end
• an arrow as part of the label indicates the reading direction of the verb-phrase and does not indicate any kind of direction for the association

Interpreting Multiplicities

In the diagram below, the relationship between classes “Auction” and “Bid” should be read as follows:

1. Any (one) bid is made in exactly one auction.
2. Any (one) auction has multiple bids made in it; there is no limit on the bids and some auctions may not have any bids.

We can think of classes as sets of instances (objects), which means that an association relationship is a mapping between objects of one set to objects of another set.

For example, auction 7467 does not have any bids, while auction 8613 has two bids (bids 101 and 102). Every bid is connected to from exactly one auction; there are no bids that are not connected to an auction.

Conclusion

Relationships between object instances (association, aggregation, and composition) must have multiplicities that define the mapping between the class instances of the respective classes.

Tutorial

The video tutorial below explains in more detail the concept of a relationship between objects as a mapping between two sets, or a function that maps an instance of class A to zero or more instances of class B.

---

Files & Resources

All Files for Lesson 30.153

---

References

None.

Errata

Let us know.