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
*
*************************************************************************
