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

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

Post by idob » Fri, 29 Dec 2006 18:23:10


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

I design the use case "Process File".

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?
or
- Three use cases: "scan file" "browse" "mail" with <<include>>
relation to 4th use case "Process"?
or
- One use case "Process", with <<generalize>> relation to the 3 use
cases "scan","browse","mail"?

Thank you.
 
 
 

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

Post by Mark Woyn » Fri, 29 Dec 2006 23:56:44

I would start with a single use case, "Process File", with 3 scenarios,
and see if that works. The approach follows the "do the simplest thing
that can possibly work" philosophy.

Keep in mind that a use case is nothing but a requirements document.
What do you gain by splitting the use case into multiple parts? Who's
the intended audience? Which approach do you think would be the easiest
to follow? Will it be easier to jump between multiple documents, or
have everything grouped together in a single document?

IMHO, focusing on producing the world's greatest, most complicated use
case model distracts one from the real goal: capturing clear
requirements that one can then turn into working software. In fact, one
might argue whether use cases are appropriate for such trivial
functions. User Stories might be preferable.

Mark

 
 
 

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

Post by Nick Malik » Sat, 30 Dec 2006 00:50:46

Note that the use case may not be the actual place where you describe the
activity that takes place when you process the file. Processing the file
may be something that the user doesn't actually understand. Use cases
describe things that the user understands.

Therefore, I'd say that you have three different use cases (because the user
will view each of these interactions as having a different motivation or
reason for using them). Each will simply end with a part of the scenario
that says " the file is submitted for processing (use case 99) and the
user's view changes to XXX"

A seperate use case, written from either the technical viewpoint, the
auditor's viewpoint, or the operations manager's viewpoint, can describe the
activities that will occur when a file is processed.

Hope that helps,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://www.yqcomputer.com/

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
 
 

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

Post by H. S. Lahm » Sat, 30 Dec 2006 02:24:46

esponding 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.


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


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.


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.]


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
XXXX@XXXXX.COM
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslah