Just to quote directly from the OMGs UML definition version 1.4 (the one currently agreed).

both semantics and notation.

3.57.1 Semantics
There are several standard relationships among use cases or between actors and use
cases.
 Association - The participation of an actor in a use case; that is, instances of the
actor and instances of the use case communicate with each other. This is the only
relationship between actors and use cases.

3.57.2 Notation
An association between an actor and a use case is shown as a solid line between the
actor and the use case. It may have end adornments such as multiplicity.


I think it is quite clear from this that the association is he ability for the actor and use case to communicate not what the communication is, nor its flow.

I look forward to much more discussion on this point!
Thanks
Steve


-----Original Message-----
From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
Sent: 09 October 2001 20:24
To: ROSE_FORUM
Subject: Re: (ROSE) Use case to actor Yes or No



I love it when "simple" questions turn into long, contradictory
discussions.

The issue is:  Can a use case "point to" an actor in a use case
diagram?  Further discussion shows that the intent of the question is
more like:  Can information flow to an actor from a use case?

The best short answer is:  The use case diagram doesn't say that kind of
thing.

The sequence diagram *does* say whether objects in the use case
realization pass messages to an actor.  In this context, the situation
is clearer.  Passing a message to an object implies that the object has
an operation that is a part of the sequence.  Passing a message to an
actor also implies that the actor has an operation that is part of the
sequence.  You can say this about a human actor if you want to, but how
will anybody realize it?  If you are doing system modelling, I advise
against passing messages to human actors.  It would be acceptable in
business modelling, but that wasn't the intent of the original question.

Going back to the use case diagram:  The association between an actor
and a use case does imply <<communicates>> (if I remember correctly),
but it does not indicate a direction.  Of course, you can nudge the
association into saying something more, by using your own stereotypes,
etc., but I don't see the benefit.  Straight vanilla UML intentionally
avoids showing flow of data or control in use case diagrams.

-Eric

