Subtitles of the Movie

In use case diagrams you show a relationship between use cases through dependency and In this movie, we'll talk about the include dependency. So 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.