Slide 2:Use case basics.Well talk about use cases, well define what they aretake a look at the basic elements that go into a use case and well take aquick look at a use case diagram made with UML.So our first question to ask is whats a use case?In other words use cases tell us what the system should do.Slide 3:So lets take a look at what goes into use casefor our examplewell 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 lets say that the customers goal is to get some money. Well call this the withdraw cash use case. A use case title is a statement of the actors 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 thesystem.When youre looking to capture the use caseswhat you want to do is think of all the actors that you can think of who mightinteract with the system and then ask yourself what uses does this actor have forthis system?Now use cases are written text and often youll find them in a requirementspecification.So where does UML come in?Well UML use case diagrams serve as a visual table of contents to those writtenuse cases and youll 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 writtenuse cases and youll see what I mean by that in just a minute.But first lets talk about written use cases.Now written use cases are really beyond the scope of what were doing herebecause they dont involve UML and they really dont actually have a standardformat that they follow.But just so you have an idea of what youre working with when your drawing youruse case diagram well do a quick overview.Although for each written use case what you want to do is describe the stepsinvolved in an interaction between an actor in the system beginning with theprimary actor.The primary actor is what initiates the use case.In the ATM example, its the customer who inserts his card into the machine.
You want to start with the main success scenario and this is sometimesinformally called the happy path and what it is,is a description of the steps that occur back and forth between the actor and thesystem when everything works the way its suppose to from the time that the usecase begins,the bank customer inserts his card, to the time the use case successfully finishes,the actor has the cash in his hand. So thats the happy path, you want to describewhat happens under ideal conditions in an ideal world so that actor achieves hisgoal and interacting with the system.But as we as all know we dont live in an ideal world so the next thing you wantto do is look for alternative paths and there aretwo 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 ATMs 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 dont have to get a receipt in order to successfully complete the withdraw cash use case but its an option that you have.
So the print receipt use case would be an extension of the withdraw cash usecase.And heres an example of a use case diagram,this diagram is for an online reservation system for making travelarrangements andI just want to point out the basic elements,1. we have a rectangle here and that represents the system and you see its 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 here3. 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. Well talk more about this in subsequent movies as we start to draw our own use case diagrams.
A Use Case Diagram for an ATM Lets look at our automated teller example to see how we might start to capture the various use cases in a given system. 1. So well start by drawing our system and well call it ATM 2. and we will identify an actor who wants to interact with that ATM and well call that actor the customer. 3. So what goals might a customer have in interacting with an ATM system? Lets 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 doesnt 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 well 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 cant withdraw cash unless somebody puts cash in it, well call that person the stocker and the stockers 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 weve 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 its helpful to identify secondary actors, sometimes you dont needthem.What you want to do is look at your diagram and ask, is this easyto understand?Is it getting too cluttered? Is it clear that the customer is the initiator here and that the bank system comesinto 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 ofthe 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 throughdependencywell talk about the include dependency.In use case diagrams the include dependency indicates a necessary relationship between two usecases.The invoking use case depends on the included use case in order to be complete.Lets take a look at what that means,you have an invoking use case and that use case requires a second use case andwell call that the included use case in order to be completeand you show that relationship with a dotted arrow called a dependency arrow.And you label the dotted arrowwith the type of dependency youre talking about.So well say include, so take a look at what that suggests, this use case requires or depends onthis use case in order to be complete.The direction of the dependency arrow always shows the direction of dependency, so this usecase depends on the included use case.
Lets take a look at an example to clarify that a little bit more.Lets say we have some kind of online purchasing application and ouruse case is make a purchase,now in order for that make purchase use case to be complete at some point the system will haveto verify the purchasers credit card.And we draw the arrow between them to show that the make a purchase use case depends on orincludes the verify credit card use case,so what this diagrams indicates is an order for a make a purchase use case to reach its goal wehave 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 caseinvokes the verify credit card use case.So you want to use the include dependency when you know exactly when the invoking usecase needs the included use case.At what point in the process, at some point in the process you know that to make a purchaseyoull have to verify the credit card. So when the sequence of events in the included use caseclearly represent a step in the invoking use case, thats when you use the include dependency.Also in written use cases its useful to include a use case when you know that its steps arerequired by a number of other use cases.For example in the ATM example we were using before you might know that you have to verifybalance 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 youre drawing these diagrams the included use case always appears to the right of the invoking use case. So thats the convention to keep in mind when your drawing an include dependency. Youre 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 were dealing with really is kind of inheritance hierarchy. We have a general use case and well call it the parent use case that contains a certain set of behaviors, constraints and assumptions. Now for each specialized use case well call it child one, child two, youre 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 andassumptions that belong to the parent use case but each adds something more on itsown.So that child one is a type of parent, child is two is also of the same type as parent butthere is differences between these that make it worth writing their own use case foreach andyou show the generalization relationship with a triangular headed arrow that pointsfrom the child back to the parent.Now its a nice principle of drawing diagrams to keep your diagrams neat and one of theways to do that is to minimize your number arrows. So with a generalized relationshipyou can show it like this and this shows that these two child use cases generalize back tothe parent use case. So lets look at a more specific example.Thinking about an automated teller machine lets be very general and make our parentuse 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 alittle bit more might be withdraw cash, deposit funds, maybe transfer funds and soon.Thats enough for illustrated purposes, so each of these involves the behaviors of doinga 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 thats unique to this particular use case. So well 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 youve 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 youre not dealing with a generalized relationship and that illustrates incidentally why you cant generalize between actors and use cases. If you said is a corporate customer a type of transaction, that wouldnt make any sense at all so we know that there a generalized relationship would not work.(UML / Use Case Diagrams / Putting It AllTogether) Lets 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 atthe top we have the title, its an online reservation system. Interacting with that systemover here we have an actor who is the customer and the customer has associations withall of these different use cases, each use case appears inside the system in an ellipse. Sothe customer is the primary actor who initiates all of these different use cases, thecustomer interacts with the system, in other words whether the customer wants to searchfor flights, make a reservation, check flight status and so on, its the customer who getsthe ball rolling. Over here we have a secondary actor in this case the secondary actor is asystem which is a payment processor. Now the difference between a primary actor and asecondary actor is the primary actor is the one who initiates the use case, the secondaryactor comes into play once the use case is under way. So for example when the validatecredit 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 betweenactual use cases inside the system and a good example here is the purchase ticket usecase. The purchase ticket use case includes the validate credit card use case and as youllrecall the include dependency is shown by a dotted arrow that points from the dependentuse case to the use case that it depends on. So what include means here is that in orderfor the purchase use ticket, use case to be complete the validate credit card use case alsohas to be complete. So this must happen before the purchase ticket use case can becomplete. The purchase ticket use case also has an extend relationship with this use caseright here select seat. In this example the dependency arrow points from the extendinguse case back to the purchase ticket use case because the select seat use case depends onthe purchase ticket use case. Its not going to happen all by itself, so the extendrelationship means as you know that this use case is optional before this use case iscomplete. Now you can probably think of other use cases and you can probably think ofways in which we might be able to generalize some of these use cases but you want tokeep in mind that your goal is to keep your diagram simple. This diagram as it stands issimple, its easy to understand and it doesnt go into too much detail thats going to clutterup the diagram and make it harder to read.