Sequence Diagrams

[article]
Testing UML Models, Part 2

In today's testing world there is good news and bad news. The good news is that, more and more, testers are being asked to evaluate the quality of object-oriented analysis and design work earlier in the development process. The bad news is that most testers do not have an extensive background in the object-oriented paradigm or in UML (Unified Modeling Language), the notation used to document object-oriented systems.

This is the second in a series of articles written to

  • introduce you to the most important diagrams used in object-oriented development (use case diagrams, sequence diagrams, class diagrams, and state-transition diagrams)
  • describe the UML notation used for these diagrams
  • give you as a tester a set of practical questions you can ask to evaluate the quality of these object-oriented diagrams

As in the first article, we will use three independent approaches to test these diagrams:

  • syntax–"Does the diagram follow the rules?"
  • domain expert–"Is the diagram correct?" "What else is there that is not described in this diagram?"
  • traceability–Does everything in this diagram trace back correctly and completely to its predecessor?" "Is everything in the predecessor reflected completely and
    correctly in this diagram?"

For this set of articles we will use a case study: a Web-based online auction system that I invented: f-Lake. Yes, I invented the idea of online auctions. I'm not sure why f-Lake never caught on.

Sequence Diagram
A sequence diagram describes how groups of objects collaborate in accomplishing some system behavior. This collaboration is implemented as a series of messages between objects. Typically, a sequence diagram describes the detailed implementation of a single use case (or one variation of a single use case). Sequence diagrams are not useful for showing the behavior within an object. Consider using state-transition diagrams for that purpose.

The UML notation for sequence diagrams is shown below:


 

Notation
For those not familiar with the notation used for sequence diagrams, some explanation is in order.

Object. Each of the objects that participate in the processing represented in the sequence diagram is drawn across the top. Note that objects are used in this diagram while classes are used in use cases, class diagrams, and state-transition diagrams.

Lifeline. A dotted line is dropped from each object in the sequence diagram. Arrows terminating on the lifeline indicate messages (commands) sent to the object. Arrows originating on the lifeline indicate messages sent from this object to another object. Time flows from top to bottom on a sequence diagram.

Active. To indicate that an object is executing, i.e., it has control of the CPU, the lifeline is drawn as a thin rectangle.

Message. A horizontal arrow represents a message (command) sent from one object to another. Note that parameters can be passed as part of the message and can (optionally) be noted on the diagram.

Return. When one object commands another, a value is often returned. This may be a value computed by the object as a result of the command or a return code indicating whether the object completed processing the command successfully. These returned values are generally not indicated on a sequence diagram; they are simply assumed. In some instances the object may not be able to return this information immediately. In this case, the return of this information is noted on the diagram later using a dotted arrow. This indicates the flow of information was based on a previous request.

Conditional. Square brackets are used to indicate a conditional, i.e., a Boolean expression that evaluates to TRUE or FALSE. The message is sent only if the expression is TRUE.

Iteration. Square brackets preceded by an asterisk (*) indicate iteration. The message is sent multiple times. The expression within the brackets describes the iteration rule.

Deletion. An X is used to indicate the termination (deletion) of an object.

Syntax Testing
Let's begin with the simplest kind of testing-syntax testing. When performing syntax testing, we are verifying that the sequence diagram contains correct and proper information. We ask three kinds of questions: Is it complete? Is it correct? Is it consistent?

Do you remember our secret from the last article? You do not need to know the answers to any of these questions before asking them. It is the process of asking and answering that is most important. Listen to the answers you are given. Are people confident about their answers? Can they explain them rationally? Or do they hem and haw and fidget in their chairs or look out the window or become defensive when you ask? Now for the questions:

Complete:

  1. Does each object required for the interaction appear on the diagram?

Correct:

  1. Have all objects not required in the interaction been removed from the diagram?
  2. Does each object's lifeline begin and end at the proper time?
  3. Is each object's activation described properly?
  4. If the object's lifetime terminates, is it indicated with an X?
  5. Is each message well named with a strong verb?

  6. Are proper parameters included for each message?
  7. Are conditional branches drawn properly?

Consistent:

  1. Do conditionals cover all of the cases?
  2. Have any overlaps of conditionals been removed?

Domain Expert Testing
After checking the syntax of the sequence diagrams, we proceed to the second type of testing-domain expert testing. Again, we have two options: find a domain expert or attempt to become one. (The second approach is always more difficult than the first, and the first can be very hard.) Continuing, we ask two kinds of questions: Is it complete? Is it correct?

Complete:

  1. Are all the ways that things could go right identified and handled properly?
  2. Are all the ways that things could go wrong identified and handled properly?
  3. Does the main success scenario run from the trigger to the delivery of the success end condition?

Correct:

  1. Does the sequence diagram show each step that must be executed to implement the function?
  2. Can each step actually be implemented?

Traceability Testing
Finally, after having our domain expert scour the sequence diagrams, we proceed to the third type of testing-traceability testing. We want to make certain that we can trace from the use cases to the sequence diagrams and from the sequence diagrams back to the use cases. Again, we turn to one question: Is it consistent?

Consistent:

  1. Is each use case represented by at least one sequence diagram?
  2. Does each actor appear on at least one sequence diagram?

Conclusion
This set of questions, based on syntax, domain expert, and traceability testing; and focused on completeness, correctness, and consistency; is designed to get you started testing in an area with which you may not be familiar. Future articles will apply the same principles to testing class diagrams and state-transition diagrams.

Have fun testing. 

Other articles in this series:
Use Cases:
Testing UML Models, Part 1

Class Diagrams:
Testing UML Models, Part 3

State-Transition Diagrams: Testing UML Models, Part 4

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.