RE: (ROSE) Use cases: When its not clear who gets the value

[Angay, Huseyin (Huseyin)** CTR **]

> ----------
> From:         Lars Hauschultz[SMTP:[EMAIL PROTECTED]]
> Reply To:     Lars Hauschultz
> Sent:         27 March 2001 11:15
> To:   Rose Forum (E-mail)
> Subject:      RE: (ROSE) Use cases: When its not clear who gets the value
> 
> 
> Hi Huseyin,
> 
> I do not want Time being an actor in order to satisfy some schoolmaster
> telling me that all use cases must have actors. I want Time being an actor
> so that I can easily collect use cases, which are initiated at specific
> moments in time. I need this for reports etc. I would be quite as happy
> having Time being a trigger source, or whatever name one could invent.
> 
I can see it better now: You like categorising use cases by actor. I can
also see that you would need to invent a placeholder actor for time-related
events.
This will not cause trouble as long as you an your team is agreed on the
fact that Time or Timers are not quite the kind of actor that you normally
expect. That is, if you all agree on what it means to you, there isn't musch
anyone else can say about it. We are talking textual descriptions whose main
purpose is to get a point across, not to get compiled, after all.

> What is a trigger and how do you model it in UML?
> 
A Trigger is an event that triggers the start of a use case.
I saw them first in a use case template by Alan Cockburn circa 94-95, I
think.
Some people like to put an event category in this field, e.g. Time,
Temperature Event, Money Withdrawal. Others prefer a detailed account, e.g.
"Daily at 10 o'clock", "When the temperature falls below 0 degrees C", "When
the account value falls below 0."
In some past projects, we chose to categorise use cases by trigger, rather
than actor, because it made more sense. This is most typical in real-time
systems.
One thing worth noting about triggers is that they may be internal or
external, hence, they don't necessarily need an actor. I find that this
neatly sidesteps the arguments over whether time is an actor or not.
Instead, I worry about whether there is a trigger for the use case -- which
is generally easier to spot.

> "Outside temperature goes above 10 degrees C" is an event in the real
> world.
> The system might be polling a temperature sensor in order to catch this
> event, or the sensor might be external to the system and send a message to
> the system, when the sensor catches the event. In both situations there is
> a
> source (time/sensor) to the event. The original phrase is probably precise
> enough to define the general behaviour of a system, but you might end up
> in
> discussions with your customer, say if the system would only poll the
> sensor
> once a day. The source to the "Outside temperature goes above 10 degrees
> C"
> event could be named Environment (I fear that this is a basis for an
> extension of the discussion :-)  ).
> 
I'm afraid it is, too. I will justify my initial comment very quickly by
saying, "That depends on where your system boundary is". If the sensors are
internal to your system, although the event is external, the detection is
internally done -- hence, no actor. My PC's motherboard bristles with
internal temperature sensors. All I care about is that the motherboard knows
the temperature; how it knows the temperature is immaterial in this case.


