UML Use Case Diagram

• Maybe your idea is for a new app, and every time you talk about it
people don’t really understand how they’d interact with the app or
what it would do.
• This type of scenario is where a Use Case diagram is very helpful.
A system is whatever you’re developing.

It could be a website, a software component, a business process,

an app, or any number of other things.

You represent a system with a rectangle, and you put the name
of the system at the top.
We’re going to build a Use Case diagram for a very simple
Banking Application.

We’ll call our system Banking App.

This rectangle helps define the scope of this system.

Anything within this rectangle happens within the Banking App.

Anything outside this rectangle doesn’t happen in the Banking

App.
The next element is an actor, which is depicted by this stick
figure.

An actor is going to be someone or something that uses our

system to achieve a goal.

That could be a person, an organization, another system, or an

external device.
So who or what is going to be using our Banking App?

The most obvious actor is a customer.

We’re going to have customers that download and use our

Banking App.

Another actor that we’ll want in our diagram is the Bank.

The Bank is going to provide information that feeds into our

Banking App, like transactions and account balances.
Here are a couple things to keep in mind when dealing with
Actors.

First, it’s important to note that these actors are external objects.

They always need to be placed outside of our system.

Second, Actors need to be thought of as types or categories.

For our Banking App, an actor isn’t going to be a specific

individual or a specific organization.

We wouldn’t label our actors as John and Chase Bank.

We want to keep things categorical.

So right now we’re saying that both Customers and Banks are
going to use our app, and this brings up the topic of primary and
secondary actors.

A primary actor initiates the use of the system while a

secondary actor is more reactionary.

So in our example, which actor is primary and which actor is

secondary?

The primary actor is Customer.

The Customer is going to initiate the use of our system.
They’re going to pull out their phone, open up our Banking
App, and do something with it.
Bank, on the other hand, is a secondary actor.
The Bank is only going to act once the Customer does something.

If the Customer goes on the app to see how much money is in their
account, only then does the Bank engage with our system to provide the
balance.
Primary actors should be to the and secondary actors should be to the right.
left of the system
This just visually reinforces the fact that Customer engages with
the Banking App and then the Bank reacts
The next element is a Use Case and this is where you really start to describe
what your system does.

A Use Case is depicted with this oval shape and it represents an action that
accomplishes some sort of task within the system.

They’re going to be placed within the rectangle because they’re actions that
occur within the Banking App.
So what is our Banking App going to do?
So if this is what our Banking App does, we’re going
to have Use Cases that describe each of those actions.

We’ll have a Use Case called Log In, another called

Check Balance, another called Transfer Funds, and
finally Make Payment.
The final element in Use Case Diagrams are Relationships.

An actor, by definition, is using our system to achieve a goal.

So each actor has to interact with at least one of the Use Cases
within our system.

In our example, a Customer is going to Log In to our Banking

App.
So we draw a solid line between the Actor and the Use Case to
show this relationship.

This type of relationship is called an association and it just

signifies a basic communication or interaction.
A Customer is going to interact with the rest of
these Use Cases as well.

They’re going to Check Balance, Transfer Funds,

and Make Payment so we’ll draw solid lines out
to each of those as well.
Secondary Actors will also have relationships.

Remember, each actor has to interact with at

least one Use Case.

So which Use Cases will the bank interact with?

When a Customer wants to check their balance on
the app, the Bank is going to provide the correct
amount.

Let’s draw a line between Bank and Check

Balance.
Similarly, when a Customer wants to transfer funds or
make a payment, the Bank is going to follow through
with those transactions.

We don’t need draw a line to Log In, because that

process happens within the Banking App.

There’s no need for the Bank to actually get involved

with the login process.
When a Customer types in their login information,
our Banking App is going to verify the password
before completing the login process.
But if the password is incorrect, the Banking App is
going display an error message.
But if the password is incorrect, the
Banking App is going display an error
message.

So let’s create two new Use Cases for

Verify Password and Display Login
Error.
When a Customer wants to transfer funds or make a payment,
our Banking App is going to make sure there’s enough money to
complete those transactions.

So we’ll also create another Use Case called Verify Sufficient

Funds.
And finally, when a Customer wants to make a
payment, our Banking App is going to give them the
option of paying from either their checking account or
their savings account.

So we’ll create two more Use Cases called Pay From

Checking and Pay From Savings.
This is an Include relationship.

An Include relationship shows dependency between a base use case and an included use case.

Every time the base use case is executed, the included use case is executed as well.
Another way to think of it is that the base use case requires an included use case in order to be complete.

When you have an include relationship, you draw a dashed line with an arrow that points towards the included use
case.
So in our example, Log In is the base use case and Verify Password is the included use case.

Every time a Customer Logs In, our Banking App will automatically Verify Password.

This Log In use case won’t be complete unless Verify Password is complete.
An extend relationship has a base use case and an extend use case.

When the base use case is executed, the extend use case will happen sometimes but not every time.

The extend use case will only happen if certain criteria are met.
In our example, Log In is a base use case and Display Login Error is an extended use case.

Our Banking App won’t display a Login Error Message every time a Customer logs in.

