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 * *************************************************************************
