- Forward


Use Case Modeling
An Introduction


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Use Cases
Back SMYC Forward
  • Alternative Definitions:
    • An abstract episode or interaction between a system and its environment
    • A description of one or more sequences of actions that a system performs to yield an observable result
    • A way of using a system
    • A dialog that a system and its environment share as they interact
  • Uses:
    • A way to describe the requirements/features of a product/system
An Example: Designing a House
Back SMYC Forward
  • Using the house for cooking and eating
    • Unloading groceries, storage, placement of appliances, serving meals, ...
  • Using the house for entertaining
    • Flow of people, facilitating conversation, ...
  • Using the house for sleeping
  • Using the house to raise children
Properties of Good Use Cases
Back SMYC Forward
  • A use case should be an entire transaction
    • A withdrawal from an ATM machine
    • A telephone call
  • The collection of uses cases should entirely characterize the functionality of the system
Developing Use Cases
Back SMYC Forward
  1. Define the context of the system (i.e., the environment)
  2. Identify outside entities that interact with the system (i.e., actors)
  3. Consider the behavior that each actor expects/requires the system to provide
  4. Identify common behaviors (i.e., use cases)
Identifying the Actors
Back SMYC Forward
  • Types:
    • Principal actors (e.g., people who use an ATM)
    • Secondary actors (e.g., people who maintain an ATM)
    • External hardware (e.g., the printer in an ATM)
    • Other systems (e.g., the bank network)
  • Description:
    • Use at most 3-4 lines of text
Things to Think About Next
Back SMYC Forward
  • What are the tasks of the actor?
  • What information must be created, saved, modified, deleted or read by the actor?
  • Will the actors have to notify the system of any external modifications?
  • Will the system have to notify the actor of internal conditions?
Identifying the Flow of Events
Back SMYC Forward
  • The beginning of the use case
  • The origin of information
  • The exchange of information (chronological)
  • The end of the use case
Identifying the Flow of Events (cont.)
Back SMYC Forward
  • Types of Flow:
    • Main Flow of Events
    • Exceptional Flow of Events
  • Specifying Optional Situations:
    • "The actor chooses one of the following:
      • (a) Cash
      • (b) Credit

      and then..."

Scenarios vs. Use Cases
Back SMYC Forward
  • A scenario is a description of a specific interaction involving a particular actor
  • A use case abstracts scenarios that are instances of the same kind of interaction
Use Case Granularity
Back SMYC Forward
  • Definition:
    • The size or scope of a use case
  • Examples:
    • Large: "Manage Pharmacist Privileges"
    • Small: "Fill a Prescription"
Use Case Granularity (cont.)
Back SMYC Forward
  • Tradeoffs:
    • A large number of simple use cases vs. a small number of complicated use cases
  • What to Try For:
    • A collection of use cases at a uniform granularity
Use Case Diagrams
Back SMYC Forward
  • Defined:
    • A schematic representation of actors, use cases, and the relationships between and among them
    • NOT a diagram illustrating the details of a use case
  • Actors:
    • Abstractions of agents that interact with a system
    • Names are usually noun phrases (e.g., SalesRep, BillingSystem)
  • Use Cases:
    • Abstract episodes or interactions between a system and its environment
    • Names are usually verb phrases (e.g., EnterSale) though not always (e.g., ElectronicFundsTransfer is more meaningful than TransferFundsElectronically)
Using the Unified Modeling Language
Back SMYC Forward
  • Actors: actor
  • Use Cases: usecase
  • Relationships:
    • Association association
    • Specialization/Generalization generalization
Identifying Commonalities/Hierarchies
Back SMYC Forward
  • Actors:
    • "Is a" relationship (e.g., CommercialCustomer extends Customer)
  • Use Cases:
    • "Use" relationship (e.g., FundsTransfer uses IdentifyCustomer)
    • "Is a" relationship (e.g., TransferFundsElectronically extends TransferFunds)
Association: Examples
Back SMYC Forward
association2
Specialization/Generalization: Example
Back SMYC Forward
generalization1
generalization2
Example: In-Vehicle Advanced Navigation Assistant (IVANA)
Back SMYC Forward
A (Non-Atomic) Needs List

Drivers need IVANA to help get them where they want to go.

IVANA should work with the vehicle's location system (e.g., GPS), programmable display, and speech generation system.

IVANA should display a map and vehicle's location on the programmable display.

The user needs to be able to enter a destination.

IVANA should determine a recommended route, display it on the programmable display, and provide spoken turn-by-turn directions.

Example: IVANA (cont.)
Back SMYC Forward

Use Case Diagram

ivana_usecases
Use Case Descriptions
Back SMYC Forward
  • Defined:
    • Describe how the actors and systems interact
    • ARE a description of a use case
  • Notation:
    • There is no standard notation
    • Natural language is often used
Levels of Abstraction
Back SMYC Forward
  • High Level (i.e., Most Abstract):
    • Often only a few sentences
    • Usually do not include interaction protocols (e.g., user identifies himself/herself to ATM)
  • Low Level (i.e., Most Detailed):
    • Provide additional details
  • Implementation Level (a.k.a., Real):
    • Include interaction protocols (e.g., user is prompted with ..., must enter a 4-digit PIN, must press...)
Formatting Use Case Descriptions
Back SMYC Forward
  • An Observation:
    • There is no standard
  • Remember:
    • Clarity is paramount
An Example in Stimulus-Response Format
Back SMYC Forward

From an In-Vehicle Navigation System named IVANA

Enter Destination
(Actors: Driver)


Actor Action System Response

0. This use case begins when the Driver chooses to enter a Destination.

1. The system asks the Driver to select a Destination Type (either an Address or a Location).

2. The Driver selects a Destination Type.

3. The system asks the Driver to enter a Destination.

4. The Driver enters a Destination.

5. If the Destination is a Location the system records it.


If the Destination is an Address the system attempts to geocode it (i.e., determine a Location). If it can, it records the Location. If it can't, this use case re-starts.

An Example in a Linear Format
Back SMYC Forward

From a Timetable System named Papyrus

use-case-description_papyrus
There's Always More to Learn
Back -