Use case diagrams 2014
-
Upload
inge-powell -
Category
Education
-
view
676 -
download
1
Transcript of Use case diagrams 2014
Use Case Diagrams
Inge Powell
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/
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.
ACTORSUse Case Diagrams
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.
ACTORS
Although typically they are depicted with stickmen…………………..
Sometimes they are also shown more graphically
ACTORS
The actors are annotated with their role..
Administrator
Operator
Customer
ManagerClient
ACTORS
Actors are not ALWAYS people, however you can still depict them with stickmen.
Administrator BankCustomer
Bank Website Server
ACTORS
Administrator Customer
Website Server
SYSTEM BASICS
Use Case Diagrams
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.
SYSTEM
We write the function in the ovals
We give the overall process a title to show what we are depicting.
SYSTEM
Select Customer
Select Custome
r
Create Order
Select Product
s
Take Payment
Order System
We show which actor interacts with each processSYSTEM
Select Customer
Create Order
Select Products
Process Payment
Order System
Phone Operator
Regardless of whether this is a two way process, we show who initiates the process with an arrow.
SYSTEM
Select Customer
Create Order
Select Products
Process Payment
Order System
Phone Operator
Information from the system is shown with an arrow back to the user.
SYSTEM
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
Order Status
Often there are more than one user who interacts with the system.
SYSTEM
Select Customer
Create Order
Select Products
Make Payment
Online orders
Order Clerk
Bank
Payment Authorisation
Process Order
Confirm Order
Customer
<<INCLUDES>>
Use Case Diagrams
Sometimes a process has more steps to complete that process. Note the direction of arrows.
INCLUDES
Create Order
Add Delivery Address
Select Delivery Option
<<include>><<include>>
Sometimes a process has a lot more steps to complete that process.
INCLUDES
Create Order
Add Delivery Address
Enter Delivery Notes
Add Billing
Address
Select Delivery Option
<<include>>
<<include>>
<<include>>
<<include>>
We only show the include on the main process if it does not become too confusing, the idea is to keep it simple
INCLUDES
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
Search Customer
Delivery Option
<<include>>
<<include>>
Otherwise we show it separately
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
INCLUDES
Create Order
Add Deliver
y Addres
s
Enter Delivery Notes
Add Billing Addres
s
Select Deliver
y Option
<<include>>
<<include>>
<<include>>
<<include>>
Notice that this is not a FULL system, so we do NOT enclose it in the system box.
It is perfectly acceptable to show some important ‘include’ inside the main system box, and some separately.
INCLUDES
Create Order
Add Deliver
y Addres
s
Enter Delivery Notes
Add Billing Addres
s
Select Deliver
y Option
<<include>>
<<include>>
<<include>>
<<include>>
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
Search Customer
<<include>>
It is also acceptable to show more than one set of breakdowns outside the main system box.
INCLUDES
Create OrderAdd
Delivery
Address
Enter Delivery Notes
Add Billing Addres
s
Select Deliver
y Option
<<include>>
<<include>>
<<include>>
<<include>>
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
Search Customer
<<include>>
Select Products
Search Product
s
Select Colour
Select size
Enter Quantit
y
<<include>>
<<include>>
<<include>>
<<include>>
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.
INCLUDES
<<EXTEND>>Use Case Diagrams
Sometimes a process has a step that it might include to complete that process. Note the direction of arrows.
EXTENDS
Select Customer
Search by Postcode
NewCustomer
<<extend>><<extend>>
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 might include a lot more steps that could potentially be needed to complete that process, but not always.
EXTENDS
Create Order
New Customer
Check Age
Restrictions
Check Licence
Include COSH
<<extend>>
<<extend>>
<<extend>>
<<extend>>
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.
We only show the extend on the main process if it does not become too confusing, the idea is to keep it simple.
EXTENDS
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
New Customer
Arrange Air Mail
<<extend>>
<<extend>>
Otherwise we show it separately
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
EXTENDS
Notice that this is not a FULL system, so we do NOT enclose it in the system box.
Create Order
Safety Instruction
s
Check Age Restriction
s
Check Licence
Include COSH
<<extend>>
<<extend>>
<<extend>>
<<extend>>
It is perfectly acceptable to show some important ‘extend’ inside the main system box, and some separately.
EXTENDS
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
New Customer
<<extend>>Create Order
Safety Instruction
s
Check Age Restriction
s
Check Licence
Include COSH
<<extend>>
<<extend>>
<<extend>>
<<extend>>
It is also acceptable to show more than one set of breakdowns outside the main system box.
EXTENDS
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
New Customer
<<extend>>
Create Order
Delivery Options
Check Age Restriction
s
Check Licence
Include COSH
<<extend>>
<<extend>>
<<extend>>
<<include>>
Select Products
Search Product
s
Select Colour
Select size
Enter Quantit
y
<<include>>
<<extend>><<extend>>
<<include>>
Search Customer
<<include>>
Note that you can mix include and extend.
SYSTEM LEVELS
Use Case Diagrams
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.
LEVELS
Business Use Case Business use case is the top most level.
LEVELS
Note that you would show the customers or shareholders at this level even if they have no direct contact with the actual system.
Orders
Fulfil Orders
Manage Database
Sooooper shops Ltd
Order Clerk
Supplier
Payments
Invoices
Shares
Customer
Manager
Admin
Shareholder
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..
LEVELS
Select Customer
Create Order
Select Products
Make Payment
Orders System
Order Clerk
Bank Payment Authorisatio
n
Process Order
Confirm Order
Customer
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
Order Clerk
A System Use Case will show a complete process rather than an overall picture.
Levels
Select Customer
Create Order
Select Products
Make Payment
Orders System
Order Clerk
Bank
Payment Authorisatio
n
Process Order
Confirm Order
Customer
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.
Order Clerk<Telephone Order>
Customer
<Confirm Order>
A System Use Case will show a complete process rather than an overall picture.
LEVELS
Select Customer
Create Order
Select Products
Make Payment
Orders System
Order Clerk
Bank
Payment Authorisatio
n
Process Order
Confirm Order
Customer
The subtle difference in this Use Case is that the system sends out a confirmation email direct to the customer.
Order Clerk<Telephone Order>
Customer
Remember to show the FULL system process including any further levels of process.
LEVELS
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
New Customer
<<extend>>
Create Order
Delivery Options
Check Age Restriction
s
Check Licence
Include COSH
<<extend>>
<<extend>>
<<extend>>
<<include>>
Select Products
Search Product
s
Select Colour
Select size
Enter Quantit
y
<<include>>
<<extend>><<extend>>
<<include>>
Search Customer
<<include>>
These Use Cases are unlikely to be used in isolation, and are likely to have an additional narrative.
LEVELS
Select Customer
Create Order
Select Products
Take Payment
Order System
Phone Operator
New Customer
<<extend>>
Search Customer
<<include>>
Note that this process has been simplified for example purposes and would probably include some more process as discussed earlier.
• 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.
THINK!Use Case Diagrams
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?
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.
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.
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.
THINK!