View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

How to create good Sequence Diagrams - Lander L. Basterra

A sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. Sequence diagrams consist of rectangles placed on top of the page horizontally that represent the classes that interact in your scenario and vertical lines coming out of this rectangles called lifelines. Each Lifeline element represents the life of a given object. Lifelines are connected by horizontal lines denoting messages that pass from one object in the scenario to the next object in the scenario. A sequence diagram captures the behavior of a single scenario. The diagram shows a number of objects and the messages that are passed between these objects within the scenario.

We will consider a simple scenario.We have a shopping order and we are going to invoke a command on it to calculate its price. To do that, the order needs to look at all the line items on the order and determine their prices, which are based on the pricing rules of the order line’s products. Having done that for all the line items, the order then needs to compute an overall discount, which is
based on some rules.
Figure 1 is a sequence diagram that shows one implementation of that scenario. Sequence diagrams show the interaction by showing each participant with a lifeline that runs vertically down the page and the ordering of messages by reading down the page.
Each lifeline has an activation bar that shows when the participant is active in the interaction. Also, I only used one return line; however you could use them for all calls. The first message doesn’t have a participant that sent it, as it comes from an undetermined source. Sequence diagrams clearly show how objects interact. They aren’t good at showing details of algorithms, such as loops and conditional behavior, but they make the calls between objects clear and give a really good picture about which objects are doing which processing. You can see that the objects in this Sequence Diagram have a more distributed control; this is good since it is more suitable for polymorphism and inheritance.

Sequence diagrams show some extra notation for creating and deleting participants (Figure 2). To create a participant, you draw the message arrow directly into the participant box. A message name is optional here if you are using a constructor, but you can mark it with “new” . If the participant immediately does something once it’s created, you start an activation right after the participant box.
Deletion of an object is indicated by big X. A message arrow going into the X indicates one participant explicitly deleting another; an X at the end of a lifeline shows a participant deleting itself.

A common issue with sequence diagrams is how to show looping and conditional behavior. Here’s the notation to use. Both loops and conditionals use
interaction frames, which are ways of marking off a piece of a sequence diagram. Figure 3 shows a simple algorithm based on the following pseudocode:

procedure dispatch
foreach (lineitem)
if (product.value > $10K)
end if
end for
if (needsConfirmation) messenger.confirm
end procedure

In general, frames consist of some region of a sequence diagram that is divided into one or more fragments. Each frame has an operator. To show a loop, you use the
loop operand with a single fragment. For conditional logic, you can use an alt operator and put a condition on each fragment. If you have only one region, there is an opt operator.

Here are different operators with their associated meaning:

loop –> Looping, for each element of the collection or the interval, it will perform what is inside the frame

alt –> Alternative multiple fragments; only the one whose condition is true will execute

opt –> Optional; the fragment executes only if the supplied condition is true. Equivalent to an alt with only one trace

par –> Parallel; each fragment is run in parallel.

region –> Critical region; the fragment can have only one thread executing it at once.

neg –> Negative; the fragment shows an invalid interaction.

ref –> Reference; refers to an interaction defined on another diagram.

You should use sequence diagrams when you want to look at the behavior of several objects within a single use case. Sequence diagrams are good at showing collaborations among the objects; they are not so good at precise definition of the behavior.

A typical mistake when working with sequence diagrams is adding too much detail. Just because your code has several branches in a particular method doesn't mean you should include each one (or even any of them) in the same diagram using block or scenario elements. Adding too much detail just ends up cluttering the diagrams and making them more difficult to read and understand.

Another common mistake is attempting to create a sequence diagram for each and every possible scenario in the system, particularly when designing close to the source code level.

At the other extreme is the mistake of having too few sequence diagrams covering only parts of the most basic scenarios such as get some value or create a new object.


Links to this Page