Originally posted by Joseph Sweet: I don't know, but both these definitions look the same to me. Can you help me understand what is the difference between generalization and extend?
It's a matter of direction. For an extension you are looking from the basic to the derived (from the general to the more specialized). For a generalization you are looking from the specialized to the more general.
So generalization and extension are opposite views of the same thing.
Quite often you are dealing with multiple similar cases and you are looking for the commonalities between them - you are looking for a generalization. Then later you discover more cases an add them as extensions of your generalization.
1. So you say it's the same thing, but from different directions. So I build a diagram, and if I put the arrow this way then it's extend, but if I put it that way then it's a generalization? Seems weird to me.....
2. Look at the image in the link.... "Pay Bill" is the super case (the general case). Both "Defer Payment" and "Bill Insurance" are special cases of that case.... but you reach from "Defer Payment" to "Pay Bill" by saying "Defer Payment extends Pay Bill", while you reach from "Bill Insurance" to "Pay Bill" buy saying "Pay Bill is a generalization of Bill Insurance".... So even the arrows are at the same direction, because the titles on the arrows match to inverted sentences in English.....
Joined: Aug 19, 2005
Should have looked at the diagram to get those neurons firing again.
The generalization is "more like" inheritance. The parent captures the commonality of the children - the parent could be abstract. Each child is a full description of a use case.
An extend is more like a "plugin" or "module" that plugs into the extension points of the base use case. So to get the full extended use case you have to look at "base + extend". The base case can specify multiple extension point names - the extension can then insert segments into these extension point to modify the behavior of the base case.
Then there is also the "include" which typically is a fragment can be shared between multiple use cases.
Of all the diagrams in UML, use case diagrams are the most confusing, and the least useful. With the exception of the system boundary diagram, which I�ll describe in a minute, I recommend that you avoid the them entirely.
If you have to expend any effort on use cases (instead of User Stories) you should focus on the text-based use cases:
Use case relationships fall into the category of things that �seemed like a good idea at the time�. I suggest that you actively ignore them. They�ll add no value to your use cases, or to your understanding of the system, and they will be the source of many never ending debates about whether or not to use �extends� or �generalization�.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus