Subtitles of the Movie

Another kind of relationship between use cases is called the extend dependency and the extend dependency indicates an optional relationship between two use cases. So in this dependency you have two use cases, we'll call one base use case and we'll call the other one the extending use case. And what this relationship indicates is that the extending use case expands the behavior of the base use case. You have your base use case you have a discreet series of steps that make up that use case, but at some point in those steps you have an option to extend the use case to include the steps in the extending use case. Now notice the direction of the dependency arrow in an extend relationship, remember that the direction of a dependency arrow indicates the direction of the dependency. So the extending use case depends on the base use case. Also when your drawing an extend dependency it's conventional for the extending use case to appear below the base use case. So as I've said the extending use case expands the behavior of the base use case by adding a new sequence of steps to the steps that already exist in the base use case. So let's look at an example, imagine you're buying gas for your car and you want to make your purchase with a credit card, we'll call that the purchase gas with credit card use case. At some point in the transaction you're offered the option of printing your receipt. You don't have to print a receipt for the sale to be complete but it's an option that you have. So purchase gas with credit card would be the basis case and the extending use case would be print receipt and again as I've said the direction of the dependency arrow goes from the extending use case to the base use case. So we have an extend relationship. Now look what's happened here, when I added the dependency arrow to show the extend dependency between these two use cases we have an opportunity to put in an extension point and what the extension point tells you is where in the base use case the extension use case comes into play. So in this case it would probably be where the account is charged once the gas has been purchased and the charge has made that's going to be the logical place to print the receipt. You don't have to include extension points, you'll see plent of use case diagrams that don't but if you have the information and it's helpful to add it you might want to include it. Now the extension use case may happen as part of the steps in the base use case, in other words it may happen synchronizely in the steps of the base use case or it may happen in parallel, it may happen asynchronizely, either one of those are a possibility. When you're drawing use case diagrams use extensions sparingly, this is something that might clutter up your diagrams, put in too much information, make them hard to read. So ask yourself is there a reason that we want to put this extension in here. Another thing to think about when you're working with extensions is extension use cases are by definition, secondary. In this example the main thing you want the system to be able to do is to charge gas purchase to a credit card, printing the receipt is something that's nice to have, but it's not essential to the base use case. So you might think about extension use cases as candidates for later implementations if you happen to be on a tight schedule.