2. Definition –
What does Use Case mean?
• “A use case is a software and system engineering
term that describes how a user uses a system to
accomplish a particular goal. A use case acts as a
software modeling technique that defines the
features to be implemented and the resolution of
any errors that may be encountered.”
• http://www.techopedia.com/
3. Use cases define the system. They show
interactions between actors and the
system to create a working structure.
Although you might break them down to smaller
components, uses cases will show:
• Actors: Actors are the users that interact with
the system, can be human roles or system.
• Processes: Use cases show the processes that
actors use to show the intended behaviour of the
system.
• System: Use cases should show all the
processes, describing the activities for each actor
that match the system functional requirements.
5. ACTORS
Actors are the people who will interact
with the system, who does what.
Typically in a simple Use Case diagram, they
are depicted with stickmen.
7. ACTORS
The actors are annotated with their role..
Administrator
Operator
Customer
Client
Manager
8. ACTORS
Actors are not ALWAYS people, however you can still depict
them with stickmen.
Administrator
Administrator
Customer
Customer
Bank
Bank
Website Server
Website Server
10. SYSTEM
Ovals show each functional requirement
of the system, the steps or processes.
When we show these functional
requirements as a whole
process from start to finish we
show them inside the system
boundary.
11. SYSTEM
Select
Customer
We write the function in the ovals
Order System
Select
Customer
We give the overall process a
title to show what we are
depicting.
Create
Order
Select
Products
Take
Payment
12. SYSTEM
We show which actor interacts with each process
Order System
Select
Customer
Create Order
Select
Products
Phone Operator
Process
Payment
13. SYSTEM
Regardless of whether this is a two way process, we
show who initiates the process with an arrow.
Order System
Select
Customer
Create Order
Select
Products
Phone Operator
Process
Payment
14. SYSTEM
Information from the system is shown with an arrow
back to the user.
Order System
Select
Customer
Create Order
Select
Products
Phone Operator
Take
Payment
Order Status
15. SYSTEM
Often there are more than one user who interacts
with the system.
Online orders
Select
Customer
Create Order
Select
Products
Bank
Make
Payment
Payment
Authorisation
Process Order
Order Clerk
Confirm Order
Customer
17. INCLUDES
Sometimes a process has more steps to complete
that process. Note the direction of arrows.
Create
Order
<<include>>
Add
Delivery
Address
<<include>>
Select
Delivery
Option
18. INCLUDES
Sometimes a process has a lot more steps to
complete that process.
<<include>>
Create
Order
<<include>>
Add
Delivery
Address
Select
Delivery
Option
<<include>>
<<include>>
Add Billing
Address
Enter
Delivery
Notes
19. INCLUDES
We only show the include on the main process if it
does not become too confusing, the idea is to keep
it simple
Order System
Select
Customer
<<include>>
Search
Customer
Create Order
<<include>>
Delivery
Option
Phone Operator
Select
Products
Take
Payment
20. INCLUDES
Otherwise we show it separately
Order System
Select
Customer
Create Order
<<include>>
Create
Order
<<include>>
Add
Delivery
Address
Select
Delivery
Option
<<include>>
<<include>>
Select
Products
Phone Operator
Take
Payment
Add
Billing
Address
Enter
Delivery
Notes
Notice that this is not a FULL system, so we do NOT enclose it in
the system box.
21. INCLUDES
It is perfectly acceptable to show some important ‘include’ inside
the main system box, and some separately.
Order System
Select
Customer
<<include>>
Search
Customer
Create
Order
Phone
Operator
Select
Products
Take
Payment
<<include>>
Create
Order
<<include>>
Add
Delivery
Address
Select
Delivery
Option
<<include>>
<<include>>
Add
Billing
Address
Enter
Delivery
Notes
22. INCLUDES
It is also acceptable to show more than one set of breakdowns
outside the main system box.
Create
Order
<<include>>
Order System
Select
Customer
Add
Delivery
Address
<<include>>
Select
Delivery
Option
<<include>>
<<include>>
<<include>>
Add
Billing
Address
Search
Customer
Enter
Delivery
Notes
Create
Order
<<include>>
Phone
Operator
Select
Products
Select
Products
<<include>>
Search
Products
Enter
Quantity
<<include>>
<<include>>
Take
Payment
Select
size
Select
Colour
23. INCLUDES
Includes is used to show a process that is
always part of the parent process.
Is it a parent process or a child process?
• Try and think in levels.
• An order management process might be shown as
one process box in a larger system.
• Its child processes might include select customer,
create order, add products, take payment.
• The children of these process might include,
search customer, delivery type, quantity, etc.
• Think of titles for the overall process, that
becomes the parent.
25. EXTENDS
extend are
different to
include.
Includes means
that a process
IS made up of
smaller
processes.
extend means
a process
MIGHT include
more smaller
processes.
Sometimes a process has a step that it might
include to complete that process. Note the direction
of arrows.
Select
Customer
<<extend>>
Search by
Postcode
<<extend>>
New
Customer
26. EXTENDS
In this example,
an existing
customer might
order a lollypop
or beach ball.
No extend
required.
But if they were
a new
customer or
ordered a
chemical
product, more
processes
might be
required.
Sometimes a process might include a lot more
steps that could potentially be needed to complete
that process, but not always.
<<extend>>
Create
Order
<<extend>>
New
Customer
Include
COSH
<<extend>>
<<extend>>
Check
Licence
Check Age
Restrictions
27. EXTENDS
We only show the extend on the main process if it does
not become too confusing, the idea is to keep it simple.
Order System
Select
Customer
<<extend>>
New
Customer
Create Order
<<extend>>
Arrange
Air Mail
Phone Operator
Select
Products
Take
Payment
28. EXTENDS
Otherwise we show it separately
Order System
<<extend>>
Select
Customer
Create Order
Create
Order
<<extend>>
Safety
Instructions
Include
COSH
<<extend>>
<<extend>>
Select
Products
Phone Operator
Check
Licence
Check Age
Restrictions
Take
Payment
Notice that this is not a FULL system, so we do NOT enclose it in
the system box.
29. EXTENDS
It is perfectly acceptable to show some important ‘extend’ inside
the main system box, and some separately.
Order System
Select
Customer
<<extend>>
<<extend>>
New
Customer
Create
Order
Create
Order
<<extend>>
Safety
Instructions
Include
COSH
<<extend>>
<<extend>>
Phone
Operator
Select
Products
Take
Payment
Check
Licence
Check Age
Restrictions
30. EXTENDS
Note that you
can mix include
and extend.
It is also acceptable to show more than one set of breakdowns
outside the main system box.
Create
Order
<<include>>
Order System
Select
Customer
<<extend>>
Delivery
Options
Include
COSH
<<extend>>
<<extend>>
<<include>>
Search
Customer
Create
Order
Select
Products
<<extend>>
Check
Licence
New
Customer
<<include>>
Check Age
Restrictions
Select
Products
<<include>>
Search
Products
<<extend>>
<<extend>>
Phone
Operator
Take
Payment
Select
size
Select
Colour
Enter
Quantity
32. LEVELS
Where do I start? At what level am I
creating the use case for?
There is a difference between Business Level Use
Case and System Level Use Case:
• Business Level Use Case: Try to show the
whole business in its most simple forms including
all actors who will be included.
• System Level Use Case: Try to show the
system in complete processes. For example the
customer management system, the order system
or booking process.
33. LEVELS
Note that you
would show the
customers or
shareholders at
this level even
if they have no
direct contact
with the actual
system.
Business Use Case
Business use case is the top most level.
Sooooper shops Ltd
Orders
Customer
Order Clerk
Fulfil Orders
Manage
Database
Admin
Supplier
Invoices
Payments
Shares
Manager
Shareholder
34. LEVELS
Note that there
is a line to the
customer, yet
no arrow.
shows a data
transfer but no
initialisation.
Note also,
rather than
have lines
cross over
which would
confuse the
system, an
actor is just
repeated
A BUSINESS Use Case may show system, it will show
where the information comes from even if that actor has no
direct interaction with the system..
Orders System
Select
Customer
Order Clerk
Create
Order
Select
Products
Make
Payment
Bank
Payment
Authorisation
Process Order
Confirm Order
Order Clerk
Customer
35. Levels
Note that the
customer, is
shown on this
diagram to
clarify, but is
not necessary.
Note in this
system it is
clear that the
customer has
no direct
interaction.
A System Use Case will show a complete process rather
than an overall picture.
Orders System
Select
Customer
Create
Order
<Telephone
Order>
Order Clerk
Select
Products
Order Clerk
Make
Payment
Payment
Authorisation
<Confirm
Order>
Process Order
Customer
Confirm Order
Bank
Customer
36. LEVELS
A System Use Case will show a complete process rather
than an overall picture.
Orders System
The subtle
difference in
this Use Case
is that the
system sends
out a
confirmation
email direct to
the customer.
Select
Customer
Create
Order
<Telephone
Order>
Order Clerk
Select
Products
Order Clerk
Make
Payment
Payment
Authorisation
Process Order
Customer
Confirm Order
Bank
Customer
37. LEVELS
Remember to show the FULL system process including any
further levels of process.
Create
Order
<<include>>
Order System
Select
Customer
<<extend>>
Delivery
Options
Include
COSH
<<extend>>
<<extend>>
<<include>>
<<extend>>
Search
Customer
New
Customer
Create
Order
Phone
Operator
Select
Products
Check
Licence
<<include>>
Check Age
Restrictions
Select
Products
<<include>>
Search
Products
<<extend>>
<<extend>>
Take
Payment
Select
size
Select
Colour
Enter
Quantity
38. LEVELS
Note that this
process has
been simplified
for example
purposes and
would probably
include some
more process
as discussed
earlier.
These Use Cases are unlikely to be used in isolation, and are
likely to have an additional narrative.
Order System
Select
Customer
<<include>>
<<extend>>
Search
Customer
New
Customer
Create
Order
Select
Products
Take
Payment
Phone
Operator
• Operator receives a call from
the customer.
• Operator selects the customer.
• This will include searching
to find if the customer
exists.
• This may also include
creating a new customer.
• Operator will create the order.
• Operator will select products.
• Operator will take payment.
40. THINK!
It is important to note that there is not
always a „correct‟ version.
But there are wrong ways, so ask yourself:
• Actors: Am I correctly showing who has access
to the system, who uses which process?
• System: Is it clear what the system does?
• Goals: Is the full process shown?
• Clear: Can I clarify the diagrams?
• Too Simple: Do I need to add more breakdowns
to clarify the process?
• Too Complicated: Do I need to split some
breakdowns out of the main system?
41. THINK!
I have seen „extends‟ not „extend‟.
You only use „extend‟ Why?
UML changes over time to keep up with real world
systems.
• Extends: Used to be shown on models as
<<extends>>, but was shortened to <<extend>>
to keep the diagram as short as possible.
• Both are still widely accepted and neither is
wrong. <<extend>> is just more up to date.
42. THINK!
I have seen „includes‟ not „include‟.
You only use „include‟ Why?
UML changes over time to keep up with real world
systems.
• Includes: Used to be shown on models as
<<includes>>, but was shortened to <<include>>
to keep the diagram as short as possible.
• Both are still widely accepted and neither is
wrong. <<include>> is just more up to date.
43. THINK!
I have seen „include‟ and „uses‟.
You have not used „uses‟, why not?
In UML diagrams, „include‟ is now used now to
cover both includes and uses.
• Includes: <<includes>> used to be shown on
models just to show that a sub process was an
integral part of the main process.
• Uses: <<uses>> used to be shown on models to
show that a sub process was a re-usable part of
the main process. It may also have been used
elsewhere.
• Both are still widely accepted and neither is
wrong. <<include>> is just more up to date.
