Use case basics

Use case basics.We'll talk about use cases, we'll define what they are
take a look at the basic elements that go into a use case and we'll take a
quick look at a use case diagram made with UML.

So our first question to ask is what's a use case?
In other words use cases tell us what the system should do.

Slide 3:
So let's take a look at what goes into use case
for our example

we'll use an automated teller machine,

so for any use case that you would write involving the ATM you would need

1. an actor and an actor is someone or something that has a goal in using the
system.
For this example, obviously the actor is the customer,
so an actor can be a person but an actor also can be another system or an
organization,
basically anyone or anything that has some goal in using this system.
And it can be helpful to think of actors not as individuals but as roles.
2. Goal
So we said the actor has a goal and what we mean by that is simply whatever it is
that the actor wants to achieve by interacting with the system.

For our example let's say that the customer's goal is to get some money.
We'll call this the withdraw cash use case.
A use case title is a statement of the actor's goal in the form of a verb phrase. So
withdraw cash is a good title for our use case.

Use cases capture all the different goals that various actors have in using the
system.

When you're looking to capture the use cases
what you want to do is think of all the actors that you can think of who might
interact with the system and then ask yourself what uses does this actor have for
this system?

Now use cases are written text and often you'll find them in a requirement
specification.
So where does UML come in?

Well UML use case diagrams serve as a visual table of contents to those written
use cases and you'll see what I mean by that in just a minute.

So where does UML come in?
Well UML use case diagrams serve as a visual table of contents to those written
use cases and you'll see what I mean by that in just a minute.

But first let's talk about written use cases.

Now written use cases are really beyond the scope of what we're doing here
because they don't involve UML and they really don't actually have a standard
format that they follow.
But just so you have an idea of what you're working with when your drawing your
use case diagram we'll do a quick overview.

Although for each written use case what you want to do is describe the steps
involved in an interaction between an actor in the system beginning with the
primary actor.

The primary actor is what initiates the use case.

In the ATM example, it's the customer who inserts his card into the machine.

You want to start with the main success scenario and this is sometimes
informally called the happy path and what it is,

is a description of the steps that occur back and forth between the actor and the
system when everything works the way it's suppose to from the time that the use
case begins,

the bank customer inserts his card, to the time the use case successfully finishes,
the actor has the cash in his hand. So that's the happy path, you want to describe
what happens under ideal conditions in an ideal world so that actor achieves his
goal and interacting with the system.

But as we as all know we don't live in an ideal world so the next thing you want
to do is look for alternative paths and there are

two kinds of alternative paths to take into account.
1. One is exceptions, at each step along the main success scenario you stop and
ask what could go wrong here.

For example what would happen if the customer put in more money to
withdraw then he actually had in his bank account,

how would the system handle that?

2. The other kind of alternative path is called an extension,

to find the extensions you ask what other goal might come into play here?

For example some ATM's give you the option of whether or not you want to
print a receipt so at a certain point along the main success scenario the
system might ask do you want a receipt.

You don't have to get a receipt in order to successfully complete the withdraw
cash use case but it's an option that you have.

So the print receipt use case would be an extension of the withdraw cash use
case.

And here's an example of a use case diagram,

this diagram is for an online reservation system for making travel
arrangements and

I just want to point out the basic elements,

1. we have a rectangle here and that represents the system and you see it's
named, online reservation system.
2. Our actors are represented by stick figures and those are also labeled
with the role of that actor. So we have the customer and over here

3. we have a payment processor which is indicated to be a system.

4. We also have our use cases; those are represented by ellipses,

so each use case, the title of it, appears inside an ellipsis inside the
rectangle that represents the systems.

So we have our actors, we have our use cases and we have our system.
We also show relationships between the actors and the use cases and
between the use cases themselves. We'll talk more about this in
subsequent movies as we start to draw our own use case diagrams.

A Use Case Diagram for an ATM
Let's look at our automated teller example to see how we might start to capture the
various use cases in a given system.

1. So we'll start by drawing our system and we'll call it ATM

2. and we will identify an actor who wants to interact with that ATM and we'll call that
actor the customer.

3. So what goals might a customer have in interacting with an ATM system?
Let's see what use cases we can identify, withdraw cash,
 the customer might want to make a deposit.
 Customer might want to check the balance in an account and
 the customer also might want to transfer funds.
You might be able to think of a few more but these will suit our purposes for now.

So in each of these cases the customer is the primary actor who has these various goals
in interacting with the ATM.

4. So to show that we want to make an association between the customer and each
of these different use cases.

5. Now looking at that we might want to ask who else interacts with ATM and it
doesn't take very long to think of another actor. For example somebody has to
perform maintenance on the machine so the way to phrase the use case,

the goal that the maintenance person might have in interacting with the machine
could be something like perform routine maintenance.

Now the maintenance person, not the customer is the initiator of this use case so
we'll indicate that by drawing a line from maintenance, the maintenance person to
perform the routine maintenance use case, we have an association between this
actor and this use case.

6. And also when you think about it the customer can't withdraw cash unless
somebody puts cash in it,

we'll call that person the stocker and the stocker's goal is to fill ATM with cash.

And again there is an association that indicates that this actor is the primary actor
in this use case.

So now we have our system, we have three different actors we've identified and
we have various goals that are associated with the different actors.

The next thing we want to ask is, is there any other actor that
comes into play in order for a particular use case to successfully
finish

and if we look at these, the customer use cases withdraw cash, deposit funds, check
balance and so on, for each of those we do need a secondary actor.

The ATM needs to talk with the bank system in order for each of these goals to be
achieved, so we also have associations from these use cases to this secondary actor.

Now sometimes it's helpful to identify secondary actors, sometimes you don't need
them.

What you want to do is look at your diagram and ask, is this easy
to understand?

Is it getting too cluttered?

Is it clear that the customer is the initiator here and that the bank system comes
into play once the use case has been initiated?

And in this simple diagram that is clear.

So one way that you can show this is to have the primary actors on the left side of
the diagram and the secondary actors on the right.

(UML / Use Case Diagrams / The<>
Dependency)

In use case diagrams you show a relationship between use cases through
dependency

we'll talk about the include dependency.
In use case diagrams the include dependency indicates a necessary relationship between two use
cases.

The invoking use case depends on the included use case in order to be complete.

Let's take a look at what that means,

you have an invoking use case and that use case requires a second use case and

we'll call that the included use case in order to be complete

and you show that relationship with a dotted arrow called a dependency arrow.
And you label the dotted arrowwith the type of dependency you're talking about.

So we'll say include, so take a look at what that suggests, this use case requires or depends on
this use case in order to be complete.

The direction of the dependency arrow always shows the direction of dependency, so this use
case depends on the included use case.

Let's take a look at an example to clarify that a little bit more.

Let's say we have some kind of online purchasing application and our

use case is make a purchase,

now in order for that make purchase use case to be complete at some point the system will have
to verify the purchaser's credit card.

And we draw the arrow between them to show that the make a purchase use case depends on or
includes the verify credit card use case,

so what this diagrams indicates is an order for a make a purchase use case to reach it's goal we
have to include the verify credit card use case.

So the way to think of this is that one use case invokes another, the make a purchase use case
invokes the verify credit card use case.

So you want to use the include dependency when you know exactly when the invoking use
case needs the included use case.

At what point in the process, at some point in the process you know that to make a purchase
you'll have to verify the credit card. So when the sequence of events in the included use case
clearly represent a step in the invoking use case, that's when you use the include dependency.

Also in written use cases it's useful to include a use case when you know that its steps are
required by a number of other use cases.

For example in the ATM example we were using before you might know that you have to verify
balance as part of several different use cases.

So for example you have

 to verify the balance when the customer wants to withdraw cash,

so the withdraw cash use case will include the verify balance use case.

 But another use case such as maybe transfer funds from one account to another also
needs to include that verify balance use case.

As you can imagine this will save you a lot of steps in writing use cases because instead
of having to write the steps one by one for what it takes to verify the balance when you
write the withdraw cash use case, when you write the transfer funds use case you can
write those steps only once as the verify balance use case and then include that use case
in any other use case that invokes it.

And just a quick final note, when you're drawing these diagrams the included use case
always appears to the right of the invoking use case. So that's the convention to keep in
mind when your drawing an include dependency.

You're not likely to actually draw the include relationship in this way in a diagram, it
would clutter things up, this is just to show the concept. But in the written use cases it
can save you a lot of steps if you write an included use case as a separate use case and
then include it in the main success scenarios of any use cases that invoke it.

(UML / Use Case Diagrams / Generalization)

In UML generalization is similar to the object oriented concept of sub classing, it shows
the relationship between a general case and one or more specific specialized cases.

So what we're dealing with really is kind of inheritance hierarchy.

