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
This example does not prove or disprove the usability of "include" and other
use case dependencies.
(lh) I agree.
Had your navigation system been required to steer the ship every time a
navigation command was entered, including Steer Ship in Enter Navigational
COmmand would have been more appropriate and more correct.
(lh) Again, I agree.
What this use case pair says is that it is sufficient to react to one
navigation command
per second.
(lh) In this case the autopilot will only accept exactly one command per
second. This is an important and explicitly wanted behaviour of the system,
which I am not able to describe in any better way than using the system
state as a means of coupling between the two use cases.
Now, what if you had to react to every navigation command?
(lh) Then, I would have used <<include>>.
Well, maybe the system cannot issue more than a few navigation commands a
second.
But what about the future? What if the navigation commands came at the rate
of several a second? Suddenly, you have an invisible (or, at least,
indirect) dependency between these two use cases: you have to make a
decision about how to handle these -- e.g. increase the polling rate or
state that it is acceptable to ignore all but one of the navaigation
commands every second.
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.
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
*
*************************************************************************
