00:00:00
Hi! My name's Collin,
00:00:01
and today I'll be teaching
you everything you need to know
00:00:03
about UML use case diagrams.
00:00:06
We'll start with a
high level overview.
00:00:08
And then we'll talk
about systems, actors, use cases,
00:00:11
and relationships.
00:00:12
And finally,
00:00:13
we'll build an entire use
case diagram together and go over
00:00:16
some examples to explain
these concepts in-depth.
00:00:19
Have you ever had an idea
that makes perfect sense in your
00:00:22
head, but when you try
to explain it to someone else,
00:00:25
they're completely lost?
00:00:26
Maybe your ideas for a new app,
00:00:28
and every time
you talk about it,
00:00:30
people don't really understand
how they'd interact with it,
00:00:32
or what it would do.
00:00:34
This type of scenario is where
a use case diagram is super helpful.
00:00:38
Here's a simple description
of a use case diagram.
00:00:42
First, it shows a
system or application.
00:00:44
Then it shows the
people, organizations,
00:00:46
or other systems that
interact with it. And finally,
00:00:49
it shows a basic flow of
what the system or application does.
00:00:53
It's a very high level diagram and
typically won't show a lot of detail,
00:00:57
but it's a great way to
communicate complex ideas in a
00:01:00
fairly basic way. But before we
get too far into this tutorial,
00:01:04
let's talk about how you're
going to make a use case
00:01:06
diagram. You could use a pen
and paper to draw them out,
00:01:10
but a diagramming application
is going to be way easier.
00:01:13
Today, I'll be using
Lucidchart. And you can't, too.
00:01:16
For free, actually!
00:01:17
Just click the link to
access Lucidchart's website,
00:01:20
enter your email address,
00:01:21
and then you can follow along with
me as we create these use case diagrams.
00:01:25
Okay.
00:01:26
So we're gonna break down
use case diagrams into four
00:01:29
different elements:
systems, actors,
00:01:33
use cases, and relationships.
00:01:35
Let's start with systems.
00:01:37
A system is whatever you're
developing. It could be a
00:01:40
website, a software component,
a business process, an app,
00:01:44
or any number of things.
00:01:45
You represent a system
with a rectangle,
00:01:47
and you put the name of
the system at the top.
00:01:50
We're going to build a use
case diagram for a very simple
00:01:53
banking application.
00:01:55
We'll call our
system banking app.
00:01:58
This rectangle helps define
the scope of the system.
00:02:00
Anything within this rectangle
happens inside the banking app.
00:02:04
Anything outside this rectangle
doesn't happen in the banking
00:02:07
app. The next element is actor,
which is depicted by this stick figure.
00:02:13
An actor is going to be someone
or something that uses our
00:02:16
system to achieve a goal.
00:02:17
That could be a person, an
organization, another system,
00:02:21
or an external device.
00:02:23
So who or what is going
to be using our banking app? Well,
00:02:26
the most obvious
actor is a customer.
00:02:29
We're gonna have customers that
download and use our banking
00:02:31
app. Another actor that we'll want
in our diagram is the bank.
00:02:36
The bank is going to
provide information that feeds into our
00:02:38
banking app, like transactions
and account balances.
00:02:42
Here are a couple things to
keep in mind when dealing with
00:02:44
actors. First,
00:02:46
it's important to note
that these actors are external
00:02:48
objects. They always need to
be placed outside of our system.
00:02:52
Second, actors need to be
thought of as types or categories.
00:02:55
For our banking app,
00:02:56
an actor isn't going to be
a specific individual or a
00:02:59
specific organization.
00:03:01
We wouldn't label our actors
as John and Chase Bank.
00:03:04
We wanna keep
things categorical,
00:03:06
and this brings us to the
topic of primary and secondary actors.
00:03:10
A primary actor initiates
the use of the system while a
00:03:13
secondary actor is
more reactionary.
00:03:16
So in our example,
00:03:17
which actor is primary
and which actor is secondary?
00:03:20
The primary actor
is the customer.
00:03:23
The customer is going to
initiate the use of our system.
00:03:26
They're going to pull out their
phone, open up the banking app,
00:03:29
and do something with it.
00:03:30
Bank on the other hand
is a secondary actor.
00:03:33
Bank is only going to
act once the customer does something.
00:03:36
If the customer
goes on the app,
00:03:38
to see how much money
is in their account,
00:03:40
only then does the bank engage
with our system to provide the balance.
00:03:45
Primary actors should be
to the left of the system,
00:03:48
secondary actors to the right.
00:03:51
This just visually reinforces
the fact that customer engages
00:03:54
with the banking app and
then the bank reacts.
00:03:57
The next element is a use case,
00:03:58
and this is where you really
start to describe what our system does.
00:04:02
A use case is depicted
with this oval shape and it
00:04:05
represents an action that
accomplishes some sort of task
00:04:08
within the system.
00:04:10
They're going to be
placed within the rectangle because
00:04:12
they're actions that occur
within the banking app.
00:04:15
So what is our banking
app going to do? Well,
00:04:19
we're going to keep
things very simple.
00:04:21
Our banking app is going to
allow a customer to log in,
00:04:24
check their account balance,
transfer funds between
00:04:27
accounts, and make
payments toward bills.
00:04:30
So if this is what
our banking app does,
00:04:32
we're going to have use
cases that describe each of those
00:04:34
actions. We'll have a
use case called log in,
00:04:37
another called check balance,
00:04:39
another called transfer funds,
and finally make payment.
00:04:43
You can see that each of
these use cases starts with a verb
00:04:46
and reinforces an
action that takes place.
00:04:48
We also want them
to be sufficiently descriptive.
00:04:51
If this use case only
said transfer, that'd be way too
00:04:54
vague. Finally,
00:04:56
It's good practice to put your
use cases in a logical order
00:04:59
when possible. That's why
we put log in at the top.
00:05:02
That's the first thing that
will happen when a customer uses.
00:05:07
The final element in use case
diagrams is relationships.
00:05:10
An actor by definition is using
our system to achieve a goal.
00:05:14
So each actor has to interact
with at least one of the use
00:05:18
cases within our system.
00:05:19
In our example,
00:05:20
a customer is going to
log in to our banking app.
00:05:23
So we draw a solid line between
the actor and the use case to
00:05:26
show this relationship.
00:05:28
This type of relationship
is called an association.
00:05:30
And it just signifies
a basic communication or interaction.
00:05:35
A customer is going to interact
with the rest of these use
00:05:37
cases as well. They're going
to check balance, transfer funds,
00:05:41
and make payments,
00:05:42
so we'll draw solid lines
out to each of those as well.
00:05:45
Secondary actors will
also have relationships.
00:05:48
Remember,
00:05:49
each actor has to interact
with at least one use case.
00:05:53
So which use case will the
bank interact with? Well,
00:05:56
when a customer wants to check
their balance on the app,
00:05:59
the bank is going to
provide the correct amount.
00:06:01
Let's draw a line between
bank and check balance.
00:06:04
Similarly,
00:06:05
when a customer wants to
transfer funds or make a payment,
00:06:08
the bank is going to
follow through with those transactions.
00:06:12
We don't need to draw a line
to log in because that process
00:06:14
happens within the banking app.
00:06:16
There's no need for the bank to
actually get involved with the login process.
00:06:20
There are three other types
of relationships in addition to association.
00:06:24
They're include, extend,
and generalization.
00:06:28
Let's build out this diagram
with some additional use cases
00:06:31
in order to explain these
other types of relationships.
00:06:34
When a customer types in
their login information,
00:06:37
Our banking app is going
to verify the password before
00:06:39
completing the login process. But
if the password is incorrect,
00:06:43
the banking app is going
to display an error message.
00:06:46
So let's create two new
use cases for verify password and
00:06:49
display login error. When
a customer wants to transfer
00:06:52
funds, or make a payment,
00:06:54
our banking app is going
to make sure there's enough money
00:06:56
to complete those transactions.
00:06:58
So we'll also create another
use case called verify
00:07:01
sufficient funds.
00:07:03
And finally, when a customer
wants to make a payment,
00:07:06
our banking app is going to
give them the option of paying
00:07:08
from either their checking
account or their savings account.
00:07:12
So we'll create two more
use cases called pay from checking
00:07:15
and pay from savings.
00:07:17
Okay.
00:07:17
Let's circle back to this
verify password use case and
00:07:20
talk about relationships again.
00:07:22
How does verify password relate
to the rest of the diagram?
00:07:26
Neither of our actors
are directly initiating this action,
00:07:29
it's just immediately going to
happen within our banking app
00:07:31
every time there's
an attempt to log in.
00:07:34
This is an include
relationship.
00:07:36
An include relationship shows
dependency between a base use
00:07:40
case and an included use case.
Every time the base use case is
00:07:44
executed, the included use
case is executed as well.
00:07:48
Another way to think of it
is that the base use case requires
00:07:51
an included use case in
order to be complete.
00:07:54
When you have an
include relationship,
00:07:56
you draw a down line with
an arrow that points toward the
00:07:59
included use case.
So in our example,
00:08:02
log in as the base use case
and verify password is the included use case.
00:08:06
Every time a customer logs in,
00:08:08
our banking app will
automatically verify password.
00:08:11
This login use case won't be
complete unless verify password is complete.
00:08:15
So we draw a dashed line
with the arrow pointing towards the
00:08:18
included use case, and we write
include in double chevrons.
00:08:22
The next type of
relationship is the extend relationship.
00:08:25
An extend relationship has a base
use case and an extend use
00:08:28
case. When the base
use case is executed,
00:08:31
the extend use case will
happen sometimes, but not every time.
00:08:35
The extend use case will only
happen if certain criteria are met.
00:08:39
Another way to think of it
is that you have the option to
00:08:41
extend the behavior
of the base use case.
00:08:44
When you have an
extend relationship,
00:08:45
you draw a dashed line with
an arrow that points towards the
00:08:48
base use case. In our example,
00:08:51
login is a base use case and
display login error is an
00:08:54
extended use case.
00:08:55
Our banking app won't display
a login error message every time
00:08:58
a customer logs in.
00:09:00
This will only happen once
in a while when a customer
00:09:02
accidentally enters
an incorrect password.
00:09:05
Since this is an
extend relationship,
00:09:07
we draw a dashed line with
an arrow that points to the base
00:09:10
use case and write
extend between double chevrons. Hopefully,
00:09:14
this thoroughly explains the
difference between include and
00:09:17
extend relationships.
But just in case,
00:09:19
here's a very basic example
to help differentiate between the
00:09:23
two. If you sneeze, you
will close your eyes.
00:09:26
That's an included relationship because
it is going to happen
00:09:28
every time. Additionally, if you
sneeze, you might say, excuse me,
00:09:33
That's an extended relationship
because it supplements the
00:09:36
sneeze, but isn't completely
necessary in the sneezing process.
00:09:40
Just remember that include
happens every time, extend
00:09:43
happens just sometimes,
00:09:45
and don't forget that the
arrows point in opposite directions.
00:09:49
One quick thing to know is that
multiple base use cases can
00:09:53
point to the same included
or extended use case. For example,
00:09:57
both transfer funds and make
payment are going to point to
00:10:00
verify sufficient funds
as an included use case.
00:10:03
We want our banking app to
make this check every time either of
00:10:06
these base use cases occur.
00:10:08
You don't need to duplicate
the verify sufficient funds use
00:10:10
case. The simpler your
diagram, the better.
00:10:14
The last type of
relationship we'll discuss is generalization
00:10:17
Also known as inheritance.
00:10:19
When you make a payment
from our banking app,
00:10:21
you can do so from either
your checking account or your
00:10:24
savings account.
In this scenario,
00:10:26
make a payment as a general
use case and pay from savings and
00:10:30
pay from checking
are specialized use cases.
00:10:33
You could also use the
terms parent and children.
00:10:36
Each child shares the common
behaviors of the parent,
00:10:38
but each child adds
something more on its own.
00:10:41
To show that this
is a generalization,
00:10:43
we draw this type of arrow
from the children up to the parent.
00:10:46
You can have generalizations on
use cases like we have here.
00:10:50
You can also have
generalizations with actors.
00:10:53
In certain scenarios,
00:10:54
you might want to distinguish
between a new customer and a
00:10:56
returning customer
00:10:58
You could make them both
children to a general customer actor,
00:11:01
which would allow you to
have certain behaviors or qualities
00:11:03
unique to each of
these children.
00:11:06
One last shape that we'll
quickly talk about is a use
00:11:08
case with extension points.
You can see an example here.
00:11:12
The name of the use
case is above the line,
00:11:14
and then there are extension
points below the line.
00:11:16
Extension points are just a
detailed version of extend relationships.
00:11:20
This use case shows us that
a customer can set up their
00:11:23
profile in our banking app.
00:11:24
And then these extension points show
us that when a customer is
00:11:27
setting up their profile,
00:11:28
They'll have the option to
navigate to a couple different screens.
00:11:32
If a customer is confused, they
can go to the profile help.
00:11:35
And if they want
details regarding their private
00:11:37
information, can
go to privacy info.
00:11:39
Those extension points branch
off to extended use cases,
00:11:42
go to profile help
and show privacy info.
00:11:46
We can even add a note
to show what sort of conditions would
00:11:48
lead to these extension points.
00:11:50
Now we have a complete
use case diagram with various elements
00:11:53
that help explain what
our banking app does.
00:11:56
This is a very basic example,
00:11:58
but remember that even complex
systems should be restricted to
00:12:01
a simplistic visualization
of functionality, behavior,
00:12:05
and relationship.
00:12:06
If you'd like to take a
closer look at this example,
00:12:09
click the link on the screen.
00:12:11
There you'll find the exact
banking app example plus
00:12:13
several other
examples and resources
00:12:15
Well, that wraps up our
tutorial for UML use case
00:12:18
diagrams. We hope you found
our explanations of systems,
00:12:21
actors, use cases, and
relationships help.
00:12:25
And if you're interested
in learning more about other
00:12:27
diagramming processes, systems,
and organizations, visit
00:12:32
training.lucid.co
Thanks for watching.
00:12:34
We hope to see you there.