This will only happen once in a while when a Customer accidently enters an incorrect password.
If you sneeze, you will close your eyes.
That’s an included relationship because it’s going to happen every time.
Additionally, if you sneeze, you might say excuse me.
That’s an extended relationship because it supplements the sneeze, but isn’t completely necessary in the sneezing
process.
Just remember that include happens every time, extend happens just sometimes,
If you sneeze, you will close your eyes.

That’s an included relationship because it’s going to happen every

time.

Additionally, if you sneeze, you might say excuse me.

That’s an extended relationship because it supplements the sneeze,

but isn’t completely necessary in the sneezing process.

Just remember that include happens every time, extend happens just
sometimes,
The last type of relationship we’ll discuss is
Generalization, also known as inheritance.

When you Make a Payment from our Banking App,

you can do so from either your checking account or
your savings account.

In this scenario, Make a Payment is a general use case

and Pay from Savings and Pay from

Checking are specialized use cases.

You could also use the terms parent and children.

Each child shares the common behaviors of the parent,

but each child adds something more on its own.

To show that this is a generalization, we draw this type

of arrow from the children up to the parent.

You can have generalizations on Use Cases, like we

have here.
What is USE CASE diagram?

• A use case diagram establish the capability of the system as a whole.

• Components of use case diagram:

• Actor
• Use case
• System boundary
• Relationship
• Actor relationship

55
ACTOR:

What is an actor?
• An actor is some one or something that must interact with the system under
development
• UML notation for actor is stickman, shown below.

Customer Manager Cashier

56
ACTOR:

• It is a role, user plays with respect to system.

• Actors are not part of the system they represent anyone or anything that must interact
with the system.

• Actors carry out use cases and a single actor may perform more than one use cases.

• Actors are determined by observing the direct uses of the system.

57
ACTOR:

• Those are responsible for its use and maintain as well as other
systems that interact with the developed system.

• An actor may
- input information to the system.
- receive information from the system.
- input to and out from the system.

58
ACTOR:
How do we find the actor?

• Ask following questions to find the actors:

• Who uses the system?
• Who installs the system?
• Who Starts up the system?
• What other systems use this system?
• Who gets the information from the system?
• Who provides information to the system?

• Actor is always external to the system. They are never

part of the system to be developed.
59
ACTOR:

4-Categories of an actor:

• Principle : Who uses the main system functions.

• Secondary : Who takes care of administration &
maintenance.
• External h/w : The h/w devices which are part of application domain and must
be used.
• Other system : The other system with which the system must interact.

60
• 1)Primary/principle Actor: People who use the main system functions are refereed
as primary or principle actors. Example: in ATM system primary actor is customer
• 2)Secondary Actor: People who perform administrative or maintenance task are
referred as secondary actors. It provides a service to the system under design.
Example: in ATM system a person in charge of loading money into the system is a
secondary actor.
• 3)External actor: The hardware devices which are required as apart of application
domain and must be used are referred as external actors. Example: in ATM system
printer is an external actor.
• 4)Other system actor: The other system with which the system must interact
referred as other system actors. Example: in ATM system bank network system is
another system actor.
USE CASE:
What is USE case?
• A use case is a pattern of behavior, the system exhibits
• Each use case is a sequence of related transactions
performed by an actor and the system in dialogue.
• USE CASE is dialogue between an actor and the system.
• Examples:

Open new account Withdrawal of cash

from ATM
62
USE CASE:
• It is a snapshot of one aspect of system.

• They model a dialog between actor and system.

• A use case typically represents a major piece of functionality that

is complete from beginning to end.

• Most of the use cases are generated in initial phase, but you find
some more as you proceed.

• A use case may be small or large. It captures a broad view of a

primary functionality of the system in a manner that can be easily
grasped by non technical user.

63
USE CASE:

• A use case must deliver something of value to an actor.

• The use cases may be decomposed into other use cases.

• Use cases also present a good vehicle for project planning.

64
USE CASE:

How do we find the use cases?

• What functions will the actor want from the system?

• Does the system store information? What actors will create, read, update. Or
delete that information?

• Does the system need to notify an actor about changes in its internal state?

65
USE CASE:
• Generic format for documenting the use case:
- Pre condition: If any
• Use case : Name of the case.
• Actors : List of actors(external agents), indicating who
initiates the use case.
• Purpose : Intention of the use case.
• Overview : Description.
• Type : primary / secondary.
• Post condition: If any
• Typical Course of Events:
ACTOR ACTION : Numbered actions of the actor.
SYSTEM RESPONSE : Numbered description of system responses.

66
USE CASE:
USE CASE documentation example:
• The following use case describes the process of opening a new
account in the bank.
Use case :Open new account
Actors :Customer, Cashier, Manager
Purpose :Like to have new saving account.
Description :A customer arrives in the bank to open the new
account. Customer requests for the new
account
form, fill the same and submits, along with the
minimal deposit. At the end of complete
successful
process customer receives the passbook.
Type :Primary use case.
67
Grouping USE CASES:
• Those use case functionality which are directly dependent
on the system environment are placed in interface objects

• Those functionality dealing with storage and handling of

information are placed in entity objects

• Functionality's specific to one or few use cases and not

naturally placed in any of the other objects are placed in
control objects

By performing this division we obtain a structure which

helps us to understand the system from logical view.

68