Eric,
Thanks for the king size virtual beer! Splendid flavour - I really enjoy it!
(You made MY day too!)
You are right, <<insert>> would probably cause less misunderstandings.
Lars
-----Original Message-----
From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
Sent: 30. januar 2001 04:11
To: Lars Hauschultz
Cc: Rose Forum (E-mail)
Subject: Re: (ROSE) Bar Bet #2
Lars Hauschultz wrote:
> IMHO use cases do not exist as "things" in the real world, so they cannot
> send messages to each other or communicate whatsoever. [snip]
>
> Using an <<include>>d use case is really more like inserting a source code
> macro than executing a subroutine. [snip]
> if you change the inserted "macro" text, you will have to check all use
> cases which depend(!) on this text to function properly.
>
Very nice, indeed. I like your semantics and your analogy. Behaviour
of the included use case is inserted into the behaviour of the base use
case. Maybe the stereotype should have been <<insert>> !
Not only do you improve my language, but you handle the nub of the bar
bet: dependency is the right relation because changing the included
behaviour may require changing the base behaviour.
I hope the OMG is listening. I wouldn't support <<lars>> or
<<haushultz>>, but <<insert>> is a natural!
IMO, you win a virtual beer! (And my lasting admiration.)
-Eric
Lars Hauschultz wrote:
>
> 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
*
*************************************************************************
************************************************************************
* 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
*
*************************************************************************