[EMAIL PROTECTED] wrote:
>
> You seem to have lost the plot too.  Actors can be classed as primary or
> secondary actors to a given use-case.
>
> Primary actors initiate the use case.
>
> Secondary actors are "used" in some way by the use case in order for it to
> complete its basic or alternate path.  Secondary actors are normally other
> systems or components within a system, although sometimes (I can't think
> when) they could be humans.
>
> The diagram does not show the flow of information as you say, but show the
> interactions/involvement between use cases and actors.
>
> Haydn
>
>
>                     "Baynes, Steve"
>                     <stephen.baynes@eds        To:
[EMAIL PROTECTED]
>                     .com>                      cc:
>                     Sent by:                   Subject:     RE: (ROSE) Use
case to actor Yes or
>                     owner-rose_forum@ra        No
>                     tional.com
>
>
>                     09/10/2001 14:48
>                     Please respond to
>                     "Baynes, Steve"
>
>
>
> This discussion is quite interesting but many people seem to be missing
the
> point.  The use case diagram shows involvement.  All actors are involved
in
> the use case and therefore point to the use case.  The diagram is not
> showing the flow of information.  This is modelled using other artefacts
> (activity diagram, collaboration diagram etc).
>
> Actors are involved in use cases, use cases are not involved in actors,
any
> actors.
>
> Hope this helps.
> Steve
>
> -----Original Message-----
> From: Kelly, Stephen [mailto:[EMAIL PROTECTED]]
> Sent: 09 October 2001 14:04
> To: [EMAIL PROTECTED]
> Subject: RE: (ROSE) Use case to actor Yes or No
>
> In this example you will clearly end up with an artificial representation
> of
> what you really want to say.
>
> A real person such as a customer service clerk cannot have something done
> to
> them by the system. In real life, what would happen is the system would
> generate an email (action by the system), and at some arbitray
> (undefinable)
> point the customer service clerk would read emails (action by the person
> actor). The fact that the system generates an email doesn't guarantee that
> the email will be read (the whole customer service department might
quit!).
> Also, setting up a username and password doesn't happen as a result of the
> email being generated. It happens as a result of the customer service
clerk
> doing something to the system.
> The fact that the customer service clerk might decide to do something as a
> result of reading the email is nothing to do with the system - i.e. the
> actions of a person actor cannot be predicted by a use case within a
> system.
>
> The situation would be far better documented as a 'request new user
> registration' use case, intiated by the broker, which interacts with the
> email system. And then a separate and independent use case like 'create
new
> user' initiated by a customer servive 'actor'.
>
> The other important thing to remember is that use cases don't really say
> anything about the 'flow of control'. They are supposed to represent the
> functions / actions of a system. So, don't make the mistake of thinking in
> terms of 'this use case happen, then the next use case happens, etc.'.
>
> Stephen.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: 09 October 2001 13:12
> > To: Kelly, Stephen; 'Jo�o Paulo Marto Pereira';
> > [EMAIL PROTECTED]
> > Subject: RE: (ROSE) Use case to actor Yes or No
> >
> >
> > Hi,
> >
> > Stephen mentioned that a use case should never point to a
> > person actor.
> > From my point of view, this is not true. The actor who
> > initiates the use
> > case points to the use case. The use case points to actors
> > (persons or systems)
> > who participate in that use case later on.
> >
> > Example: A broker registers himself online in a financial
> > trading system.
> > Customer Service reveives an email to check the registration
> > and provide
> > username and password for the broker.
> > Here the broker initiates the use case wheras customer
> > service enters the
> > game due to the initial request of the broker.
> >
> > I hope that helps.
> >
> > Regards
> > J�rg
> >
> > ___________________________________________________________
> > Joerg Dirbach  mailto:[EMAIL PROTECTED]
> > Software Architect / Software Engineering Trainer
> > Object Technology Center
> > Zuehlke Engineering AG  Wiesenstrasse 10a  CH-8952 Schlieren
> > Phone: +41 (0) 1 733 65 71   Fax: +41 (0) 1 733 69 02
> > http://www.zuehlke.com/
> >
> >
> > -- Original-Nachricht --
> >
> > >
> > >The example you gave is a clear case where it is a very bad
> > idea to relate
> > >a
> > >use case to an actor.
> > >
> > >It makes no sense at all that a 'system' should do something
> > to a 'person'.
> > >Even if you imagine the system flashing a message on that
> > 'person's' screen,
> > >the system is not really doing something to the person - it
> > is simply doing
> > >something to a system device.
> > >
> > >You should never have a causal relationship _from_ a use
> > case _to_ a person
> > >'actor'.
> > >
> > >On the other hand, many analysts treat external systems as
> > 'actor's. In
> > this
> > >case you might have a relationship from one of your use cases to the
> > >'actor'.
> > >
> > >For example, one of your requirements might be that your
> > system send data
> > >to
> > >an external accounting system for the company's book-keeping.
> > >In this case you could represent the accounting system as an
> > 'actor' and
> > >may
> > >have a use case like 'post accounting item' which is related
> > to this actor.
> > >
> > >When doing this it is a good idea to ensure that in your diagrams the
> > >stereotype display of 'actor's that are really external
> > systems is different
> > >to the stereotype display of people 'actor's - use the icon
> > (a stick man)
> > >for people and the label (a box with the <<actor>> label)
> > for external
> > >systems.
> > >
> > >Stephen.
> > >
> > >> -----Original Message-----
> > >> From: Jo�o Paulo Marto Pereira [mailto:[EMAIL PROTECTED]]
> > >> Sent: 09 October 2001 11:42
> > >> To: [EMAIL PROTECTED]
> > >> Subject: (ROSE) Use case to actor Yes or No
> > >>
> > >>
> > >>
> > >> Hi, again
> > >>
> > >> I've had answers saying I could point a use case to an actor,
> > >> an others that
> > >> said, no way! Is it possible and desireble or not?
> > >>
> > >> Thanks
************************************************************************
* 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/support/usergroups/rose/rose_forum.jsp
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************

Reply via email to