Use case diagrams 2014

43
Use Case Diagrams Inge Powell

Transcript of Use case diagrams 2014

Page 1: Use case diagrams 2014

Use Case Diagrams

Inge Powell

Page 2: Use case diagrams 2014

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/

Page 3: Use case diagrams 2014

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.

Page 4: Use case diagrams 2014

ACTORSUse Case Diagrams

Page 5: Use case diagrams 2014

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

Page 6: Use case diagrams 2014

Although typically they are depicted with stickmen…………………..

Sometimes they are also shown more graphically

ACTORS

Page 7: Use case diagrams 2014

The actors are annotated with their role..

Administrator

Operator

Customer

ManagerClient

ACTORS

Page 8: Use case diagrams 2014

Actors are not ALWAYS people, however you can still depict them with stickmen.

Administrator BankCustomer

Bank Website Server

ACTORS

Administrator Customer

Website Server

Page 9: Use case diagrams 2014

SYSTEM BASICS

Use Case Diagrams

Page 10: Use case diagrams 2014

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

Page 11: Use case diagrams 2014

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

Page 12: Use case diagrams 2014

We show which actor interacts with each processSYSTEM

Select Customer

Create Order

Select Products

Process Payment

Order System

Phone Operator

Page 13: Use case diagrams 2014

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

Page 14: Use case diagrams 2014

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

Page 15: Use case diagrams 2014

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

Page 16: Use case diagrams 2014

<<INCLUDES>>

Use Case Diagrams

Page 17: Use case diagrams 2014

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>>

Page 18: Use case diagrams 2014

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>>

Page 19: Use case diagrams 2014

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>>

Page 20: Use case diagrams 2014

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.

Page 21: Use case diagrams 2014

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>>

Page 22: Use case diagrams 2014

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>>

Page 23: Use case diagrams 2014

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

Page 24: Use case diagrams 2014

<<EXTEND>>Use Case Diagrams

Page 25: Use case diagrams 2014

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.

Page 26: Use case diagrams 2014

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.

Page 27: Use case diagrams 2014

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>>

Page 28: Use case diagrams 2014

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>>

Page 29: Use case diagrams 2014

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>>

Page 30: Use case diagrams 2014

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.

Page 31: Use case diagrams 2014

SYSTEM LEVELS

Use Case Diagrams

Page 32: Use case diagrams 2014

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

Page 33: Use case diagrams 2014

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

Page 34: Use case diagrams 2014

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

Page 35: Use case diagrams 2014

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>

Page 36: Use case diagrams 2014

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

Page 37: Use case diagrams 2014

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>>

Page 38: Use case diagrams 2014

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.

Page 39: Use case diagrams 2014

THINK!Use Case Diagrams

Page 40: Use case diagrams 2014

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!

Page 41: Use case diagrams 2014

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!

Page 42: Use case diagrams 2014

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!

Page 43: Use case diagrams 2014

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!