UML USE Case Diagrams

UML USE Diagrams

 it shows the system or the application
 shows the people, organization and other
systems that interact with it.

• Lucid Charts
Four elements of a USE CASE Diagram.

1. Systems
2. Actors
3. Use Cases, describes what the system
does.
4. Relationships
1. Systems  It is whatever you are
developing, a website, software
Banking App component, business process an
application or any other things.
 You represent a system with a
rectangle and put the name of
the system at the top.
 Ex. Banking App. Draw a
Rectangle this helps define the
scope of the system. Anything
within the drawn rectangle
happens within the banking
app. Anything outside the
rectangle does not happen in
the banking app.
2. Actors

 Usually depicted by a stick man.

 Someone or something that uses the
system to achieve a goal. (person,
organization, another system, external
device) Who or what is going to using
the banking app.
 The most obvious actor is the
customer, they download and use the
banking app.
 Another actor could be the bank, they
are the one who will provide
information that feeds into our
banking app like transactions and
account balances.
 2. Actors
Some of the things to keep in mind when
dealing with actors.
1. Important to note that these actors are
external objects.
2. They always need to be placed outside of the
system.
3. They need to be thought of as types or
categories. So, in a banking app, the actor is
going to be a specific individual or specific
organization. (Customers, Bank) will use the
app.
2. Actors
Primary and Secondary
Actors

 PRIMARY - initiates
the use of the system
Ex. customer, they will
initiate the use of the
system, they will pull-out
their phone, open the
banking app and do
something with it.
  SECONDARY - reactionary
2. Actors
Ex. bank, it will only act once the
customer does something. If the
customer goes to the app to see how
much money is in their account, only
then that bank engage with the system
to provide the balance.

 Primary actor should be at the left of

the system and secondary should be
to the right. This visually reinforces
the fact that customer engages the
banking app and then the bank reacts
 3. Use Cases, describes what the system does.
 depicted with oval shape, this represents an action
that accomplishes some sort of task in the system.

 this will be placed within the rectangle, because

their actions occur within the banking app. So what
is the banking app going to do?
3. Use Cases, describes what the system does.

Ex, BANKING APP (to be converted into

USE CASES)
 will allow the customer to log-in
 check their account balance
 transfer funds between accounts
 make payments towards bills
3. Use Cases, describes what the system does.

 So, we create a USE CASE

that describes each of those
actions. Each of the USE
CASES starts with a verb,
which enforces and action
that takes place. It must
also be sufficiently
descriptive and put them in
a logical order when
possible. (ex. log-in at the
top)
4. Relationships
 By definition the actor is using the system to
achieve a goal.
 So each actor has to interact with at least one USE
CASE within the system.
4. Relationships  Ex. Customer is going to log-in into
the banking account app. So we
draw a line between the actor and
the USE CASE log-in to show the
relationship, this type of
relationship is called an association
and it just signifies a basic
communication or interaction.
 A customer will also interact with
the rest of the USE CASES, they
will check balance, transfer funds
and make payments so a line will be
drawn for each USE CASES to the
customer.
  Secondary Actors will also
4. Relationships have relationships, keep in
mind that each Actor will
have to interact with at
least one USE CASE.
 So, which USE CASE will
the bank interact with? So,
when the customer will
check balance on the app
the bank is going to
provide the correct
amount, so draw a line
between the bank and
check balance USE
CASE.
4. Relationships  Similarly, when a customer
wants to transfer funds or
make a payment the bank will
follow through those
transactions, so draw a line
connecting the bank and the
rest of the USE CASES.
 No need to draw a line to log-
in and bank because that
process happens between the
banking app, there is no need
for the bank to be actually get
involved in the log-in process.
4. Relationships

 THREE TYPES of RELATIONSHIPS in

addition to Association
1. Include
2. Extend
3. Generalization
4. Relationships
When a customer types in their log-in
information, the banking app will verify the
username and password before completing
the log-in process. If the password is
incorrect the banking app will display an
error message.
 4. Relationships
So we create two new USE CASES.
 Verify password
 Display log-in error
