Early in analysis, the objects available for scenarios are the system and the external objects identified in the context and use case diagrams. Later analysis decomposes the system into objects, and the scenario process can be applied to them as well. Ultimately, internal scenarios must map to the identified use cases. In fact, the objects identified decompose into multiple objects, and the messages are decomposed into protocols consisting of many messages. Just as iterative refinement of the object model identifies more classes, refinement of the scenarios adds more detail to the interactions.
It is important to stress that building and analyzing scenarios is a creative process of discovery. It is not simply a matter of starting with postulates and applying mathematical deduction to derive all possible behavior paths. Deep within the crevices of the domain experts’ minds are hidden requirements that, if left to their own devices, will never be explicitly identified. These cannot be deduced from the problem statement per se. The process of scenario modeling brings these hidden requirements to the surface where they can be added to the system features.
Two primary scenario models exist: Sequence and collaboration diagrams. The first is the most commonly used and emphasizes messages and their sequence. The second is also popular and tends to stress the system object structure. Both diagrams show scenarios but differ in what they emphasize. Although most people tend to stick to one or the other, some people find it useful to use sequence diagrams early and switch to collaboration diagrams once the object and class structure has stabilized.
2.4.1 Sequence Diagrams
Sequence diagrams show the sequence of messages between objects. The graphical syntax for sequence diagrams is shown in Figure 12. This figure shows all the elements used in most sequence diagrams. The vertical lines represent objects, with the name of the object written above or below the line. The horizontal directed lines are messages. Each message line starts at the originator object and ends at the target object and has a message name on the line. This name might, in later phases, specify an operation with a parameter list and a return value. Time flows from the top of the page downwards so that "Request UP Elevator" is sent before "Button Backlight," and so on. The time axis shows only sequence; the scale is not linear nor is a scale provided.
Note the textual annotation along the left side of the diagram. This descriptive text identifies initial conditions, actions, and activities not shown by the message sequence itself. Some of the messages are internal to the object, that is, with the same originator and target object. This means that the message is sent internally from one method to another within the same object. It is not strictly necessary to identify such messages, but it can be illuminating to do so. For example, the internal message "Door times out and closes" helps to set off the preceding "Door opens" (on floor 8) and the subsequent "Door opens" (on floor 2) messages.
Most sequence diagrams contain only the elements identified in Figure 12: objects, messages, (implicit) inactive periods, and scenario annotations. Sequence diagrams can contain a great deal more information when necessary, however. The full graphical syntax of message diagrams is shown in Figure 13.
The additional features shown in this figure are:
Timing marks are indicated in two different fashions. The first is to use a marker bar with a time value between the two ends. This kind of time mark is shown between events "a" and "b." It defines the time between the two events as 500 ms in this example. Relational expressions can also indicate timing constraints. These are off to the one side of the relevant messages and are delineated by curly braces. Event IDs are used in time expressions, as in
{ d - e <= 5 seconds }
which means simply that the time between events "e" and "d" must be less than or equal to 5 seconds.
Timing mark expressions need not be only for adjacent events. Imagine two constraints:
{ e - a < 10 seconds
d - c <= 500 ms }
Thus, it is possible to provide multiple timing constraints within the same timing mark. It is even possible to provide more elaborate constraints. Suppose a series of 6 messages reoccurs every 30 seconds, and the series of 6 has a hard constraint of 5 seconds, with an average time constraint of 3 seconds. This can be indicated as shown in Figure 14.
UML does not define the language used to specify constraints, so we are free here to add constraint notations as the need arises. The period is shown is two ways on the figure, although normally only one would be used at a time. An enclosing rectangle encapsulates the periodic message sequence. The sequence begins with an initial event id of "a" and the last event id of "b". The notation
ab = 30 seconds
means the period of the sequence begun by "a" and ended with "b" is 30 seconds long. An alternative is to use the expression
{ a’ - a = 30 seconds }
which says exactly the same thing. If preferred, the expression can just be written out as
{ PERIOD(ab) = 30 seconds }
The hard time constraint of 5 seconds between events "b" and "a’ is denoted by the expression
{ b - a <= 5 seconds }
The soft constraint that the average time must be less than or equal to 3 seconds uses the AVE operator to indicate "average":
{ AVE(b-a) <= 3 seconds }
Note that it is perfectly permissible to have multiple constraints on the same events, but they must be mutually consistent.
The vast majority of sequence diagram messages are peer-to-peer. That is, one object transmits a specific message and one object receives it. Broadcast messages are messages that are sent by a single object but received by more than one. Broadcast messages imply concurrency (otherwise multiple messages would have to be sent). They apply to both uniprocessor systems running multiple threads of execution and multiprocessor systems. Events must often be sent to multiple threads within a single processor. This is common when a resource becomes available. RTOSes support this using event queues. Multidrop buses are common in multiprocessor systems. These are buses that multiple devices use to communicate among themselves. Such systems usually have some messaging to which all devices must listen.
Broadcast messages originate from the source object at the same point in time, but arrive at different objects at potentially different times. Arrows terminate on all objects that receive the message. Even though the messages are broadcast, not all objects in the scenario must receive the message. The terminating arrows indicate those objects that receive the message.
State marks are an extension to core UML that bridge the gap between sequence and state diagrams. State marks are rounded rectangles (the standard UML notation for a state on a state diagram) placed on the vertical object line. This allows the scenario to follow the state as it changes due to incoming events. The sequence diagram in Figure 15 illustrates the use of state marks. States and statecharts are discussed in detail in Chapter 4.
More specialized forms of sequence diagrams show detailed focus of control. These are discussed later in the chapters on design.
2.4.2 Collaboration diagrams
The other popular technique for showing scenarios is the collaboration diagram. Collaboration diagrams show the same basic information as the sequence diagrams. The difference is that sequence diagrams focus on the sequence of messages while collaboration diagrams focus on the static structure of the collaborating objects. A simple collaboration diagram is shown in Figure 16.
This figure shows exactly the same scenario as in the sequence diagram of Figure 12. The object structure is clearer than in the sequence diagram, but finding the sequence can require some hunting. Some CASE tools support collaboration diagrams, but not all provide automatic message numbering. Thus, if the analyst adds a missing message, he must manually renumber all subsequent messages in the diagram. The other downside of collaboration diagrams is that if the structure of collaboration changes, they require more work to maintain than sequence diagrams. Nevertheless, they are valuable in their depicting of the structure of collaboration and map directly to the class diagram.
The components of collaboration diagrams are:
Figure 17 shows the basic form of a collaboration diagram with these basic elements.
The object names identify which objects are participating, while the association links show which objects collaborate. An association link between two objects must exist for one object to send a message to another. The messages themselves are named with message identifiers. A sequence number precedes the identifier to define the flow of messages in the scenario, just as in sequence diagrams. Broadcast messages use the same source, message name and sequence number. Finally, the direction of the message defines the sender and the receiver of the message.
Collaboration diagrams support a much richer syntax than this minimum set, and can support the wider range of semantics shown in Figure 18. The syntactic elements include
In multithreaded scenarios, the delivery of some set of messages may
form a precondition for a specific message to be sent. Such a precondition
is a kind of guard and is enclosed within square brackets that precede
the message name. The precondition is specified as a comma-separated list
of message sequence numbers that must refer to messages appearing elsewhere
in the diagram. The precondition list clarifies the thread synchronization
requirements in the presence of multiple threads.
2.4.2.2 Role names
A role name identifies the participatory role an object plays in an association. Role names are optional but should be included when they clarify the association. It is rarely necessary to name both roles because one role is the conjugate of the other. For example, if one role is "Owns," the other is necessarily something like "Owned by." An object may have more than one association, including multiple associations with the same object. Just remember that each association has an impact on implementation. For sequential messages with the «call» stereotype, these associations will be implemented using pointers or references. CASE tools that automatically generate executable code from object models (as opposed to code frames) may use the role name as the names of pointers or references in the generated code and will provide default role names when they are omitted.
Roles may have implementation stereotypes. UML defines the following implementation stereotypes for roles:
Table 4: Role Implementation Stereotypes
| Stereotype | Description |
| «association» | Redundant, as this is the default. |
| «parameter» | Procedural parameter |
| «local» | Local variable |
| «global» | Global variable |
| «self» | Link to the same instance (object can send itself a message) |
The iteration expression defines a set of similar messages sent along the link. They are denoted by the preceding asterisk and the parenthesis around the expression. Iteration variables may be included if desired. For example, the following two iteration expressions are equivalent:
*(j=1..n)
*(1..n)
The asterisk alone specifies an unknown number of iterations.
Since iterated messages are part of the same message flow, they must
all have the same message stereotype.
2.4.2.4 Parameter lists and return values
Later in design, the object behaviors evolve into defined operations with parameters and return values. The collaboration diagram can model these details. The return value may be indicated either by following the parameter list with a colon and the return value, or with an assignment statement using the ":=" operator. For example
DoIt(a,b,c): status
status := DoIt(a,b,c)
The analyst may use his discretion as to which form is preferred.
2.4.2.5 Guard
A guard is a Boolean condition which must evaluate to TRUE before the message can be sent. It provides a simple way of showing conditional message transmission on a single scenario. The UML does not specify the precise language for guard expressions, so you are free to use source code, structured English, or mathematical expressions in your Guard expressions. For example
DoIt[x>0]
DoItAgain[isOk( )]
are messages with guards.
2.4.2.6 Message Stereotype
Earlier in this chapter, we defined a number of message stereotypes
that defined the arrival and synchronization patterns for the messages.
This stereotype may be included in the standard guillemet form preceding
the message identifier or may be indicated using an iconic message arrow.
The two forms are equivalent as a matter of individual preference.
2.4.2.7 Thread sequence numbers
Sequence numbers identify the order in which messages occur in the scenario. Simple scalar sequence numbers indicate sequence when only a single thread is active. In concurrent object systems, the order of events between synchronization points is not known. In concurrent models, the sequence number may be preceded by a thread indicator. This is normally a letter to distinguish it from message sequence numbers, but can be a thread name. Within a given thread, the normal sequence number rules apply.
Including a preconditional guard expression explicitly shows the synchronization dependencies among threads. For example, the message
[B6, A3]C13: DoIt[x + y < z]
has a thread ID of "C" and a sequence number within that thread of 13.
It must be preceded by message instances B6 (thread B, message instance
6) and A3 (thread A, message instance 3) and the guard expression "x+y<z"
must evaluate to TRUE. Preconditions are only needed in the case of concurrent
object models.
2.4.3 Concurrent Collaboration Diagrams
Active objects are often implemented as composites whose components inherit their owner’s thread. Elaborate multithreaded collaborations can be easily shown on UML collaboration diagrams using composites and thread-specific messages.
The scenario shown in Figure 19 depicts the execution of a robot assembly system containing a Console Controller, Robot Worker, and Robot Stand. The Master Task Plan object downloads relevant portions of the plan to the active composites Robot Worker 1 and Robot Stand. These objects proceed independently using threads A and B, respectively. The Robot Stand passes a command to the Arm object to grab the work item. The Arm is itself decomposed into 4 objects: Controller, Joint 1, Joint 2, and the Manipulator. The command to grab the work item results in multiple messages, one to each of the other objects within the arm. After the Stand grabs the work item, it orders the Moving Work Surface to move to Station 1 so that Robot Worker 1 can perform its task. Once completed, the Stand sends a message to the Robot Arm that the work item is ready (B10).
The Robot Worker 1 meanwhile has not been idle. Working within Thread A, it has grabbed the appropriate tool by moving its joints and grabbing the tool. However, prior to positioning or energizing the tool, it waits for the tool to be in position. That is why message A8 depends on B10.
Use cases capture the information about the system’s environment in a different way. Use cases are a functional decomposition of the system’s systemic behavior without regard to the system’s internal structure. Use cases emphasize the behavior of the system rather than the incoming and outgoing events.
Use cases group together functionally related scenarios. Scenarios, in turn, group functionally related messages together into a protocol as they pass among objects. The complete set of interesting scenarios define the external behavior of the system. Scenarios are modeled using sequence and collaboration diagrams.
The information gathered during the construction of both these diagrams is required before any object decomposition of the system can occur. The characterization of the external events and the integration of these events into the system use cases complete the external view of the system.
The next two chapters will "drill down" into the systems and define objects, classes, and their relationships. Chapter 3 provides a number of different strategies for the identification of objects and classes, while Chapter 4 focuses on the specification of object behavior using state machines and operations.
[2] Software Design Methods for Concurrent and Real-Time Systems by Hassan Gomaa, Addison-Wesley Press, 1993
[3] Structured Development for Real-Time Systems by Ward and Mellor, Volumes 1-4, Prentice Hall Press, 1985.
[4] Objectifying Real-Time Systems by John Ellis, SIGS Books, 1994.
[5] Object-Oriented Analysis and Design with Applications by Grady Booch, Benjamin Cummings Press, 1994
[6] Object Solutions: Managing the Object-Oriented Project by Grady Booch, Addison-Wesley, 1996