If you live by use case semantics, the Browse Course Selections use case
must be performed. What if there are other ways to specify a course. For
example:
* What if you can provide the course number directly without browsing?
* What if you can select from a group of courses that you previously marked
as candidate course to take?
* What if you can select from a group of courses that you flunked and want
to retake?
An example from the Stock Trading domain:
I can choose a stock to buy in at least 3 ways:
* Browse for stocks that match certain criteria and choose one to buy.
* Directly provide the system with the symbol of the stock.
* Buy more of a stock currently owned (i.e., get a list of positions and
tell the system to buy more of a particular stock).
I see two ways to model these situations:
1. Use <<extend>> for the more colorful ways to select a stock or a course
(assuming providing the symbol or course number directly would be the
default behavior. You would specify an extension point around the step at
which you need to provide a stock. The step itself would read something
like "The Investor provides the system with the symbol of the stock to buy."
This way you're not really saying how he's doing it, but if the condition of
the extending use case isn't true, you know the Investor has to provide the
stock symbol directly; otherwise, he provided it some other way.)
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
...Which says that the "Browse Course Selections" behavior is inserted,
at need, into the "Register for Courses" behavior and the "Select
Courses to Teach" behavior.
I'm tempted to attach a .gif image of the diagram fragment, and make it
look like the signature of the artist formerly known as "Prince".
Rusty has stirred up as much virtual ink as a bar bet over this, which
reminds me....
-Eric (not the same one)
"Crain, Anthony R." wrote:
>
> Abstract and Concrete use cases are discussed in the RMUC course.
>
> An abstract use case is one that supports other use cases. Eric, you HAVE
> used them if you have used extends or includes.
>
> Concrete use cases have an actor that point to it. Like student points to
> register for courses. The actor is what I call the primary actor and it
> receives value from the use case. There are also secondary actors who can
> assist in the achievement of the use case.
>
> An abstract use case is not supposed to have any primary actors, but can
> benefit from secondary actors. This is theoretical. If you do have a use
> case that is both abstract and concrete (that is, it has a primary actor,
> but can also extend another use case, or be included by another use case)
> that violates convention. It is also harder to write the narrative, and
the
> sequence diagrams later on.
>
> A concrete use case always begins like this:
> Primary actor does something to system.
>
> An abstract use case does not have a primary actor and can start with the
> system doing something or an unspecific actor doing something.
>
> If a use case is both abstract and concrete, then what are it's rules for
> the narrative?
>
> So personally I avoid them, but having them will not make or break a
> project. If you allow for them, document any rules about how to write
their
> narratives.
>
> Need an example?
>
> Let's go back to Student and Register for Courses. Let's add another use
> case called Browse Course Offerings. One might think that Browse Course
> Offerings is a concrete use case because it students claim they feel
> browsing courses is valuable apart from Registering for Courses.
>
> So you model it like this:
>
> Student -------> Register for Courses
> \
> \
> \
> \-----> Browse Course Selections
>
> ( if only there were a tool to help me draw these! ;) )
>
> But on further thought, Browse Course Selections can help with Register
For
> Courses, so people then model it like this as an <<extends>> since you
don't
> have to do it but could:
>
> Student -------> Register for Courses
> \ ^
> \ | <<extends>>
> \ |
> \-----> Browse Course Selections
>
> Bam! Browse Course Selections is now both Abstract and Concrete. It has
> Student as a Primary Actor (concrete) but helps other use cases by
extending
> Register for Courses (abstract). It is complete and incomplete. It
starts
> with the Student, but doesn't have to. It is a result of value all by
> itself, but also just a step in a larger goal. Hence the confusion.
>
> Next people model it like this, thinking it might make things clearer:
>
> Student Register for Courses
> \ |
> \ | <<extends>>
> \ \/
> \-----> Browse Course Selections
>
> The logic here is that you will definitely Browse Course Selections, but
you
> may or may not Register for Courses when doing so. The problem is that
the
> major benefit is really Register for Courses and this solution diminishes
> that.
>
> The solution I would use is this:
>
> Student -------> Register for Courses
> ^
> | <<extends>>
> |
> Browse Course Selections
>
> The logic here is that the real goal is to Register for Courses, and now
it
> looks like it. What about Browsing by itself? Well, even if you aren't
> going to Register today, and are just doing some research, the truth is,
you
> wouldn't be doing it just for fun, right? You're doing it, because
> eventually you will Register. So the only difference is timing. Same
goal.
> Also, if you write the narrative such that in step 1 of Register for
Courses
> (or at anytime in Register for Courses) I can Browse Course Selections,
and
> I can also quit at anytime, now I can still Browse and Quit as scenario
> within the Register for Courses use case.
>
> Also this works nicely once we add the Professor and his goal of Sign up
to
> Teach Courses, which would also have Browsing in it:
>
> Student -------> Register for Courses
> \ ^
> \ | <<extends>>
> \ |
> \-----> Browse Course Selections
> |
> | <<extends>>
> \ /
> Professor -----> Select Courses to Teach
>
> If you made it this far, I am impressed.
>
> --anthony
>
> > -----Original Message-----
> > From: Aker, Eric [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 21, 2001 2:13 PM
> > To: 'Williamson, Rusty'; Aker, Eric; 'Rose Forum'
> > Subject: RE: (ROSE) UML question number one --found RUP's answer...
> >
> >
> >
> > OH YEAH, I have heard of that ;-)
> >
> > But I have never used one. All of my Use Cases do attach to actors
> > or are extended/included from a Use Case that is.
> >
> > When you extend/include a use case then almost by definition the
> > exending/including use case is NOT complete and can NOT stand by
> > itself. If a use case is including another use case then it also
> > is not complete.
> >
> > HHmmm... interesting. I think I will go read some more on this.
> >
> > Thanks for the pointer.
> > Eric
> >
> > -----Original Message-----
> > From: Williamson, Rusty [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 21, 2001 12:42 PM
> > To: 'Aker, Eric'; 'Rose Forum'
> > Subject: RE: (ROSE) UML question number one --found RUP's answer...
> >
> >
> > Eric,
> >
> > Original question:
> > Does anyone know if there is any kind of requirement that use cases in
> > extent and include relationships must always be abstract use cases?
> >
> > You teach a Rational OOA&D class and you do not know what an
> > abstract use
> > case is? I don't know what to say to that. An abstract use
> > case is one
> > that is not complete - can not stand by itself and can not be
> > connected to
> > an actor (versus a concrete use case which is always
> > connected to an actor).
> > This definition (I paraphrased of course) can be found in the
> > OMG UML Spec,
> > all of the 3-A's books on UML and UP as well as just about
> > every use case
> > book I've read. I'm sure your going to shake your head and
> > go 'oh yeah...'.
> >
> > Anyway I found the answer to my question... I guess. Interestingly I
> > searched the OMG specification and also the 3-A's UML
> > Reference and User
> > Guide and could not find anything on my particular question.
> > Maybe I just
> > missed it. Also, so far, replies from the industry (this
> > forum, newsgroups,
> > cafes) all say 'unknown' or 'not that I know of'.
> >
> > However, in the RUP eCoach (i.e. the web pages that describe
> > RUP), in the
> > sections on:
> > * Guidelines: Include Relationship
> > * Guidelines: Extend Relationship
> >
> > It states that:
> > * Included use cases are 'always' abstract
> > * Extended use cases 'may be' abstract
> >
> > Hmm... is that really the 'standard'? I guess that it makes
> > sense based on
> > the strict definitions (although it's going to change some of
> > what we've
> > done). Live and learn...
> >
> > Thanks!
> > Rusty
> > ---------------------------------------------------------------
> > Rusty Williamson
> > Sr. Systems Architect
> >
> > Corporate Office
> > GERS, Inc.
> > 10431 Wateridge Circle * San Diego, CA 92121
> > (800) 854-2263 * CA (858) 457-3888
> > FAX (858) 484-9237 * Desk (858) 484-9237
> > E-mail: [EMAIL PROTECTED] * Web http://www.gers.com
> > "e-Business Solutions for the Consumer-Driven World"
> >
> >
> > -----Original Message-----
> > From: Aker, Eric [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 21, 2001 11:00 AM
> > To: 'Williamson, Rusty'; 'Rose Forum'
> > Subject: RE: (ROSE) UML question number one
> >
> > No there is not.
> > What is a "abstract use case"?
> > I know what an abstract class is.
> >
> > Eric Aker
> >
> > -----Original Message-----
> > From: Williamson, Rusty [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 21, 2001 10:14 AM
> > To: 'Rose Forum'
> > Subject: (ROSE) UML question number one
> >
> >
> >
> > Hello,
> >
> > Does anyone know if there is any kind of requirement that use cases in
> > extent and include relationships must always be abstract use cases?
> >
> > Thanks!
> > Rusty
> > ---------------------------------------------------------------
> > Rusty Williamson
> > Sr. Systems Architect
> >
> > Corporate Office
> > GERS, Inc.
> > 10431 Wateridge Circle * San Diego, CA 92121
> > (800) 854-2263 * CA (858) 457-3888
> > FAX (858) 484-9237 * Desk (858) 484-9237
> > E-mail: [EMAIL PROTECTED] * Web http://www.gers.com
> > "e-Business Solutions for the Consumer-Driven World"
> >
************************************************************************
* 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
*
*************************************************************************
