Common Modeling Techniques

Modeling Simple Collaborations

No class stands alone. Rather, each works in collaboration with others to carry out some
semantics greater than each individual. Therefore, in addition to capturing the vocabulary of
your system, you'll also need to turn your attention to visualizing, specifying, constructing,
and documenting the various ways these things in your vocabulary work together. You use
class diagrams to represent such collaborations.

To model a collaboration,

 Identify the mechanism you'd like to model. A mechanism represents some function
or behavior of the part of the system you are modeling that results from the
interaction of a society of classes, interfaces, and other things.
 For each mechanism, identify the classes, interfaces, and other collaborations that
participate in this collaboration. Identify the relationships among these things as
well.
 Use scenarios to walk through these things. Along the way, you'll discover parts of
your model that were missing and parts that were just plain semantically wrong.
 Be sure to populate these elements with their contents. For classes, start with
getting a good balance of responsibilities. Then, over time, turn these into concrete
attributes and operations.
 For example, Figure 8-2 shows a set of classes drawn from the implementation of an
autonomous robot. The figure focuses on the classes involved in the mechanism for
moving the robot along a path. You'll find one abstract class (Motor) with two concrete
children, SteeringMotor and MainMotor. Both of these classes inherit the five operations of
their parent, Motor. The two classes are, in turn, shown as parts of another
class, Driver. The class PathAgent has a one-to-one association to Driver and a one-to-
many association to CollisionSensor. No attributes or operations are shown for PathAgent,
although its responsibilities are given.
  Figure 8-2. Modeling Simple Collaborations




 There are many more classes involved in this system, but this diagram focuses only
on those abstractions that are directly involved in moving the robot. You'll see some
of these same classes in other diagrams. For example, although not shown here, the
class PathAgent collaborates with at least two other classes (Environment and GoalAgent) in a
higher-level mechanism for managing the conflicting goals the robot might have at a
given moment. Similarly, also not shown here, the
classes CollisionSensor and Driver(and its parts) collaborate with another class
(FaultAgent) in a mechanism responsible for continuously checking the robot's
hardware for errors. By focusing on each of these collaborations in different
diagrams, you provide an understandable view of the system from several angles.

Interaction Diagrams
Sequence diagrams and communication diagrams which are collectively called interaction
diagrams are two of the diagrams used in the UML for modeling the dynamic aspects of
systems. An interaction diagram shows an interaction, consisting of a set of objects and
their relationships, including the messages that may be dispatched among them. A
sequence diagram is an interaction diagram that emphasizes the time ordering of
messages; a communication diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive messages.
You use interaction diagrams to model the dynamic aspects of a system. For the most part,
this involves modeling concrete or prototypical instances of classes, interfaces, components,
and nodes, along with the messages that are dispatched among them, all in the context of a
scenario that illustrates a behavior. Interaction diagrams may stand alone to visualize,
specify, construct, and document the dynamics of a particular society of objects, or they
may be used to model one particular flow of control of a use case.

Interaction diagrams are not only important for modeling the dynamic aspects of a system,
but also for constructing executable systems through forward and reverse engineering.

Terms and Concepts

An interaction diagram shows an interaction, consisting of a set of objects and their
relationships, including the messages that may be dispatched among them. A sequence
diagram is an interaction diagram that emphasizes the time ordering of messages.
Graphically, a sequence diagram is a table that shows objects arranged along the X axis and
messages, ordered in increasing time, along the Y axis. A communication diagram is an
interaction diagram that emphasizes the structural organization of the objects that send and
receive messages. Graphically, a communication diagram is a collection of vertices and arcs.

Common Properties

An interaction diagram is just a special kind of diagram and shares the same common
properties as do all other diagramsa name and graphical contents that are a projection into
a model. What distinguishes an interaction diagram from all other kinds of diagrams is its
particular content.

Interaction diagrams commonly contain

 Roles or objects
 Communications or links
 Messages

Note

An interaction diagram is basically a projection of the elements found in an interaction. The

semantics of an interaction's context, objects and roles, links and connectors, messages,
and sequencing apply to interaction diagrams.

Like all other diagrams, interaction diagrams may contain notes and constraints.

