Use Cases

1
Use Cases

• Alistair Cockburn, Writing Effective Use Cases,
  Addison-Wesley, 2000.
• Grady Booch, James Rumbaugh, and Ivar Jacobson,
  Unified Modeling Language User Guide, 2nd
  edition, Addision-Wesley, 2005.
• Scott W. Ambler, The Elements of UML 2.0 Style,
  Cambridge University Press, 2005.

2
Groups of 3

• Recorder/timekeeper
• Participation checker
• Devils advocate

3
Motivation

• One way to describe a system is to create a
  story, the interaction between a user and the
  system.
• This story should be just one path through the
  system, start to finish, that a user will want to
  take.

4
Task

• Read the ATM description
• Describe the withdraw transaction from start to
  finish
• Make sure you describe exactly one path
• 10 minutes

5
Report
6
Questions

• What questions did you come up with about the
  ATM?
• Other than the customer, what other things did
  you need to interact with?
• How did you decide what is inside and outside of
  your system?
• Where in your description could things have been
  different?

7
What Is an Actor?

• Not part of a system
• Represents roles a user can play (not people or
  job titles)
• Represents a human, a machine or another system
• Actively exchanges information with the system a
  giver or a recipient

8
A User Can Act As Several Actors
Charlie as Caller
Charlie as Customer
Phone Carrier
Charlie
Phone Owner
9
ActorsHelp Define System Boundaries
System boundary?
Voice mail
Phone System
Caller
Callee
Is the Voice Mail an actor or part of the system?
What about other providers?
10
Questions to Identify Actors

• Who will use the system?
• Who needs support from the system to do regularly
  occurring tasks?
• Who will maintain the system?
• What hardware does the system support or interact
  with?
• What other systems are needed for this system to
  work?
• Who will supply, use, or remove information?
• Dont just consider people in front of a computer
  screen

11
Task

• Identify all of the actors in the ATM exercise.
• 3 minutes

12
Here on Thursday

• Fix ATM description so that only withdraw on
  sufficient funds.

13
ATM Actors
14
Use Cases
A use case defines a sequence of actions
performed by a system that yields an observable
result of value to an actor.
15
Use Cases

• A use case is always initiated by an actor.
• A use case provides value to an actor.
• A use case is complete.

16
Use Cases

• A use case is always initiated by an actor.
• Is always performed on behalf of an actor.
• Actor must directly or indirectly initiate the
  use case.
• A use case provides value to an actor.
• A use case is complete.

17
Use Cases

• A use case is always initiated by an actor.
• A use case provides value to an actor.
• The use case must deliver some tangible value to
  an actor.
• A use case is complete.

18
Use Cases

• A use case is always initiated by an actor.
• A use case provides value to an actor.
• A use case is complete.
• A use case is a complete description.
• A use case is not complete until the end value is
  produced.

19
For Each Actor, Ask the Following Questions

• What are the primary tasks the actor wants the
  system to perform?
• Will the actor create, store, change, remove,
  or read data in the system?
• Will the actor need to inform the system about
  sudden, external changes?
• Does the actor need to be informed about certain
  occurrences in the system?
• Will the actor perform a system startup or
  termination?

20
Think About Data

• Who creates it?
• Who displays or uses it?
• Who updates or modifies it?
• Who deletes it?
• These are typical use cases for data objects in
  the system.

21
Candidate Use Cases Must Be For the Actor

• Rule 1 Be sure the use case provides value to
  the actor.

22
Task

• Identify the main use cases of the ATM system.
• 3 minutes

23
Main Use Cases
24
Task

• Identify the main use cases for Gas Pump.
• 3 minutes

25
Gas Pump Use Cases

• Pump gas

26
Documenting Use Cases

• Use case diagrams consisting of
• system
• actors
• use cases

system boundary
Goldmine
use case
ltltincludegtgt
actor
ltltincludegtgt
ltltextendgtgt
27
Use Case Diagram System

• Diagram starts with a
• bounding box
• and a subject
• Goal determine the boundaries of the system,
  i.e., whats in, whats out.

Cell-phone System
28
The Use-Cases ModelMajor Concepts

• An actor represents an external entity that
  interacts with the system.
• A use case defines a sequence of actions
  performed by a system that yields an observable
  result of value to an actor.

Actor
Use case
29
Actor Icons
These are the same, but the class rectangle is
almost never used in use case diagrams.
Borrower
ltltactorgtgt Borrower
30
A Sample System
Cell-phone System
Callee
Caller
Non-network provider
Customer
Billing manager
A model of what the system is supposed to do (use
case), and the systems surroundings (actors).
31
Task

• Draw the Use Case Diagram for ATM.
• Time 5 minutes

