1. A use case describes one “case” of how a user can use the system.
informal definition:
A use case describes one “case” of how a user can use the system.
– i.e., a ‘system service’ that the user can request from the system.
example:
Register Club Member
Order Vehicle Model
UML definition:
A use case is a sequence of actions performed by a system that yields an observable result of value to a particular actor.

2. Use Case documentation ~ the initial elements
writing up the Use Case...
For example:
Use Case name:
Order Vehicle Model
Use Case summary, in terms of a brief description of:
the nature of what the actor needs (the system) to do
the observable result of value to the actor
For example, In “Order Vehicle Model” the actor wishes to ...
add more vehicles of a particular model into EU-Rent’s vehicle inventory,
increasing the model’s vehicle-count of the model’s.
More detail will be added (later).
system action (execution of some computation or algorithmic procedure), invoked when:
an actor signals (sends a request) to the system, or
the system gets a scheduled request. [k94]
For example:
Use Case name:
Withdraw Money
Nature of the initiating request:
The use-case begins when the Customer inserts an ATM card into the ATM's reader. The System reads and validates the information on the card.
Use Case description:
the authorized removal of money from an account, debiting the account's balances by the amount of the withdrawal and issuing funds in the withdrawal amount.

3. Use Cases
the 6 most important things to know about a Use Case model:
What a Use Case is NOT
Where does ‘Use Case’ fit in the development process?
What are the basic elements of a Use Case?
How do I draw a Use Case as a diagram?
How do I discover Use Cases?
After the basics, how do I refine a Use Case?

4. How do I discover Use Cases?
Business Workflow
Decide the activities in the Business Workflow that call for system support.
These will become our initial “use cases.”
It can be hard to decide whether a set of actor-system interactions is a single use-case or several use-cases.
Why wasn't prompting for the PIN and validating it a complete use-case?
"Use cases emerge when you focus on the things of value that a system provides to an actor." ~ Kruchten [k100]
These "valued outputs" come in two flavors:
1 the Information Requirements
providing critical outputs from the system
2 the Information Updates
keeping the system data used in (1) current and correct

5. Swimlane - UML definition
Business Workflow
Describes business activities and workers
Drawn as Swimlanes
Swimlane - UML definition
A partion on an activity diagram for organizing the responsibilities for actions. Swimlanes typically correspond to organizational units in a business model.

6. Loyalty Program business workflow as swimlanes diagram

7. Loyalty Program business workflow, annotated with system support points

8. Loyalty Program Use Cases

9. After the basics, how do I refine a Use Case?
In addition to the associations between actors and use-cases, you can link use-cases:
using stereotype extensions:
the <<include>> stereotype
the <<extend>> stereotype
using use-case generalization / specialization
used to describe a specific form of a more general use-case.
In our work, we will only use the two stereotype extensions.

10. Refinement via stereotype
UML has standard features to customize / extend the language.
The Guillemet character denotes a stereotype extension.
<< >>
2 stereotype extensions are used to define relationships between Use Cases:
<<include>>
<<extend>>
Note: “UML trivia” ~ a Guillemet is a single symbol, not two ‘less-than’ or two ‘greater-than’ characters.
UML has standard features to customize / extend the language.
The Guillemet character denotes a stereotype extension.
2 stereotype extensions define relationships between use-cases:
<<include>>
<<extend>>
UML snobs point out that this is a single symbol, not two less-than or greater-than characters.

11. Inventory Management

12. The Use Case <<include>>
use <<include>> if you find you are repeating actions in two or more separate use-cases and you want to “factor out” the common actions into one use-case that can be used in many places.
For example,
You may find that the ”List Vehicle Model" use-case in the Inventory Management system also includes the step of listing the groups and models.
This can be factored out into a "Produce Rental Group Summary " use-case which is related to each of the including use-cases.
use <<include>> if you find you are repeating actions in two or more separate use-cases and you want to factor out the repeating actions into a reusable use-case.
For example,
You may find that the "Check Balance" use-case in the ATM system also includes the step "System prints receipt."
This can be factored out into a "Print receipt" use-case which is related to each of the including use-cases.
<graphic>
Identify New
Rental Group
<<include>>
Produce Rental
Group Summary
List Vehicle Model
<<include>>

13. The Use Case <<extend>>
use <<extend>> when you need to describe a conditional variation of a base case.
The “extension points” will be defined in that base case.
For example,
Discounting a model sometimes involves handling any vehicles that remain on the rental lots.
This is used primarily to represent optional behavior, to handle exceptions, or to simplify complex event flows.
use <<extend>> if you need to describe a conditional variation of a base case, with extension points defined in that base case.
For example,
The third entry of an invalid PIN might retain the card and trigger an activity in a security violation use-case.
<graphic>
This is used primarily to represent optional behavior, to handle exceptions, or to simplify complex event flows.
Discountine
vehicle model
Handle existing vehicle
<<extend>>

14. How do we know one big use case or two little ones?
Where do we go from here?
Once identified, it can still be hard to decide whether a set of actor- system interactions is a single use-case or several use-cases.
How do we know one big use case or two little ones?
"Use cases emerge when you focus on the things of value that a system provides to an actor." ~ Kruchten
We focus on these "valued outputs" by analyzing the “Information Requirements” of the system, in two flavors:
(1) the Information Queries
providing critical outputs from the system
(2) the Information Updates
keeping the system data used in (1) current and correct
Next Lessons...
It can be hard to decide whether a set of actor-system interactions is a single use-case or several use-cases.
Why wasn't prompting for the PIN and validating it a complete use-case?
"Use cases emerge when you focus on the things of value that a system provides to an actor." ~ Kruchten [k100]
These "valued outputs" come in two flavors:
1 the Information Requirements
providing critical outputs from the system
2 the Information Updates
keeping the system data used in (1) current and correct