Now on the subject of polling vs. events.
Triggers are very useful in this case. Time based triggers indicate polling,
whereas an event trigger implies that we are always listening. In the latter
case, you can qualify "listening" during design as genuine event-triggered
behaviour or as pseudo-events where you poll every 10 seconds, say.
Categorising by Trigger helps a lot in this case. You can pull together a
bunch of temperature event based use cases and ask yourself how long you can
afford to wait before one of them activates: can your afford to overheat for
a minute or whould you expect the engine to shut off within two seconds of
the temperature hitting 100 degrees C? This came home to me last week when I
ran for a few miles with a punctured radiator last week (car's radiator,
that is. I don't have one.). Had the engine stopped instantly, I would not
have been looking for a reconditioned one now (it burnt itself out trying to
climb a hill with no water in the radiator). Then again, had it stopped
there and then, I would have had the opportunity to personally meet and
greet the ubiquitous moron with the BMW driving two meters behind me.
These are issues worth exploring. Having an easy way to categorise by
trigger gives you a good tool for flushing out some of these issues.


> I agree to your red herring, but what is the use of introspective use
> cases,
> if no one will notice them being there at all?
> 
I have managed to justify my argument at the time by mentioning that there
was no "immediate outside visibility". That may be the case for a system
that commits financial transactions daily at midnight. In the database, some
tables get updated, but you don;t get notification of anything. It's only
when you use the system afterwards (i.e. as a result of another use case)
that you see a change (in my case, it normally goes like this: one day I
have money in the bank; the next day, I'm overdrawn. Where did it all go?
When the overdraft gets too serious, the bank manager phones me. I suspect
he gets a daily listing of people who exceed their limit by a large margin
-- there: another use case.).

> Lars.
> 
> 
Regards,
Huseyin


> -----Original Message-----
> From: Angay, Huseyin (Huseyin)** CTR ** [mailto:[EMAIL PROTECTED]]
> Sent: 27. marts 2001 11:29
> To: '[EMAIL PROTECTED]'
> Subject: Re: (ROSE) Use cases: When its not clear who gets the value
> 
> 
> 
> The earlier suggestion from Eric of simply specifying that a use case
> happens regularly every day at 10:00, say, is generally sufficient. You
> could make this the first line of the use case, or, as I normally
> recommend,
> put it in the Trigger field.
> 
> Introducing Time as an actor is a kneejerk reaction based on earlier rules
> of thumb taught to budding use case writers: "All use cases have actors."
> This is fine for most use cases that you write. Unfortunately, what is
> good
> enough when taught in three day courses is not good enough for the rest of
> your career. The actual rule should be phrased, "Be extremely suspicious
> of
> use cases without actors." That doesn't mean that you should dismiss them
> or
> invent actors for the sake of making your use case compliant. It means
> that
> a use case without an actor should prompt you to look again. If the use
> case
> is acceptable otherwise, forget the actor.
> (By the way, triggers do not have to have actors. They may just happen.
> "Outside temperature goes above 10 degrees C" or "10:00 o'clock daily" are
> good triggers; and for systems that do not rely on outside temperature
> sensors or clocks, no actors are needed to do the prompting.)
> 
> 
> Another red herring worth binning:
> Actors do not need to get any benefit from a use case.
> BUT, a use case must have Stakeholders who get a benefit from the correct
> execution of the use case. 
> Quite often, the stakeholders may not even appear in the list of actors of
> a
> system. This does not make them any less involved. They are just not
> ~directly~ involved.
> 
> 
> In summary, if you can find a stakeholder for your use case, you can
> dispense with actors if the system can internally trigger the execution of
> the use case. Some use cases are even purely introspective, in that there
> may be no immediate outside visibility of their execution.
> 
> 
> 
> 
> Regards,
> Huseyin Angay
> 
> Karabash Ltd.
> www.karabash.co.uk
> 
> 
> 
> > ----------
> > From:       Eric D. Tarkington[SMTP:[EMAIL PROTECTED]]
> > Reply To:   Eric D. Tarkington
> > Sent:       27 March 2001 7:31
> > To:         Rose Forum (E-mail)
> > Subject:    Re: (ROSE) Use cases: When its not clear who gets the value
> > 
> > 
> > Lars and others,
> > 
> > When it's a requirement that a system acts "independently" on the basis
> > of time, it is unnecessary, but probably harmless, to use Time as an
> > actor.  What you're doing in that case is putting an aspect of the
> > platform outside the system boundary, which is within the scope of your
> > authority as analyst (thank-you, Les Munday).
> > 
> > I don't think modelling Time as an actor does much good in ordinary
> > cases, but it's cool (which may be enough motivation to do it).
> > 
> > As to communicating with customers, there may be less here than meets
> > the eye.  Because of constraints on your time and effort, there are
> > numerous cases in which you just have to tell a customer "at this point,
> > a miracle happens", or give a Startrek engineer's explanation that
> > passifies 'em.  I'm not knocking this approach very much -- it may be a
> > practical and effective substitute for knowledge when the user doesn't
> > need to know the real details.
> > 
> > As to communicating with designers, for some of them you can just use
> > "communicating with customers", above.  For the grumpy designers that
> > want more, or actually get to implement the timely behaviour, you should
> > avoid letting them force such implementation details into high-level
> > models of the system.  Unless it's really cool, of course.
> > 
> > This is all a matter of opinion, for now.  When use case diagrams or
> > similar models can be used to generate executable systems automatically,
> > issues like this will meet a definitive test.  Until then, you can
> > Rational-ize doing what you please.
> > 
> > Finally, in answer to Lars' PS, a riddle (probably quoted more or less
> > correctly) from J. R. R. Tolkein's THE HOBBIT:
> > 
> > "This thing all things devours;
> > Birds, beasts, trees, flowers;
> > Gnaws iron, bites steel;
> > Grinds hard stones to meal;
> > Slays kings, ruins town,
> > And beats high mountains down."
> > 
> > -Eric :?)
> > 
> > Lars Hauschultz wrote:
> > > 
> > > Hi Eric and others,
> > > 
> > > I agree that you don't have to model everything. But what if it is an
> > > important feature of the System that it from time to time does
> something
> > on
> > > its own? How do you communicate this feature to the customer and the
> > > designers, if you do not include it in your model? If you include it
> and
> > you
> > > then have to write a number of use cases, which start with "This use
> > case is
> > > initiated automatically every ...", wouldn't it be convenient to have
> > Time
> > > as an Actor to hold all the strings to these use cases in its hand,
> even
> > if
> > > Time does not get a value from doing so?
> > > 
> > > Lars Hauschultz
> > > 
> > > P.S.: How do you actually know that Time does not get a value from
> this?
> > Who
> > > knows Time that well?  ;-)
> > > 
> > > -----Original Message-----
> > > From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
> > > Sent: 22. marts 2001 19:33
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: (ROSE) Use cases: When its not clear who gets the value
> > > 
> > > We had another thread on similar issues a couple of weeks ago, and
> > > nobody suggested the simplest solution:  don't model time or trigger
> as
> > > an actor.
> > > 
> > > You don't have to model everything.
> > > 
> > > In this example, there will be a use case that wakes up "mysteriously"
> > > at the right time, whenever that may be.  Use of a call to the
> operating
> > > system is an implementation detail that we don't need to model in a
> use
> > > case diagram -- it's a "how", and we're at the "what" level.
> > > 
> > > In documenting the timely use case, you can start the behaviour with
> > > "This use case starts when the timer times out."  A few more
> adjectives
> > > wouldn't hurt.  Maybe the timer issues a more informative command.
> > > 
> > > On the other hand, peoply find it nifty to make Time an actor, and I
> > > don't see the harm.  The system can talk to Time (by some protocol
> > > hidden in the implementation) to say "Wake me up at 8:00am," and Time
> > > can talk to the system at the appropriate moment.
> > > 
> > > Obviously, Time gets no value from the use case, other than
> fulfillment
> > > of it's mysterious compulsion to say "beep" after some
> > > externally-supplied interval.  This is sorta like a dog fetching a
> > > stick:  you are the system, you selected and threw the stick in
> > > anticipation of the dog's reaction, and the dog looks an awful lot
> like
> > > an actor when he brings it back.
> > > 
> > > Don't worry, be happy.
> > > 
> > > -Eric
> > > 
> > > "Frank I. Reiter" wrote:
> > > >
> > > > Thanks to all those who have replied so far.
> > > >
> > > > A couple people have asked, in one way or another, "Who is it that
> > > ultimately gets value from this use case?"
> > > >
> > > > What the use case accomplishes is that the information is the
> system's
> > > database is more up to date after each execution than immediately
> > before.
> > > Who cares about that?  Several actors who get that value through other
> > use
> > > cases in which they interact with the information that this use case
> > > updates.
> > > >
> > > > They do not however participate in this interaction between my
> system
> > and
> > > an external system, and may not in fact be aware that it even happens.
> > > >
> > > > Since they do not initiate, participate in, or know about this use
> > case, I
> > > have trouble thinking of them as actors.
> > > >
> > > > Frank.
> > >
> ************************************************************************
> > > * 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
> *
> *************************************************************************
> ************************************************************************
> * 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
*
*************************************************************************