Logical View  «Prev  Next»
 Lesson 7 Modeling associations, continued Objective Define the notation for three variations on associations

# Define the Notation for Three Variations on Associations

This lesson will define the notation for three variations on associations:
1. reflexive association,
2. association classes and
3. qualified association.

In addition to the basic associations we just covered, the UML supports reflexive and qualified associations and association classes.
1. Reflexive association: The reflexive association is used when objects in the same class can be associated. The entire association notation remains the same, except that the association line is drawn to and from the same class. Both examples below are equivalent expressions; one uses roles, whereas the other uses an association name:
2. Association Class: Association classes are used to identify information about an association. The information is placed in a class attached to the association that it describes by a dashed line.

Be on the lookout for association classes when you see a multiplicity of more than one used on both ends of the association.
3. Qualified Association: Qualified associations provide the same functionality as indexes. The notation has a bit of a twist, so pay attention. To indicate that a customer can look up an order using the order's `ordernumber` attribute, the `ordernumber` attribute name is placed in a rectangular box on the Customer end of the association. All the other association notation remains intact but is pushed out to the edge of the rectangle. Also, because the qualifier is an attribute, it may include a data type.

Use qualifiers to reduce the multiplicity in the same way you would use indexes in a database. Note in the example how the multiplicity for Order changed from `0..*` to `1` because the qualifier provided a unique key for Order.

UML Bible

The following section discusses the elements of a UML class diagram.

## Structure Diagram

As the most important example of the new structure diagram type in UML 2, the class diagram can be used by analysts, business modelers, developers, and testers throughout the software development lifecycle. This article offers a comprehensive introduction. In UML 2 there are two basic categories of diagrams:
1. structure diagrams and
2. behavior diagrams.
Every UML diagram belongs to one these two diagram categories. The purpose of structure diagrams is to show the static structure of the system being modeled. They include the
1. class,
2. component, and
3. object diagrams.
Behavioral diagrams on the other hand, show the dynamic behavior between the objects in the system, including things like their methods, collaborations, and activities. Example behavior diagrams are activity, use case, and sequence diagrams.

## Class Diagram in particular

UML 2 considers structure diagrams as a classification; there is no diagram itself called a Structure Diagram. However, the class diagram offers a prime example of the structure diagram type, and provides us with an initial set of notation elements that all other structure diagrams use. And because the class diagram is so foundational, we will focus on the class diagram's notation set. You should have an understanding of how to draw a UML 2 class diagram and have a solid footing for understanding other structure diagrams when we cover them later.
Here are the correct matches:

Diagrammatic Class Diagram - Example The section below has you view and identify elements of a UML Class diagram.
Elements of Class Diagram

### Review Your Class Diagrams Frequently While You are Assigning Operations to Classes

Since you are now actively assigning operations to classes, and since it is very easy to make mistakes while drawing sequence diagrams, you should continually cross-check your sequence diagram and your class diagram to make sure that when you assign an operation to a class, you have done it in a way that makes sense. An excellent reference that can help you to make good design decisions is Rebecca Wirfs-Brock's book Object Design: Roles, Responsibilities, and Collaborations. This book teaches a very useful technique called Responsibility-Driven Design (we describe this technique in a little more detail later in this book).
• Static models of a system: Static models of a system describe the structural relationships that hold between the pieces of data manipulated by the system. They describe how data is parcelled out into objects, how those objects are categorized, and what relationships can hold between them. They do not describe the behaviour of the system, nor how the data in a system evolves over time. These aspects are described by various types of dynamic model. The most important kinds of static model are object diagrams and class diagrams. An object diagram provides a 'snapshot' of a system, showing the objects that actually exist at a given moment and the links between them. Many different object diagrams can be drawn for a system, each representing the state of the system at a given instant. An object diagram shows the data that is held by a system at a given moment, This data may be represented as individual objects, as attribute values stored inside these objects, or as links between objects.

In the next lesson, you will learn about aggregation and composition associations.