Hi Eric,
I agree that time is not really an actor, but: "This thing makes other
things happen"!
A concrete example:
We are developing a system, which shall output specific messages on various
serial ports at fixed intervals. The contents of the messages depend on the
system state, so I would very much like to include this system behaviour in
the use case model. Would one prefer a use case narrative (without time as
an actor) like: "When a certain amount of time has passed since the last
initiation of this use case, this use case is (magically ;-) ) initiated
again."? Is the event causing this initiation really inside the system? If
we were talking implementation, I would agree to the latter.
In the automatic-system-generating future Rose will take the actor "Time",
create an interface class named "Time Handler" and have it send events to
other classes. The "Time" code generation add-in will insert the actual
timeout values based on some propertiy of the association between Time and
the use cases (future extension to UML). :-)
Lars.
-----Original Message-----
From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
Sent: 27. marts 2001 08:32
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
*
*************************************************************************
