There are several ways that you can improve the quality and effectiveness of your UML sequence diagrams. These include:

• Verifying your decisions with subject matter experts
• Keeping your solution as simple as possible
• Choosing a consistent and effective style for drawing messages and return values
• Layering your sequence diagrams
• Following a consistent logic style
• Remembering that sequence diagrams are dynamic

Verify decisions

When I developed the sequence diagram of Figure 1, I made several decisions that could potentially affect my other models. For example, as I modeled Step 10, I made the assumption (arguably, a design decision) that the fee display screen also handled the verification by the student that the fees were acceptable. This decision should be reflected by my user interface prototype, and verified by my subject matter experts (SMEs). Sequence diagramming is something you should be doing together with your SMEs, particularly sophisticated ones who understand how to develop models such as this.

Back to top

Keep it simple

As I was modeling Steps 2 and 3, I came to the realization that students should probably have passwords to get into the system. I brought this concept up with my SMEs and discovered I was wrong: the combination of name and student number is unique enough for our purposes and the university didn't want the added complexity of password management. This is an interesting decision that would be documented in the supplementary specification, likely as a business rule, because it is an operating policy of the university. By verifying this idea with my SMEs, instead of assuming I knew better than they did, I avoided an opportunity for goldplating and, thus, reduced the work my team would need to do to develop this system.

Back to top

Drawing messages and return values

I prefer to draw messages going from left-to-right and return values from right-to-left, although that doesn't always work with complex objects/classes. I align the label on messages and return values, so they are closest to the arrowhead. I prefer not to indicate return values on sequence diagrams to simplify the diagrams whenever possible. However, it is equally valid to always indicate return values, particularly when your sequence diagram is used for design instead of analysis. (I like my analysis diagrams to be as simple as possible and my design diagrams to be as thorough as possible.) During analysis, my goal is to understand the logic and to ensure I have it right. During design, I then flesh out the exact details, as the note reminds me to do with the "qualifications()" message in Figure 1.

Back to top

Layer your sequence diagrams

I prefer to layer the sequence diagrams from left to right. I indicate the actors, then the controller class(es), and then the user interface class(es), and, finally, the business class(es). During design, you probably need to add system and persistence classes, which I usually put on the right-most side of sequence diagrams. Layering your sequence diagrams in this manner often makes them easier to read and also makes it easier to find layering logic problems, such as user interface classes directly accessing persistence classes (more on this in a future modeling tip).

Back to top

Follow a consistent logic style

Note that the style of logic changed part way through the sequence diagram of Figure 1. The user interface was handling some of the basic logic at first, particularly the login -- yet for selecting the seminar, and then verifying it, the controller class did the work. This is actually a design issue. I wouldn't get too worked up over this but, as always, I suggest choosing one modeling style that works for you and applying it consistently throughout all of your sequence diagrams.

Back to top

Remember that sequence diagrams are dynamic

You may have heard terms such as dynamic modeling and static modeling bantered about by other developers familiar with object-oriented modeling techniques. You may even have heard arguments about the merits of each style.

Dynamic modeling techniques focus on identifying the behavior within your system, including sequence diagramming and activity diagramming (see "How to draw UML activity diagrams") and UML collaboration diagramming. Meanwhile, static modeling focuses on the static aspects of your system including the classes, their attributes, and the associations between classes. Class models are the main artifact of static modeling as are persistence/data models.

So there really is nothing to debate -- both dynamic and static modeling techniques are required to specify an object-oriented system adequately.

Resources

• The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2001.
  
  
• The Unified Process Inception Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000.
  
  
• The Unified Modeling Language Reference Manual by James Rumbaugh, Grady Booch, and Ivar Jacobson. Reading, MA: Addison-Wesley Longman, Inc., 1999.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Verify decisions
• Keep it simple
• Drawing messages and return values
• Layer your sequence diagrams
• Follow a consistent logic style
• Remember that sequence diagrams are dynamic
• Resources
• About the author
• Comments

Next steps from IBM

With Rational Software Modeler you can increase productivity by dragging and dropping your way to a visual interpretation of your UML design.

---

• Try: Download a free trial version of Rational Software Modeler, a UML 2.0-based visual modeling and design tool for architects, systems analysts, and designers.
• Article: Learn what UML limitations are and how you can overcome them with Rational Software Modeler.
• Tutorial: This tutoral provides a tour of Rational Software Modeler's Visual UML modeling tools.
• Demo: This demo guides you through the creation of a UML modeling with Rational Software Modeler.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Java on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers