Use Case Analysis

1
Use Case Analysis
Software Engineering Lab.
2
Objectives

• Use Case Analysis
• To be able to
• Develop Use Cases to indicate how a system will
  be used

3
What is Use Case Analysis?
Use Case Analysis Analysis of the required
system behavior from the external point of view
4
What is a Use Case?
Use Case A behavior or coherent set of
behaviors triggered by events sent to the system
by human user(s), other systems, hardware
components, or an internal clock
5
Use Cases Partition the System
A subset of system requirements
A set of potential scenarios
A description of behavior
Use Case
Source of system operations
A group of cooperating entities
6
UML Use Case Diagrams

• Use Case Diagram
• Shows the set of external actors and the Use Cass
  that the actors participate in
• May show the messages or events exchanged between
  the actors and the Use Cases
• May show the mechanisms for the exchanges

7
Basic Use Case Modeling Notation
Use Case
Use Case Name
Actor
System
ltltactorgtgt Name
or
Name
Name
Communicates Association
ltltcommunicatesgtgt
Use Case Name
Name
Optional stereotype may include mechanism
8
Actors

• A class of objects that interact with the portion
  of the system under consideration
• Can be any entity that interacts with the system

human
Another (sub)system
hardware
clock

• Can query or modify system, report on
  surroundings, and receive events
• A Use Case has one initiating actor but may have
  more than one actor participating

9
An Actor is a Role

• An actor defines a single role played by users in
  their interactions with the system
• Multiple users can play a single role
• A single user may play multiple roles

ltltactorgtgt Consultant
ltltactorgtgt Instructor
ltltactorgtgt Project Manager
ltltactorgtgt John
ltltactorgtgt Jane
10
Actors and Generalization

• More than one actor may participate in the same
  sequence of behaviors
• Generalize actors to find the common role

Submit Expense Accounts
ltltactorgtgt Traveler
ltltactorgtgt Consultant
ltltactorgtgt Instructor
ltltactorgtgt Project Manager
11
Actor Types

• Primary Actor For whom the system is designed
• Secondary Actor Supervises and maintains the
  system

Less Independent Volition, More
Design Control, Inside System, Allocated Many
System Requirements
More Independent, Less Design Control, Completely
Outside System, Drive System
Requirements
Primary
Secondary
Specifying the details of a Use Case constrains
the behavior of the actors
12
Actors as Classes

• Model actors as classes to
• Track System requirements to operations
• Internal staff and external users may be
  allocated system requirements to perform

Circulation Clerk

• Help write job descriptions
• Help write user manuals
• An Actors attributes are
• Facts that the user is expected to know
• Constrained properties that represent job
  requirements

userid education gt 12 years computer-user
accept patrons books verify patron status stamp
due date on book

• An actors operations are
• Behaviors that the user must be able to perform
• Communications that the actor must be able to
  send
• Communications that the actor must be able to
  receive

13
Realizing a Use Case

• Use Cases are expressed textually
• But typically need graphical depiction of the
  interaction
• Activity Diagrams
• Emphasize the steps in the process
• Sequence Diagrams
• Emphasize the message flow and sequencing
• Collaboration Diagrams
• Emphasize the context, message, and data flow

14
Use Cases are System Operations

• Use Cases focus on the externally visible
  behavior of the system from the users point of
  view
• They are the systems public operations

Library System
Library System
borrow
borrow() reserve()
reserve
Patron
15
Use Case Relationships

• Typically, a Use Case is directly initiated by an
  event from an actor (a communicates association)
• Occasionally, it is desirable to encapsulate an
  embedded subflow of events into a separate Use
  Case
• These additional Use Cases are
• Typically called from within a base Use Case
• Related individually to the base Use Case via a
  uses or extends relationship

16
Uses and Extends Relationships

• The uses relationship indicates that the used
  Use Case (the target) is included with the source

• May bundle common flows of events that are
  extracted from multiple Use Cases to avoid
  redundancies a kind of behavior subroutine

ltltusesgtgt
source
target
Uses (source Use Case includes target behavior)

• The extends relationship indicates that the
  extensions Use Case (the source ) may embed
  additional behavior in the target

