Re: use case <<include>> vs. <<generalize>>

Responding to Idob...

I basically agree with Woyna: do whatever you feel will be most clear to the developers for the particular application in hand. All three options are just reorganizing the use case to eliminate redundancy in specifying the 'process' task.

Hi I would like to have your opinion about the following:

I design the use case "Process File".

Note that name you have chosen already makes a statement about what is the central notion in the use cases. B-)

There are 3 situations of processing the file:
- scan and process
- browse and process
- get mail attachment and process.

What is the best way to describe it in use case model?:

- Use case "Process", in the uc, script with 3 options?

This would probably be the best choice if the important thing that the use case describes is the processing of the file information. That is, how the source of the file information is acquired is secondary.

or
- Three use cases: "scan file" "browse" "mail" with <<include>>
relation to 4th use case "Process"?

This would probably be the best solution if the use case is primarily concerned with how the file information is obtained. That would be common in an interactive application where the user needs to do different things to obtain the file information. Remember that use cases are requirements that describe black box functionality from the user's perspective. So even though the common processing may be quite complex at the software level, the user may perceive the different interactive modes as dominant.

Note that this is a trade-off between making things clear to the developers and ensuring the requirements are specified properly. One value of use cases is that they describe how the software is actually used. That tends to reduce requirements specification errors. So ideally one wants to define use cases in terms of what the user does with the software. OTOH, one wants to make sure the developers understand what is really important in the use case.

[Of course, separating the file processing into a standalone included "Process" use case does a pretty good job of emphasizing the importance of the file processing. B-) In the end it really comes down to what the details of the particular situation are.]

or
- One use case "Process", with <<generalize>> relation to the 3 use
cases "scan","browse","mail"?

FWIW, in practice I have never seen much use for generalization in use cases for two reasons. One is that in practice there is no formal mapping of how the subordinate use cases are substituted in the main use case. Another is that in use cases, unlike OO generalization, the goal is to fully specify exactly what the differences are. That is, in an OO Class Model generalization the specific implementation in each subclass is not specified.

To put it another way, use case generalization is a UML construct. That's fine for UML because UML does not specify the /content/ of use cases. So there may be a logical generalization but the mechanics of actually writing the use cases so the developers know what is going on are another thing entirely. The clearest way to actually write the use cases is to have the supercase empty and each subcase substitutes its own "implementation" within the body of the overall use case, which makes for a lot of redundancy.

Alternatively one can use some custom notation in the <common> supercase specification to indicate that substitution takes place; in effect identifying a selective <<includes>>. However, that gets messy if the specializations affect more than one place in the supercase because the mapping of which part of the subcase to substitute in each location is ambiguous.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.