Subtitles of the Movie

Use case basics. In this movie, 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? Use cases capture the functional that is the behavioral requirements of a system. In other words use cases tell us what the system should do. As well use cases describe the interactions between various actors and the system. 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 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. 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. 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. 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? 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, we have a rectangle here and that represents the system and you see it's named, online reservation system. 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 we have a payment processor which is indicated to be a system. 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.