Identifying valid actors for use cases

[m***@lycos.com]

Hi,

We have this "know all" guy at work who obviously thinks he knows all
there is to know and everyone else is scum. I have some questions
about some actors that he has identified for some use cases on our new
project. If I remember correctly, actors should be either the
stimulants or the beneficiaries of a use case. Am I right? Can we
have an actor for a use case that is neither a stimulant nor a
beneficiary?

Thanks for your consideration!
MI

[s***@gmail.com]

Post by m***@lycos.com
Hi,
We have this "know all" guy at work who obviously thinks he knows all
there is to know and everyone else is scum.  I have some questions
about some actors that he has identified for some use cases on our new
project.  If I remember correctly, actors should be either the
stimulants or the beneficiaries of a use case.  Am I right?  Can we
have an actor for a use case that is neither a stimulant nor a
beneficiary?
Thanks for your consideration!
MI

You can have whatever you want that allows you to understand the
problem and develop a solution. Don't get too into the definition of
an actor. remember the point of the use cases is to help you
understand what the system is supposed to do, as long as they do that
do it however you want. It is not an exam on use cases it is a project
that should end in a correct system. Just make sure everyone is doing
it the same for the project.

[Peter Morris]

I've not seen an actor that isn't either providing information or consuming
it, nor can I currently think of an example of an actor that wouldn't do one
of these.

Maybe if you put forward the questionable case of this person you'd get a
more precise answer, generic questions/answers aren't always of any use.

[H. S. Lahman]

Responding to masood.iqbal...

Post by m***@lycos.com
We have this "know all" guy at work who obviously thinks he knows all
there is to know and everyone else is scum. I have some questions
about some actors that he has identified for some use cases on our new
project. If I remember correctly, actors should be either the
stimulants or the beneficiaries of a use case. Am I right? Can we
have an actor for a use case that is neither a stimulant nor a
beneficiary?

Define 'stimulant' and 'beneficiary'. B-)

Generally something qualifies as an Actor if: (A) it has behavior; (B)
that behavior interacts with the software under development; and (C) it
is external to the software under development.

The notion of 'interact' is pretty loose; it usually just means that the
Actor does something that somehow affects the software. Thus in a
control system when the hardware sets an interrupt bit the software will
<eventually> respond but the bit is still in the hardware so there is no
direct interaction.

Note that when the hardware sets the interrupt bit it is not directly
stimulating the software; the hardware doesn't even know the software is
there. The software responds if and when it polls the interrupt. So I am
not all that keen on the notion of 'stimulant'.

Also, consider a self-destruct mechanism that is triggered by software.
It is kind of hard to rationalize that being destroyed is some kind of
benefit doled out by the software. B-)

[m***@lycos.com]

Post by H. S. Lahman
Define 'stimulant' and 'beneficiary'. B-)

Without sounding flippant, a "stimulant" is the actor who provides the
stimulus for the use case and gets everything going. The
"beneficiary" is the actor who benefits from the use case.

I have been told that generally Step 1 of a use case talks about the
trigger from the "stimulant" actor (or from the "Time" actor, if the
use case is triggered by a timer or a periodic schedule etc.) and the
last step talks about how the "beneficiary" actor (not necessarily the
same as the "stimulant" actor) benefits from the use case.

Is it correct to say that good use case analysis only talks about
actors only from the perspective of the triggers they provide and the
benefits they receive and refraining completely from describing their
behavior?


Masood

[H. S. Lahman]

Responding to masood.iqbal...

Post by m***@lycos.com

Post by H. S. Lahman
Define 'stimulant' and 'beneficiary'. B-)

Without sounding flippant, a "stimulant" is the actor who provides the
stimulus for the use case and gets everything going. The
"beneficiary" is the actor who benefits from the use case.
I have been told that generally Step 1 of a use case talks about the
trigger from the "stimulant" actor (or from the "Time" actor, if the
use case is triggered by a timer or a periodic schedule etc.) and the
last step talks about how the "beneficiary" actor (not necessarily the
same as the "stimulant" actor) benefits from the use case.
Is it correct to say that good use case analysis only talks about
actors only from the perspective of the triggers they provide and the
benefits they receive and refraining completely from describing their
behavior?

I'm just not very comfortable with 'stimulant' and 'beneficiary' as a
classification system for use cases. I don't think one needs more
differentiation that an actor being some entity that interacts with the
software.

Consider a use case where the user requests a particular report. When
the report is generated who is the beneficiary? Do we make the report
itself an actor because it is the beneficiary of the software
processing? Unlikely. So is it the user? What if the user requested it
for someone else? What about the ultimate reader of the report being the
beneficiary? Does the software care who that reader is (i.e., will that
reader affect in any way what the software does)? Do we care who the
reader is enough to raise the reader to the stature of an actor (i.e.,
will doing so enhance out understanding of the requirements for the
software)?

I don't think so. In this example there there is probably some
beneficiary from the software doing its thing somewhere. But I just
don't think it is worth worrying about in those terms.

Consider a hardware control system. The hardware is clearly an actor. In
my OP I cited the notion of setting an interrupt bit by the hardware as
being a indirect interaction. But it seems to me it would be a real
stretch to think of that interaction as a stimulus. Typically the
software will detect the set bit in a polling loop of some sort. IOW,
the software detects the state of the hardware on it own. The
interaction is there but the hardware is essentially passive in that
interaction. [Note that this applies to 'trigger' as well, which is
another mapping I am not too crazy about. B-)]

When it is easy to come up with examples where mental gymnastics are
required to rationalize a classification, I think one has to re-evaluate
the utility of the classification. Just using 'interaction' is broad
enough not avoid such problems.

[gargoyle47]

Post by m***@lycos.com
We have this "know all" guy at work who obviously thinks he knows all
there is to know and everyone else is scum.  

His name isn't Roger Sleet, is it?

[m***@lycos.com]

Post by gargoyle47

Post by m***@lycos.com
We have this "know all" guy at work who obviously thinks he knows all
there is to know and everyone else is scum.  

His name isn't Roger Sleet, is it?

No, his name isn't Roger Sleet, but I think I can already picture how
Roger Sleet operates