Anthony,
Awesome dissertation and examples. Kind of got on a roll didn't you?! Very
cool! Just one little problem... maybe...
>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.
Now, assuming that what RUP says is 'convention', although it claims that
use cases used with 'include' must always be abstract, it states that use
cases used with 'extend' can either be abstract or concrete.
Perhaps:
a) Your explanation and examples did not really dispute this (they certainly
seem to though)
b) You know something we don't (like RUP is not stating the OMG standard's
view)
In either case, it sounds like you know your stuff so I'd like to get your
take on this.
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: Crain, Anthony R. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 5:00 PM
To: Aker, Eric; 'Williamson, Rusty'; 'Rose Forum'
Subject: RE: (ROSE) UML question number one --found RUP's answer...
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
*
*************************************************************************
************************************************************************
* 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
*
*************************************************************************
