> ----------
> From: Eric D. Tarkington[SMTP:[EMAIL PROTECTED]]
> Reply To: Eric D. Tarkington
> Sent: 27 February 2001 0:15
> Cc: [EMAIL PROTECTED]
> Subject: Re: (ROSE) "System" as Actor
>
>
> Les,
>
> Maybe I should have made this a bar bet, but I do those when I have a
> (secret) opinion firmly formed on the controversy.
>
> Does the system include the system boundary? If so, is the system
> within the system? If the system is not within the system, can it be
> said to be external to the system? If the system is external to the
> system, and communicating with itself, why can't it be an actor?
>
I don't think it is as clear cut as saying, "This is the system and this is
the outside world," all based on what you consider to be your hardware or
software. The important things about actors are (1) whether the system being
developed has control over their actions; (2) whether the actors are worth
modelling as actors (i.e. they exhibit some behaviour that's worth thinking
of as complex).
(1) affects the way you write your use cases, as it talks about the
unpretictability of the actors. Neither can you control them, so you must
ensure that your use cases cover every reasonable eventuality when talking
to actors.
(2) affects your budgets. The more actors you have, however insignificant,
the more you have to write and the more you have to discuss and maintain. So
they better be worth modelling.
Once you answer these, depending on their worth to your project, you will
have a better idea who or what is an actor to ~your system~ and what isn't.
> Probably, most people would say that the system *is* within the system
> boundary, so it can't be an actor.
>
Yep.
> Is it true that I can't treat anything within the system as an actor?
> If I can treat an "untouchable" legacy subsystem as an actor, why not
> the system?
>
Refer to (2). What does treating parts of the system as an actor give you?
Is it worth modelling the printer as an actor? If you are writing software
that drives the printers, definitely yes. If you are writing Windows
software that takes care of all the printing, maybe, but only if a print
job's failure affects your software's behaviour. Microsoft Word has trouble
on a machine that does not have a default printer installed -- it wants to
display things as they will print. On the other hand, Excel will have that
problem only with the Print Preview function; everything else works fine.
> Using "Time" instead of "System Clock" as an actor is an interesting
> idea -- sort of an Ingmar Bergman thing. The "grim reaper" has already
> been used for death, but "father time" is very similar -- do you think
> it would be suitable as an icon?
>
Time as an actor comes under both (1) and (2). Both timers and the actual
time start to become important in the design of real-time systems. Yet, I
have found stating that a use case activates/starts every ten minutes or
daily at midnight is enough. Or you could mention that an alternative flow
takes place if some actor (or some included use case) does not finish its
task in 30 microseconds.
As soon as you have time as an actor, you have to start thinking about the
messages we send to Time and the messages that we receive from it. Are the
contents of these messages important? Or are we interested in just receiving
timely reminders?
Almost every use of time and timer actors I have seen in use cases has been
an attempt to make something fairly innocuous (like clock ticks and timer
counts) clever. I know we are not supposed to assume things in our designs,
and nothing is obvious. But there are some very fundamental things about
time that we cannot help but assume (and correctly, too).
The exception, by the way, was in a past system where there had to be some
very complicated watchdogging handled by some obscure old board. You had to
keep prodding this thing with various messages and it barked every now and
then, when it decided that you hadn't kicked it often enough or hard enough
-- I'm not inventing this vocabulary, by the way; that's how they talked
about this board.
(Interestingly enough, a past colleague recently told me that the board had
outlived its useful life and had to be replaced eventually, along with the
rest of the system. Guess what, when they looked at what the board did, it
was nothing more than counting the microseconds. There were no complicated
rules, no diffcult decisions and certainly no deep logic. That complexity
had been the intention at first, when the system was initially designed, and
the board could have done it had the software been written for the logic.
However the software that it ran, once they looked at it, was still in its
early revisions, where it did simple counting. They had never needed the
more complex behaviour, so never bothered updating the software. But because
the board was there, its existence was proof enough of its complexity. In
fact, the unpredictability was due to nothing more than vagaries of board
and bus timings, which was all within the safe limits of the system,
although it was seen by the testers as "complex" behaviour.)
> In the end, best practices can include some arbitrary standards, and I
> can accept that.
>
Perhaps arbitrary to an outsider, but I would hope that the people who wrote
the use cases had some good reasons for their choices.
But in the sense that there are no hard and fast rules to these things, yes,
I agree.
> -Eric
>
>
Regards,
Huseyin Angay
Karabash Ltd.
www.karabash.co.uk
> [EMAIL PROTECTED] wrote:
> >
> > Eric,
> >
> > I think the problem could be caused by 'your students' not having a firm
> > idea as the scope of the system.
> >
> > You might try drawing a context diagram where everyone contributes and
> > agrees to the exact boundary to your system.
> >
> > As for system clock, as an actor, the actor is 'Time' and produces an
> input
> > to your system clock.
> >
> > The printing issue comes about as a result of not having system scope
> > defined. I.e. Is the Printer inside or outside your system? You decide.
> If
> > it's outside, the printer can be an actor, if it's inside then the actor
> > is/maybe the printed output or the person the output is for, depends
> very
> > much on why you're sending it to the printer.
> >
> > Hope this helps,
> >
> > Les.
> >
> > When drawing their first use case diagrams, my students (including some
> > of my best) sometimes identify the system under development as an actor.
> >
> > I've been telling them not to do this, since my favorite sources don't
> > do it, but lately it has been bothering me.
> >
> > When the system is doing something like scheduling activities for
> > regular or delayed execution, I have seen authorities use a "system
> > clock" actor. Also, in some environments it is quite right to say that
> > the system provides services such as printing. If the system looks like
> > an actor, walks like an actor, and quacks like an actor, what is it?
> >
> > -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
*
*************************************************************************
