I am not sure if this is a common knowledge (did not watch this user group
for a long while) but this is IMO very important modeling problem. It takes
me to a use cases which are usually implemented as "batches" or "jobs" or
whatever you'll call it - there is not too much interaction with the system
boundary (aka actors) but you have to implement it so this functionality
probably can be included in use case model. Usually I use stereotype
"batch" for these use cases, but it is not important at the moment.
The interesting thing about these functionalties is they can be triggered
usually by two "actors" (better said resources) - time (usually we use
actor called "Scheduler" or "Daemon" or something, not Time, time is
innocent :)) and some sort of administrator.
If you model it this way, what you get is just a bunch of "webs" - some use
cases, all of them connected to Scheduler and to Administrator actors (hey,
it is really simplified :) - consider several possible Administrators and
only one Scheduler)... Later we have discovered it is more "pragmatic" to
use some sort of stereotype for use case (like "Batch") and at least all
the detail about scheduling (time intervals etc.) leave to a textual
description. Sometimes it is even fine not to overload the Administrator
actor with all the batch associations (in case there is really only one
Administrator actor).
What is your opinion on this?
(For me Time as an Actor is really confusing, what I know it is not by time
but by some software which checkes time and calls the appropriate
functionality... but may be this is not the case)
Regards
Jiri Svacina
UNICORN
http://www.unicorn.cz
-----Puvodni zprava-----
Od: Lars Hauschultz [SMTP:[EMAIL PROTECTED]]
Odeslano: 26. boezna 2001 16:31
Komu: Rose Forum (E-mail)
Poedmit: RE: (ROSE) Use cases: When its not clear who gets the value
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
*
*************************************************************************
