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

Terms and Concepts

An interaction is a behavior that comprises a set of messages exchanged among objects in a set of roles within a context to accomplish a purpose. A message is a specification of a communication between objects that conveys information with the expectation that activity will ensue.

Context

You may find an interaction wherever objects are linked to one another. You'll find interactions in the collaboration of objects that exist in the context of your system or subsystem. You will also find interactions in the context of an operation. Finally, you'll find interactions in the context of a class.

Most often, you'll find interactions in the collaboration of objects that exist in the context of your system or subsystem as a whole. For example, in a system for Web commerce, you'll find objects on the client (such as instances of the classes BookOrder and OrderForm) interacting with one another. You'll also find objects on the client (again, such as instances of BookOrder) interacting with objects on the server (such as instances of BackOrderManager). These interactions therefore not only involve localized collaborations of objects (such as the interactions surrounding OrderForm), but they may also cut across many conceptual levels of your system (such as the interactions surrounding BackOrderManager).

You'll also find interactions among objects in the implementation of an operation. The parameters of an operation, any variables local to the operation, and any objects global to the operation (but still visible to the operation) may interact with one another to carry out the algorithm of that operation's implementation. For example, the operation moveToPosition(p : Position) defined for a class in a mobile robot will involve the interaction of a parameter (p), an object global to the operation (such as the object currentPosition), and possibly several local objects (such as local variables used by the operation to calculate intermediate points in a path to the new position).

Finally, you will find interactions in the context of a class. You can use interactions to visualize, specify, construct, and document the semantics of a class. For example, to understand the meaning of a class RayTraceAgent, you might create interactions that show how the attributes of that class collaborate with one another (and with objects global to instances of the class and with parameters defined in the class's operations).

Note

An interaction may also be found in the representation of a component, node, or use case, each of which is really a kind of UML classifier. In the context of a use case, an interaction represents a scenario that, in turn, represents one thread through the action of the use case.

Objects and Roles

The objects that participate in an interaction are either concrete things or prototypical things. As a concrete thing, an object represents something in the real world. For example, p, an instance of the class Person, might denote a particular human. Alternately, as a prototypical thing, p might represent any instance of Person.

Note

In a collaboration, the interactors are usually prototypical things that play particular roles, not specific objects in the real world, although it is sometimes useful to describe collaborations among particular objects.

In the context of an interaction, you may find instances of classes, components, nodes, and use cases. Although abstract classes and interfaces, by definition, may not have any direct instances, you may represent instances of these things in an interaction. Such instances do not represent direct instances of the abstract class or of the interface, but may represent, respectively, indirect (or prototypical) instances of any concrete children of the abstract class of some concrete class that realizes that interface.

You can think of an object diagram as a representation of the static aspect of an interaction, setting the stage for the interaction by specifying all the objects that work together. An interaction goes further by introducing a dynamic sequence of messages that may pass along the links that connect these objects.

Links and Connectors

A link is a semantic connection among objects. In general, a link is an instance of an association. As Figure 16-2 shows, wherever a class has an association to another class, there may be a link between the instances of the two classes; wherever there is a link between two objects, one object can send a message to the other object.

Associations are discussed in Chapters 5 and 10; connectors and roles are discussed in Chapter 15 .role; a prototypical link is called a

connector ; the context is a collaboration or the internal structure of a classifier. The multiplicity of roles and connectors are defined relative to their enclosing context. For example, a multiplicity of 1 on a role means one object represents the role for each object that represents the context. A collaboration or internal structure can be used many times, just like a class declaration; each use is bound to a separate set of objects and links for the context, roles, and links.

Figure 16-2 shows an example. The top of the figure shows a class diagram that declares classes Person and Company and the many-to-many employee-employer association between them. The middle shows the contents of a collaboration WorkAssignment that assigns an employee to a job. It has two roles and a connector between them. The bottom shows an instance of this collaboration, in which there are objects and links bound to the roles and connectors. A concrete message in the bottom represents the prototypical message declaration in the collaboration.

Messages

Suppose you have a set of objects and a set of links that connect those objects. If that's all you have, then you have a completely static model that can be represented by an object diagram. Object diagrams model the state of a society of objects at a given moment in time and are useful when you want to visualize, specify, construct, or document a static object structure.

Suppose you want to model the changing state of a society of objects over a period of time. Think of it as taking a motion picture of a set of objects, each frame representing a successive moment in time. If these objects are not totally idle, you'll see objects passing messages to other objects, sending events, and invoking operations. In addition, at each frame you can explicitly visualize the current state and role of individual instances.

Operations are discussed in Chapters 4 and 9; events are discussed in Chapter 21; instances are discussed in Chapter 13 .occurrence is the UML name for an instance of an event.)

When you pass a message, an action usually results on its receipt. An action may result in a change in state of the target object and objects accessible from it.

In the UML, you can model several kinds of messages.

Note

You can model complex actions in the UML as well. In addition to the five basic kinds of messages listed above, you can include actions on individual objects. The UML does not specify the syntax or semantics of such actions; it is expected that tools will supply various actions languages or use the syntax of programming languages.

The UML provides a visual distinction among these kinds of messages, as Figure 16-3 shows.

The most common kind of message you'll model is the call, in which one object invokes an operation of another (or the same) object. An object can't just call any random operation. If an object, such as c in the example above, calls the operation setItinerary on an instance of the class TicketAgent, the operation setItinerary must not only be defined for the class TicketAgent (that is, it must be declared in the class TicketAgent or one of its parents), it must also be visible to the caller c.

