Use Cases

1
Use Cases

• Elizabeth Bigelow
• CS 15-499C
• 9/15/2000

2
Administration

• Only 4 students have submitted applications for
  TogetherJ Accounts
• Please get these in no later than Sunday evening

3
Use Cases

• A form of dynamic modeling
• Very informal
• Tend to be unwieldy for large systems
• Not a bad way to start, but usually will not
  scale well
• Easy for users to understand
• Difficult to use for embedded systems

4
Use Case Contents

• Use cases (ovals)
• Actors
• Dependency, generalization and association
  relationships

5
Common Uses

• Model the context of a system
• Draw a line around the whole system and assert
  which actors lie outside the system and interact
  with it. Use case diagrams specify the actors and
  the meaning of their roles
• Model the requirements of a system
• Specify what the system should do independent of
  how the system should do it (ie, desired behavior
  as a black-box)

6
Credit Card Validation System Context
7
(No Transcript)
8
If you start from use cases

• Decide who interacts with the system (may be an
  external system)these are the actors
• Decide what lies within the system (the system
  boundary
• Develop high level use cases, then use
  generalization, dependency and association to
  make more precise
• Note that in this context association is the
  relationship of the actors and the use cases

9
More details on use cases

• Extends relationship is used to show
• Optional behavior
• Behavior that is only run under certain
  conditions
• Several different flows which may be run based on
  actor selection

10
(No Transcript)
11
Scenarios

• A scenario is a specific instance of a use case
• Expressing the whole system via scenarios is
  tedious, and time consuming
• Specifying a few scenarios, however, can
  significantly help getting started

12
80/20 Rule

• For any technique, keep the 80/20 rule in mind
• Dont specify everything!