Subtitles of the Movie

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.