1. Use cases

2. Applying UML and Patterns :Craig Larman

3. N
Overview
Use cases describe domain processes in a structured prose format.
We explore basic skills.
Definitions.
Notation.
Guidelines.
Practice.

4. Objectives Read and create high-level and expanded format use cases.
Distinguish between essential and real use cases.

5. Use cases They are used to discover and record requirements.
Use cases are not diagrams they are text documents.
Use cases are one way of capturing the functional requirements.
Use cases are text stories
of some actors using a
system to meet goals.

6. MOTIVATION: Comprehensible & Familiar
Use cases are stories.
A simple and familiar model that many people, especially non-technical, can easily relate to.

7. Use Cases
They are a collection of related success and failure scenarios that describe an actor using a system to satisfy a goal.
They must return an observable value to a particular actor.

8. scenarios A scenario is also called a use case instance.
It is a specific sequence of actions and interactions between actors and the system. or
It is one path through the system.

9. Actor An actor is someone with behavior.
Think of actors in terms of Roles rather than job titles.
Actors carry out use cases.
A single actor carries out many use cases and many roles.
There is one Primary actor and possibly several secondary actors.

10. Actors Actors can be: Roles of humans. Example: A Patron.
Other computer systems. Example: The Visa network.

11. The three Common formats for Use cases.
Brief: One paragraph summary of the main success scenario.
Casual: multiple paragraphs that covers various scenarios.
Fully dressed: All steps and sections are written in detail, and there are supporting sections such as preconditions and success guarantees. Also known as the expanded format.

12. Brief Use Case
Name: Borrow Resources Actors: Patron (initiator), Librarian Description: The use case begins when the Patron arrives at the check-out with books and videos to borrow and submits them to the Librarian, who records the resources borrowed. The Patron then leaves with the resources.

13. Use Case Diagrams

14. Sample High-Level Primary Use Cases
Name: Add Resources.
Actors: Librarian.
Description: The use case begins when the Librarian receives new resources (books and videos) to add to the catalog. The title,
call number, and other information are recorded. Then the resources are placed on a shelf organized by resource type and call numbers.

15. Sample High-Level Primary Use Cases
Other possible use cases.
Return a Resource.
Delete a Resource.
Notify Overdue Patrons.
Collect Fines.

16. GUIDELINES: Use Case Modeling
It is common to group CRUD (Create, Read, Update, Delete) operations into one use case.
Manage Users
Name starts with a verb.
All systems have a Start Up and Shut Down use case (perhaps trivial and low level).

17. Abstraction Levels of Use Cases

18. Essential versus Real Use Cases

19. Expanded Format Use Cases
Describe the use case in greater detail.
Can be written essential or real.
Have the following components:
Name.
Starts with a verb.
Description.
From the high-level use case.
Actors.
Initiator and participants from high-level use case.
Type.
If decomposed, then super / sub (abstract).
Also, primary / secondary, and essential / real.

20. Expanded Format Use Cases (continued)
Have the following components (continued):
Cross-references.
Related use cases and system functions.
Preconditions.
Assumptions that must hold true.
Stakeholders and their interests.
Typical Course of Events.
Most important section describes regular flow of events.
Alternatives.
Exceptional alternatives that might arise.
Special requirements. : related non-functional requirements.
Technology and data variation
Frequency.
Open Issues.

21. EBP for Use Case Levels
Focus on use cases at the level of EBPs.
“A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.”
Naively, can you apply the “boss test” for an EBP?

22. Here’s one in a brief format:
Rent Videos. A Customer arrives with videos to rent. The Clerk enters their ID, and each video ID. The System outputs information on each. The Clerk requests the rental report. The System outputs it, which is given to the Customer with their videos.

23. EBP for Use Case Levels Boss: “What do you do all day?”
For example, how do we know which of these is at a useful level?
Negotiate a Supplier Contract
Rent Videos
Log In
Start Up
Boss: “What do you do all day?”
Me: “I logged in!”
Is Boss happy?

24. Size for Use Case Levels
An EBP-level use case usually is composed of several steps, not just one or two.
It isn’t a single step.
Applying the EBP and size guidelines:
Negotiate a Supplier Contract
Rent Videos
Log In
Start Up
The others can also be modeled as use cases.
But, prefer a focus on the EBP level.

25. Use Case Diagrams

26. GUIDELINES: Use Case Diagrams

27. EXAMPLE: Fully Dressed
Use Case UC1: Rent Video
Level: User-level goal (EBP level)
Primary Actor: Clerk
Preconditions:
Clerk is identified and authenticated.
Stakeholders and their Interests:
Clerk: Wants accurate, fast entry.
Customer: Wants videos, and fast service with minimal effort.
Accountant: Wants to accurately record transactions.
Marketing: Wants to track customer habits.

28. EXAMPLE: Fully Dressed
Main Success Scenario (or Basic Flow or “Happy Path”):
Customer arrives at a checkout with videos or games to rent.
Clerk enters Customer ID.
Clerk enters rental identifier.
System records rental line item and presents item description.(Clerk repeats steps 3-4 until indicates done.)
System displays total.
Customer pays. System handles payment.
Clerk requests rental report.
System outputs it. Clerk gives it to Customer.
Customer leaves with rentals and report.

29. EXAMPLE: Fully Dressed
Extensions (or Alternatives):
a*. At any time, System fails:
Clerk restarts System
logs in
requests recovery from prior state
1a. New Customer.
1. Perform use case Manage Membership.
2a. Customer ID not found.
1. Cashier verifies ID. If entry error, reenter, else Manage Membership.
2b. Customer has unpaid fines (usually for late returns).
1. Pay Fines.

30. EXAMPLE: Fully Dressed
Special Requirements:
Language internationalization on the display messages and rental report.
Large text on display. Visible from 1 m.
Technology and Data Variations:
ID entries by bar code scanner or keyboard.
Frequency:
Near continuous
Open Issues:
Should we support a magnetic stripe cards for customer ID, and allow customer to directly use card reader?

31. Use-Case Miscellany
The first line of a use case course of events should describe the event that starts the use case.
Example: This use case begins when the <actor> <generates an input event>
Start the use-case name with a verb.
Purchase …
Borrow …

32. generalization
A use case generalization shows that one use case is simply a special kind of another.
A child can be substituted for its parent whenever necessary.
Generalization appears as a line with a triangular arrow head toward the parent use case.

33. Include relationships
Includes are especially helpful when the same use case can be factored out of two different use cases.
In the diagram, include notation is a dotted line beginning at base use case ending with an arrows pointing to the include use case. The dotted line is labeled <<include>>.

34. extend relationship
An extend relationship indicates that one use case is a variation of another.
Extend notation is a dotted line, labeled <<extend>>, and with an arrow toward the base case.
The extension point, which determines when the extended case is appropriate, is written inside the base case.