Use Case Diagram

In this diagram, we will be dealing with systems.

Actors

Usecases
---- Relationships
Systems  A system is whatever you’re developing such as website,
software component, business process, application, etc.
System is represented with rectangle.

Put the name on the top of the rectangle. This rectangle helps to find the
scope of the system.
Anything within this rectangle happens within the ‘Banking App’ as
we’re building a Simple Banking Application.
Anything outside of this rectangle doesn’t happen in the ‘Banking App’.
Actors  An actor is depicted as follows.
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 external device.
Who or where is going to be using our ‘Banking App’.
The most obvious actor is the Customer. We’re going to have
Customer’s that download and use our ‘Banking App’.
Another actor in our diagram will be the Bank. The Bank is going to
provide information that feeds into the Banking App like Transactions
and Account balances.
A few 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.
Actors need to be thought of as types or categories.
For our ‘Banking App’, an actor isn’t going to be specific individual or a
specific organization.
We wouldn’t label our actors as ‘ABC’ and ‘XYZ Bank’. We want to
keep things categorical.
So, right now we’re saying that both Customer’s and Banks are to going
to use our App and this brings up the topics Primary Actor and
Secondary Actor.
Primary Actor  A Primary actor initiates the use of a system while the
secondary actor is more reactionary.
So, in our example, which actor is primary and which actor is
secondary?
Primary Actor  Customer
Secondary Actor  Bank
The Customer is going to initiate the use of our system.
They’re going to pull out their phone, open our ‘Banking App’ and do
something with it.
Bank on the other hand is a secondary actor. The Bank is 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 left of the system and secondary actors
should be to the right.
Use Case  This is where you really start to describe what your system
does.
A Use Case is depicted with 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’.
What is our ‘Banking App’ going to do?
We’re going to keep things very simple. Our ‘Banking App’ is going to
allow a Customer to Login, Check their account balance, transfer funds
between accounts, and make payments towards bills.
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 ‘LogIn’, ‘Check Balance’, ‘Transfer
Funds’, ‘Make Payment’.

You can see that each of these Use Cases starts with a verb and
reinforces an action that takes place. We also want them to be
sufficiently descriptive.
It is a good practice to put your Use Cases in a logical order when
possible.
That’s why we put ‘LogIn’ Use Case at the top.
That’s the first thing that will happen when a Customer uses our
‘Banking App’ .
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 LogIn to our ‘Banking App’. So, we draw
a solid line between the Actor and the Use Case ‘LogIn’ to show the
relationship.

.
This type of relationship is called as Association and it just signifies a
basic communication or interaction.
A Customer is going to interact with the rest of the Use Cases as well.
They’re going to be ‘Check Balance’, ‘Transfer Funds’ and ‘Make
Payment’ , so we’ll draw a 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.
Which Use Case will the Bank interact with?
When the Customer wants to check their balance on the app, the bank is
going to provide the correct amount. Now, draw a solid line between
Bank and Check Balance.
Similarly, when a Customer wants to ‘Transfer Funds’ or ‘Make
Payment’, the Bank is going to follow through with those transactions.

We don’t need to draw a line to ‘LogIn’ because that process happens

within the ‘Banking App’. There’s no need for the bank to actually get
involved within the login process.
There are 3 other types of relationships.
Include, Extend and Generalization.
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 to display an
error message.
So, let’s create 3 new Use Cases for ‘Verify Password’ and ‘Display
Login Error’ .
When a Customer wants to ‘Transfer Funds’ or ‘Make Payment’, our
‘Banking App’ is going to make sure there’s enough money to complete
these transactions. So, we’ll also create another Use Case called ‘Verify
Sufficient Funds’.
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 2 more Use Cases
called ‘Pay from Checking Account’ and ‘Pay from Savings Account’.
How does ‘Verify Password’ relate to the rest of the diagram?
Neither our actors are directly initiating the action. It’s just immediately
going to happen within our ‘Banking App’ every time there’s an attempt
to ‘LogIn’.
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 complete.
When you have an include relationship, you draw a dashed line with an
arrow that points towards the included use case.

In this example, ‘LogIn’ 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 ‘LogIn’ Use Case won’t be complete unless ‘Verify Password’ is
complete.