Refining Use Cases with Sequence Diagrams - Practices

 

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.

---

NOTE

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.

---

TIP

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.

   

Summary

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
http://www.stevemcconnell.com/CargoCultSe.pdf.

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,
1999).

 

 

 

 

 

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

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
Architecture (Addison-Wesley, 2002).

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

blog comments powered by Disqus