Hi, my name’s Chloe and I’ll be teaching
you everything you need to know about UML Use Case diagrams. We’ll start with a high-level overview. 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 examples to explain all 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 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. 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. Before we really get into the tutorial, let’s
talk about how you’re going to make a Use Case diagram. You can draw them out with pen and paper,
but a diagramming application is going to be much easier. Today I’ll be using Lucidchart. And you can use it too, for free actually. Just click the link to access Lucidchart’s
website, enter your email address, and you’ll have a free Lucidchart account in just a few
seconds. It’s easy to use and you can follow along
with me as we build a Use Case diagram. (Okay, so) We’re going to 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 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 left of the
system, and secondary actors should be 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 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? 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
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 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 just said Transfer, that’d
be 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 our Banking App. 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. There are three other types of relationships
in addition to association. There’s Include, Extend, and Generalization. Let’s build out this diagram with additional
Use Cases in order to explain these 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 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. 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 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. 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, 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. 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’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, and don’t forget that the arrows point in opposite directions. One quick thing to note 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 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. 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
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 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 was a very basic example, but remember
that even complex systems should be restricted to a simplistic visualization of functionality,
behavior, and relationships. Save the details for other diagrams. If you’d like to take a closer look at this
example, click on the card. You’ll find this exact Banking App example
plus several other examples and resources. Thanks for watching this tutorial on UML Use
Case Diagrams. Please subscribe to our channel to see more
helpful tutorials. Leave a comment if you have any thoughts or
questions. And lastly, click here to try a free Lucidchart
account and start making your own UML diagrams.