• Models optional behavior
• Highlights flow of infrequent events
• Allows versioning

ltltextendsgtgt
source
target
Extends (target Use Case may include source Use
Case)
17
Combining Use Cases
Register After Class Start
Logon
ltltextendsgtgt
ltltusesgtgt
ltltusesgtgt
Sign Up To Teach
Register
User
ltltactorgtgt Student
ltltactorgtgt Professor
18
Recipe for Applying Use Cases

• Conceptualization
• Ask users what the system needs to do
• Identify each actor who uses the system
• Bound the scope of the system
• Draw the Top-Level Use Case Diagram
• Develop a candidate Use Case list
• Identify every purpose to which the system will
  be put
• Briefly describe each Use Case
• Determine operations concepts
• Organize all Use Cases graphically in a Use Case
  Diagram

19
Recipe for Applying Use Cases

• Analysis
• Describe Use Case behavior in detail using a
  narrative form this may identify additional Use
  Case (uses and extends associations) Identify
  each actor who uses the system
• Rely on domain analysis models to provide
  consistency across the set of Use Case narratives
• Sketch or prototype the human interface
  (visualization)
• Examine and model scenarios
• Update Use Cases to accommodate application
  analysis decisions
• Package Use Case for delivery increments

20
Recipe for Applying Use Cases

• Design
• Develop detailed interactions to satisfy Use
  Cases
• Complete sequence or collaboration diagrams

• Integration Test
• Develop system in Use Case package increments
• Organize test around Use Case and their scenarios

21
Sample Basic Use Case Template

• Use Case name and number
• Author
• Date
• Summary
• Assumptions (e.g., frequency of use, design
  considerations)
• Actors
• Preconditions (constraints for initiation of Use
  Case)
• Description
• Exceptions
• Postconditions Conditions that will hold if Use
  Case ends successfully

22
Use Case Template (Cont)

• Description This Use Case starts when actor
• The system responds by
• sequence of interactions
• data is retrieved, manipulated, stored
• description of all choices, all looping
  behavior, any resets
• rules of making choices
• stimulus to actors
• This Use Case ends when

23
Use Case Description

• Payroll System
• Use Case Record time worked
• Author Joe Smith
• Last Update April 20, 1996
• Summary Employee informs system of hours worked
  and expenses incurred via a push button phone
• Actors Employees
• Assumptions No more than five employees call at
  the same time
• Preconditions Employee has access to push button
  phone and can use it
• Telephone network available
• Employee known to system

24
Example

• Payroll system Use Case description (Cont)
• Description This Use Case starts when an
  employee dials
• system telephone number system responds with
  introduction and status message. Employee
  identifies self to system by entering unique user
  ID. System acknowledges employee by name and
  requests password. Exception Employee not
  found. Employee enters password. System accepts
  password and asks for hours worked. Exception
  Bad password. Employee specifies day and month,
  time period, and number of hours worked during
  that period. System audibly repeats time
  information to employee. Employee acknowledges
  correctness of information or re-enters time
  data. This Use Case ends when employee is
  satisfied by time entry information and hangs up.

25
Example

• Payroll system Use Case description (Cont)
• Exceptions Time out System disconnects call
• Bad password User allowed to try three times
• If not successful, then Use Case terminates
• Employee not found Advise employee to see
  their manager
• Postconditions System has stored hours worked
  for that employee during specified time period

26
Use Case Header Template(1/2)
27
Use Case Header Template(2/2)
28
Sample Main Use Case Body
29
Example Main Use Case Body
30
Sample Extension Template
31
Example Extension Template
32
Sample Use Case Trailer
33
Example Use Case Trailer
34
Packages

• Packages are used to partition Use Cases and
  Actors
• Several possible approaches
• Logical Grouping
• Separate high-level packages to separate
  system-level vs. software-level concerns
• Separate Primary and Secondary Actors
• Keep each actor with their own Use Cases in a
  package
• Implementation Grouping
• Separate Actors from Use Cases
• Separate Use Cases by priority (likely
  implementation ordering) and mechanism

35
Summary

• Use Case Analysis
• Use Case capture how a system will be used
• Who does what
• What happens
• When it happens
• Use Cases are started during conceptualization
  and maintained throughout development