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
Devil’s 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. Actors Help 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?
Don’t 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
system boundary
Goldmine
User
Register
use case
Student
Check Grades
<<include>>
Validate User
actor
Get Roster
<<include>>
Faculty
<<extend>>
Enter Grades

27. Use Case Diagram: System
Diagram starts with a
bounding box
and a subject
Goal: determine the boundaries of the system, i.e., what’s in, what’s out.
Cell-phone System

28. The Use-Cases Model Major 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
<<actor>>
Borrower

30. A Sample System
Cell-phone System
Place Call
Callee
Caller
Text Message
Non-network
provider
Bill Customer
Customer
Billing manager
A model of what the system is supposed to do (use case), and the system’s surroundings (actors).

31. Task
Draw the Use Case Diagram for ATM.
Time: 5 minutes

32. Use Case Model
Model of system’s intended functions and its surrounding
Answers the question “what the system does to benefit users?”
Communicates the system’s functionality and behavior to the customer or end user
Use terminology that users understand.
Verifies developer’s 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
“We’ll have to create a new use case and modify some existing ones …”
Makes customers aware of impact of changes

34. So, What’s 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 .
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 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 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
The caller activates the “call” option. (this may be by opening the phone or selecting some UI element.)
The system displays a blank list of digits and indicates it is in “call” mode.
The user enters digits (ALT 1).
The system displays the entered digits.
The user selects the “dial” option (ALT 2).
The system sends the sequence of digits to the network provider.
The network provider accesses the network and makes a connection (ALT 3, ALT 4).
The callee answers (ALT 5).
The network provider completes the voice connection.
The caller and callee engage in voice communications.
The caller hangs up (ALT 6).
The system returns to idle mode.
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
Manager
Borrower

47. “Include” Relationship
Withdraw
Cash
Deposit
Cash
Withdraw Cash
IC1
… for identifying customer
ICm W1
… for withdrawing cash Wn
Deposit Cash D1
… for depositing cash Dn
Withdraw Cash
include::Identify Customer W1 … Wn
Deposit Cash
include::identify Customer D1 Dn
Identify Customer
IC1
ICm
Withdraw
Cash
Deposit
Identify
Customer
<<include>>

48. Include Relationship Used as follows: Description
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
include::Identify Customer.
Identify
Customer
<<include>>
<<include>>
<<include>>
Withdraw
Cash
Deposit
Cash
Transfer
Funds

49. “Extend” Relationship
Enroll
In Univ.
Enroll In University I1 … Im
(Ext: int’l student)
Im+1
Im+l
Check Security C1 Cn
Check
Security
Enroll
In Univ
<<extend>>
Enroll In University I1 … Im C1
… if int’l student Cn
Im+1
Im+l

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
<<extend>>
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
<<include>>
Place
Order
<<extend>>
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
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
Favor the strong verb over weak ones. Be sure the use case provides value to the actor.

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 <<include>> when you know exactly when to invoke the use case. These should rarely nest more than 2 deep.
Avoid using <<extend>>.

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.