Relationships Among Elements of Class Diagrams

Go Up to UML 1.5 Class Diagrams

A relationship is a connection among elements. In the Modeling, the three most important relationships are dependencies, generalizations, and associations. Graphically, a relationship is rendered as different kinds of lines used to distinguish the kinds of relationships.

Kinds of Relationships Among Elements of Class Diagrams

You can use the following kinds of relationships among elements of class diagrams:

• Generalization and implementation
• Dependency
• Association (simple association, N-ary association, aggregation, and composition)
• Provided and Required Interfaces (UML 2.0)

Generalization and Implementation

• Generalization -- A generalization is a relationship between a general element (superclass or parent) and a more specific kind of that element (subclass or child). Also a generalization is used to point the inheritance relationship between two interfaces (a child and a parent).

Generalization means that a child inherits the properties (attributes, operations, and others) of its parents and that objects of the child element may be used anywhere the objects of the parent element may appear.

Graphically, a generalization is rendered as a solid directed line with a large closed arrowhead, pointing to the parent:

• Implementation -- An implementation relationship is the special kind of the generalization relationship. An implementation is an inheritance link indicating that a child class implements a parent interface.

Graphically, an implementation is rendered as a dashed directed line with a large closed arrowhead, pointing to the parent interface:

Dependency

A dependency is a relationship between two elements in which a change to one element (the independent element - supplier) causes changes to the other element (the dependent element - client).

Graphically, a dependency is rendered as a dashed directed line, directed to the thing being depended on (supplier):

Association

A relationship between instances of two classes. There is an association between two classes if an instance of one class (client) must know about the other (supplier).

In a diagram, an association is rendered as a solid line connecting two classes.

Navigation, roles, and multiplicities are optional items placed on associations to provide clarity:

• Association Navigation. Associations can be directed or undirected. A directed link points to the supplier class (the target). A navigation arrow on an association shows the direction in which the association can be traversed or queried. A class can be queried about its "item", but not the other way around. The arrow also lets you know who "owns" the implementation of the association. Associations with no navigation arrows are bi-directional. For example, a bi-directional association between the Library and Book classes indicates that you can traverse from objects of the Library type to objects of the Book type and the other way around.

• Roles. An association has two ends. Each end can have a role name to clarify the nature of the association.

• Multiplicity. An association end can have a multiplicity. The multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end. Multiplicities are numbers or ranges of numbers.

This table lists the most common multiplicities:

Multiplicity	Meaning
0..1	Zero or one instance. The notation n..m indicates n to m instances.
1 or n	Exactly one instance or exactly n instances.
0..* or *	No limit on the number of instances (including none).
1..*	At least one instance.

Types of Associations

These are the types of an association relationship:

1. Association (Simple Association) -- An association ("simple association") between two peer classes. It represents a pure structural relationship between two peers. Both classes are conceptually at the same level, neither being more important than the other.

Graphically, an association is rendered as a solid line connecting two classes:

This figure shows the "simple association" link, which has the owner role, the 1 and 0..* multiplicities, and specifies the association navigation from the Client to the Password classes.

2. Association (N-ary Association) -- N-ary association can connect as many association end classes (participants) as required. To create N-ary associations, use an association class.

Association classes appear in diagrams as three related elements:

* Association class itself (), represented by a class icon.

* N-ary association class link (), represented by a diamond.

* Association connector (), represented by a link between an association class icon and an association diamond.

The Object Inspector of an association class, association link, and connector contains an additional Association tab. This tab contains only the label property, its value being synchronized with the name of the association class. For the association classes and association end links, the Custom item of the Object Inspector displays additional properties that correspond to the role of this part of n-ary association (associationClass and associationEnd respectively).

You can delete any of the association end links or participant classes without destroying the entire n-ary association. However, deleting the association class results in deleting all the components of the n-ary association.

See also: Creating an Association Class.

3. Aggregation -- An aggregation is the special kind of association representing a "part-whole" relationship, in which one class represents a larger element ("whole") containing smaller elements ("parts"). A separate aggregation link is used between each class representing a part and a class representing the whole.

Graphically, an aggregation is rendered as a solid line between two classes with a hollow-diamond at the "whole" end:

This figure shows the aggregation link. The Group class represents the "whole" and the Person class represent "parts". 0..* multiplicities on both ends and the union and member roles specify that each union (of the Group type) can contain any number of members (of the Person type) and, on the contrary, that each Person type object can be a member of any number of unions (of the Group type). The bi-directional aggregation navigation specifies that both a Group type object can request for its Person type members and a Person type object can request for unions (of the Group type) of which it is a member.

4. Composition -- A composition is a special "strong" form of aggregation in which the "composite end" has the the total responsibility for managing its "part ends" (such as the creation and destruction of its parts).

Graphically, a composition is rendered as a solid line between two classes with a filled-diamond at the composition end:

This figure shows the composition links. The Order class represents the "composition" and the Customer and LifeItem classes represent "parts".

Provided and Required Interfaces

UML 2.0 class diagrams introduce the provided and required interfaces.

To mark provided and required interfaces, UML 2.0 class diagrams use the provided interface ("lollipop" notation) and required interface ("soket" notation) links (see UML 2.0 Class Diagram Elements).

See Also

• UML 2.0 Class Diagrams
• Class Diagram Procedures