The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Terms and Concepts

A relationship is a connection among things. In object-oriented modeling, the three most important relationships are dependencies, generalizations, and associations. Graphically, a relationship is rendered as a path, with different kinds of lines used to distinguish the kinds of relationships.

Dependencies

A dependency is a relationship that states that one thing (for example, class Window) uses the information and services of another thing (for example, class Event), but not necessarily the reverse. Graphically, a dependency is rendered as a dashed directed line, directed to the thing being depended on. Choose dependencies when you want to show one thing using another.

Most often, you will use dependencies between classes to show that one class uses operations from another class or it uses variables or arguments typed by the other class; see Figure 5-2. This is very much a using relationshipif the used class changes, the operation of the other class may be affected as well, because the used class may now present a different interface or behavior. In the UML you can also create dependencies among many other things, especially notes and packages.

Note

A dependency can have a name, although names are rarely needed unless you have a model with many dependencies and you need to refer to or distinguish among dependencies. More commonly, you'll use stereotypes to distinguish different flavors of dependencies.

Generalizations

A generalization is a relationship between a general kind of thing (called the superclass or parent) and a more specific kind of thing (called the subclass or child). Generalization is sometimes called an "is-a-kind-of" relationship: one thing (like the class BayWindow) is-a-kind-of a more general thing (for example, the class Window). An objects of the child class may be used for a variable or parameter typed by the parent, but not the reverse. In other words, generalization means that the child is substitutable for a declaration of the parent. A child inherits the properties of its parents, especially their attributes and operations. Oftenbut not alwaysthe child has attributes and operations in addition to those found in its parents. An implementation of an operation in a child overrides an implementation of the same operation of the parent; this is known as polymorphism. To be the same, two operations must have the same signature (same name and parameters). Graphically, generalization is rendered as a solid directed line with a large unfilled triangular arrowhead, pointing to the parent, as shown in Figure 5-3. Use generalizations when you want to show parent/child relationships.

A class may have zero, one, or more parents. A class that has no parents and one or more children is called a root class or a base class. A class that has no children is called a leaf class. A class that has exactly one parent is said to use single inheritance; a class with more than one parent is said to use multiple inheritance.

Most often, you will use generalizations among classes and interfaces to show inheritance relationships. In the UML, you can also create generalizations among other kinds of classifiers, such as nodes.

Note

A generalization with a name indicates a decomposition of the subclasses of a superclass on a particular aspect, called a generalization set. Multiple generalization sets are orthogonal; the superclass is intended to be specialized using multiple inheritance to select one subclass from each generalization set. This is an advanced topic that we do not cover in this book.

Associations

An association is a structural relationship that specifies that objects of one thing are connected to objects of another. Given an association connecting two classes, you can relate objects of one class to objects of the other class. It's quite legal to have both ends of an association circle back to the same class. This means that, given an object of the class, you can link to other objects of the same class. An association that connects exactly two classes is called a binary association. Although it's not as common, you can have associations that connect more than two classes; these are called n-ary associations. Graphically, an association is rendered as a solid line connecting the same or different classes. Use associations when you want to show structural relationships.

Beyond this basic form, there are four adornments that apply to associations.

Name

An association can have a name, and you use that name to describe the nature of the relationship. So that there is no ambiguity about its meaning, you can give a direction to the name by providing a direction triangle that points in the direction you intend to read the name, as shown in Figure 5-4.

Note

Although an association may have a name, you typically don't need to include one if you explicitly provide end names for the association. If you have more than one association connecting the same classes, it is necessary to use either association names or association end names to distinguish them. If an association has more than one end on the same class, it is necessary to use association end names to distinguish the ends. If there is only one association between a pair of classes, some modelers omit the names, but it is better to provide them to make the purpose of the association clear.

Role

When a class participates in an association, it has a specific role that it plays in that relationship; a role is just the face the class at the far end of the association presents to the class at the near end of the association. You can explicitly name the role a class plays in an association. The role played by an end of an association is called an

end name (in UML1, it was called a

role name ). In Figure 5-5, the class Person playing the role of employee is associated with the class Company playing the role of employer.

Note

The same class can play the same or different roles in other associations.

Note

An attribute may be regarded as a one-way association owned by a class. The attribute name corresponds to the end name on the association end away from the class.

Multiplicity

An association represents a structural relationship among objects. In many modeling situations, it's important for you to state how many objects may be connected across an instance of an association. This "how many" is called the multiplicity of an association's role. It represents a range of integers specifying the possible size of the set of related objects. It is written as an expression with a minimum and maximum value, which may be the same; two dots are used to separate the minimum and maximum values. When you state a multiplicity at the far end of an association, you are specifying that, for each object of the class at the near end, how many objects at the near end may exist. The number of objects must be in the given range. You can show a multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*). You can give an integer range (such as 2..5). You can even state an exact number (for example, 3, which is equivalent to 3..3).

For example, in Figure 5-6, each company object has as employee one or more person objects (multiplicity 1..*); each person object has as employer zero or more company objects (multiplicity *, which is equivalent to 0..*).

Aggregation

A plain association between two classes represents a structural relationship between peers, meaning that both classes are conceptually at the same level, no one more important than the other. Sometimes you will want to model a "whole/part" relationship, in which one class represents a larger thing (the "whole"), which consists of smaller things (the "parts"). This kind of relationship is called aggregation, which represents a "has-a" relationship, meaning that an object of the whole has objects of the part. Aggregation is really just a special kind of association and is specified by adorning a plain association with an unfilled diamond at the whole end, as shown in Figure 5-7.

Aggregation has a number of important variations, as discussed in Chapter 10 .composition in Chapter 10 for a tighter form of aggregation.

Other Features

Plain, unadorned dependencies, generalizations, and associations with names, multiplicities, and roles are the most common features you'll need when creating abstractions. In fact, for most of the models you build, the basic form of these three relationships will be all you need to convey the most important semantics of your relationships. Sometimes, however, you'll need to visualize or specify other features, such as composite aggregation, navigation, discriminants, association classes, and special kinds of dependencies and generalizations. These and many other features can be expressed in the UML, but they are treated as advanced concepts.

Dependencies, generalizations, and associations are all static things defined at the level of classes. In the UML, these relationships are usually visualized in class diagrams.

When you start modeling at the object level, and especially when you start working with dynamic collaborations of these objects, you'll encounter links, which are instances of associations representing connections among objects across which messages may be sent.

Drawing Styles

Relationships are shown in diagrams by lines from one icon to another. The lines have various adornments, such as arrowheads or diamonds, to distinguish different kinds of relationships. Typically, modelers choose one of two styles for drawing lines:

• 
  Oblique lines at any angle. Use one line segment unless multiple segments are needed to avoid other icons.

  
  

• 
  Rectilinear lines drawn parallel to the sides of the page. Unless a lines connects two icons that align, the line must be drawn as a series of line segments connected by right angles.This is the style mostly used in this book.

  
  

With care, most line crossings can be avoided. If a line crossing is necessary and there is ambiguity about how the paths are connected, a small arc can be used to indicate a line crossing.