Hi Everbody,
Since so much discussion about Actor and System
let me give some of my opinions.
I can not understand , how people consider
Printer as an actor.Then even one day developers
will start to feel monitor , keyboard all as actors.
They are just the means to display or render
output to the user(Actor) and to accept input from
the user(Actor), they themself are not actors.
One more thing considering the system under
development as Actor. Then even you will start
to feel the hardware used to develope a system
like Monitor , CPU and keyboard all as Actor.
There are very clear definitions of System , Actor and Use Case.
Just you have to read well and think twice , then sit for
the Use Case model. Then no such confusion in future.
Maheswari
"Angay, Huseyin (Huseyin)** CTR **" wrote:
> > ----------
> > 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
> *
> *************************************************************************
************************************************************************
* 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
*
*************************************************************************
