I have never modeled a system without them. I agree though that for the
first cut, there should be none (unless the modelers have a lot of
experience, and have been successful before. Then it is conceivable they
could have a few). I teach my students, and practice myself, the following:
Don't bother w/ abstract use cases (includes, extends, generalization) until
the concrete ones have been written.
In writing the concrete ones, if the main flow gets to unwieldy, you can put
a good cohesive part in a separate use case and include it. This can aid in
estimation later on too. Also, if there is a series of steps that are
needed in other use cases from your main flow, then that becomes a candidate
to get put into its own use case and included by your use case (and those
others too). In the past, we set the limit at 1 full page of transactions
per main flow. If the main flow exceed that, we would break it up. I know
there are a lot of you who don't like that strategy. I like it because:
1. It keeps use cases at roughly the same size, allowing for more
accurate estimation
(Our formula also counts number of relationships to other
use cases, supplemental requirements traced to the use case, with their
difficulties, and the number of rules and glossary references as well. All
of those help to understand the complexity of a use case.)
2. It forces people to write the narratives before they start
structuring the model.
3. The structuring is based on requirements density, not on system
functionality, preventing functional decomposition.
Also in writing the concrete use cases, if any alternate flows get too
clumsy (over a page, or if they have alternates, and those alternates have
alternates) then you could take the alternate and put it in a separate use
case that extended the current one. Thus no use case had more than three
levels of alternates before being repaired. We also broke an alternate out
if it could extend multiple other use cases.
These guidelines helped to bring order to peoples use case efforts.
Functional decomposition went away, and the level of abstraction in the use
case models was being dictated by the requirements density and complexity.
Overall has worked well for me.
This is not THE answer for includes and extends, but it is one that has
proven to work for some. Take it for what it's worth.
--anthony
> -----Original Message-----
> From: Quatrani, Terry [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 10:00 AM
> To: 'Couball, James'; '[EMAIL PROTECTED]'; 'Eric D. Tarkington';
> 'Rose Forum'
> Subject: RE: (ROSE) UML question number one --found RUP's answer...
>
>
>
> James,
> I think that is a very good practice. Too many times I have seen
> customers create a functional decomposition of a system by
> using extend and
> include relationships all over their use case diagrams. I
> rarely use them
> at all.
> My 2 cents,
> TQ
>
> Terry Quatrani
> Rose Evangelist
>
> Phone: 610-940-2132
> Cell: 610-659-8272
> Fax: 610-940-2150
>
>
> -----Original Message-----
> From: Couball, James [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 11:33 AM
> To: '[EMAIL PROTECTED]'; Couball, James; 'Eric D.
> Tarkington'; 'Rose
> Forum'
> Subject: RE: (ROSE) UML question number one --found RUP's answer...
>
>
>
> In fact, I make it a rule for people around here to take the
> first cut at
> use cases without considering include, extend, or
> generalization. These
> things make it easier for development, but do not prompt better
> understandability from the client's perspective.
>
> Sincerely,
> James.
>
> -----Original Message-----
> From: Brian G. Lyons [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 5:29 AM
> To: Couball, James; 'Eric D. Tarkington'; 'Rose Forum'
> Subject: RE: (ROSE) UML question number one --found RUP's answer...
>
>
> hiho,
>
> This is a very important sanity check. It is all well and
> good to nit-pick
> know about the subtle nuances of the notation, but the point
> is to gather
> understandable requirements.
>
> When considering breaking use cases up and using these
> relationships that
> have been discussed, stop and reconsider if the added
> complexity is worth
> it.
>
> ------- b
>
> --
> Brian G. Lyons
> Number Six Software - Voted Rational's Best Complementary
> Service Provider
> 1655 North Fort Myer Drive, Suite 1100
> Arlington, VA 22209-3196
> http://www.numbersix.com
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Couball, James
> Sent: Thursday, March 22, 2001 11:00 PM
> To: 'Eric D. Tarkington'; 'Rose Forum'
> Subject: RE: (ROSE) UML question number one --found RUP's answer...
>
> I am beginning to believe that as long as your the use cases
> capture all the
> functionality, you can probable get by with stating it many
> different ways.
>
> I have see others argue endlessly about structuring the use
> cases this way
> or that without actually proceeding with any real work for
> days (and even
> weeks in one case).
>
> Sincerely,
> James.
>
> -----Original Message-----
> From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 22, 2001 7:17 PM
> To: 'Rose Forum'
> Subject: Re: (ROSE) UML question number one --found RUP's answer...
>
>
>
> I like that! Define the "Browse" use case as anything that
> delivers the
> sought-for thing. Suppress the detail.
>
> Besides, you can't *prove* that isn't what I meant in the first place!
> The typical browse dialog box has an edit box for typing in
> whatever you
> like, y' know. All of which goes to demonstrate another important
> feature in a method: a tendency to hide my mistakes! (If any --
> remember, you can't prove a thing!)
>
> -Eric
>
> Chris Gardner wrote:
> >
> > 2. Use <<include>> to include an abstract use case that's
> specialized to
> > handle the different ways to select a stock or a course.
> >
> > As an OO person, the second appeals to me more, but I don't
> know what the
> > customer would think. Sorry for the long-winded response.
> >
> > -----Original Message-----
> > From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, March 22, 2001 12:49 PM
> > Cc: 'Rose Forum'
> > Subject: Re: (ROSE) UML question number one --found RUP's answer...
> >
> > How 'bout this?
> >
> > Student <<communicate>> Register for Courses <<include>>
> Browse Course
> > Selections
> > &
> > Professor <<communicate>> Select Courses to Teach <<include>> Browse
> > Course Selections
> **************************************************************
> **********
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
> http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> **************************************************************
> ***********
> **************************************************************
> **********
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