4. Relationships
If the customer wants to transfer funds or make a payment, the
banking app is going to make sure there is enough money to
complete the transactions.
So, we will also create another USE CASE called "verify
sufficient funds".
 4. Relationships
And finally, when a customer wants to make a
payment the banking app is going to give them the
option of paying from either checking account or
savings account. So we will create two more USE
CASES "pay from checking" and "pay from savings"
 4. Relationships
And finally, when a customer wants to make a payment the
banking app is going to give them the option of paying from
either checking account or savings account. So, we will create
two more USE CASES "pay from checking" and "pay from
savings"
 4. Relationships
 Let us go back to the "verify password" USE
CASE and talk about relationships again.
How does “verify password” relates to the
rest of the diagram? Neither of our actors are
directly initiating this action, it is just
immediately going to happen within our
banking app every time there is an attempt to
log-in.
 This is an INCLUDE relationship.
 4. Relationships
 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 is that the Base USE CASE
requires the Included USE CASE in order to be complete. When
you have an include relationship you draw a dash line with an
arrow that is pointing towards the Included USE CASE ----->.
 Include Relationship
 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 the banking app will
automatically verify the password.
This log-in USE CASE will not be
complete unless verify password is
complete, so we draw a dash line
with the arrow pointing towards
the "verify password" USE CASE
and we will type in <<include>>
 EXTEND RELATIONSHIP - 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 a
certain criteria are met. Another
way to think of it is that you have
the option to extend the behavior
of the Base USE CASE. When
you have an Extend Relationship
you draw a dash line with an
arrow that points towards the base
USE CASE <----.
 EXTEND RELATIONSHIP
 In our example, "log-in" is a Base
USE CASE and "display log-in
error" is an extended USE CASE.
The banking app will not display a
log-in error message every time an
customer logs-in, this will only
happen once in a while when a
customer accidentally inputs the
incorrect password, since this is an
extend relationship, we draw a
dash line with an arrow that points
to the Base USE CASE and write
<<extend>>.
 One quick thing to know is that
multiple Base USE CASES can point
to the same Included or Excluded
USE CASE.
 For example, both "transfer funds"
and "make payment" are going to
point to "verify sufficient funds" as
and Included USE CASE.
 We want the bank to make this check
every time either of these Base USE
CASE occur. You don't need to
duplicate the "verify sufficient funds"
USE CASE, the simpler the diagram
the better.
 GENERALIZATION
RELATIONSHIP
 Also known as inheritance.
When you make a payment
from the banking app you
can do so from either the
checking account or the
savings account, in this
scenario "make payment" is
a General USE CASE and
"pay from savings" and "pay
from checking" are
Specialized USE CASES.
 GENERALIZATION
RELATIONSHIP
 You can also use the terms
PARENT and CHILDREN.
Each child shares the
common behaviors of the
parents, but each child adds
something more on its
own.
 To show that this a
generalization draw an
arrow from the children to
the parent.
 GENERALIZATION
RELATIONSHIP
 We can have Generalization in USE
CASES we can also have
Generalization with actors.
 In certain scenarios you might want to
distinguish a "new customer" and a
"returning customer" you can make
them both children to the General
"Customer" actor which would allow
you to have certain behaviors or
qualities unique to each this children.
 4. Relationships
 The last shape is a USE CASE with extension
points.
 the name of the USE CASE is above the line
and there extension points below the line.
Extension points are just the detailed version of
Extend Relationship. (Illustration).
 This USE CASE shows that a customer can set
up their profile in the Banking App and then the
Extension Point shows that when a customer is
setting up their profile they have the option to
navigate to a couple of different screens.
 4. Relationships
 If the customer is confused, they can go to "profile help" and if
they want details regarding their private information, they can
go to privacy info. Those extension points branch off to
extended USE CASES, "go to profile help" and "show privacy
info." We can even add a note to show what sort of conditions
will lead to this extension points.
Complete USE CASE
Diagram ---
Banking APP
 This a very basic example
but remember even a
complex systems should be
restricted to a simplistic
visualization of
functionality, behavior and
relationships.
 Banking APP

 Change PIN Number

 Deactivate Card – ATM Card & Credit Card