1. UML Use Case Diagrams

2. Use Cases Use case modeling captures functional requirements
Identifies what users intend to do with software systems
Used in requirements elicitation and analysis, and can be part of specifications
“Actor’s” perspective of how the system is used

3. Use Case Approach to Modeling
There are two things involved in modeling with use cases:
the use case diagram
provides visual overview of important interactions
captures scope (identifies external entities)
the use case text
documents in a textual form the details of the requirements, what the use case must do. 3

4. Use Cases Actors: things outside of the system Use Cases:
Actors are classes
Not restricted to humans
Use Cases:
What the system should do
Sequences of interactions between actors and the system; also known as “scenarios” 4 4

5. Use Case Diagram System Boundary “Participates-In” association UseCase
Actor
UseCase
“Participates-In” association 5 5

6. Scenarios
A scenario is an example of what happens when an actor interacts with a “system”. A use case describes a scenario.
Typical Scenario:
A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot.
Alternative Scenario:
A patient calls the clinic to make an appointment for a yearly checkup. The receptionist cannot find the patient in their database. They are scheduled as a new patient.
Exceptional Scenario:
A patient calls the clinic to make an appointment for a yearly checkup. The phone disconnects before the process is complete. 6 6

7. More Scenarios ATM: Validate User
Typical scenario: The use case starts when the system prompts the Customer for a PIN. The customer can now enter a PIN on the keypad. The customer commits the entry by pressing Enter. The system checks the PIN number to see if it is valid. If valid, the system acknowledges the user and the use case ends.
Exceptional scenario: The customer can cancel a transaction at any time by pressing the cancel button.
Exceptional scenario: The customer enters an invalid PIN and the use case restarts. After three attempts the system cancels the transaction and is frozen for 60 seconds. 7 7

8. Example Use Cases for a Student Information System
Obtain Student Grant
Obtain Student Loan
Pay Course Fees
Reimburse Course Fees
Enroll in Class
Drop Class
Distribute transcripts 8 8

9. Use Cases for Student Info. System9 9

10. Enlarging on Use Cases Actor Special Actor Special Actor Customer
Commercial
Residential
Actor
Generalization
Special
Actor
Special
Actor

11. Factors use cases into additional ones
Example
Base Use Case
Specializes
base cases
into cases that do more
Validate
User
Place
Order
<<includes>>
Handle
Rush Order
<<extends>>
<<extends>>
Extending Use
Case
Base Use Case
Factors use cases into additional ones
<<includes>>
Included Use
Case

12. Includes vs Extends
Use “extends” when you are describing a variation on normal behavior
Use “includes” when you are repeating yourself in two or more separate use cases and you want to avoid repetition.

13. Use Case Text: High Level Use Case
Use case: Enroll in Class
Actors: Student, Registrar
Description: A student, logged in to the registration
system, selects a class and requests
“enroll”. Notification is sent to the
registrar’s office.

14. Use Case Text: Expanded Use Case
Use case: Enroll in Class
Actors: Student, Registrar
Overview: A student, logged in to the registration
system, selects a class and requests
“enroll”. Notification is sent to the registrar’s office.
Actor Action 1. This use case begins when a student is in the “register for class” section of the system. 2. The student selects a class 3. The student requests enroll 7. Receive result
System Response 4. The system determines whether space is available in the class. 5. If space is available, update registrar’s database and student record. 6. Inform student of result

15. Use Case Hints Begin with good scenarios
Each use case should name a single, identifiable and reasonably atomic behavior
Use language of user
Describe flow of events clearly enough so outsider can follow
Show only actors that relate to use cases
Specify actor names by specific roles
Avoid implementation details

16. Use Case Hints
Factor common behavior by pulling it out into <<include>> use cases
Factor variants by pushing such behavior into <<extend>> use cases
Show only use cases that are important to understand system functionality
Use top level diagram to show context
Decompose top-level use cases to show requirements

17. Example: Point-of-Sale System
Identify actors and use cases
Write high level use case descriptions (include scenarios)
Draw basic use case diagram
Write expanded use case descriptions (at least for primary use cases)
Refine use case diagram

18. 1. Identify Actors and Use Cases
Cashier
Customer
Manager
System Admin.
Use Cases:
Log In
Cash Out
Buy Items
Refund Items
Start Up
Shut Down
Manage Users

19. 1. Identify Actors and Use Cases
Cashier
Customer
Manager
System Admin.
Use Cases:
Log In
Cash Out
Buy Items
Refund Items
Start Up
Shut Down
Manage Users

20. 2. Write High-Level Use Case Descriptions
Use case: Actors: Description:
Buy Items
Customer, Cashier
A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects a payment. On completion, the Customer leaves with the items.

21. 2. Write High-Level Use Case Descriptions
Use case: Actors: Description:
Start Up
Manager
A Manager powers on a terminal to prepare it for use by Cashiers. The Manager validates that the date and time are correct, after which the system is ready for cashier use.

22. 3. Draw Basic Use Case Diagram
Buy Items
Customer
Cashier
Log In
Refund Items
Start Up
Sys Admin
Manager
Manage Users
Etc.

23. 4. Write Expanded Use Case Description (page 1 of 2 – continued on the next page)
Use case: Buy Items
Actors: Customer, Cashier
Overview: A Customer arrives at a checkout with items to purchase.
The Cashier records the purchase items and collects a payment.
On completion, the Customer leaves with the items.
Actor Action
1. This use case begins when a Customer arrives at a terminal with items to purchase.
2. The Cashier records each item. If there is more than one of an item the Cashier can enter the quantity as well.
4. On completion of item entry, the Cashier indicates to the terminal that item entry is complete.
6. The Cashier tells the Customer the total.
System Response
3. Determines the item price and adds item information to the running sales transaction The description and price of the current item are presented.
5. Calculates and presents the sale total.

24. 4. Write Expanded Use Case Description (page 2 of 2 – continued from prior page)
Actor Action
7. Customer chooses payment type:
a. if cash, see section “Pay by Cash”
b. if credit, see section “Pay by Credit”
c. if check, see section “Pay by Check”
11. Cashier gives the receipt to the Customer
12. Customer leaves with items purchased.
System Response
8. Logs the completed sale.
9. Updates inventory levels.
10. Generates a receipt.
Alternative Courses
Line 2: Invalid item identifier entered. Indicate error.
Line 7: Customer could not pay. Cancel sales transaction.

25. 5. Refine Use Case Diagram
Buy Items
Customer
Cashier
<<extends>>
<<extends>>
<<extends>>
Pay Cash
Pay Credit
Pay Check
Log In
Refund Items
Sys Admin
Manager
Start Up
Manage Users
Etc.

26. Short Exercise
We’re going to add a scenario to the Point of Sale system: handle robbery
A key ingredient: a “hot key” sequence for opening the terminal to access money also happens to send a silent alarm to mall security and to a nearby police station
How does the Use Case Diagram change?
What would a description of the use case look like?