I acknowledge all of the unofficial material that shows arrows going to or from an actor; you can include my favorite book, Visual Modeling with Rational Rose 2000 and UML. That still doesn't make it right.
Tarkington's principle states: "It is better that it be standard than that it be good." I would argue that the existence of a standard for the UML settles the question of whether or not an arrow ever goes at the end of an association between an actor and a use case. [If you are a practical person, and not a compulsive techno-geek, you will stop reading this message now.] Setting aside Tarkington's principle, putting directedness into the actor/use case association seems debatable both ways. Everybody seems pretty vague about what a use case is, but it seems to be something like a network of potential behaviors that may be performed. An actor may be associated with such a behavior network, and one network may be dependent on another. What does it tell us, exactly, if we say that the actor initiates a use case? We are saying that the behavior net is sitting idle until the actor sends a message. It is useful to say this kind of thing somewhere in our system model, but the UML spec is telling us that it is wrong to bind it in the use case diagram. Is this really so wrong, though? Look at the situation between use cases. Does the use of <<include>> and <<extend>> dependency relationships bind the issue of initiative in the use case diagram? Here's how I rationalize it: The performance of the includer use case is dependent on the performance of the included, so the arrow points to the included. The performance of the extender is dependent on the performance of the extended, so the arrow points to the extended. The includer needs the state produced by the included. The extender needs the context of the extended. What does it mean to say that one use case has the initiative relative to another use case in a dependency? It means that the insertion point for the behavior of the other use case is in the behavior of the initiator. (We can infer that the initiator use case will have an object in its realization that chooses the moment to send a message to an object in the realization of the second use case, causing the second use case to behave.) Does initiative always point in a way that is determined by the stereotype of the dependency? <<include>> behavior is always inserted into the performance at the initiative of the use case that does the including. <<extend>> behavior is always inserted into the performance at the initiative of the use case that becomes extended. I would describe this relation between use case dependency and initiative as hairy but consistent (see http://cs.senecac.on.ca/~etarking/initiative.jpg), which means that the dependency relation binds the initiative. If use case diagrams bind initiative in relationships between use cases, why not in associations between actors and use cases? Assuming that my analysis is right (a big assumption!), the UML has an inconsistency here that needs explaining. Despite the foregoing, this is a question for the Lords of Specification (does anybody know their address?), and not for the rest of us. Tarkington's principle still applies, and I will continue to teach my students to use only the association relationship between actors and use cases. We certainly get to model initiative in other standard places in the UML. Finally, if you are the kind of person who would put his tongue on both buttons of a 9-volt cell just to see what it tastes like, try thinking about the following. An actor is a network of behavior that is outside the system boundary. Can you have a dependency relationship between an actor and a use case? Can you have an association between use cases? In considering this, please bear in mind that I refuse to take responsibility for what you do with your tongue. -Eric "Brian G. Lyons" wrote: > > hiho, > > Heck, I was all ready to agree with Sushmita because I have been using a > convention of having the actor that initiates the use case have a directed > association to the use case in my use-case diagrams. But I am having > trouble finding reference to doing this in any 100% official UML source. > > The directed association is a commonly observed pattern in use-case > literature. Applying Use Cases: A Practical Guide by Geri Schneider and > Jason Winters uses directed arrows in each direction between actors and use > cases (see p127 & 177 of the first edition). Furthermore the Rational > University training material for Requirements Management with Use Cases, for > Principles of Object Technology, for Object-Oriented Analysis and Design > with UML, and for Rational Unified Process Fundamentals (phew) all show the > communicates associations pointing from actors to use cases. These courses > mostly only show a directed arrow from an actor to a use case, but here and > there you'll find arrows from use case to actor. You'll also find directed > arrows going each direction in various articles such as this one from > Software Development Magazine > http://www.sdmagazine.com/documents/s=748/sdm0001d/ and this from the > Rational Edge > http://www.therationaledge.com/content/dec_00/t_ucnotfunctions.html > > Rational's web-based RUP product specifies in its section entitled > "Guidelines: Communicates-Association": "Each role of a > communicate-association has a navigability property, indicating who > initiates communication in the interaction. Navigability is shown by an > open arrowhead. If the arrowhead points to a use case, the actor at the > other end of the association initiates the interaction with the system. If > the arrowhead points to an actor, the system initiates the interaction with > the actor. Two-way navigability is shown by a line with no arrow-heads." > (v2001A.04.00.13) > > But then when I look at the UML Reference Manual I see all bi-directional > associations and no mention of using an association that would point one way > or the other. And I can't find an example or reference to a directed > association in the UML Spec either. > > Oh well, I'll still keep using the convention of an arrow from the actor > initiating the use case (disregarding data flow). And I even use arrows > from use cases to secondary actors -- human or otherwise -- to show that the > use case initiates communcation with the actor (again disregarding actual > data flow). The use case diagram is there to communicate requirements and I > like to know who is calling whom. > > -------- b > > -- > Brian G. Lyons > Number Six Software - Voted Rational's Best Complementary Service Provider > 1655 North Fort Myer Drive, Suite 1100 > Arlington, VA 22209-3196 > http://www.numbersix.com > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Eric D. Tarkington > Sent: Wednesday, October 10, 2001 12:28 PM > To: Shukla, Susmita (CICG DTAG) > Cc: ROSE_FORUM > Subject: Re: (ROSE) Use case to actor Yes or No > > Susmita Shukla wrote: > > Question: Can a use case "point to" an actor in a use case diagram? > > > > Answer: Yes. This would be a secondary actor. The actor provides > > information needed to execute the use case. > > > > Hope this is simple enough. > > > > Susmita Shukla > > It's simple, but wrong, I think. The most important thing is that the > use case diagram cannot indicate the direction of data or control flow > between actors and use cases. > > If you want to discuss pointing, you probably need to use an interaction > diagram or an activity diagram. > > That's why I discussed the use of actors in the sequence diagram. In > that context, the question is: "Can an object point to an actor in a > sequence diagram?" There, you can say "yes", because the diagram is > capable of doing it. > > Once you are talking about the right diagram, you can introduce other > nuances without confusion. > > -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/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 > * > ************************************************************************* ************************************************************************ * 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 * *************************************************************************
