use case generalization override

[Paul Lotz]

Consider the case when we have multiple use cases that perform exactly the same high-level steps, so that the top-level activity diagrams for the use cases are identical.  This would seem to call for an application of the generalization relationship so that we won't have to recreate the same activity diagram multiple times.

Now what if the actions on that top-level diagram differ in the details on the next level down.  (As an example, consider an initialization use case.  All the various subsystems might follow the same high-level process, but the details of the individual steps on the next level down will likely differ.)  I know how to deal with this situation for a class diagram (use inheritance and override parent operations), but I don't see how the generalization relationship helps in this situation in the use case/activity world.  For instance, I can show that UseCase2 is a generalization of UseCase1, but that doesn't link UseCase2 to the activity diagram for UseCase1 and, more importantly, there doesn't seem to be any mechanism to express an override relationship for the actions on UseCase1's activity diagram.  Each action on an activity diagram can be given only one description.

So...at this point I'm planning to recreate the reused top-level activity diagram for each subsystem (undesirable because I am repeating work and because if I make a common change I have to change it in multiple places).  I can add an inheritance relationship when I am done just but this then is little more than a note to myself to take this into account when I design classes.

Is there a better way to do this?  Thanks!

Paul

[«Midnight»]

Without putting too much thought into it...

This might be one of the (rare according to much recent practice) cases where a set of «invoke» - you might use a different method, but the idea is similar regardless - «include» or «extend» [SEE BELOW] links might work. Which case was invoked could be controlled by a decision tree in the 'master' use case.

Such trees are easily represented in your activity diagrams, so this should fit within your paradigm.

David

[Paul Lotz]

David,

Hmmm.... This sounds like it might be helpful.  Is it possible you can refer me to an example somewhere (on-line?) since I am not getting it from your description and searching for UML invoke link or relationship has turned up nothing pertinent?

Paul

[thomas.kilian]

Describe it in the general UC, not in the "calling". So you have a general UC that behave different at certain locations depending on where it is used. There should be parameters you can rely on to make the decision tree.

[«Midnight»]

Paul,

Something made of solid bone became lodged in my head when I wrote the stereotype earlier.

As the edit above now says, use «include» and «extend» relationships as appropriate.

As abcde says, the decision logic belongs in the general (upper level) use case.

Sorry about the confusion.

David

[jeshaw2]

Remember that Use Case relationships are not navigated at application run-time, but only at design & development time.  These relationships are defined to ease the task of maintaining textual specifications by eliminating redundant text.  Heavy use of these relationships without the availability of a Use Case writing tool to reassemble the text for a stakeholder's consumption, make the reading the Use Cases more difficult for the reader must flip pages back and forth to fully understand the logic.

[«Midnight»]

Jim makes two very good points here - no surprise of course - and both bear careful thought.

To reiterate in different language, since I've seen both these situations:

1) Use case extensions are not meant to translate into subroutine calls in a system.

2) If your audience - any one of your potential audiences, whether it be the client business contact or a development team member - cannot easily read and clearly understand your use case, then you are cruisin' for a brusin'.

In the former case make sure your representation (tool or report) does not give this impression. In the latter case take the time to proof read the use case output before you pass it to your audience. Before you go too far, test your format. Perhaps you can get a member of each audience to read through an early version and explain the perceived scenario to you; if it is not what you thought you wrote there is a presentation problem. Otherwise consider getting a complete novice - someone who knows nothing about the system, and preferably nothing about UML - to scan the use case and tell you what it seems to mean.

[I know that was a mouthful, but you'll make all the time back with the very first preview test.]

David

David