Slide 2:

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 ATMLet'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 arrow with 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.