32
Use Case Model

• Model of systems intended functions and its
  surrounding
• Answers the question what the system does to
  benefit users?
• Communicates the systems functionality and
  behavior to the customer or end user
• Use terminology that users understand.
• Verifies developers understanding of the system.
  
• Helps verify that all requirements are captured.

33
Use Case Model (Cont.)

• Identify external interactions
• Provides a basis for system design
• Provides a basis for system testing and
  walkthroughs
• Can help avoid requirements creep
• Well have to create a new use case and modify
  some existing ones
• Makes customers aware of impact of changes

34
So, Whats a Use Case?

• A scenario is a sequence of steps describing an
  interaction between a user and a system.
• The customer browses the catalog and adds
  desired items to the shopping basket. When the
  customer wishes to pay, the customer describes
  the shipping and credit card information and
  confirms the sale. The system checks the
  authorization on the credit card and confirms the
  sale both immediately and with a follow-up email.
• What if the credit card authorization fail? A
  separate scenario!

35
Use Cases (Cont.)

• A use case is a set of scenarios tied together by
  a common user goal (e.g., success and failure
  together, and other alternative paths).

36
An Example Use Case

• Main success scenarios along with alternatives
  and extensions

• Buy product
• Main Success Scenario
• Customer browses through catalog and select items
  to buy
• Customer goes to check out
• Customer fills in shipping information (address)
• System presents full pricing information,
  including shipping
• Customer fills in credit card information
• System authorizes purchase
• System confirms sale immediately
• System sends confirmation email to customer
• Extensions
• 3a Customer is a regular customer
• 3a1 System displays current shipping, pricing
  and billing information
• 3a2 Customer may accept or override these
  defaults, returns to MSS at step 6
• 6a System fails to authorize credit purchase
• 6a1 Customer may re-enter credit card
  information or may cancel.

37
Another Presentation
Buy product Main Success Scenario
Customer 1. Browses catalog and select items 2.
Goes to check out 3. Fills in shipping
information (address) 5. Customer fills in
credit card information
System 4. Presents full pricing
information 6. Authorizes purchase 7. Confirms
sale immediately 8. Sends confirmation email to
customer
Extensions 3a Customer is a regular
customer 3a1 System displays current shipping,
pricing and billing information 3a2 Customer
may accept or override these defaults, returns to
MSS at step 6 6a System fails to authorize
credit purchase 6a1 Customer may re-enter
credit card information or may cancel.
38
Scenarios - Flow of Events

• Represents what system does, not how the system
  performs behavior
• Should be clear enough for outsider to understand
• Guidelines
• How use case starts and ends
• What data is exchanged between actor and use case
• Do not describe details of user interface
• Describe flow of events, not only functionality
• Do not describe what happens outside the system
• Avoid vague terminology (etc. information)

39
Documenting Use Cases

• Not part of UML but include (see template)
• Brief description describe the overall intent of
  the use case
• Preconditions conditions that must be true
  before the use case can begin to execute
• Basic flow used to capture the normal flow of
  execution through the use case
• Alternative flows used to capture variations to
  the basic flows, such as decisions or error
  conditions.
• Postconditions conditions that must be true for
  the use case to complete.

40
Scenario 1 Place Call

• Preconditions A caller wants to make a call to a
  callee. The cell phone is on and connected to a
  cell phone network. The phone is idle.
• Postconditions On successful completion, the
  phone is idle. The caller has been connected to
  the callee for voice communication.
• Actors Caller, Callee, Network Provider

41
Scenario 1 Place Call

1. The caller activates the call option. (this may
   be by opening the phone or selecting some UI
   element.)
2. The system displays a blank list of digits and
   indicates it is in call mode.
3. The user enters digits (ALT 1).
4. The system displays the entered digits.
5. The user selects the dial option (ALT 2).
6. The system sends the sequence of digits to the
   network provider.
7. The network provider accesses the network and
   makes a connection (ALT 3, ALT 4).
8. The callee answers (ALT 5).
9. The network provider completes the voice
   connection.
10. The caller and callee engage in voice
    communications.
11. The caller hangs up (ALT 6).
12. The system returns to idle mode.
13. End of Use Case.

42
Scenario 1 Place Call

• ALT 1 The user uses speed dial.
• A1-1 The user enters a single digit and
  selects dial.
• A1-2 The system accesses the phone number
  associated with the digit (ALT 1.1).
• A1-3 Use case continues at step 6.
• ALT 1.1 No speed dial number is associated with
  the entered digit.
• A1.1-1 The system ignores the dial command
  and displays the digit.
• A1.1-2 Use case continues at step 4.
• ALT 2 The user cancels the operation.
• A2-1 Use case continues at step 12.

