Sequence Diagrams

[article]
Testing UML Models, Part 2
Summary:

This is the second in a series of articles written to a) introduce you to the most important diagrams used in object-oriented development (use case diagrams, sequence diagrams, class diagrams, and state-transition diagrams); b) describe the UML notation used for these diagrams; and c) give you as a tester a set of practical questions you can ask to evaluate the quality of these object-oriented diagrams.

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

About the author

Lee Copeland's picture Lee Copeland

Lee Copeland has more than thirty years of experience in the field of software development and testing. He has worked as a programmer, development director, process improvement leader, and consultant. Based on his experience, Lee has developed and taught a number of training courses focusing on software testing and development issues. Lee is the managing technical editor for Better Software magazine, a regular columnist for StickyMinds.com, and the author of A Practitioner's Guide to Software Test Design. Contact Lee at lcopeland@sqe.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03