Sequence Diagrams
A sequence diagram emphasizes the time ordering of messages. As Figure 19-2 shows, you
form a sequence diagram by first placing the objects or roles that participate in the
interaction at the top of your diagram, across the horizontal axis. Typically, you place the
object or role that initiates the interaction at the left, and increasingly more subordinate
objects or roles to the right. Next, you arrange the messages that these objects send and
receive along the vertical axis in order of increasing time from top to bottom. This gives the
reader a clear visual cue to the flow of control over time.

Figure 19-2. Sequence Diagram

Sequence diagrams have two features that distinguish them from communication diagrams.
First, there is the lifeline. An object lifeline is the vertical dashed line that represents the
existence of an object over a period of time. Most objects that appear in an interaction
diagram will be in existence for the duration of the interaction, so these objects are all
aligned at the top of the diagram, with their lifelines drawn from the top of the diagram to
the bottom. Objects may be created during the interaction. Their lifelines start with the
receipt of the message create (drawn to box at the head of the lifeline). Objects may be
destroyed during the interaction. Their lifelines end with the receipt of the
message destroy (and are given the visual cue of a large X, marking the end of their lives).

If the interaction represents the history of specific, individual objects, then object symbols
with underlined names are placed at the head of the lifelines. Most of the time, however,
you will be showing prototypical interactions. The lifelines do not represent specific objects;
they represent prototypical roles that represent different objects in each instance of the
interaction. In that normal case, you do not underline the names, as they are not specific
objects.

Note
If an object changes the values of its attributes, its state, or its roles, you can place a state
icon on its lifeline at the point that the change occurs, showing those modifications.

Second, there is the focus of control. The focus of control is a tall, thin rectangle that shows
the period of time during which an object is performing an action, either directly or through
a subordinate procedure. The top of the rectangle is aligned with the start of the action; the
bottom is aligned with its completion (and can be marked by a return message). You can
show the nesting of a focus of control (caused by recursion, a call to a self-operation, or by
a callback from another object) by stacking another focus of control slightly to the right of
its parent (and can do so to an arbitrary depth). If you want to be especially precise about
where the focus of control lies, you can also shade the region of the rectangle during which
the object's method is actually computing and control has not passed to another object, but
this is rather fussy.

The main content in a sequence diagram is the messages. A message is shown by an arrow
from one lifeline to another. The arrowhead points to the receiver. If the message is
asynchronous, the line has a stick arrowhead. If the message is synchronous (a call), the
line has a filled triangular arrowhead. A reply to a synchronous message (a return from a
call) is shown by a dashed arrow with a stick arrowhead. The return message may be
omitted, as there is an implicit return after any call, but it is often useful for showing return
values.

The ordering of time along a single lifeline is significant. Usually the exact distance does not
matter; lifelines only show relative sequences, so the lifeline is not a scale diagram of time.
Usually the positions of messages on separate pairs of lifelines do not imply any sequencing
information; the messages could occur in any order. The entire set of messages on separate
lifelines forms a partial ordering. A series of messages establishes a chain of causality,
however, so that any point on another lifeline at the end of the chain must always follow the
point on the original lifeline at the start of the chain.

Structured Control in Sequence Diagrams

A sequence of messages is fine for showing a single, linear sequence, but often we need to
show conditionals and loops. Sometimes we want to show concurrent execution of multiple
sequences. This kind of high-level control can be shown using structured control operators
in sequence diagrams.

A control operator is shown as a rectangular region within the sequence diagram. It has a
taga text label inside a small pentagon in the upper left cornerto tell what kind of a control
operator it is. The operator applies to the lifelines that cross it. This is considered the body
of the operator. If a lifeline does not apply to the operator, it may be interrupted at the top
of the control operator and resumed at the bottom. The following kinds of control are the
most common:
Optional execution

The tag is opt. The body of the control operator is executed if a guard condition is true when
the operator is entered. The guard condition is a Boolean expression that may appear in
square brackets at the top of any one lifeline within the body and may reference attributes
of that object.

Conditional execution

The tag is alt. The body of the control operator is divided into multiple subregions by
horizontal dashed lines. Each subregion represents one branch of a conditional. Each
subregion has a guard condition. If the guard condition for a subregion is true, the
subregion is executed. However, at most one subregion may be executed; if more than one
guard condition is true, the choice of subregion is nondeterministic and could vary from
execution to execution. If no guard condition is true, then control continues past the control
operator. One subregion may have a the special guard condition [else]; this subregion is
executed if none of the other guard conditions are true.

