UML Use Case Diagrams

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

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

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

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

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

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

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

Use Cases for Student Info. System 9 9

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

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

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.

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.

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

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

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

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

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

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

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.

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.

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

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.

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.

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.

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?