Use Cases and/or Sequence Diagrams

Class diagrams specify of the classes within a project from a static perspective. That is, class diagrams give a careful description of:

• the fields within a class and their type,
• the methods within a class and their signatures,
• relations among classes, including associations, generalizations and specifications (inheritance), dependencies, multiplicities, and constraints.

Use cases and sequence diagrams clarify how objects and classes interact during specific processing tasks. Normally, a user will initiate an action. This then triggers a program or method within the software. Processing proceeds through a series of method invocations, finally producing changes in a user display, a database, one or more files, or internal states within objects. Use cases and sequence diagrams differ in notation, format, and focus, but they both provide mechanisms to specify these dynamic interactions within a design.

For this lab, you are to work through the full range of activities that are part of your project.

1. Develop a list of use cases: normally, there should be a use case for each user interaction (each new screen, each click of a button).

2. For each use case, clarify (in outline form or in a sequence diagram):

   • What initiates the use case.
   • What program or method is invoked initially (together with what initial data, if any, are transmitted at the start).
   • What objects, if any, must be created and initialized as the use case progresses.
   • What methods (including full signatures) of which objects will be invoked in what order from which objects.
   • What results, if any, should be returned by each method.

   In summary, the content of a sequence diagram should be specified for each use case, although you may use outline form or other verbal description rather than a sequence diagram, if you wish.

3. After writing a sequence diagram or equivalent, review each stage of processing:

   • Does an object have adequate information to perform the task required within a method?
   • If processing within a method requires work by another object,
     • how does the method know about the location of that other object?
     • does the method have adequate information to supply needed parameters to that other object's method(s)?
   • Is processing within a use case centered in one method or is work distributed among several classes and methods? (Distributed work tends to allow methods to be relatively simple and straightforward; work centered in one place tends to make that method complex and thus hard to get right.)

Work to Turn In

• List of use cases
• Sequence diagram or equivalent for each use case.
• If analysis of a use case uncovers the need to revise a class (specified in the previous lab),
  • write a short paragraph indicating what changes are needed and why, and
  • include a revised class diagram for any changed classes

This document is available on the World Wide Web as

http://www.walker.cs.grinnell.edu/courses/223.fa06/labs/uml-3.shtml

created 8 August 2006 last revised 27 September 2006
For more information, please contact Henry M. Walker at walker@cs.grinnell.edu.