Hi! My name's Collin, and today I'll be teaching
you everything you need to know about UML use case diagrams. We'll start with a
high level overview. And then we'll talk
about systems, actors, use cases, and relationships. And finally, we'll build an entire use
case diagram together and go over some examples to explain
these concepts in-depth. Have you ever had an idea
that makes perfect sense in your head, but when you try
to explain it to someone else, they're completely lost? Maybe your ideas for a new app, and every time
you talk about it, people don't really understand
how they'd interact with it, or what it would do. This type of scenario is where
a use case diagram is super helpful. Here's a simple description
of a use case diagram. First, it shows a
system or application. Then it shows the
people, organizations, or other systems that
interact with it. And finally, it shows a basic flow of
what the system or application does. It's a very high level diagram and
typically won't show a lot of detail, but it's a great way to
communicate complex ideas in a fairly basic way. But before we
get too far into this tutorial, let's talk about how you're
going to make a use case diagram. You could use a pen
and paper to draw them out, but a diagramming application
is going to be way easier. Today, I'll be using
Lucidchart. And you can't, too. For free, actually! Just click the link to
access Lucidchart's website, enter your email address, and then you can follow along with
me as we create these use case diagrams. Okay. So we're gonna break down
use case diagrams into four different elements:
systems, actors, use cases, and relationships. Let's start with systems. A system is whatever you're
developing. It could be a website, a software component,
a business process, an app, or any number of 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 the system. Anything within this rectangle
happens inside the banking app. Anything outside this rectangle
doesn't happen in the banking app. The next element is 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? Well, the most obvious
actor is a customer. We're gonna 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 wanna keep
things categorical, and this brings us to 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 the customer. The customer is going to
initiate the use of our system. They're going to pull out their
phone, open up the banking app, and do something with it. Bank on the other hand
is a secondary actor. 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 left of the system, secondary actors to the right. 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 our 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? Well, we're going to keep
things very simple. Our banking app is going to
allow a customer to log in, check their account balance,
transfer funds between accounts, and make
payments toward 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 log in, another called check balance, another called transfer funds,
and finally 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. If this use case only
said transfer, that'd be way too vague. Finally, It's good practice to put your
use cases in a logical order when possible. That's why
we put log in at the top. That's the first thing that
will happen when a customer uses. The final element in use case
diagrams is 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 payments, 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 case will the
bank interact with? Well, 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 to 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. There are three other types
of relationships in addition to association. They're include, extend,
and generalization. Let's build out this diagram
with some additional use cases in order to explain these
other types of relationships. 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 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. Okay. Let's circle back to this
verify password use case and talk about relationships again. How does verify password relate
to the rest of the diagram? Neither of our actors
are directly initiating this action, it's just immediately going to
happen within our banking app every time there's
an attempt to log in. 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 down line with
an arrow that points toward the included use case.
So in our example, log in as 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. So we draw a dashed line
with the arrow pointing towards the included use case, and we write
include in double chevrons. The next type of
relationship is the 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 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 dashed line with
an arrow that points towards the base use case. In our example, login 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 accidentally enters
an incorrect password. Since this is an
extend relationship, we draw a dashed line with
an arrow that points to the base use case and write
extend between double chevrons. Hopefully, this thoroughly explains the
difference between include and extend relationships.
But just in case, here's a very basic example
to help differentiate between the two. If you sneeze, you
will close your eyes. That's an included relationship because
it is 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, and don't forget that the
arrows point in opposite directions. One quick thing to know is that
multiple base use cases can point to the same included
or extended use case. For example, both transfer funds and make
payment are going to point to verify sufficient funds
as an included use case. We want our banking app to
make this check every time either of these base use cases occur. You don't need to duplicate
the verify sufficient funds use case. The simpler your
diagram, the better. 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 as 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. You can also have
generalizations with actors. In certain scenarios, you might want to distinguish
between a new customer and a returning customer You could make them both
children to a general customer actor, which would allow you to
have certain behaviors or qualities unique to each of
these children. One last shape that we'll
quickly talk about is a use case with extension points.
You can see an example here. The name of the use
case is above the line, and then there are extension
points below the line. Extension points are just a
detailed version of extend relationships. This use case shows us that
a customer can set up their profile in our banking app. And then these extension points show
us that when a customer is setting up their profile, They'll have the option to
navigate to a couple different screens. If a customer is confused, they
can go to the profile help. And if they want
details regarding their private information, 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 would lead to these extension points. Now we have a complete
use case diagram with various elements that help explain what
our banking app does. This is a very basic example, but remember that even complex
systems should be restricted to a simplistic visualization
of functionality, behavior, and relationship. If you'd like to take a
closer look at this example, click the link on the screen. There you'll find the exact
banking app example plus several other
examples and resources Well, that wraps up our
tutorial for UML use case diagrams. We hope you found
our explanations of systems, actors, use cases, and
relationships help. And if you're interested
in learning more about other diagramming processes, systems,
and organizations, visit training.lucid.co
Thanks for watching. We hope to see you there.