We have a general use case and we'll call it the parent use case that contains a certain set
of behaviors, constraints and assumptions. Now for each specialized use case we'll call it
child one, child two, you're going to have more then one child because otherwise there is
not much point in generalizing if the general is exactly the same as the specific.

So each of these child use cases share those common behaviors, constraints and
assumptions that belong to the parent use case but each adds something more on its
own.

So that child one is a type of parent, child is two is also of the same type as parent but
there is differences between these that make it worth writing their own use case for
each and

you show the generalization relationship with a triangular headed arrow that points
from the child back to the parent.

Now it's a nice principle of drawing diagrams to keep your diagrams neat and one of the
ways to do that is to minimize your number arrows. So with a generalized relationship
you can show it like this and this shows that these two child use cases generalize back to
the parent use case. So let's look at a more specific example.

Thinking about an automated teller machine let's be very general and make our parent
use case do a transaction.

Whenever you do a transaction with an ATM, you have a certain set of behaviors,
constraints and assumptions that come into play.

Specific transactions that share those behaviors, constraints and assumptions but add a
little bit more might be withdraw cash, deposit funds, maybe transfer funds and so
on.

That's enough for illustrated purposes, so each of these involves the behaviors of doing
a transaction.

For example you have to swipe your card, you have to enter a pin but then for each of
these you do something a little bit more that's unique to this particular use case. So we'll
show your generalization relationship and again to neaten that up we minimize the
number of arrows.

So you can show generalized relationships between use cases, you can also show
them between actors.

For example you might have an actor called customer and that customer can behave in
certain ways, have certain constraints and assumptions that apply to role, then you might
have a more specialized example of customer called corporate customer. So everything
that applies to the customer actor also applies to the corporate customer actor but the
corporate customer specializes somewhat.

For example the corporate customer might have monthly billing or the ability to use
purchase orders and so on and again you indicate the generalized relationship between
actors in the same way that you indicate the generalized relationship between use cases.
Now the way to test whether you really got a generalized relationship is to ask yourself is
the child a kind of a type of parent, in other words does it make sense to say the
corporate customer is a kind of customer. If the answer is yes then you've got a
generalized relationship. Same thing with these use cases, is transfer funds a type of
transaction? Yes. Is withdraw cash a type of transaction? Yes. And if the answer is no
then you know that you're not dealing with a generalized relationship and that illustrates
incidentally why you can't generalize between actors and use cases. If you said is a
corporate customer a type of transaction, that wouldn't make any sense at all so we know
that there a generalized relationship would not work.

(UML / Use Case Diagrams / Putting It All
Together)
Let's revisit the use case diagram we saw in an earlier movie so that we can see how all
of these elements and relationships work together to give us a snapshot of what a system

or some part of a system can do. So here we have in the rectangle our system and up at
the top we have the title, it's an online reservation system. Interacting with that system
over here we have an actor who is the customer and the customer has associations with
all of these different use cases, each use case appears inside the system in an ellipse. So
the customer is the primary actor who initiates all of these different use cases, the
customer interacts with the system, in other words whether the customer wants to search
for flights, make a reservation, check flight status and so on, it's the customer who gets
the ball rolling. Over here we have a secondary actor in this case the secondary actor is a
system which is a payment processor. Now the difference between a primary actor and a
secondary actor is the primary actor is the one who initiates the use case, the secondary
actor comes into play once the use case is under way. So for example when the validate
credit card use case starts that use case brings the payment processor, this actor into play.
The besides relationship between actors and use cases we also see relationships between
actual use cases inside the system and a good example here is the purchase ticket use
case. The purchase ticket use case includes the validate credit card use case and as you'll
recall the include dependency is shown by a dotted arrow that points from the dependent
use case to the use case that it depends on. So what include means here is that in order
for the purchase use ticket, use case to be complete the validate credit card use case also
has to be complete. So this must happen before the purchase ticket use case can be
complete. The purchase ticket use case also has an extend relationship with this use case
right here select seat. In this example the dependency arrow points from the extending
use case back to the purchase ticket use case because the select seat use case depends on
the purchase ticket use case. It's not going to happen all by itself, so the extend
relationship means as you know that this use case is optional before this use case is
complete. Now you can probably think of other use cases and you can probably think of
ways in which we might be able to generalize some of these use cases but you want to
keep in mind that your goal is to keep your diagram simple. This diagram as it stands is
simple, it's easy to understand and it doesn't go into too much detail that's going to clutter
up the diagram and make it harder to read.

Use case basics

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (7)

Similar to Use case basics

Similar to Use case basics (20)

Use case basics