Corporate and Professional Publishing Group
You can also access:
Book Description,
Table of
Contents, Preface,
Chapter 1,
Chapter 3,
Cover (158K), Inside
Covers,
Ordering
Information, C&P Welcome Page.
Typically, an interaction diagram captures the behavior of a single use case. The diagram shows a number of example objects and the messages that are passed between these objects within the use case.
I'll illustrate the approach with a simple use case that exhibits the following behavior.
Each message is represented by an arrow between the lifelines of two objects. The order in which these messages occur is shown top to bottom on the page. Each message is labeled at minimum with the message name; you can also include the arguments and some control information, and you can show self-delegation, a message that an object sends to itself, by sending the message arrow back to the same lifeline.
Two bits of control information are valuable. First, there is a
condition, which indicates when a message is sent
(for example, [needsToReorder() == true]). The message is only sent if the
condition is true. The second useful control marker is the iteration
marker, which shows that a message is sent many
times to multiple receiver objects, as would happen when you are iterating
over a collection (such as * prepare).
As you can see, Figure 6-1 is very simple and has immediate visual appeal. This is its great strength.
One of the hardest things to understand in an object-oriented program is the overall flow of control. A good design has lots of small methods in different classes, and at times it can be tricky to figure out the overall sequence of behavior. You can end up looking at the code trying to find the program. This is particularly true for those new to objects. Sequence diagrams help you to see that sequence.
This diagram includes a return, which indicates the return from a message, not a new message. Returns differ from the regular messages in that the arrowhead for a return is just a pair of lines and not solid.
The POSA diagrams (Buschmann et al. 1996), on which much of the UML sequence chart notation is based, use returns extensively. I do not. I find that returns add a lot of clutter to a diagram and tend to obscure the flow. All returns are implied by the way the messages are sequenced. On occasions when returns do improve the clarity of the diagram, I use them.
My advice is to show returns only when they improve clarity. The only reason I used a return in Figure 6-1 is to demonstrate the notation; if you remove the return, I think the diagram remains just as clear.
It is awkward that returns are so similar to messages. I would prefer a stronger distinction between the two. In pre-UML days, I used to make the returns dashed lines, and I'm still inclined to break the rules to do that now unless I can think of a better way.
I'd like to offer a piece of general advice here: Be very wary of going against the UML notation. This notation will become a well-understood notation, and to do something non-standard will harm your communication with other designers. If something is causing painful confusion, however, I would make the change. After all, the primary purpose of the diagram is communication. If you do break the UML's rules, do it sparingly and clearly define what you have done.
In Figure 6-2, we see some objects that are checking a bank transaction.
When a Transaction is created, it creates a Transaction Coordinator to coordinate the checking of the Transaction. This coordinator creates a number (in this case, two) of Transaction Checker objects, each of which is responsible for a particular check. This process would make it easy to add different checking processes because each checker is called asynchronously and proceeds in parallel.
When a Transaction Checker completes, it notifies the Transaction Coordinator. The coordinator looks to see if all the checkers called back. If not, the coordinator does nothing. If they have, and all of them are successful, as in this case, then the coordinator notifies the Transaction that all is well.
Figure 6-2 introduces a number of new elements to sequence diagrams. First, you see activations, which appear explicitly when a method is active because it is either executing or waiting for a subroutine to return. Many designers use activations all the time. I find they don't add much to procedural execution, so I use them only in concurrent situations.
Figure 6-2: Concurrent Processes and Activations
You can show the consequences of self-delegation more clearly when you have activations. Without them, or without the stacking notation used here, it is hard to tell where further calls occur after a self-delegation--either in the calling method or the called method. The stacking activations make this clear. I sometimes find this is a reason to use activations in a procedural interaction, even though I don't usually use activations in these cases.
Figures 6-2 and 6-3 show two of the scenarios in the "transaction checking" use case. I have drawn each scenario separately. There are techniques for combining the conditional logic onto a single diagram, but I prefer not to use them because it makes the diagram too complicated.
In Figure 6-3, I've employed a very useful technique: I've inserted textual descriptions of what's happening along the left side of the sequence diagram. This involves lining up each text block with the appropriate message within the diagram. This helps in understanding the diagram (at the cost of some extra work). I do this for documents I'm going to keep but not for whiteboard sketches.
Within a collaboration diagram, the example objects are shown as icons. As on a sequence diagram, arrows indicate the messages sent within the given use case. This time, however, the sequence is indicated by numbering the messages.
Numbering the messages makes it more difficult to see the sequence than putting the lines down the page. On the other hand, the spatial layout allows you to show other things more easily. You can show how the objects are linked together and use the layout to overlay packages or other information.
Figure 6-3: Sequence Diagram: Check Failure
You can use one of several numbering schemes for collaboration diagrams. The simplest is illustrated in Figure 6-4. Another approach involves a decimal numbering scheme, seen in Figure 6-5.
In the past, most people used the simple numbering scheme. The UML uses the decimal scheme because it makes it clear which operation is calling which other operation, although it can be harder to see the overall sequence.
Figure 6-4: Collaboration Diagram with Simple Numbering
In Figures 6-4 and 6-5, you can see the various forms of the UML's object naming scheme. This takes the form objectName : ClassName, where either the object name or the class name may be omitted. Note that if you omit the object name, you must retain the colon so that it is clear that it is the class name and not the object name. So the name "Macallan line : Order Line" indicates an instance of Order Line called Macallan line (this is an order I would particularly appreciate). I tend to name objects in the Smalltalk style that I used in the sequence diagrams. (This scheme is legal UML because "anObject" is a perfectly good name for an object.)
Figure 6-5: Collaboration Diagram with Decimal Numbering
One of the principal features of either form of an interaction diagram is its simplicity. You can easily see the messages by looking at the diagram. However, if you try to represent something other than a single sequential process without much conditional or looping behavior, the technique begins to break down.
There are two schools of thought. One is to use separate diagrams for each scenario. The other is to use conditions on messages to indicate the behavior.
I prefer the former. Interaction diagrams are at their best when the behavior is simple; they quickly lose their clarity with more complex behavior. If I want to capture complex behavior in a single diagram, I prefer to use an activity diagram (see Chapter 9).
The UML provides a lot of additional syntax for sequence diagrams, based on the work of the patterns team at Siemens (Buschmann et al. 1996). I won't go into it in detail here, mainly because I'm not too keen on the complexity it encourages. To me, the beauty of interaction diagrams is their simplicity, and many of the additional notations lose it in their drive to computational completeness. I encourage you not to rush to the more complex forms of interaction diagrams, because you may find the simpler ones provide the best value.
If you want to look at the behavior of a single object across many use cases, use a state transition diagram (see Chapter 8). If you want to look at behavior across many use cases or many threads, consider an activity diagram (see Chapter 9).
Book Description,
Table of
Contents, Preface,
Chapter 1,
Chapter 3,
Cover (158K), Inside
Covers,
Ordering
Information, C&P Welcome Page.
