The Register ®

Biting the hand that feeds IT

The Register » Software »

Original URL: http://www.theregister.co.uk/2007/12/22/iconix_process_sequence_diagramming/

Sequence diagramming that's fit for purpose

By Matt Stephens, the Agile Iconoclast
Published Saturday 22nd December 2007 01:02 GMT

Book extract, part 4 In this, the final part of our series of experts from Use Case Driven Object Modeling with UML: Theory and Practice Matt Stephens (http://www.softwarereality.com/MattStephens.jsp) and Doug Rosenberg (http://www.iconixsw.com/) show you how to draw lean, purposeful sequence diagrams that are driven from the use cases and preliminary design.

As before, this chapter opens with the following "you are here" diagram of the ICONIX Process, showing in red the area about to be covered.

Iconix Process sequence diagram

Mapping sequence and behavior

All the steps in the process so far have been preparing the use cases for the detailed design activity. By this time, your use case text should be complete, correct, detailed, and explicit. In short, your use cases should be in a state where you can create a detailed design from them.

If you figure that preliminary design is all about object discovery, then detailed design is, by contrast, about behavior allocation - that is, allocating the software functions you've identified into the set of classes you discovered during preliminary design.

When you draw sequence diagrams, you're taking another sweep through the preliminary design, adding in detail. You use sequence diagrams to drive the detailed design. We advocate drawing your sequence diagrams in a minimal style.

Here is our final 10-point checklist for successful sequence diagramming. As with all our lists, pay attention because there will be questions:

Top 10 sequence diagramming guidelines

10. Clean up the static model before proceeding to the next step

9. "Prefactor" your design on sequence diagrams before coding

8. Review your class diagrams frequently while you're assigning operations to classes, to make sure all the operations are on the appropriate classes

7. Assign operations to classes while drawing messages. Most visual modeling tools support this capability

6. Don't spend too much time worrying about focus of control

5. Make sure your use case text maps to the messages being passed on the sequence diagram. Try to line up the text and message arrows.

4. Use the sequence diagram to show how the behavior of the use case is accomplished by the objects

3. Start your sequence diagram from the boundary classes, entity classes, actors, and use case text that result from robustness analysis

2. Do a sequence diagram for every use case, with both basic and alternate courses on the same diagram

1. Understand why you're drawing a sequence diagram, to get the most out of it

Sequence diagramming in practice - test yourself

Continuing with our sample internet bookstore application, the following diagram shows an excerpt from a sequence diagram for the "Create New Book" use case. This use case is intended for bookstore staff, so that they can add new book titles to their online catalog. There are a couple of problems with this diagram excerpt - one of which is repeated many times in our diagram. See if you can find them both. Hint: the errors relate back to items one and seven in the top-10 list.

Iconix Process sequence diagram exercise one

Hidden problems: flawed sequence diagram

Our next illustration highlights the parts of the sequence diagram that have gone wrong. The main issue is that the sequence diagram is being used as a flowchart, instead of for its primary purpose in life: to allocate behavior to classes.

Flowcharting on sequence diagrams isn't necessarily an evil thing in and of itself, and it is almost certainly better than not doing the sequence diagram at all. But we consider it to be (at best) a weak usage of a sequence diagram because it doesn't leverage the ability to assign operations to classes while drawing message arrows.

Since, in our opinion, this activity is pretty much the fundamental place where "real" object oriented design happens, we've flagged it as an error.

The second issue is that there’s no validation performed on the incoming form data - and therefore no error handling code for rejecting bad data. Either the validation steps were left out of the use case or the designer didn't draw the sequence diagram directly from the use case text.

Iconix Process sequence diagram exercise two

Problems exposed in the sequence diagram

The final illustration shows the corrected version of the sequence diagram and includes the alternate course - shown in red - for when the form validation fails.

Iconix Process sequence diagram exercise three

Correct sequence of events

This concludes our series of excerpts from Matt and Doug's book. As you can imagine, the book itself goes into masses more detail and includes a raft of examples and exercises. The book follows several use cases from inception all the way to source code and tests, using an example Spring/JSP project. It also introduces design-driven testing, a practical alternative (or complement) to test-driven development, and illustrates how to deal with functional requirements documents and extract lightweight use cases from them.

For those of you more interested in performing a mashup of an object oriented analysis and design process with your favorite agile development practices, then you might want to read this book’s companion volume, here (http://books.theregister.co.uk/catalog/browse.asp?isbn=1590594649), also available through Register Books.®

Use Case Driven Object Modeling with UML: Theory and Practice is available for purchase through Register Books (http://books.theregister.co.uk/catalog/browse.asp?isbn=1590597745), at the special price of £34.99.

© Copyright 2008