43
Task

• Write the use case scenario for Withdraw.
• Include alternative flows.
• 10 minutes

44
More on UML Use Case Diagrams

• Relationships
• Association between an actor and a use case
• Dependency between two use cases
• Generalization between two actors
• Generalization between two use cases

45
Actor and Use Case

• Indicate participation of actors in use cases
• Optional direction indicating the initiator of
  the use case, e.g.,

Place Call
Caller
Callee
46
Actor Generalization
Generalization can be used to clarify the model
when users have common behaviors however,
systems are frequently best understood by
understanding a person plays more than one role.
Registered User
Borrower
Manager
47
Include Relationship

• Withdraw Cash
• IC1
• for identifying customer
• ICm
• W1
• for withdrawing cash
• Wn
• Deposit Cash
• IC1
• for identifying customer
• ICm
• D1
• for depositing cash
• Dn

48
Include Relationship

• Used as follows
• Factor out behavior that is common for 2 use
  cases.
• Factor out behavior from base use case if not
  necessary for understanding of primary purpose of
  use case.
• Description
• Define location within the behavior sequence of
  base case where inclusion is to be inserted, e.g.
• includes the Identify Customer use case to
  determine the identity of the customer, or
• includeIdentify Customer.

Identify Customer
ltltincludegtgt
ltltincludegtgt
ltltincludegtgt
Withdraw Cash
Deposit Cash
Transfer Funds
49
Extend Relationship

• Enroll In University
• I1
• Im
• C1
• if intl student
• Cn
• Im1
• Iml

50
Extend Relationship

• Used to
• Show that a part of a use case is optional
• Show that a subflow is executed only under
  certain conditions
• Show that there may be set of behavior segments
  that are inserted depending on interaction with
  actors

Enroll in University
Student
ltltextendgtgt
Check Security
51
Extend Relationship Description

• Each extend relationship has a list of references
  to extension points in the base case.
• Extension points are referenced by name.
• Example
• Condition The student is an international
  student.
• Extension Points International Student insert
  the whole use case
• In main flow of events, show the extension point
  as follows (Ext 1 International Student).

52
Use Case Generalization

• Use when two or more use cases have commonalities
  in behavior, structure, or purpose.
• Describe in child spec how behavior sequences
  from the parents are interleaved with the child.

Place Order
Phone Order
Internet Order
Customer
Internet Customer
53
Use Case Relationships
Request Catalog
ltltincludegtgt
Place Order
ltltextendgtgt
Pay
Extends Insertion of additional behavior into a
use case that does not know about it.
Credit Card
Cash
Generalization relationship between general case
and specific case that adds features to the
general case
54
Difference Between Include And Extend

• Include
• Several use cases have common action.
• Action is not a use case on its own.
• Factor common action and include.
• Always included and explicit
• Extends
• Use case has as part of its action all of another
  use case.
• This use case provides service beyond other use
  case.
• Optionally extended and implicit

55
Stages of Use Case Construction

• Identify most important interactions
• Fill in use cases
• Triggers, pre and post conditions, basic course
  of events, document exceptions
• Break out detailed use cases
• Focus
• Clarify scope, separate essential from
  non-essential, eliminate duplicates, focused and
  detailed scenarios.

56
Candidate Use Cases Verbs

• Strong verbs
• Create, remove, merge, defer, switch, calculate,
  pay, credit, register, deactivate, review, view,
  enter, change, combine, release, search, migrate,
  receive, debit, activate, archive, browse
• Weak verbs
• Make, report, use, organize, record, find,
  process, maintain, display, list, input

57
Style Notes (Ambler, 2005)

• Use case names begin with strong verbs.
• While use cases do not imply timing, order cases
  from top to bottom to imply timing (improves
  readability).
• The primary actors should appear in the top left.
• Actors are associated with one or more use cases.
  
• Do not use arrows on the actor-use case
  relationship.
• Include an actor called time to initiate
  scheduled events.
• Do not show actors interacting with each other.
• Apply ltltincludegtgt when you know exactly when to
  invoke the use case. These should rarely nest
  more than 2 deep.
• Avoid using ltltextendgtgt.

58
Subflows parts

• Extract parts of flow of events and describe
  these separately.
• Alternative flow of events within base case
  (variant, option, exception)
• Explicit inclusion in base case
  (include-relationship)
• Implicit inclusion in base case
  (extend-relationship)
• Separate subflow (e.g., Maintain Employee
  Information may have subflows for adding or
  deleting)

59
Subflows

• Flow may consist of several subflows.
• Subflows can be reused in other use cases.
• Avoid if-then-else constructs pseudocode
• Extract parts of flow of events and describe
  these separately.