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