Home arrow Practices arrow Page 11 - Design with ArgoUML

Refining Use Cases with Sequence Diagrams - Practices

This article provides an overview of the practical application of object-oriented analysis and design (OOAD) design concepts and the Unified Modeling Language (UML). It is taken from chapter two of the book Enterprise Java Development on a Budget, written by Brian Sam-Bodden and Christopher M. Judd (Apress, 2004; ISBN: 1590591259)

  1. Design with ArgoUML
  2. The Unified Modeling Language
  3. Model-Driven Architecture and the UML
  4. Design Roadmap
  5. The Editing Pane
  6. Drawing Diagrams in ArgoUML
  7. Object Modeling Using Archetypes and Color in UML
  8. Adding Modeling Elements to the Class Diagram
  9. Assigning Archetypes and Creating Associations
  10. Use Case Modeling
  11. Refining Use Cases with Sequence Diagrams
By: Apress Publishing
Rating: starstarstarstarstar / 35
August 25, 2005

print this article




The UML sequence diagram models the dynamic behavior of a system by depicting object interactions over time. These interactions are expressed as a series of messages between objects. UML sequence diagrams are ideal for elaborating a use case execution in terms of objects from your domain model. One sequence diagram is typically used to represent a single use case scenario or flow of events. The message flow of a sequence diagram matches the narrative of the corresponding use case.

Sequence diagrams are an excellent way to document use case scenarios and refine and synchronize a use case diagram with respect to a domain model. A sequence diagram typically shows a user or actor and the object and components they interact with in the context of a use case execution.


Sequence diagrams aren’t working in ArgoUML as of the release of version v0.14. As an alternative, we suggest using the community edition of Poseidon UML, which is a commercial offering based on ArgoUML. We expect sequence diagrams to be available in the near future (hopefully by the time you read this!).

Whenever necessary use-sequence diagrams are used in the book to refine and validate a use case against the application’s domain model.


Don’t assign operations to a class without first refining complex use cases with sequence or interaction diagrams. By refining what capabilities a given class should have, you avoid the eventual generation of unneeded code. This practice aligns well with test-driven development and XP's You-Ain't-Gonna-Need-It (YAGNI).
Best Practices

Model-driven development is a practice that takes time to master, but the results are well worth the effort. We’ve compiled a list of best practices taken from the literature and from our own experiences to help you get started.

  • Keep models simple: Don’t over-model.
  • Use color in your models. As seen in this chapter color greatly enhances your ability to quickly grasp the both the static and dynamic elements of a model.


  • Choose model element names carefully. A model name can greatly influence the person that has to turn it into code.


  • Avoid design or implementation-specific constructs in the analysis model.


  • Keep models and source code synchronized: incremental changes are easier to incorporate.


  • In modeling, no single view is sufficient. Approach a complex system with a small set of independent views.


  • The best models are connected to reality and reality is all about trade-offs. Flexibility and performance are sometimes at odds when modeling a system.


  • There will be a point in a model’s life when the level of detail can only be expressed directly in code. Make sure that you don’t waste valuable time trying to overmodel something graphically that can be explained with a code sample or an annotation. UML notes are a great way to address some of these issues at the model level.



As you prepare for a journey into the J2EE world it’s important to remember that sound design practices—not technology—should drive the development of enterprise applications. Although at specific points you might have to make an implementation decision that’s driven by the shortcomings of a particular technology, you should always keep in mind the greater picture of a solid design based on the problem space rather than the solution space.

In this era of agile methodologies and techniques, many are quick to dismiss software modeling. But as Scott Ambler (http://www. agilemodeling.com) and others have demonstrated, software modeling can be just another weapon in your arsenal of agile methods.

In this chapter you’ve learned a solid set of techniques and with the help of Open Source modeling tools you can make your models more robust and resilient to requirements and technology changes.



1. Craig Larman, Applying UML and Patterns (Prentice Hall PTR, 2001).

2. Edward R. Tufte, The Visual Display of Quantitative Information
(Cheshire, CT:Graphics Press, 1983).

3. G.A. Miller, “The magical number seven, plus or minus two: Some
limits on our capacity for
processing information” (The
Psychological Review,
vol. 63, 1956) pp. 81–97.

4. Object Management Group, “OMG Unified Modeling Language
Specification,” Version 1.5
(March 2003), p. 1–1.

5. Craig Larman, Applying UML and Patterns (Prentice Hall PTR, 2001).

6. Jack Greenfield (Rational Software Corporation), “UML Profile For
EJB” [JSR-000026
UML/EJB(TM) Mapping Specification 1.0 Public
Review Draft] (2001), p. 8.

7. Steve McConnell, “From the Editor,” (IEEE Software, March/April
2000). Available online at


8. Jacobson et al, The Unified Software Development Process
(Addison-Wesley, 1999).

9. Coad et al, Java Modeling In Color With UML: Enterprise
Components and Process
(Prentice Hall PTR, 1999).

10. Kent Beck, Extreme Programming Explained (Addison-Wesley,






11. Scott Ambler et al, Agile Modeling (John Wiley & Sons, 2002). For
more information on agile
modeling also visit


12. Ambler et al, Agile Modeling.

13. ArgoUML online user manual, Chapter 8.

14. R. Chandra, A. Gupta, and J. L. Hennessy, “Integrating
Concurrency and Data Abstraction in
the Cool Parallel
Programming Language” (
IEEE Computer, February 1994).

15. Martin Fowler, Patterns of Enterprise Application
(Addison-Wesley, 2002).

>>> More Practices Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates


Dev Shed Tutorial Topics: