Use-Cases

Outline Introduction Use Case Diagrams Writing Use Cases

Use Cases Register User Illustration Register User admin Use case in diagram Use Case in script A use case is a contract of an interaction between the system and an actor. A full use-case model comprise of: A diagram, describing relations between use-cases and actors. A document describing the use case in details Use cases are essentially a contract, which can be used for testing. More use cases in the cellphone example: Cell migration HTML sites viewing Email integration …

Use Case Diagram Objective Create a semi-formal model of the functional requirements Analyze and define: Scope External interfaces Scenarios and reactions

Outline Introduction Use Case Diagrams Writing Use Cases Guidelines for Effective Use Cases

What’s in a Use Case Model? Diagram Use Case Defines a sequence of actions performed by a system that yields an observable result of value to the actor Actor Someone or something outside the system acting in a role that interacts with the system. Could be a human or another system. Actor Detailed textual actor and Use Case report descriptions (99% of the effort) Summarised as Use Case Model diagram (1% of the effort) Use Case

A Simple Example Example Actors System boundary Association Use Case

Use Case Model: Identify Example use case: Name: Submit Timesheet Brief Description: The consultant enters details of the number of hours worked and the activities worked on, then confirms and submits the timesheet. Each Actor and Use Case needs a brief description. Actor Briefly state its role, goals and responsibilities in relation to the system. Use Case Briefly summarise what takes place in the use case, giving an indication of its scope. Example actor: Name: Consultant Brief Description: The consultant updates their daily timesheet and expense information and gets status reports. Consultant System Project Manager Submit Timesheet Complete Timesheets Use Case Name The name should be: Brief Unique Written as an active verb Meaningful You should be able to tell what the actor wants to achieve in the use case from its name. Project Accounting

Linking Use-Cases Three mechanism are used: Include Extend Inheritance

Alistair Cockburn “Writing Effective Use Cases” Use-Case Levels Base Use Case: Used directly by the user Perform Sale User goals Sub-functionality Choose Products Fill-in billing info One of the main utilizations for linking mechanisms is to distinguish between use-case levels. Alistair Cockburn “Writing Effective Use Cases”

The “Include” Construct Include is used when: Decomposing complicated behavior Centralizing common behavior The base use case explicitly incorporates the behavior of another use case at a location specified in the base. Example Perform Sale Fill-in billing info <<include>>

Extend – Graphical Representation The base use case can incorporate another use case at certain points, called extension points. Note the direction of the arrow The base use-case does not know which use-case extends it Example <<extend>> Product is a gift Gift wrap Products Perform Sale After checkout

Example: Amazon Shopping Cart Product Page Review Writing TODO: add a search page before the product page Think of Amazon, which functions are there. List them, and try to create a use-case from them. Review Writing

Example – cont’d Write Review Rank Supplier Search Product «extend» Search Product View Product Details «include» Write Review After page generation Navigate Deals «extend» «include» Add to cart «extend» Checkout «include» «extend» user is not a member Important points: Note that weak relations between use-cases are not mentioned. For instance, add to cart provides products to checkout, but the relation is not modeled. Also, the hierarchy between use-cases originates from the user perspective: Even though “View Product Details” is the central component from the programmers point of view, the user wants to search products or to see deals, and that the top use-case. Use extend when: You want to leave the important UC as simple as possible For flexibility: we want to be able to add more features to important UCses. When the extending UC is rare, it does not always happen. Login Register Handle Order Status «include»

Outline Introduction Use Case Diagrams Writing Use Cases Guidelines for Effective Use Cases

Structure of a Use Case Specification Name Actors Trigger Preconditions Post conditions Success Scenario Alternatives flows

Triggers What starts the use-case? Examples: Customer reports a claim Customer inserts card System clock is 10:00pm

Preconditions What the system needs to be true before running the use-case. Examples User account exists User has enough money in her account There is enough disk space

Post-Conditions A post-condition is the outcome of the use-case. Examples Money was transferred to the user account User is logged in The file is saved to the hard-disk

Success Scenario The success scenario is the main story-line of the use-case It is written under the assumption that everything is okay, no errors or problems occur, and it leads directly to the desired outcome of the use-case It is composed of a sequence of action steps Example: Interaction step Administrator enters course name, code and description System validates course code System adds the course to the db and shows a confirmation message Validation Step Internal Change Step (plus) Interaction Step

Use-Cases – Common Mistakes Complex diagram No system No actor Too many user interface details “User types ID and password, clicks OK or hits Enter” Very low goal details User provides name User provides address User provides telephone number …

Alternative Flows Starting points Success Scenario Used to describe exceptional functionality Examples: Errors Unusual or rare cases Failures Starting points Endpoints Shortcuts Shortcuts Exceptions Endpoints

Alternative Flows - Example Errors: “Case did not eject properly” “Any network error occurred during steps 4-7” “Any type of error occurred” Unusual or rare cases “Credit card is defined as stolen” “User selects to add a new word to the dictionary” Endpoints “The system detects no more open issues” Shortcuts: “The user can leave the use-case by clicking on the “esc” key An alternative success path (user uses a shortcut) A sequential behavior had ended (End-of-file) The first stage of a sequential behavior Actor behaves incorrectly (invalid course ID) Inaction by an actor (timeout) Every validation step (system validates…) Internal system failure, which is part of a normal business scenario (printer is stuck, network is unavailable) Unexpected and abnormal internal failure (no more memory)

Exercise I am the manager of a theatre. I want to create an automated movie ticket machine. You are analysts who need to describe what the customer wants as a set of use cases Simplifying assumptions: One movie showing at a time Movie time is same every day, only one time, same price Only manager can change/add movie Customer can only buy tickets Who or what are the actors? What are the use cases (goals of actors)?

Use case diagram for Movie Ticket Machine Why are there three Actors? Why three use cases for Customer? Which use cases look easy to write?

Use cases for Manager Use case: Set title Actors: Manager, Machine 1. Manager requests a change of movie title 2. Machine asks manager for new movie title 3. Manager enters movie title Use case: Set price 1. Manager requests a change of ticket price 2. Machine asks manager for new price for movie title 3. Manager enters ticket price Alternatives: Invalid price If manager enters price below $1 or greater than $10 3a. Machine asks manager to reenter price Use case: Set seats 1. Manager requests a change in number of seats 2. Machine asks manager for number of seats in theatre 3. Manager enters number of seats Alternatives: Invalid number of seats If manager enters number less than 20 or greater than 999 3a. Machine asks manager to reenter number of seats

Use cases for Customer Use case: # of tickets Actors: Customer, Machine 1. Customer enters number of tickets 2. Machine displays total balance due Alternative: Customer wants zero tickets At step 1, customer enters zero tickets 1a. Display thank you message 1b. Set balance to $0.0 Use case: Return change to customer 1. Customer requests change 2. Machine dispenses money 3. Machine updates customer balance Use case: Buy tickets Actors: Customer, Machine 1. Customer requests tickets 2. Machine tells customer to put balance due in money slot 3. Customer enters money in money slot 4. Machine updates customer balance 5. Customer requests tickets 6. Machine prints tickets 7. Machine updates number of seats Alternative: Insufficient seats At step 1, if number of tickets requested is less than available seats, 1a. Display message and end use case Alternative: Insufficient funds At step 5, if money entered < total cost, 5a. Display insufficient amount entered 5b. Go to step 3

In Summary Disciplined documentation of use case flows makes testing easier Use case flows combine as use case scenarios Use Case scenarios become test scenarios Test scenarios + data = test cases