Parallel execution

The tag is par. The body of the control operator is divided into multiple subregions by
horizontal dashed lines. Each subregion represents a parallel (concurrent) computation. In
most cases, each subregion involves different lifelines. When the control operator is
entered, all of the subregions execute concurrently. The execution of the messages in each
subregion is sequential, but the relative order of messages in parallel subregions is
completely arbitrary. This construct should not be used if the different computations
interact. There are very many real-world situations that decompose into independent,
parallel activities, however, so this is a very useful operator.

Loop (iterative) execution

The tag is loop. A guard condition appears at the top of one lifeline within the body. The
body of the loop is executed repeatedly as long as the guard condition is true before each
iteration. When the guard condition is false at the top of the body, control passes out of the
control operator.

There are many other kinds of operators, but these are the most useful.

To provide a clear indication of the boundary, a sequence diagram may be enclosed in a

rectangle, with a tag in the upper left corner. The tag is sd, which may be followed by the
name of the diagram.

Figure 19-3 shows a simplified example that illustrates some control operators. The user
initiates the sequence. The first operator is a loop operator. The numbers in parentheses
(1,3) indicate the minimum and maximum number of times the loop body must be
executed. Since the minimum is one, the body is always executed at least once before the
condition is tested. In the loop, the user enters the password and the system verifies it. The
loop continues as long as the password is incorrect. However, after three tries, the loop
terminates in any case.
 Figure 19-3. Structured Control Operators

The next operator is an optional operator. The optional body is executed if the password is
valid; otherwise the rest of the sequence diagram is skipped. The optional body contains a
parallel operator. Operators can be nested as shown.

The parallel operator has two subregions: one allows the user to enter an account and the
other allows the user to enter an amount. Because they are parallel, there is no required
order for making the two entries; they can occur in either order. This emphasizes that
concurrency does not always imply physically simultaneous execution. Concurrency really
means that two actions are uncoordinated and can happen in any order. If they are truly
independent actions, they can overlap; if they are sequential actions, they can occur in any
order.

Once both actions have been performed, the parallel operator is complete. In the next
action within the optional operator, the bank delivers cash to the user. The sequence
diagram is now complete.
Nested Activity Diagrams

Activity diagrams that are too large can be difficult to understand. Structured sections of an
activity can be organized into a subordinate activity, especially if the subordinate activity is
used more than once within the main activity. The main activity and the subordinate
activities are shown on separate diagrams. Within the main activity diagram, a use of a
subordinate activity is shown by a rectangle with the tag ref in its upper left corner; the
name of the subordinate behavior is shown in the box. The subordinate behavior is not
restricted to an activity diagram; it could also be a state machine, sequence diagram, or
other behavioral specification. Figure 19-4 shows the diagram from Figure 19-3 rearranged
by moving two sections into separate activity diagrams and referencing them from the main
diagram.

Figure 19-4. Nested activity diagram

Communication Diagrams

A communication diagram emphasizes the organization of the objects that participate in an

interaction. As Figure 19-5 shows, you form a communication diagram by first placing the
objects that participate in the interaction as the vertices in a graph. Next, you render the
links that connect these objects as the arcs of this graph. The links may have rolenames to
identify them. Finally, you adorn these links with the messages that objects send and
receive. This gives the reader a clear visual cue to the flow of control in the context of the
structural organization of objects that collaborate.

Figure 19-5. Communication Diagram

Note

Unlike a sequence diagram, you don't show the lifeline of an object explicitly in a
communication diagram, although you can show both create and destroy messages. In
addition, you don't show the focus of control explicitly in a communication diagram,
although the sequence number on each message can indicate nesting.

Communication diagrams have two features that distinguish them from sequence diagrams.
First, there is the path. You render a path corresponding to an association. You also render
paths corresponding to local variables, parameters, global variables, and self access. A path
represents a source of knowledge to an object.

Second, there is the sequence number. To indicate the time order of a message, you prefix
the message with a number (starting with the message numbered 1), increasing
monotonically for each new message in the flow of control (2, 3, and so on). To show
nesting, you use Dewey decimal numbering (1 is the first message, which contains
message 1.1 and message 1.2, and so on). You can show nesting to an arbitrary depth. Note
also that, along the same link, you can show many messages (possibly being sent from
different directions), and each will have a unique sequence number.