I think that one should be very weary of mixing state specifications into
Use Case modelling. The diagrams themselves regard chunking of the
functionality of a system, first and foremost as a requirements management
and project management artifacts. A lot of books on Use Cases (including
some by heavywheight authors) seem to bring use case specifications down to
a level that comes pretty close to user interface design and detailed state
specifications. I think this reflects one of the major weak points of the
Unified Process at its current state,- the user interface design process is
not very well handled. I could generalize further and suggest that the
*design* activities at this specific point in the process are not well
handled, in my experience they are trying to do a complex design job with
too few artifacts.
I like your views on the "functionality" of Use Cases. In my experience,
<<includes>> serves the role og signalling conceptual re-use in an anlysis
model. Wether your are modelling Business Use Cases or System Use Cases, you
are signalling to the analysts/designers further down the road that these
use cases are (probably) the same. In that sense, <<includes>> is an
important prosject management artifact because it allows a possibly large
project group to "see" re-use that could very easily be missed. (Or, done
badly, the opposite way)
Kristian
-----Original Message-----
From: Lars Hauschultz
To: Rose Forum (E-mail)
Sent: 29.01.01 10:16
Subject: RE: (ROSE) Bar Bet #2
Hi Eric,
about communication between use cases:
IMHO use cases do not exist as "things" in the real world, so they
cannot
send messages to each other or communicate whatsoever. For the time
being, I
am on a team, which is building an analysis model for a certain system.
We
often end up in discussions like: "How can a use case send its results
to an
other use case". The way I see it, it is better to use a different
approach:
A use case may change the state of the system (or its actors), and an
other
use case may read the state of the system and react on this. Thinking
this
way forces us to identify system states and leads to clearer and simpler
use
cases.
Using an <<include>>d use case is really more like inserting a source
code
macro than executing a subroutine. The benefit of <<include>> is that
you
don't need to write the same text over and over again. The drawback is
that
if you change the inserted "macro" text, you will have to check all use
cases which depend(!) on this text to function properly.
I hope this sounds reasonable,
Lars Hauschultz.
-----Original Message-----
From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
Sent: 29. januar 2001 00:43
To: Quatrani, Terry; ROSE_FORUM
Subject: Re: (ROSE) Bar Bet #2
Terry,
First of all, I'm thrilled that my favorite writer on the UML actually
replied to Bar Bet #2. I was just at the point of deciding it was a
dud, and trying again to stir some controversy. I'm forwarding the mail
to my mother -- see, Ma, somebody important answered me!
Technically, there is one standard (OMG) answer, and the latest Rose
supports it: we should stop using <<uses>> & <<extends>>, and we should
use <<include>> and <<extend>> with a dependency relationship. The
discussion probably failed to heat up because people have long ago given
up on using these stereotypes "properly", anyway. I *have* used
unidirectional association, at least partly because we haven't upgraded
from Rose 98 yet.
The thing that bugs me most is that unidirectional association with
these stereotypes actually makes more sense to me than dependency.
Clearly, the base use case will not be "compiled" before "linking" with
the extending use case (because we don't compile use cases, at least for
now). On the other hand, association implies messaging, and it seems to
me that, if you can bundle up behaviour into use cases, the bundles can
send messages to each other.
In the end, standards and common usage will trump other considerations.
I accept that. I've been telling people for years that I plan to become
famous by promulgating "Tarkington's Principle", which says: "It's
better that it be standard than that it be good." That's a very
perverse idea to software types, who are nitpicking perfectionists by
nature, but it's amazing how often it applies. Call it "Tarkington's
Perverse Principle", if you like. For me, it applies here.
It's quite clear that dependency is the standard relationship to use
with <<include>> and <<extend>> in use case diagrams, therefore that's
the better answer until standards change. It still doesn't strike me as
a good answer, though.
I'm looking forward to your next version of Visual Modeling with RR,
though I don't expect you to explain why dependency is intuitively the
right relationship in a basic introductory book on the UML.
But, it would be very nice if one of the philosophers or angels at
Rational Corp. has written this up somewhere. Please, somebody, just
give me a sense of the word "dependency" that makes sense in this
context. Bend me, shape me.
-Eric
"Quatrani, Terry" wrote:
>
> Eric,
> Now you can see how hard it is to write a book when things keep
changing.
> In the earlier versions of UML (and Rose) the relationships between
use
> cases were uses and extends and I think the notation was indeed a
> generalization arrow. In later (and the current) version of UML, the
words
> changed to include and extend and the notation was a stereotyped
dependency.
> But Rational Rose did not support that (so I used a stereotyped
> association). Now, Rose does support a stereotyped dependency between
use
> cases. So the correct answer is "there are two different
relationships
> between use cases. They are include and extend. Both relationships
are
> stereotyped dependencies. For an include relationship, the dependency
> points from the use case doing the using to the used use case. For an
> extend relationship, the dependency points from the extension use case
to
> the base use case (the use case being extended". These relationships
will
> be update in the next version of my book (which I am starting to
write).
> Hope this helps.
> TQ
>
> Terry Quatrani
> Rose Evangelist
>
> Phone: 610-940-2132
> Cell: 610-659-8272
> Fax: 610-940-2150
>
> -----Original Message-----
> From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 25, 2001 2:24 AM
> To: ROSE_FORUM
> Subject: (ROSE) Bar Bet #2
>
> It's been months since Bar Bet #1 (which I really enjoyed, thanks),
but
> I guess everyone will forgive, since we are all too busy for humans.
>
> Largely because I'm teaching the UML at Seneca College (School of
> Computer Studies), I keep on asking basic questions over and over.
The
> instructors don't agree about some basic stuff, and neither does the
> literature on the UML. We get down to the point where you can't
appeal
> to logic and you can't appeal to authority.
>
> So, here's my latest vexed question: In use case diagrams, how do
> association stereotypes know which way to go?
>
> In VISUAL MODELING WITH RATIONAL ROSE AND UML, (c)1998, p. 34, Terry
> Quatrani writes: "Uses and extends relationships must use stereotypes
> because they are both represented by a generalization arrow."
>
> In VISUAL MODELING WITH RATIONAL ROSE 2000 AND UML, (c)2000, p. 34,
> Terry Quatrani writes: "Include and extend relationships must use
> stereotypes since they are both represented by a dependency
> relationship." The rest of chapter 3 contains examples that
> consistently use a unidirectional association relationship, instead.
>
> We're teaching an introduction to the UML using Rose, and we've been
> treating include/extend as identical to uses/extends. So, reading
> Quatrani, we get three options for which relationship "goes with"
> include and extend stereotypes:
> 1. generalization (solid line, closed arrow)
> 2. dependency (dashed line, open arrow)
> 3. unidirectional association (solid line, open arrow)
>
> Quatrani is a genuinely excellent resource, who gives a lot of her
kung
> fu along with the facts in her books. Which one of these options is
> wrong? Is more than one of them right? Are uses/extends the same as
> include/extend? When David Duchovny comes back, will there be another
> season of X-Files?
>
> There are actually two bar bets here. My final formulation is:
> 1. Uses/extends is the same as the newer include/extend.
> 2. Unidirectional association is the relationship to which these
> stereotypes should apply.
>
> As before, I won't tell what I think until the pressure becomes
> unbearable.
>
> -Eric
************************************************************************
* 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
*
*************************************************************************