Note

Languages such as C++ are statically typed (although polymorphic), meaning that the legality of a call is checked at compilation time. Languages such as Smalltalk, however, are dynamically typed, meaning that you can't determine if an object can properly receive a message until execution time. In the UML, a well-formed model can in general be checked statically by a tool because, at modeling time, the developer typically knows the intent of the operation.

When an object calls an operation or sends a signal to another object, you can provide actual parameters to the message. Similarly, when an object returns control to another object, you can model the return value as well.

Messages can also correspond to the sending of signals. A signal is an object value communicated to a target object asynchronously. After sending a signal, the sending object continues its own execution. When the target object receives the signal message, it independently decides what to do about it. Usually signals trigger transitions in the state machine of the target object. Firing a transition causes the target object to execute actions and change to a new state. In an asynchronous message-passing system, communicating objects execute concurrently and independently. They share values only by passing messages, so there is no danger of conflict over shared memory.

Note

You can also qualify an operation by the class or interface in which it is declared. For example, invoking the operation register upon an instance of Student would polymorphically invoke whatever operation matches that name in the Student class hierarchy; invoking IMember::register would invoke the operation specified in the interface IMember (and realized by some suitable class, also in the Student class hierarchy).

Sequencing

When an object passes a message to another object (in effect, delegating some action to the receiver), the receiving object might in turn send a message to another object, which might send a message to yet a different object, and so on. This stream of messages forms a sequence. Any sequence must have a beginning; the start of every sequence is rooted in some process or thread. Furthermore, any sequence will continue as long as the process or thread that owns it lives. A nonstop system, such as you might find in real time device control, will continue to execute as long as the node it runs on is up.

Each process and thread within a system defines a distinct flow of control, and within each flow, messages are ordered in sequence by time. To better visualize the sequence of a message, you can explicitly model the order of the message relative to the start of the sequence by prefixing the message with a sequence number set apart by a colon separator.

A communication diagram shows message flow between roles within a collaboration. Messages flow along connections of the collaboration, as in Figure 16-4.

Most commonly, you can specify a procedural or nested flow of control, rendered using a filled solid arrowhead, as Figure 16-4 shows. In this case, the message findAt is specified as the first message nested in the second message of the sequence (2.1).

Less common but also possible, as Figure 16-5 shows, you can specify a flat flow of control, rendered using a stick arrowhead, to model the nonprocedural progression of control from step to step. In this case, the message assertCall is specified as the second message in the sequence.

Note

The distinction between asynchronous and procedural sequences is important in the modern concurrent computing world. To show the overall behavior of a system of concurrent objects, use asynchronous message passing. This is the most general case. When the calling object is able to make a request and wait for a respond, you can use procedural flow of control. Procedural flow of control is familiar from traditional programming languages, but keep in mind that a series of nested procedure calls results in a stack of blocked objects that are temporarily unable to do anything, so it is not very useful if they represent servers or shared resources.

When you are modeling interactions that involve multiple flows of control, it's especially important to identify the process or thread that sent a particular message. In the UML, you can distinguish one flow of control from another by prefixing a message's sequence number with the name of the process or thread that sits at the root of the sequence. For example, the expression

D5 : ejectHatch(3)

specifies that the operation ejectHatch is dispatched (with the actual argument 3) as the fifth message in the sequence rooted by the process or thread named D.

Not only can you show the actual arguments sent along with an operation or a signal in the context of an interaction, you can show the return values of a function as well. As the following expression shows, the value p is returned from the operation find, dispatched with the actual parameter "Rachelle". This is a nested sequence, dispatched as the second message nested in the third message nested in the first message of the sequence. In the same diagram, p can then be used as an actual parameter in subsequent messages.

1.3.2 : p := find("Rachelle")

Note

In the UML, you can also model more-complex forms of sequencing, such as iteration, branching, and guarded messages. In addition, to model timing constraints such as you might find in real time systems, you can associate timing marks with a sequence. Other, more exotic forms of messaging, such as balking and time out, can be modeled by defining an appropriate message stereotype.

Creation, Modification, and Destruction

Most of the time the objects you show participating in an interaction exist for the entire duration of the interaction. However, in some interactions objects may be created (specified by a create message) and destroyed (specified by a destroy message). The same is true of links: The relationships among objects may come and go. To specify if an object or link enters and/or leaves during an interaction, you can attach a note to its role within a communication diagram.

During an interaction, an object typically changes the values of its attributes, its state, or its roles. You can represent the modification of an object in a sequence diagram by showing the state or the values on the lifeline.

Within a sequence diagram, the lifetime, creation, and destruction of objects or roles are explicitly shown by the vertical extent of their lifelines. Within a communication diagram, creation and destruction must be indicated using notes. Use sequence diagrams if object lifetimes are important to show.

Representation

When you model an interaction, you typically include both roles (each one representing objects that appear in an instance of the interaction) and messages (each one representing the communication between objects, with some resulting action).

You can visualize those roles and messages involved in an interaction in two ways: by emphasizing the time ordering of its messages, and by emphasizing the structural organization of the roles that send and receive messages. In the UML, the first kind of representation is called a sequence diagram; the second kind of representation is called a communication diagram. Both sequence diagrams and communication diagrams are kinds of interaction diagrams. (UML also has a more specialized kind of interaction diagram called a

timing diagram , which shows the exact times at which messages are exchanged by roles. This diagram is not covered in this book. See the

UML Reference Manual for more information.)

Interaction diagrams are discussed in Chapter 19 .