To further Brian's point, let me throw in another wrench. Rather than have
the <<extend>> or <<include>>, I've been experimenting with another
approach. For use cases analogous to "Register for Courses" that
technically require you to have either performed a search or provided an
identifier (e.g., course number) directly, I would write something as:
"The <Actor> provides the system with the course number of the course for
which he needs to register."
The whole step of providing the course number is abstract. Moreover, there
is no <<include>> or <<extend>> to "Browse for Courses." The actor just
provides the data. It doesn't matter how he did it. Of course you can
still have a use case called "Browse for Courses", but in no way would there
be a relationship betwixt it and "Register for Courses."
In this case, I would leave it up to the user-interface design, which should
be orthogonal to use cases (and vice-versa), to specify a "Register" button
by the list of courses that the "Browse for Courses" use case presented.
Also, think about a use case that required a lot of data entry, say 20
items. What if 15 of those items could be browsed to provide the chosen
input? A "Register for Courses" might have 15 <<include>> or
<<extend>>'s--Oh Mamma!
-----Original Message-----
From: Brian G. Lyons [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 23, 2001 8: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
*
*************************************************************************
