3.5 Lines
In the UML, lines are used to express messages (dynamic connections between model elements), "links" (relationships between model elements—the term link also has a formal meaning within the UML), and interactions. Generally, messages don't appear in structural models; links don't appear in dynamic models. But this, too, can be varied within a dialect. A basic set of line-based UML notation is explained in the following sections.
NOTE
Remember (as I mentioned when discussing visual relationships in Section 3.1.2, "Diagrams"), lines must be terminated in some fashion in the UML, either with a model element graphic or an icon.
3.5.1 Messages
Messages are used in interactions between model elements in dynamic models, those that represent the behavior in a system. Messages convey information between objects, for example, and trigger activities. There are four types of messages (as shown in Figure 3.14):
){kind=link}
Simple message—Control is passed from one object to another without providing details.
Synchronous message—The sending object pauses to wait for results.
Asynchronous message—The sending object does not pause to wait for results.
Return message—This message indicates a return from a procedure call.
Figure 3.14 The four types of messages.
3.5.2 Relationships in General
Relationships are used in structural models to show semantic connections between model elements.
Adependency is what The Unified Modeling Language User Guide calls a "using" relationship (Jacobson, Booch, and Rumbaugh 1998a), one in which the connection between two things means that if one changes, it affects the other (see Figure 3.15). Dependencies can be used to identify connections between a variety of model elements, packages being a notable example. These are unidirectional relationships.
){kind=link}
Figure 3.15 Dependency.
Ageneralization is a relation between two elements, in which one is a more general form of the other (see Figure 3.16). Class inheritance is represented this way, but generalization can be used more generally. Again, packages are an example.
){kind=link}
Figure 3.16 Generalization.
An association is what the UML calls a structural relationship, mapping one object to another set of objects (see Figure 3.17). It is also used to identify the communication path between an actor and a use case. The Unified Modeling Language Reference Manual describes associations as "the glue that ties systems together" (Jacobson, Booch, and Rumbaugh 1998b, 47). In the UML, an association has a navigational sense to it as well (you can get there from here, from one object to another), which can cause heartburn among some object methodology purists.
){kind=link}
Figure 3.17 Association.
A realization is a type of dependency relationship that identifies a contractual link between elements—a realizing element. For example, a class implements the behaviors in a specifying element; in this case, it is an interface (see Figure 3.18). A realization also links use cases and collaborations. (See Section 3.5.4, "Relationships: Some Uses of Dependency.")
){kind=link}
Figure 3.18 Realization.
3.5.3 Relationships: Some Types of Associations
The UML considers aggregations and composites to be special forms of association with distinctive notations. Needless to say, the semantics of aggregates and composites is subject to much debate.
A qualified association is a plain association with an indication of what information to use when identifying a target object in the set of associated objects. In Figure 3.19, bank account # is used to identify the customer it belongs to.
){kind=link}
Figure 3.19 Qualified association.
An aggregation represents a whole-part relationship. This contrasts with a plain association, which shows a relationship among/between peers, depending on the number (see Figure 3.20). In an aggregation, one element is the whole and the other(s) are the parts.
){kind=link}
Figure 3.20 Aggregation.
A composition is an aggregation that has strong ownership of its parts. Therefore, if the whole element disappears, the parts do, too (see Figure 3.21).
){kind=link}
Figure 3.21 Composition.
3.5.4 Relationships: Some Uses of Dependency
Dependency relationships are frequently stereotyped in the UML to support the needs of particular types of diagrams or model elements. The following are some examples:
Extends provides a way of handling behavior that is optional in a use case (see Figure 3.22). The optional behavior is packaged in an extending use case and connected via an <<extends>> dependency.
){kind=link}
Figure 3.22 Extends dependency.
Includes provides a way of handling behavior that is common to a number of use cases (see Figure 3.23). The optional behavior is factored out, packaged in an included use case, and connected via an <<includes>> dependency.
){kind=link}
Figure 3.23 Includes dependency.
Imports is a dependency between packages (see Figure 3.24). A receiving package can access the publicly visible elements of the package being imported.
){kind=link}
Figure 3.24 Imports dependency.
3.5.5 Abstraction: Other Uses of Dependency
The UML includes a variety of explicit expressions of abstraction:
Refinement indicates a dependency between two elements at different levels of abstraction (see Figure 3.25). An example of this is related elements in different types of models, such as an analysis model and a design model, which are very important in D'Souza and Wills' book, but are hardly mentioned in the RUP.
){kind=link}
Figure 3.25 Refinement.
Realization was introduced earlier as a full-blown significant relationship meriting its own line symbol. It can also be indicated by using a stereotype (see Figure 3.26). The UML Specification says, "Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, and so on" (Rational Software Corporation 1999).
){kind=link}
Figure 3.26 Realization.
Derivation indicates that an instance of an element (the derived element) can be computed from the other element in the relationship (see Figure 3.27).
){kind=link}
Figure 3.27 Derivation
A trace relationship shows connections between model elements or sets of model elements representing the same concept in different models (see Figure 3.28). Traces are mainly used for tracking requirements and changes across models.
){kind=link}
Figure 3.28 Trace.