> ----------
> From: Lars Hauschultz[SMTP:[EMAIL PROTECTED]]
> Reply To: Lars Hauschultz
> Sent: 30 January 2001 10:15
> To: Rose Forum (E-mail)
> Subject: RE: (ROSE) Bar Bet #2
>
>
> Huseyin,
>
> see my comments inline below.
>
> Lars
>
> -----Original Message-----
> From: Angay, Huseyin (Huseyin)** CTR ** [mailto:[EMAIL PROTECTED]]
> Sent: 30. januar 2001 10:39
> To: '[EMAIL PROTECTED]'
> Subject: RE: (ROSE) Bar Bet #2
>
(...)
> Having a dependency stated explicitly makes life easier. With the above
> example as it stands, you would need to go through your model and check
> every use case that reads or sets the ActiveNavigationCommand when you
> change one use case that reads or sets it. Suddenly, you're back to the
> necessary evil of doing dependency management -- only, in a different
> manner.
> (lh) I agree. I do, though, have the help of Rose. I have made a diagram,
> which shows dependencies between use cases and the concepts. In this way,
> I
> can easily (and automatically per Rose script) check, which use cases
> depend
> on which concepts.
>
You'll certainly go a lot further this way than had you haphazardly created
lots of use cases linked together haphazardly using dependencies. I see the
latter a lot. Unrelated use cases that meddle with the system internals with
no tracking is number two in the top of the evils list.
Nice to see someone doing dependency tracking well.
> Regards,
> Huseyin Angay
> Karabash Ltd.
> www.karabash.co.uk
>
>
> > ----------
> > From: Lars Hauschultz[SMTP:[EMAIL PROTECTED]]
> > Reply To: Lars Hauschultz
> > Sent: 29 January 2001 11:38
> > To: Rose Forum (E-mail)
> > Subject: RE: (ROSE) Bar Bet #2
> >
> >
> > Hi Kristian,
> >
> > let me give you a simplified example, taken from our analysis:
> >
> > Use Case "Enter Navigation Command":
> > User enters a NavigationCommand.
> > System stores the NavigationCommand as ActiveNavigationCommand.
> > End.
> >
> > Use Case "Steer Ship":
> > Invoked by timer every 1 second.
> > System reads ActiveNavigationCommand and transmits corresponding
> > command to Autopilot.
> > End.
> >
> > System, User, Autopilot, NavigationCommand and ActiveNavigationCommand
> are
> > concepts described in the Conceptual Model.
> >
> > ActiveNavigationCommand is actually part of the System state. The first
> > use
> > case changes the state. The second one reads the state and maybe changes
> > the
> > state of the Autopilot.
> >
> >
> > All above are parts of our Analysis Model, from which the Design Model
> > emerges. We are proceding pretty much along the guidelines of Craig
> > Larman,
> > "Applying UML and Patterns", Prentice Hall. IMO, he shows a usable
> method,
> > how to separate analysis and design and how to connect them again.
> >
> > Lars
> >
> >
> > -----Original Message-----
> > From: Kristian Rosenvold [mailto:[EMAIL PROTECTED]]
> > Sent: 29. januar 2001 11:29
> > To: 'Lars Hauschultz '; 'Rose Forum (E-mail) '
> > Subject: RE: (ROSE) Bar Bet #2
> >
> >
> > 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
> *
> *************************************************************************
> ************************************************************************
> * 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
*
*************************************************************************
