Issue 8893: UseCase and Actors (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: UseCase can be connected with Actors using Association, but neither UseCase nor Actor can't own Properties (there are no subsets), so Association is always non-navigable, properties are owned by Association. Resolution: Revised Text: Actions taken: June 20, 2005: received issue Discussion: End of Annotations:===== m: "Nerijus Jankevicius" To: , "Juergen Boldt" Subject: issues Date: Mon, 20 Jun 2005 18:13:07 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Hi All, Here are some problems (should be registered as issues), maybe someone may provide some workaround solutions? 1. UseCase and Actors To: "Nerijus Jankevicius" Cc: issues@omg.org, "Juergen Boldt" , uml2-rtf@omg.org Subject: Re: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 22 Jun 2005 03:55:57 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 06/22/2005 03:55:59, Serialize complete at 06/22/2005 03:55:59 Some comments on Nerijus issues: "Nerijus Jankevicius" wrote on 06/21/2005 04:35:44 AM: > 1. UseCase and Actors > UseCase can be connected with Actors using Association, but neither > UseCase nor Actor can't own Properties (there are no subsets), so > Association is always non-navigable, properties are owned by Association. Not sure what "there are no subsets" means, but both UseCase and Actor are kinds of Classifier and, therefore, can have Properties as attributes (this comes to Classifier via Namespace::ownedMember, which is a subset of Namespace::member). > 6. Syntax of Transition is described as: > " ::= [.,. ]* [.[. constraint>.].] [./. ] > The behavior expression may be an action sequence comprising a > number of distinct actions including actions that explicitly > generate events, such as sending signals or invoking operations." > Information from this expression (operation call for example) can't > be mapped and saved into model. This one doesn't look right either: the activity expression maps to some subclass of Behavior. The actions are part of that Behavior. > 7. Similar situation with reply messages in interactions. > ::= ([ .=.] > [.(. [ [.,.]* .).] [.:. ]) | .*. > Message can display return values and variable assignments, but > there is no way to store this information in the model, because > Message has no attributes for these properties. Message can own a set of ValueSpecifications for this purpose. Can you please clarify what you meant here, Nerijus? (I have not checked the other issues raised, so there may be answers to them as well.) Regards...Bran From: "Nerijus Jankevicius" To: "Branislav Selic" Cc: , "Juergen Boldt" , Subject: Re: some issues Date: Wed, 22 Jun 2005 12:02:15 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Bran, 1. You are not right. Classifier can't have Properties, because /attribute is derived union, calculated from real containers (/member and /ownedMember also). Every subclass of Classifier must have REAL container for Properties (ownedAttributes in Class for example). UseCase and Actor doesn't have containers for Properties, so they can't own Properties, so navigable Association can't be created. 6. Actions are part of Behavior, but Transition should know which one to display on signature, Transition should have references to elements that should be displayed on it, or you mean that Transition should list all actions from "effect" behavior? 7. What you mean "can own a set of ValueSpecifications"? Own as arguments of the message? But when a Message represents an Operation invocation, the arguments of the Message are the arguments of the CallOperationAction, number of arguments should be the same as number of Parameters. Even if "([ .=.]" is mapped into Message argument, it can't be recognized from arguments used for other purposes. We decide to create new reply message and map these attributes as arguments of reply message, but for this purpose Message model was extended to have reference to reply message. Other problems related with this issue are: - what is reply message? How it can be recognized from other messages? - how valueSpecification can represent some element like attribute or variable? For this purpose special kind of ValueSpecification should be introduced (ElementValue or similar) with reference to represented element. Waiting for answers to my previous email. All problems are blockers for us. Regards, -- Nerijus Jankevicius Senior Programmer & System Analyst No Magic Lithuanian Development Center ----- Original Message ----- From: Branislav Selic To: Nerijus Jankevicius Cc: issues@omg.org ; Juergen Boldt ; uml2-rtf@omg.org Sent: Wednesday, June 22, 2005 10:55 AM Subject: Re: some issues Some comments on Nerijus issues: "Nerijus Jankevicius" wrote on 06/21/2005 04:35:44 AM: > 1. UseCase and Actors > UseCase can be connected with Actors using Association, but neither > UseCase nor Actor can't own Properties (there are no subsets), so > Association is always non-navigable, properties are owned by Association. Not sure what "there are no subsets" means, but both UseCase and Actor are kinds of Classifier and, therefore, can have Properties as attributes (this comes to Classifier via Namespace::ownedMember, which is a subset of Namespace::member). > 6. Syntax of Transition is described as: > " ::= [.,. ]* [.[. constraint>.].] [./. ] > The behavior expression may be an action sequence comprising a > number of distinct actions including actions that explicitly > generate events, such as sending signals or invoking operations." > Information from this expression (operation call for example) can't > be mapped and saved into model. This one doesn't look right either: the activity expression maps to some subclass of Behavior. The actions are part of that Behavior. > 7. Similar situation with reply messages in interactions. > ::= ([ .=.] > [.(. [ [.,.]* .).] [.:. ]) | .*. > Message can display return values and variable assignments, but > there is no way to store this information in the model, because > Message has no attributes for these properties. Message can own a set of ValueSpecifications for this purpose. Can you please clarify what you meant here, Nerijus? (I have not checked the other issues raised, so there may be answers to them as well.) Regards...Bran Reply-To: From: "Conrad Bock" To: "Nerijus Jankevicius" , , "Juergen Boldt" , Subject: RE: some issues Date: Thu, 23 Jun 2005 20:15:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Nerijus, > 3. ObjectNode is abstract, so CentralBuffer or DataStore should > be always used in Activity diagram. It is normal? > CentralBuffer and DataStore are described as "special cases of > ObjectNodes", but simple ObjectNode can't exist. Pins are also object nodes, see Figure 178. But even apart from Activities, pins can hold values because they are typed elements, see Figure 143. Object nodes add queuing, etc. > 4. The same situation is with abstract Action in Activity > diagram. OpaqueAction also can't be used, because can't have Pins. This was recently filed, will add pins to OpaqueAction. > How to draw "human friendly" action (activity)? The only way is > to use CallBehaviorAction? OpaqueAction isn't actually that friendly, because it isn't reusable. > 5. OutputPin should hold output value, but there is no way to > store it. Should be introduced similar metaclass like ValuePin > for InputPin. Didn't understand this question. To: "Nerijus Jankevicius" Cc: "Juergen Boldt" , uml2-rtf@omg.org Subject: Re: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 24 Jun 2005 02:34:11 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 06/24/2005 02:34:16, Serialize complete at 06/24/2005 02:34:16 Nerijus, > 1. You are not right. Classifier can't have Properties, because > /attribute is derived union, calculated from real containers > (/member and /ownedMember also). Every subclass of Classifier must > have REAL container for Properties (ownedAttributes in Class for > example). UseCase and Actor doesn't have containers for Properties, > so they can't own Properties, so navigable Association can't be created. My apologies, Nerijus, you are absolutely right. I did not notice that ownedMember was also derived. Perhaps the resolution is to make both Actor and UseCase a kind of Class? What kind of Properties do you think these two should have? What is the use case to justify these. > 6. Actions are part of Behavior, but Transition should know which > one to display on signature, Transition should have references to > elements that should be displayed on it, or you mean that Transition > should list all actions from "effect" behavior? Actually, listing the actions on a transition "signature" is a notation that does not scale up and is, therefore, impractical. Also, the behavior attached to a signature can be any kind of behavior (including a state machine, activity, or interaction) -- and this is not something that can be displayed in a "signature". However, if you do want to display the behavior in a signature, then you should display all of it and not just some arbitrary subset. So, in that case, you should display all the actions. (NB: If you want, your tool can provide a filtering mechanism for this; e.g., to only display the "send" and "call" actions, which is what most people want to see in such cases.) > 7. What you mean "can own a set of ValueSpecifications"? Own as > arguments of the message? Precisely. > But when a Message represents an Operation invocation, the arguments > of the Message are the arguments of the CallOperationAction, number > of arguments should be the same as number of Parameters. > Even if "([ .=.]" is mapped into Message argument, it > can't be recognized from arguments used for other purposes. I don't understand what you mean by "arguments for other purposes". A message carries the arguments for its parameters and nothing else. > We decide to create new reply message and map these attributes as > arguments of reply message, but for this purpose Message model was > extended to have reference to reply message. I don't understand what you mean above. The reply message should carry the return value (if any). Why do you want to copy the input arguments here? Is your real issue that you cannot distinguish a reply message from an invocation message? > Other problems related with this issue are: > - what is reply message? How it can be recognized from other messages? Oystein should answer this one, but I believe that this is done through the fact that it is tied to the event occurrence that designates the end of the execution occurrence specification corresponding to the invoked operation. > - how valueSpecification can represent some element like attribute > or variable? For this purpose special kind of ValueSpecification > should be introduced (ElementValue or similar) with > reference to represented element. Again, Oystein should answer this, but the value specification here is just the value, not the variable or attribute. Are you saying you would like to include a reference to a variable or an attribute instead of a value? > Waiting for answers to my previous email. All problems are blockers for us. I am really sorry to hear this. Please note that the answers may not necessarily come as quickly as one might hope, since some of the things you are asking for may be contentious. I am quite willing to treat these as priority issues to be handled in this RTF cycle (the formal issues submission deadline for 2.1 passed over a month ago) but, formally, the resolutions are not binding until the RTF report is approved by the OMG. Of course, if we can all agree on the solutions ahead of that, chances are that you will be able to include these solutions in your tools sooner than that without worrying that they may get changed later. For such emergency situations, I suggest that you propose solutions along with your fixes -- after all, I believe that you folks are RTF members. This constructive approach should help focus the discussion and shorten the process. Regards,...Bran Subject: RE: some issues Date: Mon, 27 Jun 2005 15:52:12 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some issues thread-index: AcV4h3OexYfSbBXFSXCZMVLLAbfE+AClX5gg From: "Tim Weilkiens" To: "Branislav Selic" , "Nerijus Jankevicius" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5RE2ihh009636 Nerijus, Bran, > > 1. You are not right. Classifier can't have Properties, because > > /attribute is derived union, calculated from real containers > > (/member and /ownedMember also). Every subclass of Classifier must > > have REAL container for Properties (ownedAttributes in Class for > > example). UseCase and Actor doesn't have containers for Properties, > > so they can't own Properties, so navigable Association > can't be created. > > My apologies, Nerijus, you are absolutely right. I did not > notice that ownedMember was also derived. Perhaps the > resolution is to make both Actor and UseCase a kind of Class? > What kind of Properties do you think these two should have? > What is the use case to justify these. I would prefer to introduce a specialized association like the communication path in the deployment package or a complete new relationship. The relationship between an actor and an use case isn't a structural thing. It looks strange to me that an actor owns a property typed by an use case. User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 27 Jun 2005 11:43:10 -0400 Subject: Re: some issues From: James Odell To: In the W3C "Service-Oriented Architecture", one or more instances of Actor can request a Service (Use Case) one or more times. Furthermore, a Service (Use Case) can be provided by 1 or more Actors. So, instances of Actor and Instances of Use Case invocations have associations which are not just communication related -- even "structural." IMO, then, limiting associations will also limit the expressiveness needed in representing SOA. -Jim On 6/27/05 9:52 AM, "Tim Weilkiens" indited: > Nerijus, Bran, > >>> 1. You are not right. Classifier can't have Properties, because >>> /attribute is derived union, calculated from real containers >>> (/member and /ownedMember also). Every subclass of Classifier must >>> have REAL container for Properties (ownedAttributes in Class for >>> example). UseCase and Actor doesn't have containers for Properties, >>> so they can't own Properties, so navigable Association >> can't be created. >> >> My apologies, Nerijus, you are absolutely right. I did not >> notice that ownedMember was also derived. Perhaps the >> resolution is to make both Actor and UseCase a kind of Class? >> What kind of Properties do you think these two should have? >> What is the use case to justify these. > > I would prefer to introduce a specialized association like the > communication path > in the deployment package or a complete new relationship. > > The relationship between an actor and an use case isn't a structural > thing. It looks > strange to me that an actor owns a property typed by an use case. > > Tim From: "Nerijus Jankevicius" To: "Oystein Haugen" Cc: Subject: Re: some issues Date: Mon, 27 Jun 2005 19:02:51 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Oystein, Two months ago I sent you several emails about Interaction issues, but got no answers. Please see questions below my comment about message arguments and return values. >The Operation is referenced indirectly and you may match arguments and find their names. > I cannot see that arguments of Messages are different from arguments of (say) methods regarding value specifications? First of all, arguments are values that have no references to represented parameters, so they can be matched and synchronized with Operation parameters only by order, not by names. Call message signature example: memberNumber = registerMember("John", 15) : 66 where operation signature is registerMember(name : String, age : int ) : int "John", 15 and 66 can be mapped to arguments of the message (66 in place of return parameter ) The problem is with "memberNumber" mapping. It can't be mapped to message argument, because argument should be in pair with parameter. "memberNumber" is variable from some NameSpace or Property of some class, not value. I suggest to add special references to these variables (or one variable? It's not clear how many assignments can be on message). Questions from previous emails: 1. Events in Sequence diagram MessageEnd are MessageOccurrenceSpecification that redefines "event" as MessageEvent. DestructionEvent and CreationEvent are not subclasses of MessageEvent, so can't be on message end, so how to map "create message" and "destroy message"? 2. Arguments of Message > Variables, members and other "value holders" can be used as > arguments of call actions or arguments of message (for example > setName(name) where "name" is variable defined in Interaction), but > now arguments are simple ValueSpecification, so can't have > reference to "real" argument (variable, member, parameter of behavior etc.) > Maybe Argument should be in metamodel as in UML 1.4, or at least > ValueSpecification should be subclassed in Interactions package and > introduce reference to Element that value it represents? 3. Variables What namespace should be owner of variables used in sequence diagram? If variables are added into Interaction, they conflict, because every execution (method for example, or even loop or any combined fragment) can introduce variables with some names, that should be not accessible outside. Maybe ExecutionSpecification or InteractionFragment should be NameSpaces and declare collection for storing variables? Regards, -- Nerijus Jankevicius Senior Programmer & System Analyst OMG-Certified UML Professional No Magic Lithuanian Development Center Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com ----- Original Message ----- From: Oystein Haugen To: Nerijus Jankevicius Cc: Branislav Selic ; Juergen Boldt ; uml2-rtf@omg.org Sent: Thursday, June 23, 2005 10:28 PM Subject: Re: some issues Nerijus As responsible for Interactions in the UML RTF, I comment on your item #7. It is true that there is an issue with reply messages and distinguishing them from other (kinds of) messages and matching them with the proper message of the call. This is known, but not quite fixed. On the other hand I cannot understand why Message arguments are not covered by the owned set of ValueSpecifications. The Operation is referenced indirectly and you may match arguments and find their names. I cannot see that arguments of Messages are different from arguments of (say) methods regarding value specifications? Forgive me if I have not quite understood your concerns. Regards, Oystein -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh Nerijus Jankevicius wrote: Bran, 7. What you mean "can own a set of ValueSpecifications"? Own as arguments of the message? But when a Message represents an Operation invocation, the arguments of the Message are the arguments of the CallOperationAction, number of arguments should be the same as number of Parameters. Even if "([ .=.]" is mapped into Message argument, it can't be recognized from arguments used for other purposes. We decide to create new reply message and map these attributes as arguments of reply message, but for this purpose Message model was extended to have reference to reply message. Other problems related with this issue are: - what is reply message? How it can be recognized from other messages? - how valueSpecification can represent some element like attribute or variable? For this purpose special kind of ValueSpecification should be introduced (ElementValue or similar) with reference to represented element. Waiting for answers to my previous email. All problems are blockers for us. Regards, -- Nerijus Jankevicius Senior Programmer & System Analyst No Magic Lithuanian Development Center ----- Original Message ----- From: Branislav Selic To: Nerijus Jankevicius Cc: issues@omg.org ; Juergen Boldt ; uml2-rtf@omg.org Sent: Wednesday, June 22, 2005 10:55 AM Subject: Re: some issues Some comments on Nerijus issues: "Nerijus Jankevicius" wrote on 06/21/2005 04:35:44 AM: > 7. Similar situation with reply messages in interactions. > ::= ([ .=.] > [.(. [ [.,.]* .).] [.:. ]) | .*. > Message can display return values and variable assignments, but > there is no way to store this information in the model, because > Message has no attributes for these properties. Message can own a set of ValueSpecifications for this purpose. Can you please clarify what you meant here, Nerijus? (I have not checked the other issues raised, so there may be answers to them as well.) Regards...Bran Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 27 Jun 2005 10:17:05 -0700 To: UML-RTF From: Joaquin Miller Subject: actors and use cases Was: some issues I would prefer to introduce a specialized association like the communication path in the deployment package or a complete new relationship. The relationship between an actor and an use case isn't a structural thing. It looks strange to me that an actor owns a property typed by an use case. Extremely strange. If we consider the UML specification to be about a data structure for modeling tools, then that there may well be some good reason for an actor to have a property that is a use case. But if we consider that one important intent of the UML specification is to provide a conceptual model of modeling, then certainly: a use case has one or more actors ('has' meaning those actors participate in that use case) a use case does not own those actors (the same actor can participate in several use cases) an actor may participate in one or more use cases (or may be an actor of a class or component) an actor does not own use cases (else: which actor owns a use case with more than one actor?) ('own' meaning is on the diamond end of a black diamond line) [I'm prepared for contradiction. I'm confident we don't have a shared understanding here.] Cordially, Joaquin [p.s. A couple of questions i asked, way back when, about what has since become figure 401 of ptc/04-10-02: Can an actor own use cases? Where do we find the traditional relationship of actors to use cases?] www.joaquin.net From: "Nerijus Jankevicius" To: "Branislav Selic" Cc: "Juergen Boldt" , Subject: Re: some issues Date: Mon, 27 Jun 2005 20:36:01 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Bran, Thanks for your comments. >I don't understand what you mean by "arguments for other purposes". A message carries >the arguments for its parameters and nothing else. I describe this problem in my email to Oystein. Call message signature example: memberNumber = registerMember("John", 15) : 66 where operation signature is registerMember(name : String, age : int ) : int "John", 15 and 66 can be mapped to arguments of the message (66 in place of return parameter ) The problem is with "memberNumber" mapping. It can't be mapped to message argument, because argument should be in pair with parameter. "memberNumber" is variable from some NameSpace or Property of some class, not value. I suggest to add attribute to Message to reference variables of these assignments. >Oystein should answer this one, but I believe that this is done through the fact that it >is tied to the event occurrence that designates the end of the execution occurrence >specification corresponding to the invoked operation. ExecutionOccurrenceSpecification that designates end of the execution can't be tied with Message, because it is not MessageOccurrenceSpecification. I suggest to make ExecutionOccurrenceSpecification subclass of MessageOccurrenceSpecification. The similar problem is with CreationEvent and DestructionEvent that are not subclasses of MessageEvent and can't be used in MessageOccurrenceSpecification to indicate "create message" or "destroy message". Regards, -- Nerijus Jankevicius Senior Programmer & System Analyst OMG-Certified UML Professional No Magic Lithuanian Development Center Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com ----- Original Message ----- From: Branislav Selic To: Nerijus Jankevicius Cc: Juergen Boldt ; uml2-rtf@omg.org Sent: Friday, June 24, 2005 9:34 AM Subject: Re: some issues Nerijus, > 1. You are not right. Classifier can't have Properties, because > /attribute is derived union, calculated from real containers > (/member and /ownedMember also). Every subclass of Classifier must > have REAL container for Properties (ownedAttributes in Class for > example). UseCase and Actor doesn't have containers for Properties, > so they can't own Properties, so navigable Association can't be created. My apologies, Nerijus, you are absolutely right. I did not notice that ownedMember was also derived. Perhaps the resolution is to make both Actor and UseCase a kind of Class? What kind of Properties do you think these two should have? What is the use case to justify these. > 6. Actions are part of Behavior, but Transition should know which > one to display on signature, Transition should have references to > elements that should be displayed on it, or you mean that Transition > should list all actions from "effect" behavior? Actually, listing the actions on a transition "signature" is a notation that does not scale up and is, therefore, impractical. Also, the behavior attached to a signature can be any kind of behavior (including a state machine, activity, or interaction) -- and this is not something that can be displayed in a "signature". However, if you do want to display the behavior in a signature, then you should display all of it and not just some arbitrary subset. So, in that case, you should display all the actions. (NB: If you want, your tool can provide a filtering mechanism for this; e.g., to only display the "send" and "call" actions, which is what most people want to see in such cases.) > 7. What you mean "can own a set of ValueSpecifications"? Own as > arguments of the message? Precisely. > But when a Message represents an Operation invocation, the arguments > of the Message are the arguments of the CallOperationAction, number > of arguments should be the same as number of Parameters. > Even if "([ .=.]" is mapped into Message argument, it > can't be recognized from arguments used for other purposes. I don't understand what you mean by "arguments for other purposes". A message carries the arguments for its parameters and nothing else. > We decide to create new reply message and map these attributes as > arguments of reply message, but for this purpose Message model was > extended to have reference to reply message. I don't understand what you mean above. The reply message should carry the return value (if any). Why do you want to copy the input arguments here? Is your real issue that you cannot distinguish a reply message from an invocation message? > Other problems related with this issue are: > - what is reply message? How it can be recognized from other messages? Oystein should answer this one, but I believe that this is done through the fact that it is tied to the event occurrence that designates the end of the execution occurrence specification corresponding to the invoked operation. > - how valueSpecification can represent some element like attribute > or variable? For this purpose special kind of ValueSpecification > should be introduced (ElementValue or similar) with > reference to represented element. Again, Oystein should answer this, but the value specification here is just the value, not the variable or attribute. Are you saying you would like to include a reference to a variable or an attribute instead of a value? > Waiting for answers to my previous email. All problems are blockers for us. I am really sorry to hear this. Please note that the answers may not necessarily come as quickly as one might hope, since some of the things you are asking for may be contentious. I am quite willing to treat these as priority issues to be handled in this RTF cycle (the formal issues submission deadline for 2.1 passed over a month ago) but, formally, the resolutions are not binding until the RTF report is approved by the OMG. Of course, if we can all agree on the solutions ahead of that, chances are that you will be able to include these solutions in your tools sooner than that without worrying that they may get changed later. For such emergency situations, I suggest that you propose solutions along with your fixes -- after all, I believe that you folks are RTF members. This constructive approach should help focus the discussion and shorten the process. Regards,...Bran Subject: RE: actors and use cases Was: some issues Date: Tue, 28 Jun 2005 05:37:00 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues Thread-Index: AcV7nL3HfkiM2cXFT2qikAB/rIbsXwAJPZnw From: "Pete Rivett" To: "Tim Weilkiens" , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5S9Sihh022826 In which case should this connection between Actor and UseCase not inherit from Relationship rather than Association - it seems we need to have no Properties for either end. It frees up use of the arrow to indicate the more common semantic described rather than navigability. However, though it might make more sense, I do have a concern about forward compatibility if we take this approach. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Tuesday, June 28, 2005 5:49 AM > To: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > Joaquin, > > I agree if the semantic of an association allows the statement > "'has' meaning those actors participate in that use case". > > I'm not sure about this. If instances of two classes can communicate > there's not necessarily an association between those classes. > > The semantics of a connector sounds more reasonable for actor/use case > relationships. However it doesn't fit into the use case model. > > The composition relationship between actor and use case is > allowed as well > as aggregation. I think it shouldn't. > Navigation is often interpreted as "Who starts the > communication?". I don't think > that's conform to the formal definition of navigation. > However what does it mean to have > navigation e.g. from an actor to an use case? > > Using the standard association between actor and use cases > opens a lot of questions. > To dash off a sketch I would define a subclass of association > that relates actor and use case > which - in that case - still can be subclasses of classifier. > And we can omit composition, > aggregation, and navigation or define a more appropriate > semantic for them. That approach should > also consider Jim's objection. > > > Tim > > > > > -----Original Message----- > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > Sent: Monday, June 27, 2005 7:17 PM > > To: UML-RTF > > Subject: actors and use cases Was: some issues > > > > I would prefer to introduce a specialized association > > like the communication path in the deployment package or a > > complete new relationship. > > > > The relationship between an actor and an use case isn't > > a structural thing. It looks strange to me that an actor owns > > a property typed by an use case. > > > > > > Extremely strange. > > > > If we consider the UML specification to be about a data > > structure for modeling tools, then that there may well be > > some good reason for an actor to have a property that is a use case. > > > > But if we consider that one important intent of the UML > > specification is to provide a conceptual model of modeling, > > then certainly: > > > > a use case has one or more actors ('has' meaning those > > actors participate in that use case) > > a use case does not own those actors (the same actor can > > participate in several use cases) > > > > an actor may participate in one or more use cases (or may > > be an actor of a class or component) > > an actor does not own use cases (else: which actor owns a > > use case with more than one actor?) > > > > ('own' meaning is on the diamond end of a black diamond line) > > > > > > [I'm prepared for contradiction. I'm confident we don't have > > a shared understanding here.] > > > > > > Cordially, Joaquin > > > > > > [p.s. A couple of questions i asked, way back when, about > > what has since become figure 401 of ptc/04-10-02: Can an > > actor own use cases? Where do we find the traditional > > relationship of actors to use cases?] > > > > > > > > > > > > [LID] www.joaquin.net > > > > > Subject: RE: actors and use cases Was: some issues Date: Tue, 28 Jun 2005 13:48:05 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues thread-index: AcV7nL3HfkiM2cXFT2qikAB/rIbsXwAJPZnwAAVKjpA= From: "Tim Weilkiens" To: "Pete Rivett" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5SBwjhh023784 I don't think that we have compatibility problems since it is still possible to use non-navigable associations between use case and actor. Both are classifiers. Tim > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Tuesday, June 28, 2005 11:37 AM > To: Tim Weilkiens; uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > In which case should this connection between Actor and > UseCase not inherit from Relationship rather than Association > - it seems we need to have no Properties for either end. > It frees up use of the arrow to indicate the more common > semantic described rather than navigability. > However, though it might make more sense, I do have a concern > about forward compatibility if we take this approach. > > Pete > > Pete Rivett (mailto:pete.rivett@adaptive.com) > CTO, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Tuesday, June 28, 2005 5:49 AM > > To: uml2-rtf@omg.org > > Subject: RE: actors and use cases Was: some issues > > > > Joaquin, > > > > I agree if the semantic of an association allows the statement > > "'has' meaning those actors participate in that use case". > > > > I'm not sure about this. If instances of two classes can communicate > > there's not necessarily an association between those classes. > > > > The semantics of a connector sounds more reasonable for > actor/use case > > relationships. However it doesn't fit into the use case model. > > > > The composition relationship between actor and use case is > > allowed as well > > as aggregation. I think it shouldn't. > > Navigation is often interpreted as "Who starts the > > communication?". I don't think > > that's conform to the formal definition of navigation. > > However what does it mean to have > > navigation e.g. from an actor to an use case? > > > > Using the standard association between actor and use cases > > opens a lot of questions. > > To dash off a sketch I would define a subclass of association > > that relates actor and use case > > which - in that case - still can be subclasses of classifier. > > And we can omit composition, > > aggregation, and navigation or define a more appropriate > > semantic for them. That approach should > > also consider Jim's objection. > > > > > > Tim > > > > > > > > > -----Original Message----- > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > Sent: Monday, June 27, 2005 7:17 PM > > > To: UML-RTF > > > Subject: actors and use cases Was: some issues > > > > > > I would prefer to introduce a specialized association > > > like the communication path in the deployment package or a > > > complete new relationship. > > > > > > The relationship between an actor and an use case isn't > > > a structural thing. It looks strange to me that an actor owns > > > a property typed by an use case. > > > > > > > > > Extremely strange. > > > > > > If we consider the UML specification to be about a data > > > structure for modeling tools, then that there may well be > > > some good reason for an actor to have a property that is > a use case. > > > > > > But if we consider that one important intent of the UML > > > specification is to provide a conceptual model of modeling, > > > then certainly: > > > > > > a use case has one or more actors ('has' meaning those > > > actors participate in that use case) > > > a use case does not own those actors (the same actor can > > > participate in several use cases) > > > > > > an actor may participate in one or more use cases (or may > > > be an actor of a class or component) > > > an actor does not own use cases (else: which actor owns a > > > use case with more than one actor?) > > > > > > ('own' meaning is on the diamond end of a black diamond line) > > > > > > > > > [I'm prepared for contradiction. I'm confident we don't have > > > a shared understanding here.] > > > > > > > > > Cordially, Joaquin > > > > > > > > > [p.s. A couple of questions i asked, way back when, about > > > what has since become figure 401 of ptc/04-10-02: Can an > > > actor own use cases? Where do we find the traditional > > > relationship of actors to use cases?] > > > > > > > > > > > > > > > > > > [LID] www.joaquin.net > > > > > > > > > From: "Nerijus Jankevicius" To: "Tim Weilkiens" , "Pete Rivett" Cc: Subject: Re: actors and use cases Was: some issues Date: Tue, 28 Jun 2005 15:01:34 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 The problem is that non-navigable association is notated as line with "crosses" at non-navigable ends, but in all usecase diagrams examples are used association symbols as simple lines. -- Nerijus Jankevicius Senior Programmer & System Analyst OMG-Certified UML Professional No Magic Lithuanian Development Center Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com ----- Original Message ----- From: "Tim Weilkiens" To: "Pete Rivett" Cc: Sent: Tuesday, June 28, 2005 2:48 PM Subject: RE: actors and use cases Was: some issues I don't think that we have compatibility problems since it is still possible to use non-navigable associations between use case and actor. Both are classifiers. Tim -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, June 28, 2005 11:37 AM To: Tim Weilkiens; uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues In which case should this connection between Actor and UseCase not inherit from Relationship rather than Association - it seems we need to have no Properties for either end. It frees up use of the arrow to indicate the more common semantic described rather than navigability. However, though it might make more sense, I do have a concern about forward compatibility if we take this approach. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Tuesday, June 28, 2005 5:49 AM > To: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > Joaquin, > > I agree if the semantic of an association allows the statement > "'has' meaning those actors participate in that use case". > > I'm not sure about this. If instances of two classes can communicate > there's not necessarily an association between those classes. > > The semantics of a connector sounds more reasonable for actor/use case > relationships. However it doesn't fit into the use case model. > > The composition relationship between actor and use case is > allowed as well > as aggregation. I think it shouldn't. > Navigation is often interpreted as "Who starts the > communication?". I don't think > that's conform to the formal definition of navigation. > However what does it mean to have > navigation e.g. from an actor to an use case? > > Using the standard association between actor and use cases > opens a lot of questions. > To dash off a sketch I would define a subclass of association > that relates actor and use case > which - in that case - still can be subclasses of classifier. > And we can omit composition, > aggregation, and navigation or define a more appropriate > semantic for them. That approach should > also consider Jim's objection. > > > Tim > > > > > -----Original Message----- > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > Sent: Monday, June 27, 2005 7:17 PM > > To: UML-RTF > > Subject: actors and use cases Was: some issues > > > > I would prefer to introduce a specialized association > > like the communication path in the deployment package or a > > complete new relationship. > > > > The relationship between an actor and an use case isn't > > a structural thing. It looks strange to me that an actor owns > > a property typed by an use case. > > > > > > Extremely strange. > > > > If we consider the UML specification to be about a data > > structure for modeling tools, then that there may well be > > some good reason for an actor to have a property that is a use case. > > > > But if we consider that one important intent of the UML > > specification is to provide a conceptual model of modeling, > > then certainly: > > > > a use case has one or more actors ('has' meaning those > > actors participate in that use case) > > a use case does not own those actors (the same actor can > > participate in several use cases) > > > > an actor may participate in one or more use cases (or may > > be an actor of a class or component) > > an actor does not own use cases (else: which actor owns a > > use case with more than one actor?) > > > > ('own' meaning is on the diamond end of a black diamond line) > > > > > > [I'm prepared for contradiction. I'm confident we don't have > > a shared understanding here.] > > > > > > Cordially, Joaquin > > > > > > [p.s. A couple of questions i asked, way back when, about > > what has since become figure 401 of ptc/04-10-02: Can an > > actor own use cases? Where do we find the traditional > > relationship of actors to use cases?] > > > > > > > > > > > > [LID] www.joaquin.net > > > > > Subject: RE: actors and use cases Was: some issues Date: Tue, 28 Jun 2005 14:07:26 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues thread-index: AcV72a07SmjjQozKQPe65lkX37XjagAACQkw From: "Tim Weilkiens" To: "Nerijus Jankevicius" , "Pete Rivett" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5SCHxhh023974 The presentation options allow to suppress the cross notation. Tim > -----Original Message----- > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > Sent: Tuesday, June 28, 2005 2:02 PM > To: Tim Weilkiens; Pete Rivett > Cc: uml2-rtf@omg.org > Subject: Re: actors and use cases Was: some issues > > The problem is that non-navigable association is notated as line with > "crosses" at non-navigable ends, but in all usecase diagrams > examples are > used association symbols as simple lines. > > > -- > Nerijus Jankevicius > Senior Programmer & System Analyst > OMG-Certified UML Professional > No Magic Lithuanian Development Center > Savanoriu pr. 363, LT 49425 Kaunas > P.O. box 2166, LT- 3000, Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > > > ----- Original Message ----- > From: "Tim Weilkiens" > To: "Pete Rivett" > Cc: > Sent: Tuesday, June 28, 2005 2:48 PM > Subject: RE: actors and use cases Was: some issues > > > >I don't think that we have compatibility problems since it is still > >possible > > to use non-navigable associations between use case and > actor. Both are > > classifiers. > > > > Tim > > > >> -----Original Message----- > >> From: Pete Rivett [mailto:pete.rivett@adaptive.com] > >> Sent: Tuesday, June 28, 2005 11:37 AM > >> To: Tim Weilkiens; uml2-rtf@omg.org > >> Subject: RE: actors and use cases Was: some issues > >> > >> In which case should this connection between Actor and > >> UseCase not inherit from Relationship rather than Association > >> - it seems we need to have no Properties for either end. > >> It frees up use of the arrow to indicate the more common > >> semantic described rather than navigability. > >> However, though it might make more sense, I do have a concern > >> about forward compatibility if we take this approach. > >> > >> Pete > >> > >> Pete Rivett (mailto:pete.rivett@adaptive.com) > >> CTO, Adaptive Inc. > >> Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > >> Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > >> http://www.adaptive.com > >> > >> > >> > >> > >> > -----Original Message----- > >> > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > >> > Sent: Tuesday, June 28, 2005 5:49 AM > >> > To: uml2-rtf@omg.org > >> > Subject: RE: actors and use cases Was: some issues > >> > > >> > Joaquin, > >> > > >> > I agree if the semantic of an association allows the statement > >> > "'has' meaning those actors participate in that use case". > >> > > >> > I'm not sure about this. If instances of two classes can > communicate > >> > there's not necessarily an association between those classes. > >> > > >> > The semantics of a connector sounds more reasonable for > >> actor/use case > >> > relationships. However it doesn't fit into the use case model. > >> > > >> > The composition relationship between actor and use case is > >> > allowed as well > >> > as aggregation. I think it shouldn't. > >> > Navigation is often interpreted as "Who starts the > >> > communication?". I don't think > >> > that's conform to the formal definition of navigation. > >> > However what does it mean to have > >> > navigation e.g. from an actor to an use case? > >> > > >> > Using the standard association between actor and use cases > >> > opens a lot of questions. > >> > To dash off a sketch I would define a subclass of association > >> > that relates actor and use case > >> > which - in that case - still can be subclasses of classifier. > >> > And we can omit composition, > >> > aggregation, and navigation or define a more appropriate > >> > semantic for them. That approach should > >> > also consider Jim's objection. > >> > > >> > > >> > Tim > >> > > >> > > >> > > >> > > -----Original Message----- > >> > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > >> > > Sent: Monday, June 27, 2005 7:17 PM > >> > > To: UML-RTF > >> > > Subject: actors and use cases Was: some issues > >> > > > >> > > I would prefer to introduce a specialized association > >> > > like the communication path in the deployment package or a > >> > > complete new relationship. > >> > > > >> > > The relationship between an actor and an use case isn't > >> > > a structural thing. It looks strange to me that an actor owns > >> > > a property typed by an use case. > >> > > > >> > > > >> > > Extremely strange. > >> > > > >> > > If we consider the UML specification to be about a data > >> > > structure for modeling tools, then that there may well be > >> > > some good reason for an actor to have a property that is > >> a use case. > >> > > > >> > > But if we consider that one important intent of the UML > >> > > specification is to provide a conceptual model of modeling, > >> > > then certainly: > >> > > > >> > > a use case has one or more actors ('has' meaning those > >> > > actors participate in that use case) > >> > > a use case does not own those actors (the same actor can > >> > > participate in several use cases) > >> > > > >> > > an actor may participate in one or more use cases (or may > >> > > be an actor of a class or component) > >> > > an actor does not own use cases (else: which actor owns a > >> > > use case with more than one actor?) > >> > > > >> > > ('own' meaning is on the diamond end of a black > diamond line) > >> > > > >> > > > >> > > [I'm prepared for contradiction. I'm confident we don't have > >> > > a shared understanding here.] > >> > > > >> > > > >> > > Cordially, Joaquin > >> > > > >> > > > >> > > [p.s. A couple of questions i asked, way back when, about > >> > > what has since become figure 401 of ptc/04-10-02: Can an > >> > > actor own use cases? Where do we find the traditional > >> > > relationship of actors to use cases?] > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > [LID] www.joaquin.net > >> > > > >> > > > >> > > >> > > Subject: RE: actors and use cases Was: some issues Date: Tue, 28 Jun 2005 08:45:53 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues Thread-Index: AcV7nL3HfkiM2cXFT2qikAB/rIbsXwAJPZnwAAVKjpAAASe7MA== From: "Pete Rivett" To: "Tim Weilkiens" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5SCbShh024213 My point was that, taking your line of thought further, I'm not sure the connection between Actor and UseCase would be an Association at all e.g. it could be a new metaclass ActorCommunication that inherits from Relationship without the baggage of Associations (e.g. 2 owned Properties). This is what would have compatibility issues. In this discussion we should also ensure that this Actor-UseCase connection may be sensibly traced through to implementations: especially if the Actor in question is a software component. In which case the communication at the Actor-UseCase level may trace to Ports and Connectors at the design level. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Tuesday, June 28, 2005 12:48 PM > To: Pete Rivett > Cc: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > I don't think that we have compatibility problems since it is > still possible > to use non-navigable associations between use case and actor. Both are > classifiers. > > Tim > > > -----Original Message----- > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > Sent: Tuesday, June 28, 2005 11:37 AM > > To: Tim Weilkiens; uml2-rtf@omg.org > > Subject: RE: actors and use cases Was: some issues > > > > In which case should this connection between Actor and > > UseCase not inherit from Relationship rather than Association > > - it seems we need to have no Properties for either end. > > It frees up use of the arrow to indicate the more common > > semantic described rather than navigability. > > However, though it might make more sense, I do have a concern > > about forward compatibility if we take this approach. > > > > Pete > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > CTO, Adaptive Inc. > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > Sent: Tuesday, June 28, 2005 5:49 AM > > > To: uml2-rtf@omg.org > > > Subject: RE: actors and use cases Was: some issues > > > > > > Joaquin, > > > > > > I agree if the semantic of an association allows the statement > > > "'has' meaning those actors participate in that use case". > > > > > > I'm not sure about this. If instances of two classes can > communicate > > > there's not necessarily an association between those classes. > > > > > > The semantics of a connector sounds more reasonable for > > actor/use case > > > relationships. However it doesn't fit into the use case model. > > > > > > The composition relationship between actor and use case is > > > allowed as well > > > as aggregation. I think it shouldn't. > > > Navigation is often interpreted as "Who starts the > > > communication?". I don't think > > > that's conform to the formal definition of navigation. > > > However what does it mean to have > > > navigation e.g. from an actor to an use case? > > > > > > Using the standard association between actor and use cases > > > opens a lot of questions. > > > To dash off a sketch I would define a subclass of association > > > that relates actor and use case > > > which - in that case - still can be subclasses of classifier. > > > And we can omit composition, > > > aggregation, and navigation or define a more appropriate > > > semantic for them. That approach should > > > also consider Jim's objection. > > > > > > > > > Tim > > > > > > > > > > > > > -----Original Message----- > > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > > Sent: Monday, June 27, 2005 7:17 PM > > > > To: UML-RTF > > > > Subject: actors and use cases Was: some issues > > > > > > > > I would prefer to introduce a specialized association > > > > like the communication path in the deployment package or a > > > > complete new relationship. > > > > > > > > The relationship between an actor and an use case isn't > > > > a structural thing. It looks strange to me that an actor owns > > > > a property typed by an use case. > > > > > > > > > > > > Extremely strange. > > > > > > > > If we consider the UML specification to be about a data > > > > structure for modeling tools, then that there may well be > > > > some good reason for an actor to have a property that is > > a use case. > > > > > > > > But if we consider that one important intent of the UML > > > > specification is to provide a conceptual model of modeling, > > > > then certainly: > > > > > > > > a use case has one or more actors ('has' meaning those > > > > actors participate in that use case) > > > > a use case does not own those actors (the same actor can > > > > participate in several use cases) > > > > > > > > an actor may participate in one or more use cases (or may > > > > be an actor of a class or component) > > > > an actor does not own use cases (else: which actor owns a > > > > use case with more than one actor?) > > > > > > > > ('own' meaning is on the diamond end of a black > diamond line) > > > > > > > > > > > > [I'm prepared for contradiction. I'm confident we don't have > > > > a shared understanding here.] > > > > > > > > > > > > Cordially, Joaquin > > > > > > > > > > > > [p.s. A couple of questions i asked, way back when, about > > > > what has since become figure 401 of ptc/04-10-02: Can an > > > > actor own use cases? Where do we find the traditional > > > > relationship of actors to use cases?] > > > > > > > > > > > > > > > > > > > > > > > > [LID] www.joaquin.net > > > > > > > > > > > > > > Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 28 Jun 2005 11:18:08 -0700 To: UML-RTF From: Joaquin Miller Subject: RE: actors and use cases Was: some issues Folks are doing good work on this. We are closing in on an answer. What Pete writes is on target. Pete wrote: My point was that, taking your line of thought further, I'm not sure the connection between Actor and UseCase would be an Association at all e.g. it could be a new metaclass ActorCommunication that inherits from Relationship without the baggage of Associations (e.g. 2 owned Properties). This is what would have compatibility issues. In this discussion we should also ensure that this Actor-UseCase connection may be sensibly traced through to implementations: especially if the Actor in question is a software component. In which case the communication at the Actor-UseCase level may trace to Ports and Connectors at the design level. > > > > ... if we consider that one important intent of the UML specification is to provide a conceptual model of modeling, then certainly: a use case has one or more actors ('has' meaning those actors participate in that use case) a use case does not own those actors (the same actor can participate in several use cases) an actor may participate in one or more use cases (or may be an actor of a class or component) an actor does not own use cases (else: which actor owns a use case with more than one actor?) ('own' meaning is on the diamond end of a black diamond line) www.joaquin.net User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 28 Jun 2005 18:45:41 -0400 Subject: Re: actors and use cases Was: some issues From: James Odell To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5SMuThh002322 Tim, In terms of aggregation, this is sometimes used between actors. For example, an instance of Actor A could consist of instances of Actors B and C. -Jim On 6/28/05 12:49 AM, "Tim Weilkiens" indited: > Joaquin, > > I agree if the semantic of an association allows the statement > "'has' meaning those actors participate in that use case". > > I'm not sure about this. If instances of two classes can communicate > there's not necessarily an association between those classes. > > The semantics of a connector sounds more reasonable for actor/use case > relationships. However it doesn't fit into the use case model. > > The composition relationship between actor and use case is allowed as well > as aggregation. I think it shouldn't. > Navigation is often interpreted as "Who starts the communication?". I don't > think > that's conform to the formal definition of navigation. However what does it > mean to have > navigation e.g. from an actor to an use case? > > Using the standard association between actor and use cases opens a lot of > questions. > To dash off a sketch I would define a subclass of association that relates > actor and use case > which - in that case - still can be subclasses of classifier. And we can omit > composition, > aggregation, and navigation or define a more appropriate semantic for them. > That approach should > also consider Jim's objection. > > > Tim > > > >> -----Original Message----- >> From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] >> Sent: Monday, June 27, 2005 7:17 PM >> To: UML-RTF >> Subject: actors and use cases Was: some issues >> >> I would prefer to introduce a specialized association >> like the communication path in the deployment package or a >> complete new relationship. >> >> The relationship between an actor and an use case isn't >> a structural thing. It looks strange to me that an actor owns >> a property typed by an use case. >> >> >> Extremely strange. >> >> If we consider the UML specification to be about a data >> structure for modeling tools, then that there may well be >> some good reason for an actor to have a property that is a use case. >> >> But if we consider that one important intent of the UML >> specification is to provide a conceptual model of modeling, >> then certainly: >> >> a use case has one or more actors ('has' meaning those >> actors participate in that use case) >> a use case does not own those actors (the same actor can >> participate in several use cases) >> >> an actor may participate in one or more use cases (or may >> be an actor of a class or component) >> an actor does not own use cases (else: which actor owns a >> use case with more than one actor?) >> >> ('own' meaning is on the diamond end of a black diamond line) >> >> >> [I'm prepared for contradiction. I'm confident we don't have >> a shared understanding here.] >> >> >> Cordially, Joaquin >> >> >> [p.s. A couple of questions i asked, way back when, about >> what has since become figure 401 of ptc/04-10-02: Can an >> actor own use cases? Where do we find the traditional >> relationship of actors to use cases?] >> >> >> >> >> >> [LID] www.joaquin.net >> >> Subject: RE: actors and use cases Was: some issues Date: Wed, 29 Jun 2005 09:39:06 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues thread-index: AcV7nL3HfkiM2cXFT2qikAB/rIbsXwAJPZnwAAVKjpAAASe7MAAoXnKw From: "Tim Weilkiens" To: "Pete Rivett" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5T7nuhh005931 Pete, > My point was that, taking your line of thought further, I'm > not sure the connection between Actor and UseCase would be an > Association at all e.g. it could be a new metaclass > ActorCommunication that inherits from Relationship without > the baggage of Associations (e.g. 2 owned Properties). This > is what would have compatibility issues. I agree. However Actor and UseCase are specialized Classifiers therefore it is still possible to define an association between them. Isn't that sufficient to be compatible? > In this discussion we should also ensure that this > Actor-UseCase connection may be sensibly traced through to > implementations: especially if the Actor in question is a > software component. In which case the communication at the > Actor-UseCase level may trace to Ports and Connectors at the > design level. That's an important requirement for the actor/use case relationship. Ports and connectors often relates to associations, but not necessarily. It's possible to have a connector between actor and use case typed properties without having an association between them. Tim --- Tim Weilkiens, E-Mail tim.weilkiens@oose.de Instructor, Consultant, Coach OMG Representative, INCOSE member oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet http://www.oose.de > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Tuesday, June 28, 2005 12:48 PM > > To: Pete Rivett > > Cc: uml2-rtf@omg.org > > Subject: RE: actors and use cases Was: some issues > > > > I don't think that we have compatibility problems since it is > > still possible > > to use non-navigable associations between use case and > actor. Both are > > classifiers. > > > > Tim > > > > > -----Original Message----- > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > Sent: Tuesday, June 28, 2005 11:37 AM > > > To: Tim Weilkiens; uml2-rtf@omg.org > > > Subject: RE: actors and use cases Was: some issues > > > > > > In which case should this connection between Actor and > > > UseCase not inherit from Relationship rather than Association > > > - it seems we need to have no Properties for either end. > > > It frees up use of the arrow to indicate the more common > > > semantic described rather than navigability. > > > However, though it might make more sense, I do have a concern > > > about forward compatibility if we take this approach. > > > > > > Pete > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > CTO, Adaptive Inc. > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > BH1 1HL, UK > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > http://www.adaptive.com > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Tuesday, June 28, 2005 5:49 AM > > > > To: uml2-rtf@omg.org > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > Joaquin, > > > > > > > > I agree if the semantic of an association allows the statement > > > > "'has' meaning those actors participate in that use case". > > > > > > > > I'm not sure about this. If instances of two classes can > > communicate > > > > there's not necessarily an association between those classes. > > > > > > > > The semantics of a connector sounds more reasonable for > > > actor/use case > > > > relationships. However it doesn't fit into the use case model. > > > > > > > > The composition relationship between actor and use case is > > > > allowed as well > > > > as aggregation. I think it shouldn't. > > > > Navigation is often interpreted as "Who starts the > > > > communication?". I don't think > > > > that's conform to the formal definition of navigation. > > > > However what does it mean to have > > > > navigation e.g. from an actor to an use case? > > > > > > > > Using the standard association between actor and use cases > > > > opens a lot of questions. > > > > To dash off a sketch I would define a subclass of association > > > > that relates actor and use case > > > > which - in that case - still can be subclasses of classifier. > > > > And we can omit composition, > > > > aggregation, and navigation or define a more appropriate > > > > semantic for them. That approach should > > > > also consider Jim's objection. > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > > > Sent: Monday, June 27, 2005 7:17 PM > > > > > To: UML-RTF > > > > > Subject: actors and use cases Was: some issues > > > > > > > > > > I would prefer to introduce a specialized association > > > > > like the communication path in the deployment package or a > > > > > complete new relationship. > > > > > > > > > > The relationship between an actor and an use case isn't > > > > > a structural thing. It looks strange to me that an actor owns > > > > > a property typed by an use case. > > > > > > > > > > > > > > > Extremely strange. > > > > > > > > > > If we consider the UML specification to be about a data > > > > > structure for modeling tools, then that there may well be > > > > > some good reason for an actor to have a property that is > > > a use case. > > > > > > > > > > But if we consider that one important intent of the UML > > > > > specification is to provide a conceptual model of modeling, > > > > > then certainly: > > > > > > > > > > a use case has one or more actors ('has' meaning those > > > > > actors participate in that use case) > > > > > a use case does not own those actors (the same actor can > > > > > participate in several use cases) > > > > > > > > > > an actor may participate in one or more use cases (or may > > > > > be an actor of a class or component) > > > > > an actor does not own use cases (else: which actor owns a > > > > > use case with more than one actor?) > > > > > > > > > > ('own' meaning is on the diamond end of a black > > diamond line) > > > > > > > > > > > > > > > [I'm prepared for contradiction. I'm confident we don't have > > > > > a shared understanding here.] > > > > > > > > > > > > > > > Cordially, Joaquin > > > > > > > > > > > > > > > [p.s. A couple of questions i asked, way back when, about > > > > > what has since become figure 401 of ptc/04-10-02: Can an > > > > > actor own use cases? Where do we find the traditional > > > > > relationship of actors to use cases?] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LID] www.joaquin.net > > > > > > > > > > > > > > > > > > > > Subject: RE: actors and use cases Was: some issues Date: Wed, 29 Jun 2005 08:04:05 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues Thread-Index: AcV7nL3HfkiM2cXFT2qikAB/rIbsXwAJPZnwAAVKjpAAASe7MAAoXnKwAAhmhAA= From: "Pete Rivett" To: "Tim Weilkiens" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5TBu1hh007836 > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Wednesday, June 29, 2005 8:39 AM > To: Pete Rivett > Cc: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > Pete, > > > My point was that, taking your line of thought further, I'm > > not sure the connection between Actor and UseCase would be an > > Association at all e.g. it could be a new metaclass > > ActorCommunication that inherits from Relationship without > > the baggage of Associations (e.g. 2 owned Properties). This > > is what would have compatibility issues. > > I agree. However Actor and UseCase are specialized > Classifiers therefore it is > still possible to define an association between them. Isn't > that sufficient to be > compatible? If a different element, such as ActorCommunication, is used to represent the commonly-used line between an actor and a use case on a use case diagram then that is an incompatibility. We may decide it's justified though I have not been convinced yet. Especially as it seems people are exploiting the presence of the Properties on the Association and attaching semantics to aggregation, multiplicity (the latter is somewhat fuzzily covered in the spec I just noticed) etc. > > > In this discussion we should also ensure that this > > Actor-UseCase connection may be sensibly traced through to > > implementations: especially if the Actor in question is a > > software component. In which case the communication at the > > Actor-UseCase level may trace to Ports and Connectors at the > > design level. > > That's an important requirement for the actor/use case relationship. > Ports and connectors often relates to associations, but not > necessarily. > It's possible to have a connector between actor and use case typed > properties without having an association between them. What do you mean by "use case typed properties"? Can you give an example of how such a thing would be used in practice? > > Tim > > --- > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > Instructor, Consultant, Coach > OMG Representative, INCOSE member > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > http://www.oose.de > > > > > > -----Original Message----- > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > Sent: Tuesday, June 28, 2005 12:48 PM > > > To: Pete Rivett > > > Cc: uml2-rtf@omg.org > > > Subject: RE: actors and use cases Was: some issues > > > > > > I don't think that we have compatibility problems since it is > > > still possible > > > to use non-navigable associations between use case and > > actor. Both are > > > classifiers. > > > > > > Tim > > > > > > > -----Original Message----- > > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > > Sent: Tuesday, June 28, 2005 11:37 AM > > > > To: Tim Weilkiens; uml2-rtf@omg.org > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > In which case should this connection between Actor and > > > > UseCase not inherit from Relationship rather than Association > > > > - it seems we need to have no Properties for either end. > > > > It frees up use of the arrow to indicate the more common > > > > semantic described rather than navigability. > > > > However, though it might make more sense, I do have a concern > > > > about forward compatibility if we take this approach. > > > > > > > > Pete > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > CTO, Adaptive Inc. > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > BH1 1HL, UK > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > > Sent: Tuesday, June 28, 2005 5:49 AM > > > > > To: uml2-rtf@omg.org > > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > Joaquin, > > > > > > > > > > I agree if the semantic of an association allows the > statement > > > > > "'has' meaning those actors participate in that use case". > > > > > > > > > > I'm not sure about this. If instances of two classes can > > > communicate > > > > > there's not necessarily an association between those classes. > > > > > > > > > > The semantics of a connector sounds more reasonable for > > > > actor/use case > > > > > relationships. However it doesn't fit into the use case model. > > > > > > > > > > The composition relationship between actor and use case is > > > > > allowed as well > > > > > as aggregation. I think it shouldn't. > > > > > Navigation is often interpreted as "Who starts the > > > > > communication?". I don't think > > > > > that's conform to the formal definition of navigation. > > > > > However what does it mean to have > > > > > navigation e.g. from an actor to an use case? > > > > > > > > > > Using the standard association between actor and use cases > > > > > opens a lot of questions. > > > > > To dash off a sketch I would define a subclass of association > > > > > that relates actor and use case > > > > > which - in that case - still can be subclasses of classifier. > > > > > And we can omit composition, > > > > > aggregation, and navigation or define a more appropriate > > > > > semantic for them. That approach should > > > > > also consider Jim's objection. > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > > > > Sent: Monday, June 27, 2005 7:17 PM > > > > > > To: UML-RTF > > > > > > Subject: actors and use cases Was: some issues > > > > > > > > > > > > I would prefer to introduce a specialized association > > > > > > like the communication path in the deployment package or a > > > > > > complete new relationship. > > > > > > > > > > > > The relationship between an actor and an use case isn't > > > > > > a structural thing. It looks strange to me that an > actor owns > > > > > > a property typed by an use case. > > > > > > > > > > > > > > > > > > Extremely strange. > > > > > > > > > > > > If we consider the UML specification to be about a data > > > > > > structure for modeling tools, then that there may well be > > > > > > some good reason for an actor to have a property that is > > > > a use case. > > > > > > > > > > > > But if we consider that one important intent of the UML > > > > > > specification is to provide a conceptual model of modeling, > > > > > > then certainly: > > > > > > > > > > > > a use case has one or more actors ('has' meaning those > > > > > > actors participate in that use case) > > > > > > a use case does not own those actors (the same > actor can > > > > > > participate in several use cases) > > > > > > > > > > > > an actor may participate in one or more use > cases (or may > > > > > > be an actor of a class or component) > > > > > > an actor does not own use cases (else: which > actor owns a > > > > > > use case with more than one actor?) > > > > > > > > > > > > ('own' meaning is on the diamond end of a black > > > diamond line) > > > > > > > > > > > > > > > > > > [I'm prepared for contradiction. I'm confident we > don't have > > > > > > a shared understanding here.] > > > > > > > > > > > > > > > > > > Cordially, Joaquin > > > > > > > > > > > > > > > > > > [p.s. A couple of questions i asked, way back when, about > > > > > > what has since become figure 401 of ptc/04-10-02: Can an > > > > > > actor own use cases? Where do we find the traditional > > > > > > relationship of actors to use cases?] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LID] www.joaquin.net > > > > > > > > > > > > > > > > > > > > > > > > > > > Reply-To: From: "Chris Armstrong" To: "'Pete Rivett'" , "'Tim Weilkiens'" Cc: Subject: RE: actors and use cases Was: some issues Date: Wed, 29 Jun 2005 14:49:56 -0500 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MS-TNEF-Correlator: 00000000CB80BFE818C4D311A1FC00E09800CD6AA473C301 X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter04.roc.ny.frontiernet.net Here's my take on this issue... Like others, as mentioned, we use the following convention regarding associations and navigability between actors and use cases: - Initiating actor (actor that starts use case and usually receives most, if not all, of the observable value): uni-directional association with arrow head pointing to use case - Receiving actor (actor that receive some observable value from use case, but doesn't start it): uni-directional association with arrow head pointing to actor - Supporting actor (actor that does not receive any particular value and also doesn't start use case, but needs to be there in order for the use case to complete): bi-directional association (with no arrow heads) In explaining this to practitioners, the arrow thing can be a little confusing as it inadvertently makes people think of flow. This then has the unfortunate consequence of then making some people think of data flow. It also compels many people to draw uni-directional associations between use cases to represent process flow. I've always wanted to explore some alternate notation for representing this. I don't have any particular inclinations on a solution, except that not using arrow heads would be nice. So, if we are exploring the possibility of creating a new type of relationship, perhaps some other adornment on this new relationship (as an alternative to navigability) might be possible? Regarding backwards compatibility, what are the real-world concerns and consequences about creating a new relationship? I understand that there might be technical details regarding migrating a UML 1.x model to UML 2.0 model, but it seems as if those would easily surmountable. On a related (new?) issue, we have often used realizations between actors to show how one actor sometimes behaves like another actor. This is in addition to occasionally using generalizations between actors as well. Is there any value in providing some examples of why and how someone might want to do this in the spec? Thanks, Chris ~:| -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, June 29, 2005 7:04 AM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Wednesday, June 29, 2005 8:39 AM > To: Pete Rivett > Cc: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > Pete, > > > My point was that, taking your line of thought further, I'm > > not sure the connection between Actor and UseCase would be an > > Association at all e.g. it could be a new metaclass > > ActorCommunication that inherits from Relationship without > > the baggage of Associations (e.g. 2 owned Properties). This > > is what would have compatibility issues. > > I agree. However Actor and UseCase are specialized > Classifiers therefore it is > still possible to define an association between them. Isn't > that sufficient to be > compatible? If a different element, such as ActorCommunication, is used to represent the commonly-used line between an actor and a use case on a use case diagram then that is an incompatibility. We may decide it's justified though I have not been convinced yet. Especially as it seems people are exploiting the presence of the Properties on the Association and attaching semantics to aggregation, multiplicity (the latter is somewhat fuzzily covered in the spec I just noticed) etc. > > > In this discussion we should also ensure that this > > Actor-UseCase connection may be sensibly traced through to > > implementations: especially if the Actor in question is a > > software component. In which case the communication at the > > Actor-UseCase level may trace to Ports and Connectors at the > > design level. > > That's an important requirement for the actor/use case relationship. > Ports and connectors often relates to associations, but not > necessarily. > It's possible to have a connector between actor and use case typed > properties without having an association between them. What do you mean by "use case typed properties"? Can you give an example of how such a thing would be used in practice? > > Tim > > --- > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > Instructor, Consultant, Coach > OMG Representative, INCOSE member > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > http://www.oose.de > > > > > > -----Original Message----- > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > Sent: Tuesday, June 28, 2005 12:48 PM > > > To: Pete Rivett > > > Cc: uml2-rtf@omg.org > > > Subject: RE: actors and use cases Was: some issues > > > > > > I don't think that we have compatibility problems since it is > > > still possible > > > to use non-navigable associations between use case and > > actor. Both are > > > classifiers. > > > > > > Tim > > > > > > > -----Original Message----- > > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > > Sent: Tuesday, June 28, 2005 11:37 AM > > > > To: Tim Weilkiens; uml2-rtf@omg.org > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > In which case should this connection between Actor and > > > > UseCase not inherit from Relationship rather than Association > > > > - it seems we need to have no Properties for either end. > > > > It frees up use of the arrow to indicate the more common > > > > semantic described rather than navigability. > > > > However, though it might make more sense, I do have a concern > > > > about forward compatibility if we take this approach. > > > > > > > > Pete > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > CTO, Adaptive Inc. > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > BH1 1HL, UK > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > > Sent: Tuesday, June 28, 2005 5:49 AM > > > > > To: uml2-rtf@omg.org > > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > Joaquin, > > > > > > > > > > I agree if the semantic of an association allows the > statement > > > > > "'has' meaning those actors participate in that use case". > > > > > > > > > > I'm not sure about this. If instances of two classes can > > > communicate > > > > > there's not necessarily an association between those classes. > > > > > > > > > > The semantics of a connector sounds more reasonable for > > > > actor/use case > > > > > relationships. However it doesn't fit into the use case model. > > > > > > > > > > The composition relationship between actor and use case is > > > > > allowed as well > > > > > as aggregation. I think it shouldn't. > > > > > Navigation is often interpreted as "Who starts the > > > > > communication?". I don't think > > > > > that's conform to the formal definition of navigation. > > > > > However what does it mean to have > > > > > navigation e.g. from an actor to an use case? > > > > > > > > > > Using the standard association between actor and use cases > > > > > opens a lot of questions. > > > > > To dash off a sketch I would define a subclass of association > > > > > that relates actor and use case > > > > > which - in that case - still can be subclasses of classifier. > > > > > And we can omit composition, > > > > > aggregation, and navigation or define a more appropriate > > > > > semantic for them. That approach should > > > > > also consider Jim's objection. > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > > > > Sent: Monday, June 27, 2005 7:17 PM > > > > > > To: UML-RTF > > > > > > Subject: actors and use cases Was: some issues > > > > > > > > > > > > I would prefer to introduce a specialized association > > > > > > like the communication path in the deployment package or a > > > > > > complete new relationship. > > > > > > > > > > > > The relationship between an actor and an use case isn't > > > > > > a structural thing. It looks strange to me that an > actor owns > > > > > > a property typed by an use case. > > > > > > > > > > > > > > > > > > Extremely strange. > > > > > > > > > > > > If we consider the UML specification to be about a data > > > > > > structure for modeling tools, then that there may well be > > > > > > some good reason for an actor to have a property that is > > > > a use case. > > > > > > > > > > > > But if we consider that one important intent of the UML > > > > > > specification is to provide a conceptual model of modeling, > > > > > > then certainly: > > > > > > > > > > > > a use case has one or more actors ('has' meaning those > > > > > > actors participate in that use case) > > > > > > a use case does not own those actors (the same > actor can > > > > > > participate in several use cases) > > > > > > > > > > > > an actor may participate in one or more use > cases (or may > > > > > > be an actor of a class or component) > > > > > > an actor does not own use cases (else: which > actor owns a > > > > > > use case with more than one actor?) > > > > > > > > > > > > ('own' meaning is on the diamond end of a black > > > diamond line) > > > > > > > > > > > > > > > > > > [I'm prepared for contradiction. I'm confident we > don't have > > > > > > a shared understanding here.] > > > > > > > > > > > > > > > > > > Cordially, Joaquin > > > > > > > > > > > > > > > > > > [p.s. A couple of questions i asked, way back when, about > > > > > > what has since become figure 401 of ptc/04-10-02: Can an > > > > > > actor own use cases? Where do we find the traditional > > > > > > relationship of actors to use cases?] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LID] www.joaquin.net > > > > > > > > > > > > > > > > > > > > > > > > > > > winmail1.dat Reply-To: From: "Conrad Bock" To: "Nerijus Jankevicius" Cc: Subject: RE: some issues Date: Wed, 29 Jun 2005 16:30:01 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Nerijus, > "An object node is an activity node that indicates an instance of a > particular classifier. " The whole sentence from the spec is: An object node is an activity node that indicates an instance of a particular classifier, possibly in a particular state, may be available at a particular point in the activity. > So what kind of ObjectNode should be used in regular Activity diagram to > represent instance of some type? Any of them, but normally it's Pin. The source and target of ObjectFlow edge can be Pin, which are associated with Action. But the notation can be a rectangle in between the actions. > What kind of ObjectNode is in all diagram examples in Activity chapter? Mostly pins, except for the central buffer and data store examples. > We decide to use CentralBufferNode by default in our tool, but I > think this is not acceptable, ObjectNode should be not abstract. The default would normally be Pin. What is the problem you're running into? Subject: RE: actors and use cases Was: some issues Date: Wed, 29 Jun 2005 18:29:15 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues Thread-Index: AcV847lun8SWsemSQbCCqL/fvsVTiAAEndzw From: "Pete Rivett" To: , "Tim Weilkiens" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5TML8hh018702 > Regarding backwards compatibility, what are the real-world > concerns and consequences about creating a new relationship? > I understand that there might be technical details regarding > migrating a UML 1.x model to UML 2.0 model, but it seems as > if those would easily surmountable. It's UML 2.0 to UML 2.1 (the deliverable from the current RTF) that we have to be concerned about. An RTF should provide clarifications and fix errors, but minimize unnecessary substantive changes. Real world concerns about using anew relationship are: - loading a UML 2.0 use case model/diagram into a UML 2.1 tool. The existing Associations will (I presume) still be valid but will differ from how the 'real' Actor-UseCase relationships are now represented. - loading a UML 2.1 use case model/diagram into a UML 2.0 tool. Using a new relationship would cause the import to fail or the important Actor-UseCase relationship to be lost. Hope that helps Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Chris Armstrong [mailto:chris.armstrong@aprocessgroup.com] > Sent: Wednesday, June 29, 2005 8:50 PM > To: Pete Rivett; 'Tim Weilkiens' > Cc: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > Here's my take on this issue... Like others, as mentioned, we > use the following convention regarding associations and > navigability between actors and use cases: > > - Initiating actor (actor that starts use case and usually > receives most, if not all, of the observable value): > uni-directional association with arrow head pointing to use case > - Receiving actor (actor that receive some observable value > from use case, but doesn't start it): uni-directional > association with arrow head pointing to actor > - Supporting actor (actor that does not receive any > particular value and also doesn't start use case, but needs > to be there in order for the use case to complete): > bi-directional association (with no arrow heads) > > In explaining this to practitioners, the arrow thing can be a > little confusing as it inadvertently makes people think of > flow. This then has the unfortunate consequence of then > making some people think of data flow. It also compels many > people to draw uni-directional associations between use cases > to represent process flow. I've always wanted to explore some > alternate notation for representing this. I don't have any > particular inclinations on a solution, except that not using > arrow heads would be nice. So, if we are exploring the > possibility of creating a new type of relationship, perhaps > some other adornment on this new relationship (as an > alternative to navigability) might be possible? > > Regarding backwards compatibility, what are the real-world > concerns and consequences about creating a new relationship? > I understand that there might be technical details regarding > migrating a UML 1.x model to UML 2.0 model, but it seems as > if those would easily surmountable. > > On a related (new?) issue, we have often used realizations > between actors to show how one actor sometimes behaves like > another actor. This is in addition to occasionally using > generalizations between actors as well. Is there any value in > providing some examples of why and how someone might want to > do this in the spec? > > Thanks, Chris ~ > > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Wednesday, June 29, 2005 7:04 AM > To: Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > > > > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Wednesday, June 29, 2005 8:39 AM > > To: Pete Rivett > > Cc: uml2-rtf@omg.org > > Subject: RE: actors and use cases Was: some issues > > > > Pete, > > > > > My point was that, taking your line of thought further, I'm > > > not sure the connection between Actor and UseCase would be an > > > Association at all e.g. it could be a new metaclass > > > ActorCommunication that inherits from Relationship without > > > the baggage of Associations (e.g. 2 owned Properties). This > > > is what would have compatibility issues. > > > > I agree. However Actor and UseCase are specialized > > Classifiers therefore it is > > still possible to define an association between them. Isn't > > that sufficient to be > > compatible? > > If a different element, such as ActorCommunication, is used > to represent the commonly-used line between an actor and a > use case on a use case diagram then that is an > incompatibility. We may decide it's justified though I have > not been convinced yet. Especially as it seems people are > exploiting the presence of the Properties on the Association > and attaching semantics to aggregation, multiplicity (the > latter is somewhat fuzzily covered in the spec I just noticed) etc. > > > > > > In this discussion we should also ensure that this > > > Actor-UseCase connection may be sensibly traced through to > > > implementations: especially if the Actor in question is a > > > software component. In which case the communication at the > > > Actor-UseCase level may trace to Ports and Connectors at the > > > design level. > > > > That's an important requirement for the actor/use case relationship. > > Ports and connectors often relates to associations, but not > > necessarily. > > It's possible to have a connector between actor and use case typed > > properties without having an association between them. > > What do you mean by "use case typed properties"? Can you give > an example of how such a thing would be used in practice? > > > > Tim > > > > --- > > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > > Instructor, Consultant, Coach > > OMG Representative, INCOSE member > > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > > http://www.oose.de > > > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Tuesday, June 28, 2005 12:48 PM > > > > To: Pete Rivett > > > > Cc: uml2-rtf@omg.org > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > I don't think that we have compatibility problems since it is > > > > still possible > > > > to use non-navigable associations between use case and > > > actor. Both are > > > > classifiers. > > > > > > > > Tim > > > > > > > > > -----Original Message----- > > > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > > > Sent: Tuesday, June 28, 2005 11:37 AM > > > > > To: Tim Weilkiens; uml2-rtf@omg.org > > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > In which case should this connection between Actor and > > > > > UseCase not inherit from Relationship rather than Association > > > > > - it seems we need to have no Properties for either end. > > > > > It frees up use of the arrow to indicate the more common > > > > > semantic described rather than navigability. > > > > > However, though it might make more sense, I do have a concern > > > > > about forward compatibility if we take this approach. > > > > > > > > > > Pete > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > > CTO, Adaptive Inc. > > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > > BH1 1HL, UK > > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > > > Sent: Tuesday, June 28, 2005 5:49 AM > > > > > > To: uml2-rtf@omg.org > > > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > > > Joaquin, > > > > > > > > > > > > I agree if the semantic of an association allows the > > statement > > > > > > "'has' meaning those actors participate in that use case". > > > > > > > > > > > > I'm not sure about this. If instances of two classes can > > > > communicate > > > > > > there's not necessarily an association between > those classes. > > > > > > > > > > > > The semantics of a connector sounds more reasonable for > > > > > actor/use case > > > > > > relationships. However it doesn't fit into the use > case model. > > > > > > > > > > > > The composition relationship between actor and use case is > > > > > > allowed as well > > > > > > as aggregation. I think it shouldn't. > > > > > > Navigation is often interpreted as "Who starts the > > > > > > communication?". I don't think > > > > > > that's conform to the formal definition of navigation. > > > > > > However what does it mean to have > > > > > > navigation e.g. from an actor to an use case? > > > > > > > > > > > > Using the standard association between actor and use cases > > > > > > opens a lot of questions. > > > > > > To dash off a sketch I would define a subclass of > association > > > > > > that relates actor and use case > > > > > > which - in that case - still can be subclasses of > classifier. > > > > > > And we can omit composition, > > > > > > aggregation, and navigation or define a more appropriate > > > > > > semantic for them. That approach should > > > > > > also consider Jim's objection. > > > > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > > > > > Sent: Monday, June 27, 2005 7:17 PM > > > > > > > To: UML-RTF > > > > > > > Subject: actors and use cases Was: some issues > > > > > > > > > > > > > > I would prefer to introduce a specialized association > > > > > > > like the communication path in the deployment > package or a > > > > > > > complete new relationship. > > > > > > > > > > > > > > The relationship between an actor and an use case isn't > > > > > > > a structural thing. It looks strange to me that an > > actor owns > > > > > > > a property typed by an use case. > > > > > > > > > > > > > > > > > > > > > Extremely strange. > > > > > > > > > > > > > > If we consider the UML specification to be about a data > > > > > > > structure for modeling tools, then that there may well be > > > > > > > some good reason for an actor to have a property that is > > > > > a use case. > > > > > > > > > > > > > > But if we consider that one important intent of the UML > > > > > > > specification is to provide a conceptual model of > modeling, > > > > > > > then certainly: > > > > > > > > > > > > > > a use case has one or more actors ('has' > meaning those > > > > > > > actors participate in that use case) > > > > > > > a use case does not own those actors (the same > > actor can > > > > > > > participate in several use cases) > > > > > > > > > > > > > > an actor may participate in one or more use > > cases (or may > > > > > > > be an actor of a class or component) > > > > > > > an actor does not own use cases (else: which > > actor owns a > > > > > > > use case with more than one actor?) > > > > > > > > > > > > > > ('own' meaning is on the diamond end of a black > > > > diamond line) > > > > > > > > > > > > > > > > > > > > > [I'm prepared for contradiction. I'm confident we > > don't have > > > > > > > a shared understanding here.] > > > > > > > > > > > > > > > > > > > > > Cordially, Joaquin > > > > > > > > > > > > > > > > > > > > > [p.s. A couple of questions i asked, way back when, about > > > > > > > what has since become figure 401 of ptc/04-10-02: Can an > > > > > > > actor own use cases? Where do we find the traditional > > > > > > > relationship of actors to use cases?] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LID] > www.joaquin.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: "Nerijus Jankevicius" To: Cc: Subject: Re: some issues Date: Thu, 30 Jun 2005 10:44:38 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Conrad, There are several problems if Pin should be used as separate node in Activity diagram. 1. Pin is abstract, so InputPin or OutputPin should be used. 2. Pins should be owned by Actions, but if you use as separate node and draw it on diagram, it will be owned by Activity. Not clear how to relate Pin with action - if it is between two actions, not clear which one it should be - OutputPin for first action, or InputPin for the second. If Pin is related with one action, it should be owned by this action, also should be deleted on action deleting. 3. InputPin can't have outgoing edges, OutputPin can't have incoming edges. In page 433 such notation is described as OPTIONAL notation with bizarre symbol-model mapping: "The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 294. The standalone pin in the notation maps to an output pin and an input pin in the underlying model." Nerijus ----- Original Message ----- From: "Conrad Bock" To: "Nerijus Jankevicius" Cc: Sent: Wednesday, June 29, 2005 11:30 PM Subject: RE: some issues Nerijus, > "An object node is an activity node that indicates an instance of a > particular classifier. " The whole sentence from the spec is: An object node is an activity node that indicates an instance of a particular classifier, possibly in a particular state, may be available at a particular point in the activity. > So what kind of ObjectNode should be used in regular Activity diagram to > represent instance of some type? Any of them, but normally it's Pin. The source and target of ObjectFlow edge can be Pin, which are associated with Action. But the notation can be a rectangle in between the actions. > What kind of ObjectNode is in all diagram examples in Activity chapter? Mostly pins, except for the central buffer and data store examples. > We decide to use CentralBufferNode by default in our tool, but I > think this is not acceptable, ObjectNode should be not abstract. The default would normally be Pin. What is the problem you're running into? Conrad Reply-To: From: "Conrad Bock" To: "Nerijus Jankevicius" Cc: Subject: RE: some issues Date: Thu, 30 Jun 2005 08:56:50 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Nerijus, > 1. Pin is abstract, so InputPin or OutputPin should be used. Sure, it's just easier to refer to them both at once. > 2. Pins should be owned by Actions, but if you use as separate node > and draw it on diagram, it will be owned by Activity. > In page 433 such notation is described as OPTIONAL notation with bizarre > symbol-model mapping: > "The situation in which the output pin of one action is connected to the > input pin of the same name in another action may be > shown by the optional notations of Figure 294. The standalone pin in the > notation maps to an output pin and an input pin in the The diagram and model are not always one-to-one. The notation showing an object node in the middle (eg, Figure 294 of the spec) is modeled as two pins, an output pin at the soruce action, and and input pin at the target action, connected by a single object flow edge. See the repository model in the upper part of Figure 7 in http://tinyurl.com/9y67t. It is the same underlying model as if it were notated with pins, see the upper right of Figure 1. In general, there is a tension between having a model that is closer to the meaning of the diagram versus one that is closer to pictorial nature of the diagram itself. In this case, it is closer to the user intention (ie, output flowing to input), than the diagram (round-rectangle, arrow, rectangle, arrow, round-rectangle). Being closer to the user intention is makes it more difficult to implement the interface to model mapping, but provides a single model for a variety of notations that mean the same thing. This facilitates the construction of tools that operate on the model, eg, for analysis, etc. > Not clear how to relate Pin with action - if it is between two > actions, not clear which one it should be - OutputPin for first > action, or InputPin for the second. The arrows in the diagram indicate which action should have the input and which the output pin. The arrows point away from the output pin and towards in the input pin. > If Pin is related with one action, it should be owned by this action, > also should be deleted on action deleting. Not following. > 3. InputPin can't have outgoing edges, OutputPin can't have > incoming edges. I gather this is na issue because of the incorrect mapping of notation to model (object node rectangle to single pin). Conrad Reply-To: From: "Chris Armstrong" To: "'Pete Rivett'" , "'Tim Weilkiens'" Cc: Subject: RE: actors and use cases Was: some issues Date: Thu, 30 Jun 2005 11:44:44 -0500 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MS-TNEF-Correlator: 00000000CB80BFE818C4D311A1FC00E09800CD6AE479C301 X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter06.roc.ny.frontiernet.net Duh... Sorry, for some reason I was focusing on the UML 1.x to UML 2.0 migration. I imagine there could also be issues regarding UML 1.x to UML 2.1 migration in addition to UML 2.0 to UML 2.1. Regarding your second point, is there a requirement that the spec allow a UML 2.1 model to be opened with a UML 2.0 tool? I wouldn't think that would be expected, as I wouldn't expect a UML 2.0 model to be openable in a UML 1.x tool. Thanks, Chris ~ -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, June 29, 2005 5:29 PM To: chris.armstrong@aprocessgroup.com; Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues > Regarding backwards compatibility, what are the real-world > concerns and consequences about creating a new relationship? > I understand that there might be technical details regarding > migrating a UML 1.x model to UML 2.0 model, but it seems as > if those would easily surmountable. It's UML 2.0 to UML 2.1 (the deliverable from the current RTF) that we have to be concerned about. An RTF should provide clarifications and fix errors, but minimize unnecessary substantive changes. Real world concerns about using anew relationship are: - loading a UML 2.0 use case model/diagram into a UML 2.1 tool. The existing Associations will (I presume) still be valid but will differ from how the 'real' Actor-UseCase relationships are now represented. - loading a UML 2.1 use case model/diagram into a UML 2.0 tool. Using a new relationship would cause the import to fail or the important Actor-UseCase relationship to be lost. Hope that helps Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Chris Armstrong [mailto:chris.armstrong@aprocessgroup.com] > Sent: Wednesday, June 29, 2005 8:50 PM > To: Pete Rivett; 'Tim Weilkiens' > Cc: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > Here's my take on this issue... Like others, as mentioned, we > use the following convention regarding associations and > navigability between actors and use cases: > > - Initiating actor (actor that starts use case and usually > receives most, if not all, of the observable value): > uni-directional association with arrow head pointing to use case > - Receiving actor (actor that receive some observable value > from use case, but doesn't start it): uni-directional > association with arrow head pointing to actor > - Supporting actor (actor that does not receive any > particular value and also doesn't start use case, but needs > to be there in order for the use case to complete): > bi-directional association (with no arrow heads) > > In explaining this to practitioners, the arrow thing can be a > little confusing as it inadvertently makes people think of > flow. This then has the unfortunate consequence of then > making some people think of data flow. It also compels many > people to draw uni-directional associations between use cases > to represent process flow. I've always wanted to explore some > alternate notation for representing this. I don't have any > particular inclinations on a solution, except that not using > arrow heads would be nice. So, if we are exploring the > possibility of creating a new type of relationship, perhaps > some other adornment on this new relationship (as an > alternative to navigability) might be possible? > > Regarding backwards compatibility, what are the real-world > concerns and consequences about creating a new relationship? > I understand that there might be technical details regarding > migrating a UML 1.x model to UML 2.0 model, but it seems as > if those would easily surmountable. > > On a related (new?) issue, we have often used realizations > between actors to show how one actor sometimes behaves like > another actor. This is in addition to occasionally using > generalizations between actors as well. Is there any value in > providing some examples of why and how someone might want to > do this in the spec? > > Thanks, Chris ~ > > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Wednesday, June 29, 2005 7:04 AM > To: Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > > > > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Wednesday, June 29, 2005 8:39 AM > > To: Pete Rivett > > Cc: uml2-rtf@omg.org > > Subject: RE: actors and use cases Was: some issues > > > > Pete, > > > > > My point was that, taking your line of thought further, I'm > > > not sure the connection between Actor and UseCase would be an > > > Association at all e.g. it could be a new metaclass > > > ActorCommunication that inherits from Relationship without > > > the baggage of Associations (e.g. 2 owned Properties). This > > > is what would have compatibility issues. > > > > I agree. However Actor and UseCase are specialized > > Classifiers therefore it is > > still possible to define an association between them. Isn't > > that sufficient to be > > compatible? > > If a different element, such as ActorCommunication, is used > to represent the commonly-used line between an actor and a > use case on a use case diagram then that is an > incompatibility. We may decide it's justified though I have > not been convinced yet. Especially as it seems people are > exploiting the presence of the Properties on the Association > and attaching semantics to aggregation, multiplicity (the > latter is somewhat fuzzily covered in the spec I just noticed) etc. > > > > > > In this discussion we should also ensure that this > > > Actor-UseCase connection may be sensibly traced through to > > > implementations: especially if the Actor in question is a > > > software component. In which case the communication at the > > > Actor-UseCase level may trace to Ports and Connectors at the > > > design level. > > > > That's an important requirement for the actor/use case relationship. > > Ports and connectors often relates to associations, but not > > necessarily. > > It's possible to have a connector between actor and use case typed > > properties without having an association between them. > > What do you mean by "use case typed properties"? Can you give > an example of how such a thing would be used in practice? > > > > Tim > > > > --- > > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > > Instructor, Consultant, Coach > > OMG Representative, INCOSE member > > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > > http://www.oose.de > > > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Tuesday, June 28, 2005 12:48 PM > > > > To: Pete Rivett > > > > Cc: uml2-rtf@omg.org > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > I don't think that we have compatibility problems since it is > > > > still possible > > > > to use non-navigable associations between use case and > > > actor. Both are > > > > classifiers. > > > > > > > > Tim > > > > > > > > > -----Original Message----- > > > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > > > Sent: Tuesday, June 28, 2005 11:37 AM > > > > > To: Tim Weilkiens; uml2-rtf@omg.org > > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > In which case should this connection between Actor and > > > > > UseCase not inherit from Relationship rather than Association > > > > > - it seems we need to have no Properties for either end. > > > > > It frees up use of the arrow to indicate the more common > > > > > semantic described rather than navigability. > > > > > However, though it might make more sense, I do have a concern > > > > > about forward compatibility if we take this approach. > > > > > > > > > > Pete > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > > CTO, Adaptive Inc. > > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > > BH1 1HL, UK > > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > > > Sent: Tuesday, June 28, 2005 5:49 AM > > > > > > To: uml2-rtf@omg.org > > > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > > > Joaquin, > > > > > > > > > > > > I agree if the semantic of an association allows the > > statement > > > > > > "'has' meaning those actors participate in that use case". > > > > > > > > > > > > I'm not sure about this. If instances of two classes can > > > > communicate > > > > > > there's not necessarily an association between > those classes. > > > > > > > > > > > > The semantics of a connector sounds more reasonable for > > > > > actor/use case > > > > > > relationships. However it doesn't fit into the use > case model. > > > > > > > > > > > > The composition relationship between actor and use case is > > > > > > allowed as well > > > > > > as aggregation. I think it shouldn't. > > > > > > Navigation is often interpreted as "Who starts the > > > > > > communication?". I don't think > > > > > > that's conform to the formal definition of navigation. > > > > > > However what does it mean to have > > > > > > navigation e.g. from an actor to an use case? > > > > > > > > > > > > Using the standard association between actor and use cases > > > > > > opens a lot of questions. > > > > > > To dash off a sketch I would define a subclass of > association > > > > > > that relates actor and use case > > > > > > which - in that case - still can be subclasses of > classifier. > > > > > > And we can omit composition, > > > > > > aggregation, and navigation or define a more appropriate > > > > > > semantic for them. That approach should > > > > > > also consider Jim's objection. > > > > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > > > > > Sent: Monday, June 27, 2005 7:17 PM > > > > > > > To: UML-RTF > > > > > > > Subject: actors and use cases Was: some issues > > > > > > > > > > > > > > I would prefer to introduce a specialized association > > > > > > > like the communication path in the deployment > package or a > > > > > > > complete new relationship. > > > > > > > > > > > > > > The relationship between an actor and an use case isn't > > > > > > > a structural thing. It looks strange to me that an > > actor owns > > > > > > > a property typed by an use case. > > > > > > > > > > > > > > > > > > > > > Extremely strange. > > > > > > > > > > > > > > If we consider the UML specification to be about a data > > > > > > > structure for modeling tools, then that there may well be > > > > > > > some good reason for an actor to have a property that is > > > > > a use case. > > > > > > > > > > > > > > But if we consider that one important intent of the UML > > > > > > > specification is to provide a conceptual model of > modeling, > > > > > > > then certainly: > > > > > > > > > > > > > > a use case has one or more actors ('has' > meaning those > > > > > > > actors participate in that use case) > > > > > > > a use case does not own those actors (the same > > actor can > > > > > > > participate in several use cases) > > > > > > > > > > > > > > an actor may participate in one or more use > > cases (or may > > > > > > > be an actor of a class or component) > > > > > > > an actor does not own use cases (else: which > > actor owns a > > > > > > > use case with more than one actor?) > > > > > > > > > > > > > > ('own' meaning is on the diamond end of a black > > > > diamond line) > > > > > > > > > > > > > > > > > > > > > [I'm prepared for contradiction. I'm confident we > > don't have > > > > > > > a shared understanding here.] > > > > > > > > > > > > > > > > > > > > > Cordially, Joaquin > > > > > > > > > > > > > > > > > > > > > [p.s. A couple of questions i asked, way back when, about > > > > > > > what has since become figure 401 of ptc/04-10-02: Can an > > > > > > > actor own use cases? Where do we find the traditional > > > > > > > relationship of actors to use cases?] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LID] > www.joaquin.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > winmail4.dat Subject: RE: actors and use cases Was: some issues Date: Thu, 30 Jun 2005 14:24:14 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues Thread-Index: AcV9kwT0YDBtSDtPRfOM5G+EZLFeqAAAunhw From: "Pete Rivett" To: , "Tim Weilkiens" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j5UIG5hh030352 > Regarding your second point, is there a requirement that the > spec allow a UML 2.1 model to be opened with a UML 2.0 tool? > I wouldn't think that would be expected, as I wouldn't expect > a UML 2.0 model to be openable in a UML 1.x tool. But a minor revision should be less disruptive than a major one. There is no hard-and-fast requirement even for a 2.1 tool to be able to open a 2.0 model. In the end it's up to tool vendors. But given that tools of different 2.x versions will need to co-exist and interchange, then I think we should make life as easy as possible for the vendors. So IMHO changes should fix an error in the specification or provide a significant benefit. In the end it's up to the RTF voters to decide on what to include - though the AB gets a final say . Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Chris Armstrong [mailto:chris.armstrong@aprocessgroup.com] > Sent: Thursday, June 30, 2005 5:45 PM > To: Pete Rivett; 'Tim Weilkiens' > Cc: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > Duh... Sorry, for some reason I was focusing on the UML 1.x > to UML 2.0 migration. I imagine there could also be issues > regarding UML 1.x to UML 2.1 migration in addition to UML 2.0 > to UML 2.1. > > Regarding your second point, is there a requirement that the > spec allow a UML 2.1 model to be opened with a UML 2.0 tool? > I wouldn't think that would be expected, as I wouldn't expect > a UML 2.0 model to be openable in a UML 1.x tool. > > Thanks, Chris ~ > > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Wednesday, June 29, 2005 5:29 PM > To: chris.armstrong@aprocessgroup.com; Tim Weilkiens > Cc: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > > > Regarding backwards compatibility, what are the real-world > > concerns and consequences about creating a new relationship? > > I understand that there might be technical details regarding > > migrating a UML 1.x model to UML 2.0 model, but it seems as > > if those would easily surmountable. > > It's UML 2.0 to UML 2.1 (the deliverable from the current > RTF) that we have to be concerned about. An RTF should > provide clarifications and fix errors, but minimize > unnecessary substantive changes. > > Real world concerns about using anew relationship are: > - loading a UML 2.0 use case model/diagram into a UML 2.1 > tool. The existing Associations will (I presume) still be > valid but will differ from how the 'real' Actor-UseCase > relationships are now represented. > - loading a UML 2.1 use case model/diagram into a UML 2.0 > tool. Using a new relationship would cause the import to fail > or the important Actor-UseCase relationship to be lost. > > Hope that helps > Pete > > Pete Rivett (mailto:pete.rivett@adaptive.com) > CTO, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Chris Armstrong [mailto:chris.armstrong@aprocessgroup.com] > > Sent: Wednesday, June 29, 2005 8:50 PM > > To: Pete Rivett; 'Tim Weilkiens' > > Cc: uml2-rtf@omg.org > > Subject: RE: actors and use cases Was: some issues > > > > Here's my take on this issue... Like others, as mentioned, we > > use the following convention regarding associations and > > navigability between actors and use cases: > > > > - Initiating actor (actor that starts use case and usually > > receives most, if not all, of the observable value): > > uni-directional association with arrow head pointing to use case > > - Receiving actor (actor that receive some observable value > > from use case, but doesn't start it): uni-directional > > association with arrow head pointing to actor > > - Supporting actor (actor that does not receive any > > particular value and also doesn't start use case, but needs > > to be there in order for the use case to complete): > > bi-directional association (with no arrow heads) > > > > In explaining this to practitioners, the arrow thing can be a > > little confusing as it inadvertently makes people think of > > flow. This then has the unfortunate consequence of then > > making some people think of data flow. It also compels many > > people to draw uni-directional associations between use cases > > to represent process flow. I've always wanted to explore some > > alternate notation for representing this. I don't have any > > particular inclinations on a solution, except that not using > > arrow heads would be nice. So, if we are exploring the > > possibility of creating a new type of relationship, perhaps > > some other adornment on this new relationship (as an > > alternative to navigability) might be possible? > > > > Regarding backwards compatibility, what are the real-world > > concerns and consequences about creating a new relationship? > > I understand that there might be technical details regarding > > migrating a UML 1.x model to UML 2.0 model, but it seems as > > if those would easily surmountable. > > > > On a related (new?) issue, we have often used realizations > > between actors to show how one actor sometimes behaves like > > another actor. This is in addition to occasionally using > > generalizations between actors as well. Is there any value in > > providing some examples of why and how someone might want to > > do this in the spec? > > > > Thanks, Chris ~ > > > > -----Original Message----- > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > Sent: Wednesday, June 29, 2005 7:04 AM > > To: Tim Weilkiens > > Cc: uml2-rtf@omg.org > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > > > > -----Original Message----- > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > Sent: Wednesday, June 29, 2005 8:39 AM > > > To: Pete Rivett > > > Cc: uml2-rtf@omg.org > > > Subject: RE: actors and use cases Was: some issues > > > > > > Pete, > > > > > > > My point was that, taking your line of thought further, I'm > > > > not sure the connection between Actor and UseCase would be an > > > > Association at all e.g. it could be a new metaclass > > > > ActorCommunication that inherits from Relationship without > > > > the baggage of Associations (e.g. 2 owned Properties). This > > > > is what would have compatibility issues. > > > > > > I agree. However Actor and UseCase are specialized > > > Classifiers therefore it is > > > still possible to define an association between them. Isn't > > > that sufficient to be > > > compatible? > > > > If a different element, such as ActorCommunication, is used > > to represent the commonly-used line between an actor and a > > use case on a use case diagram then that is an > > incompatibility. We may decide it's justified though I have > > not been convinced yet. Especially as it seems people are > > exploiting the presence of the Properties on the Association > > and attaching semantics to aggregation, multiplicity (the > > latter is somewhat fuzzily covered in the spec I just noticed) etc. > > > > > > > > > In this discussion we should also ensure that this > > > > Actor-UseCase connection may be sensibly traced through to > > > > implementations: especially if the Actor in question is a > > > > software component. In which case the communication at the > > > > Actor-UseCase level may trace to Ports and Connectors at the > > > > design level. > > > > > > That's an important requirement for the actor/use case > relationship. > > > Ports and connectors often relates to associations, but not > > > necessarily. > > > It's possible to have a connector between actor and use case typed > > > properties without having an association between them. > > > > What do you mean by "use case typed properties"? Can you give > > an example of how such a thing would be used in practice? > > > > > > Tim > > > > > > --- > > > Tim Weilkiens, E-Mail tim.weilkiens@oose.de > > > Instructor, Consultant, Coach > > > OMG Representative, INCOSE member > > > oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet > > > http://www.oose.de > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > > Sent: Tuesday, June 28, 2005 12:48 PM > > > > > To: Pete Rivett > > > > > Cc: uml2-rtf@omg.org > > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > I don't think that we have compatibility problems since it is > > > > > still possible > > > > > to use non-navigable associations between use case and > > > > actor. Both are > > > > > classifiers. > > > > > > > > > > Tim > > > > > > > > > > > -----Original Message----- > > > > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > > > > Sent: Tuesday, June 28, 2005 11:37 AM > > > > > > To: Tim Weilkiens; uml2-rtf@omg.org > > > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > > > In which case should this connection between Actor and > > > > > > UseCase not inherit from Relationship rather than > Association > > > > > > - it seems we need to have no Properties for either end. > > > > > > It frees up use of the arrow to indicate the more common > > > > > > semantic described rather than navigability. > > > > > > However, though it might make more sense, I do have > a concern > > > > > > about forward compatibility if we take this approach. > > > > > > > > > > > > Pete > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > > > CTO, Adaptive Inc. > > > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > > > BH1 1HL, UK > > > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > > > > Sent: Tuesday, June 28, 2005 5:49 AM > > > > > > > To: uml2-rtf@omg.org > > > > > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > > > > > > Joaquin, > > > > > > > > > > > > > > I agree if the semantic of an association allows the > > > statement > > > > > > > "'has' meaning those actors participate in that use case". > > > > > > > > > > > > > > I'm not sure about this. If instances of two classes can > > > > > communicate > > > > > > > there's not necessarily an association between > > those classes. > > > > > > > > > > > > > > The semantics of a connector sounds more reasonable for > > > > > > actor/use case > > > > > > > relationships. However it doesn't fit into the use > > case model. > > > > > > > > > > > > > > The composition relationship between actor and > use case is > > > > > > > allowed as well > > > > > > > as aggregation. I think it shouldn't. > > > > > > > Navigation is often interpreted as "Who starts the > > > > > > > communication?". I don't think > > > > > > > that's conform to the formal definition of navigation. > > > > > > > However what does it mean to have > > > > > > > navigation e.g. from an actor to an use case? > > > > > > > > > > > > > > Using the standard association between actor and > use cases > > > > > > > opens a lot of questions. > > > > > > > To dash off a sketch I would define a subclass of > > association > > > > > > > that relates actor and use case > > > > > > > which - in that case - still can be subclasses of > > classifier. > > > > > > > And we can omit composition, > > > > > > > aggregation, and navigation or define a more appropriate > > > > > > > semantic for them. That approach should > > > > > > > also consider Jim's objection. > > > > > > > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > > > > > > Sent: Monday, June 27, 2005 7:17 PM > > > > > > > > To: UML-RTF > > > > > > > > Subject: actors and use cases Was: some issues > > > > > > > > > > > > > > > > I would prefer to introduce a > specialized association > > > > > > > > like the communication path in the deployment > > package or a > > > > > > > > complete new relationship. > > > > > > > > > > > > > > > > The relationship between an actor and > an use case isn't > > > > > > > > a structural thing. It looks strange to me that an > > > actor owns > > > > > > > > a property typed by an use case. > > > > > > > > > > > > > > > > > > > > > > > > Extremely strange. > > > > > > > > > > > > > > > > If we consider the UML specification to be about a data > > > > > > > > structure for modeling tools, then that there > may well be > > > > > > > > some good reason for an actor to have a > property that is > > > > > > a use case. > > > > > > > > > > > > > > > > But if we consider that one important intent of the UML > > > > > > > > specification is to provide a conceptual model of > > modeling, > > > > > > > > then certainly: > > > > > > > > > > > > > > > > a use case has one or more actors ('has' > > meaning those > > > > > > > > actors participate in that use case) > > > > > > > > a use case does not own those actors (the same > > > actor can > > > > > > > > participate in several use cases) > > > > > > > > > > > > > > > > an actor may participate in one or more use > > > cases (or may > > > > > > > > be an actor of a class or component) > > > > > > > > an actor does not own use cases (else: which > > > actor owns a > > > > > > > > use case with more than one actor?) > > > > > > > > > > > > > > > > ('own' meaning is on the diamond end of a black > > > > > diamond line) > > > > > > > > > > > > > > > > > > > > > > > > [I'm prepared for contradiction. I'm confident we > > > don't have > > > > > > > > a shared understanding here.] > > > > > > > > > > > > > > > > > > > > > > > > Cordially, Joaquin > > > > > > > > > > > > > > > > > > > > > > > > [p.s. A couple of questions i asked, way back > when, about > > > > > > > > what has since become figure 401 of > ptc/04-10-02: Can an > > > > > > > > actor own use cases? Where do we find the traditional > > > > > > > > relationship of actors to use cases?] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LID] > > www.joaquin.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Tim Weilkiens" Cc: "Nerijus Jankevicius" , uml2-rtf@omg.org Subject: RE: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 6 Jul 2005 10:47:35 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/06/2005 10:47:37, Serialize complete at 07/06/2005 10:47:37 Dear use casers, I'm finally back in action and keen to contribute my views to this thread. I'll start with my feedback to the various postings in chronological order, fully realizing that this thread must have moved way beyond these initial discussions. > > My apologies, Nerijus, you are absolutely right. I did not > > notice that ownedMember was also derived. Perhaps the > > resolution is to make both Actor and UseCase a kind of Class? > > What kind of Properties do you think these two should have? > > What is the use case to justify these. > > I would prefer to introduce a specialized association like the > communication path > in the deployment package or a complete new relationship. > > The relationship between an actor and an use case isn't a structural > thing. It looks > strange to me that an actor owns a property typed by an use case. Remember that the ends of an association can be owned by the association and need not require the actor to have a use case-typed attribute. So, this argument does not look particularly compelling to me. Also, I would challenge the view that the relationship is not a structural thing. It most definitely is: interactions between an actor and the system involve communications -- which, in my view, requires structural things such as communication links. Do you have any better arguments for the specialized association? Bran To: Joaquin Miller Cc: UML-RTF Subject: Re: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 6 Jul 2005 11:05:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/06/2005 11:05:45, Serialize complete at 07/06/2005 11:05:45 > The relationship between an actor and an use case isn't a structural > thing. It looks strange to me that an actor owns a property typed by > an use case. > > Extremely strange. As noted earlier: I don't think it's strange at all. And, as explained, for those who do not like such things, it is not forced on them. Their actors do not have to own attributes pointing to use cases. However, there is some confusion here that I think needs to be clarified. Remember that the metamodel only describes relationships between M1 elements, which does not necessarily reflect M0 relationships. Thus, the fact that an m1 actor owns an attribute that points to a use case, does not at all mean that an M0 object that is a physical manifestation of an actor necessarily has to have that attribute. Actors, use cases, and the relationships between them are at a higher level of abstraction than code. One should not expect them to necessarily map 1-to-1 to run-time classes and links. > [p.s. A couple of questions i asked, way back when, about what has > since become figure 401 of ptc/04-10-02: Can an actor own use > cases? Where do we find the traditional relationship of actors to use cases?] I see no reason why it should not be possible for an actor to own use cases in specific cases. But, for the reasons cited by Joaquin, this is not a general model. I am not sure that we need one. I am not sure what is meant by "traditional relationship of actors to use cases". In this ignorance, my instinct is to say that this relationship is captured by the association between an actor and a use case. This is the way it always was. Bran To: "Tim Weilkiens" Cc: uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 6 Jul 2005 11:31:59 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/06/2005 11:32:00, Serialize complete at 07/06/2005 11:32:00 Tim, In reply to your copmments to Joaquin: > I agree if the semantic of an association allows the statement > "'has' meaning those actors participate in that use case". Agreed. > I'm not sure about this. If instances of two classes can communicate > there's not necessarily an association between those classes. This is actually a contentious point still in UML. At present, UML does support "implicit" associations, but a number of people have complained about this. > The semantics of a connector sounds more reasonable for actor/use case > relationships. However it doesn't fit into the use case model. I don't see how connector semantics fit into this at all. A connector is a rather concrete thing that represents a communication link between two concrete objects. A use case, OTOH, is an abstract object in the same sense that a collaboration is an abstract object (e.g., it does not have a concrete run-time identifier). (NB: The term "abstract" above, should not be taken in the technical sense that the metaclass is abstract.) Connecting an object that represents an instance of a class that realizes an actor to a use case does not make sense. > The composition relationship between actor and use case is allowed as well > as aggregation. I think it shouldn't. Disagree -- there may be cases where this is perfectly fine. > Navigation is often interpreted as "Who starts the communication?". That is a bad idea. > I don't think > that's conform to the formal definition of navigation. However what > does it mean to have > navigation e.g. from an actor to an use case? I think that both you and Nerijus are viewing use cases as something more concrete than was intended. > Using the standard association between actor and use cases opens a > lot of questions. Once the abstraction level of use cases is understood, I believe that all those questions go away. Bran To: "Pete Rivett" Cc: "Tim Weilkiens" , uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 6 Jul 2005 11:59:35 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/06/2005 11:59:36, Serialize complete at 07/06/2005 11:59:36 > My point was that, taking your line of thought further, I'm not sure > the connection between Actor and UseCase would be an Association at > all e.g. it could be a new metaclass ActorCommunication that > inherits from Relationship without the baggage of Associations (e.g. > 2 owned Properties). This is what would have compatibility issues. An association in UML can be used to represent a conceptual pairing of entities. This is a perfectly reasonable thing to do for actors and use cases. In fact, it is the more natural thing to do, since (most) use cases typically do not have M0 instances in the traditional sense (see my previous discussion on the abstract nature of use cases). It makes no sense to me to have a connector or any kind of communication link between a use case and an actor. The two are different kinds of entities altogether. Bran To: "Tim Weilkiens" Cc: "Pete Rivett" , uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 6 Jul 2005 12:02:18 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/06/2005 12:02:19, Serialize complete at 07/06/2005 12:02:19 Tim, I have to insist: > That's an important requirement for the actor/use case relationship. > Ports and connectors often relates to associations, but not necessarily. > It's possible to have a connector between actor and use case typed > properties without having an association between them. A connector, which represents a communication link between two (or more) M0 entities is absolutely the WRONG thing for representing the link between an actor and a use case (whose M0 manifestation is an abstraction). Bran To: Cc: "'Pete Rivett'" , "'Tim Weilkiens'" , uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 6 Jul 2005 12:07:11 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/06/2005 12:07:13, Serialize complete at 07/06/2005 12:07:13 Chris, In response to your comments: > Here's my take on this issue... Like others, as mentioned, we use the > following convention regarding associations and navigability between actors > and use cases: > > - Initiating actor (actor that starts use case and usually receives most, if > not all, of the observable value): uni-directional association with arrow > head pointing to use case > - Receiving actor (actor that receive some observable value from use case, > but doesn't start it): uni-directional association with arrow head pointing > to actor > - Supporting actor (actor that does not receive any particular value and > also doesn't start use case, but needs to be there in order for the use case > to complete): bi-directional association (with no arrow heads) Although such conventions have been used in the past, it should be clear to the folks here, I hope, that this is a semantically incorrect use of the navigation notation. If this is really necessary, then some other notation should be used for this purpose. > In explaining this to practitioners, the arrow thing can be a little > confusing as it inadvertently makes people think of flow. This then has the > unfortunate consequence of then making some people think of data flow. It > also compels many people to draw uni-directional associations between use > cases to represent process flow. I've always wanted to explore some > alternate notation for representing this. I don't have any particular > inclinations on a solution, except that not using arrow heads would be nice. > So, if we are exploring the possibility of creating a new type of > relationship, perhaps some other adornment on this new relationship (as an > alternative to navigability) might be possible? Agree about investigating an alternative notation. However, disagree on a new type of relationship. Bran Subject: RE: actors and use cases Was: some issues Date: Thu, 7 Jul 2005 10:11:28 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues thread-index: AcWCRJAU+B0IqjMcREmrgMMbNjQ9NAAhPpCA From: "Tim Weilkiens" To: "Branislav Selic" Cc: "Pete Rivett" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j678NChh009295 Bran, I agree that an actor is more abstract than e.g. a class. It's new to me that an actor has no M0 manifestation. The use case chapter mentions actor instances. Is it an outcome of this email thread that we should add some clarifying statements to the use case chapter, e.g. that it is not possible to use navigation? Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Wednesday, July 06, 2005 6:02 PM > To: Tim Weilkiens > Cc: Pete Rivett; uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > > Tim, > > I have to insist: > > > That's an important requirement for the actor/use case relationship. > > Ports and connectors often relates to associations, but not > necessarily. > > It's possible to have a connector between actor and use case typed > > properties without having an association between them. > > A connector, which represents a communication link between > two (or more) M0 entities is absolutely the WRONG thing for > representing the link between an actor and a use case (whose > M0 manifestation is an abstraction). > > Bran > > To: "Tim Weilkiens" Cc: "Pete Rivett" , uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 7 Jul 2005 10:15:46 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/07/2005 10:15:49, Serialize complete at 07/07/2005 10:15:49 Tim, I must have expressed myself poorly: I was trying to say that it is USE CASES that do not have a concrete M0 incanrantion (it is reasonable to expect some actors to have corresponding M0 instances). When we talk about use case "instances" we really mean that as an abstraction for the potentially complex combination of objects and links that realize the system and the actors involved, and the execution of the various interactions that effect the use case. As an analogy, think of the notion of a telephone call. In most cases, there is no actual telephone call object, yet we talk about the call as if it was reified. I think this whole thing has drifted away from Nerijus original issue which was that neither actors not use cases can own properties. I see two obvious solutions (there may be more): 1. Make both of them specializations of Class 2. Provide explicit compositions from Actor and UseCase to Property -- the way that it is done in Figure 12 for Class. Cheers, Bran "Tim Weilkiens" wrote on 07/07/2005 04:11:28 AM: > Bran, > > I agree that an actor is more abstract than e.g. a class. It's new to me > that an > actor has no M0 manifestation. The use case chapter mentions actor > instances. > > Is it an outcome of this email thread that we should add some clarifying > statements > to the use case chapter, e.g. that it is not possible to use navigation? > > Tim > > > -----Original Message----- > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > Sent: Wednesday, July 06, 2005 6:02 PM > > To: Tim Weilkiens > > Cc: Pete Rivett; uml2-rtf@omg.org > > Subject: RE: actors and use cases Was: some issues > > > > > > Tim, > > > > I have to insist: > > > > > That's an important requirement for the actor/use case relationship. > > > Ports and connectors often relates to associations, but not > > necessarily. > > > It's possible to have a connector between actor and use case typed > > > properties without having an association between them. > > > > A connector, which represents a communication link between > > two (or more) M0 entities is absolutely the WRONG thing for > > representing the link between an actor and a use case (whose > > M0 manifestation is an abstraction). > > > > Bran > > > > Subject: RE: actors and use cases Was: some issues Date: Thu, 7 Jul 2005 16:32:03 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues thread-index: AcWC/ugsFI6dRQF+TZOXyEd3XZ6gdgAARaCg From: "Tim Weilkiens" To: "Branislav Selic" Cc: "Pete Rivett" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j67Ehjhh013104 Bran, ok, now it is much clearer and I can follow your points. Back to Nerijus issue: Based on the whole email discussion - in particular Bran's statements - I asked myself if it is really necessary that actor or use cases own properties? It's possible to define an association between them that specifies the communication link. Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, July 07, 2005 4:16 PM > To: Tim Weilkiens > Cc: Pete Rivett; uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > > Tim, > > I must have expressed myself poorly: I was trying to say that > it is USE CASES that do not have a concrete M0 incanrantion > (it is reasonable to expect some actors to have corresponding > M0 instances). When we talk about use case "instances" we > really mean that as an abstraction for the potentially > complex combination of objects and links that realize the > system and the actors involved, and the execution of the > various interactions that effect the use case. > > As an analogy, think of the notion of a telephone call. In > most cases, there is no actual telephone call object, yet we > talk about the call as if it was reified. > > I think this whole thing has drifted away from Nerijus > original issue which was that neither actors not use cases > can own properties. I see two obvious solutions (there may be more): > > 1. Make both of them specializations of Class > > 2. Provide explicit compositions from Actor and UseCase to > Property -- the way that it is done in Figure 12 for Class. > > Cheers, > Bran > > "Tim Weilkiens" wrote on 07/07/2005 > 04:11:28 AM: > > > Bran, > > > > I agree that an actor is more abstract than e.g. a class. > It's new to me > > that an > > actor has no M0 manifestation. The use case chapter mentions actor > > instances. > > > > Is it an outcome of this email thread that we should add > some clarifying > > statements > > to the use case chapter, e.g. that it is not possible to > use navigation? > > > > Tim > > > > > -----Original Message----- > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > Sent: Wednesday, July 06, 2005 6:02 PM > > > To: Tim Weilkiens > > > Cc: Pete Rivett; uml2-rtf@omg.org > > > Subject: RE: actors and use cases Was: some issues > > > > > > > > > Tim, > > > > > > I have to insist: > > > > > > > That's an important requirement for the actor/use case > relationship. > > > > Ports and connectors often relates to associations, but not > > > necessarily. > > > > It's possible to have a connector between actor and use > case typed > > > > properties without having an association between them. > > > > > > A connector, which represents a communication link between > > > two (or more) M0 entities is absolutely the WRONG thing for > > > representing the link between an actor and a use case (whose > > > M0 manifestation is an abstraction). > > > > > > Bran > > > > > > > > Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 09:10:15 -0700 To: "UML 2.0 WG" From: Joaquin Miller Subject: RE: actors and use cases Was: some issues This message intends only to add comments and a question, not to disagree with anything. I agree that an actor is more abstract than e.g. a class. If UML had a first class concept of role, then the specification of actor would be precise. (Instead we have an explicit statement that we use 'role' with different meanings in different parts of the spec and we have (absolutely no offense whatsoever) vague statements about 'more abstract.' (it is reasonable to expect some actors to have corresponding M0 instances). If role were a first class concept, then we would have objects fulfilling an actor role. It's new to me that an actor has no M0 manifestation. The use case chapter mentions actor instances. it is USE CASES that do not have a concrete M0 incarantion Though, in classic Jacobson et al. there can be objects that correspond exactly to use cases. Until we have slogged clear out of the metamuddle, i feel it is best to not devote much energy to considerations like these. A connector, which represents a communication link between two (or more) M0 entities is absolutely the WRONG thing for representing the link between an actor and a use case (whose M0 manifestation is an abstraction). Is this a loose or precise use of 'link'? "a communication path is an association...through which they are able to exchange signals and messages." This sounds closer to what I think of when considering actor/use case relationships. There is also the possibility of a line that means no more than: This actor plays a part* in this use case, cleanly separating this essential concept of the use case theory from all the other considerations, such as implementation. Cordially, Joaquin * (pun intended--just jerking some folks' chain) www.joaquin.net To: Cc: "'Pete Rivett'" , "'Tim Weilkiens'" , uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 7 Jul 2005 13:44:27 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/07/2005 13:44:33, Serialize complete at 07/07/2005 13:44:34, Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/07/2005 13:44:34 "Chris Armstrong" wrote on 07/07/2005 10:46:56 AM: > I'd argue that for most practitioners, they really don't care about the > precise semantics of the UML spec in general. I don't know if we should go > as far as not allowing navigability on relationships between actors and use > cases. I did not say not to use navigability. What I said was not to use it to represent a completely different concept. > Despite that, I agree that navigability doesn't make very much sense > when interpreted literally, which is why I suggested that we explore some > alternate notation. Note that the concepts that you are trying to capture here (e.g., who initiates a use case), do not have an underlying metamodel manifestation. So, this is more than a notational issue. However, in my view, it is really not necessary to do this, since these aspects can be specified much more easily and precisely by defining one or more sequence or activity diagram that realize the use case. > Every time I start thinking about this actor/use case relationship issue and > read the spec about assocations, it seems that associations have > considerable semantics and notation that I struggle applying to actors and > use cases. You are probably right that associations may be an overloaded concept. However, they seem to be much more appropriate for what you are trying to do here than connectors or communication paths (precisely because an association does not necessarily imply communications -- merely some kind of relationships between the associated things). As I noted earlier, it makes very little sense to me to "communicate" with a use case, just like one does not communicate with a telephone call. The way I see it, the communication path you are trying to model exists between an actor and the system that realizes the use case, not betwen the actor and the use case. > I think this is why we are exploring a different type > relationship (which doesn't have to be called a "connector" as that does > have specific semantics at the M0 level). I believe someone suggested > CommunicationPath as an alternative (found in Deployments), which is a > subclass of Association, and the definition seems to meet my perspective on > actor/use case relationships -- "a communication path is an > association...through which they are able to exchange signals and messages." Can you tell me what it means to talk to a use case? Which entity is communicating with which other entity? > This sounds closer to what I think of when considering actor/use case > relationships. However, as a subclass of Association, CommunicationPath > would bring with it all the additional semantics of associations, which > again, seem out of place in the context of actors and use cases. Perhaps you are looking for some kind of specialization of Relationship (an abstract UML metaclass)? > Regarding the M1/M0 issues, as an association suggests instances of links > between typed instances, this would imply that there would be links between > actor and use case instances. Sure, there is no argument with that. However, a link may simply represent a mathematical pairing . It does not have to imply a run-time entity at all. It is my contention that this is the semantically correct way to interpret the relationship between an actor and a use case. The communication link that is used to realize the use case actually exists between the system and the actor (I think I've said this before > It is also my take that use cases (which are > at the M1 level) do have concrete M0 manifestations -- i.e. test cases. As a > use case is used to group related usage scenarios in some meaningful > context, it is abstract in the sense that it describes an infinite number of > scenarios and traversals of various flows within the use case. A test case > is a specification that describes traversing a specific set of flows, under > specific conditions, with specific expected results, which to me sounds like > an M0 thing (especially as a single use case should have many test cases -- > i.e., many instances). I really don't understand what you mean here. Can I send a message to a test case? In believe that I can send a message to something that executes a test case, e.g., a test harness, but not to the test case itself. A test case, in my understanding, is a specification (i.e., an M1 entity), that can be realized many times by one or more M0 objects. If we use the terminology that we introduced in UML 2 (see section 6.4), I would say that a test case/use case has an M0 "occurrence" but not an M0 instance. I can easily explain how to communicate with an instance, but cannot imagine how to communicate with an occurrence (except, perhaps, by communicating with an instance involved in producing the occurrence). Cheers...Bran To: Joaquin Miller Cc: "UML 2.0 WG" Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 7 Jul 2005 13:59:58 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/07/2005 14:00:03, Serialize complete at 07/07/2005 14:00:03 In Joaquin's words: This message intends only to add comments and questions, not to disagree with anything Joaquin Miller wrote on 07/07/2005 12:10:15 PM: > This message intends only to add comments and a question, not to > disagree with anything. > I agree that an actor is more abstract than e.g. a class. > > If UML had a first class concept of role, then the specification of > actor would be precise. (Instead we have an explicit statement that > we use 'role' with different meanings in different parts of the spec > and we have (absolutely no offense whatsoever) vague statements > about 'more abstract.' I am under the impression that role IS defined as a first-class concept in the context of collaborations ("collaborationRole" to be precise -- se figure 99 on page 173). If you do not view this as a first-class definition, what class level would you put it in? > (it is reasonable to expect some actors to have corresponding M0 instances). > > If role were a first class concept, then we would have objects > fulfilling an actor role. A long time ago, in the U2P, we did try to redefine actors as roles, but the God of Use Cases intervened with such ferocity that everyone agreed to leave the Use case tablets untouched. > It's new to me that an actor has no M0 manifestation. The use case > chapter mentions actor > instances. > > it is USE CASES that do not have a concrete M0 incarantion > > Though, in classic Jacobson et al. there can be objects that > correspond exactly to use cases. You are now invoking the aforementioned God of Use Cases. However, whenever I went to that source for an explanation of this mystery, I got Delphic replies that I could not fathom with my limited intelligence. Perhaps you can explain them to me, Joaquin? What does a run-time use case object looks like? Does it occupy real memory? Is it addressable such that I can send messages to it? How many software systems in the world do you know that implement such objects? > Until we have slogged clear out of the metamuddle, i feel it is best > to not devote much energy to considerations like these. There are numerous metamuddles in UML, but I do not believe that this is one. > A connector, which represents a communication link between two (or > more) M0 entities is absolutely the WRONG thing for representing the > link between an actor and a use case (whose M0 manifestation is an > abstraction). > > Is this a loose or precise use of 'link'? Precise. Link as a mathematical pair. > "a communication path is an association...through which they are > able to exchange signals and messages." This sounds closer to what I > think of when considering actor/use case relationships. > > There is also the possibility of a line that means no more than: > This actor plays a part* in this use case, cleanly separating this > essential concept of the use case theory from all the other > considerations, such as implementation. ...and I believe that this is what I am arguing for when I say that this link is merely a pairing, that is a relationship. This is what associations are for (among other things). > * (pun intended--just jerking some folks' chain) Consder me jerked (or, perhaps, a jerk -- I am no longer sure). Cheers...Bran From: "Ed Seidewitz" To: Subject: RE: actors and use cases Was: some issues Date: Thu, 7 Jul 2005 14:28:15 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWDG6Sr7x6nNtFsSYmf9E0kA+9QcQAArBSw X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail4.opentransfer.com X-Spam-Status: No, hits=0.1 required=12.0 tests=HTML_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.64 X-Spam-Level: I have been staying out of this conversation, partly just to see where it is going (and partly because my OMG time has been going elsewhere lately!). But, as a long time and extensive use case modeler, I am having real trouble seeing what the problem is here. Maybe it is just a matter of one's perspective on use case modeling. Here are some comments from my perspective. The ideas of "classifier" and "instance" don't necessarily mean that the "instance" is a physical or software object, nor is "M0" necessarily "run time" in any software sense. A use case is a classifier because it defines a class of things. It so happens that, in this case, those "things" are, as Bran says, "abstract". In instance of a use case is, in fact, a behavior scenario involving the interaction of the system being model with actors in its environment in a way that is consistent with the specification given in the use case. There may be many such scenarios that are consistent with the use case, and the set of all such scenarios is the extension of the use case as a classifier. These scenarios are "M0" in the sense that they are the "real world" behaviors that we are trying to specify through our M1 use case model. Note that a collaboration as a use case realization can be considered an M1 descriptive model (as opposed to specification) of such an M0 scenario, in the same way that an M1 instance specification is a model of an M0 "real world" object. An association is a declaration that there is (or may be) some relationship between between instances of the associated classifiers. The key semantic concept of an association is this declaration of linkage between instances, as opposed to just relating the classifiers. When an actor is associated with a use case, that means that an instance of the actor has (or may have) a link with an instance of the use case -- that is, a behavioral scenario as specified by the use case. The semantics of such a link is simply that the actor instance participates in the behavioral scenario in a way specified by the use case. To me, at least, navigability is a declaration that instances of the classifier at one end of the association "know" when they are linked to an instance at the other end, but not necessarily vice versa. This is useful when one wants to indicate that one of the classifiers in the association has an intrinsic dependency on the other, via the association, but not vice versa. Now, when an actor is associated with a use case, it is a common convention to assume that a "primary" actor (that is, one using the system whose behavior is being specified) needs to "know about" the system and its possible functions in order to initiate a particular function, and one models this by indicating navigability from the actor to the use case. Conversely, it is a common convention to assume that a purely "secondary" actor (that is, one that is used by the system whose behavior is being specified) should not need to know ahead of time that the system is going to use it, and one models this by indicating navigability from the use case to the actor. Note that these are only conventions, but I (and many others) find them useful in many (but not necessarily all) cases. Note also that, in UML 2.0 as finalized as in UML 1, I can declare navigability without requiring that the actor or the use case own any property for the association, so there is no problem there. Bottom line, I don't see that there is any need to change or further complicate the metamodel in this area. -- Ed Date: Thu, 07 Jul 2005 14:02:43 -0500 From: "Kevin C. Stanley" To: Branislav Selic Cc: "UML 2.0 WG" Subject: RE: actors and use cases Was: some issues User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 130.76.96.19 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ociweb.com Quoting Branislav Selic : > > It's new to me that an actor has no M0 manifestation. The use case > > chapter mentions actor > > instances. > > > > it is USE CASES that do not have a concrete M0 incarantion > > > > Though, in classic Jacobson et al. there can be objects that > > correspond exactly to use cases. > > You are now invoking the aforementioned God of Use Cases. However, > whenever I went to that source for an explanation of this mystery, I got > Delphic replies that I could not fathom with my limited intelligence. > Perhaps you can explain them to me, Joaquin? What does a run-time use case > object looks like? Does it occupy real memory? Is it addressable such that > I can send messages to it? How many software systems in the world do you > know that implement such objects? > Wouldn't an instance of a use case (M0) be a scenario involving specific actor instances interacting with a specific instance of the system under consideration? A use case instance could not be something that occupied real memory because a use case is not an abstraction of a system, but is instead an abstraction of the interactions between actors and a system. From: "Kevin C. Stanley" To: "'robert france'" Cc: Subject: RE: actors and use cases Was: some issues Date: Thu, 7 Jul 2005 20:56:11 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWDM7hj405ETY24SXSrKGTetgGRjAAJ3V2Q X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ociweb.com X-Spam-Status: No, hits=0.2 tagged_above=0.0 required=2.0 tests=AWL, BAYES_00, RCVD_IN_SORBS_DUL X-Spam-Level: > -----Original Message----- > From: robert france [mailto:france@CS.ColoState.EDU] > > >Wouldn't an instance of a use case (M0) be a scenario involving > >specific actor instances interacting with a specific instance of the > >system under consideration? A use case instance could not > be something > >that occupied real memory because a use case is not an > abstraction of a > >system, but is instead an abstraction of the interactions > between actors and a system. > > This meshes with my understanding of use case instances. Is > this not the interpretation supported by the standard? > One point of clarification: what is a "specific actor > instance"? My view is that an actor "instance" is an entity > (object, thing, whatever) that plays the role represented by > the actor. In this sense, the notion of an actor as an > instantiable classifier does not mesh with the notion of an > actor as a role (you do not instantiate entities that play a > role from a role). ... then again I may be confused ... You are correct. An actor is a role. In the UML metamodel an Actor is a Classifier. An Actor instance could be any object that can take on the role of the Actor, but an Actor would not be instantiable. Regards, Kevin Subject: RE: actors and use cases Was: some issues Date: Fri, 8 Jul 2005 09:39:11 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: actors and use cases Was: some issues thread-index: AcWDG6Sr7x6nNtFsSYmf9E0kA+9QcQAArBSwABw9CsA= From: "Tim Weilkiens" To: "Ed Seidewitz" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j687p0hh023597 Ed, I couldn't follow your point here: > Note also that, in UML 2.0 as finalized as in UML 1, I can declare > navigability without requiring that the actor or the use case > own any property for the association, so there is no problem there. Navigation is the notation for property ownership. You can't declare navigability without requiring that actors or use cases own properties. I would propose to not use navigability in use case diagrams. As already mentioned in this email thread navigation is often interpreted as data flow. I know this problem from many projects and my advice is always to avoid navigability if ever possible. In this case I think we have to change nothing in the specification. However if we allow navigation we must change the specification (Nerijus issue). In addition it is very important to specify the semantics of actor/use case navigation. There are so many interpretations out there....... Tim > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] > Sent: Thursday, July 07, 2005 8:28 PM > To: uml2-rtf@omg.org > Subject: RE: actors and use cases Was: some issues > > I have been staying out of this conversation, partly just to > see where it is going (and partly because my OMG time has > been going elsewhere lately!). But, as a long time and > extensive use case modeler, I am having real trouble seeing > what the problem is here. Maybe it is just a matter of one's > perspective on use case modeling. Here are some comments from > my perspective. > > * The ideas of "classifier" and "instance" don't > necessarily mean that the "instance" is a physical or > software object, nor is "M0" necessarily "run time" in any > software sense. A use case is a classifier because it defines > a class of things. It so happens that, in this case, those > "things" are, as Bran says, "abstract". In instance of a use > case is, in fact, a behavior scenario involving the > interaction of the system being model with actors in its > environment in a way that is consistent with the > specification given in the use case. There may be many such > scenarios that are consistent with the use case, and the set > of all such scenarios is the extension of the use case as a > classifier. These scenarios are "M0" in the sense that they > are the "real world" behaviors that we are trying to specify > through our M1 use case model. Note that a collaboration as a > use case realization can be considered an M1 descriptive > model (as opposed to specification) of such an M0 scenario, > in the same way that an M1 instance specification is a model > of an M0 "real world" object. > * An association is a declaration that there is (or may > be) some relationship between between instances of the > associated classifiers. The key semantic concept of an > association is this declaration of linkage between instances, > as opposed to just relating the classifiers. When an actor is > associated with a use case, that means that an instance of > the actor has (or may have) a link with an instance of the > use case -- that is, a behavioral scenario as specified by > the use case. The semantics of such a link is simply that the > actor instance participates in the behavioral scenario in a > way specified by the use case. > * To me, at least, navigability is a declaration that > instances of the classifier at one end of the association > "know" when they are linked to an instance at the other end, > but not necessarily vice versa. This is useful when one wants > to indicate that one of the classifiers in the association > has an intrinsic dependency on the other, via the > association, but not vice versa. Now, when an actor is > associated with a use case, it is a common convention to > assume that a "primary" actor (that is, one using the system > whose behavior is being specified) needs to "know about" the > system and its possible functions in order to initiate a > particular function, and one models this by indicating > navigability from the actor to the use case. Conversely, it > is a common convention to assume that a purely "secondary" > actor (that is, one that is used by the system whose behavior > is being specified) should not need to know ahead of time > that the system is going to use it, and one models this by > indicating navigability from the use case to the actor. Note > that these are only conventions, but I (and many others) find > them useful in many (but not necessarily all) cases. Note > also that, in UML 2.0 as finalized as in UML 1, I can declare > navigability without requiring that the actor or the use case > own any property for the association, so there is no problem there. > > Bottom line, I don't see that there is any need to change or > further complicate the metamodel in this area. > > -- Ed > To: robert france Cc: stanley_k@ociweb.com, uml2-wg@omg.org Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 8 Jul 2005 08:22:30 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/08/2005 08:22:32, Serialize complete at 07/08/2005 08:22:32 Robert, your understanding seems to be the same as mine and the one that is supported in the standard. One slight correction however: in UML 2 we have made the decision to distinguish the terms "instance" and "occurrence". The former refers to structural things and the latter to dynamic/behavioral things; i.e., things that transpire in time (see section 6.4.2 of the spec). These are two fundamentally different notions and confusion can result when the difference is ignored -- such as trying to connect a use case occurrence to an actor instance using a communications link. I think I have said enough on this topic and will say no more. Bran robert france 07/07/2005 04:35 PM Please respond to robert france To Branislav Selic/Ottawa/IBM@IBMCA, stanley_k@ociweb.com cc uml2-wg@omg.org Subject RE: actors and use cases Was: some issues >Wouldn't an instance of a use case (M0) be a scenario involving specific actor >instances interacting with a specific instance of the system under >consideration? A use case instance could not be something that occupied real >memory because a use case is not an abstraction of a system, but is instead an >abstraction of the interactions between actors and a system. This meshes with my understanding of use case instances. Is this not the interpretation supported by the standard? One point of clarification: what is a "specific actor instance"? My view is that an actor "instance" is an entity (object, thing, whatever) that plays the role represented by the actor. In this sense, the notion of an actor as an instantiable classifier does not mesh with the notion of an actor as a role (you do not instantiate entities that play a role from a role). ... then again I may be confused ... Robert ==================================================================== Robert B. France, Professor | Tel: 970-491-6356 Computer Science Department | Fax: 970-491-2466 Colorado State University | Email: france@cs.colostate.edu Fort Collins, CO 80523 | www.cs.colostate.edu/~france/ Do not miss MoDELS/UML 2005 http://www.modelsconference.org 8th International Conference on Model Driven Engineering Languages and Systems (formerly the UML series of conferences) To: "Tim Weilkiens" Cc: "Ed Seidewitz" , uml2-rtf@omg.org Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 8 Jul 2005 08:37:42 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/08/2005 08:37:45, Serialize complete at 07/08/2005 08:37:45 Tim, I know I said I would clam up on this topic, but I have to correct you on the following point: > Navigation is the notation for property ownership. You can't declare > navigability without requiring that actors or use cases own properties. Not true -- as of late last year. In the FTF we decided to separate the two concepts in order to better support the modeling of database systems. So, in principle, it is possible to separate the two. However, there is a hitch: we do not yet have a notation that allows us to denote that an association end is owned by the association rather than the classifiers at the ends. In the UML 2 spec, we finessed this by saying that we use the convention that navigability also implies ownership. See figure 12 on page 29 and, in particular, Association::navigableOwnedEnd for details. Cheers, Bran To: uml2-rtf@omg.org Subject: Fw: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 12 Jul 2005 10:09:50 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/12/2005 10:09:50, Serialize complete at 07/12/2005 10:09:50 Here is Trygve Reenskaug's input to the discussion on use case instances. He is unable to post to the RTF list for soem reason so I am forwarding it on his behalf. Bran ----- Forwarded by Branislav Selic/Ottawa/IBM on 07/12/2005 10:08 AM ----- Trygve Reenskaug 07/12/2005 08:40 AM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: actors and use cases Was: some issues At 22:35 07.07.2005, Robert wrote: >Wouldn't an instance of a use case (M0) be a scenario involving specific actor >instances interacting with a specific instance of the system under >consideration? A use case instance could not be something that occupied real >memory because a use case is not an abstraction of a system, but is instead an >abstraction of the interactions between actors and a system. This meshes with my understanding of use case instances. Is this not the interpretation supported by the standard? One point of clarification: what is a "specific actor instance"? My view is that an actor "instance" is an entity (object, thing, whatever) that plays the role represented by the actor. In this sense, the notion of an actor as an instantiable classifier does not mesh with the notion of an actor as a role (you do not instantiate entities that play a role from a role). ... then again I may be confused ... Robert This view conforms very nicely with BabyUML, a stored program object computer I use for experimenting with high level programming constructs. In BabyUML, a role is a query on the conceptual model (class diagram) as follows: THE B-COMPONENT. - An instance of a component encapsulates a number of objects that collaborate to realize the operations of its provided interfaces. - The component code is organized on three levels: Interaction, conceptual schema, and internals. THE B-CONCEPTUAL SCHEMA - The set of all well-formed component object structures is declared in a conceptual schema expressed e.g., as a UML class diagram or in the ODMG specification language. THE B-INTERACTION - Each provided operation is coded imperatively as an interaction between the roles of a collaboration expressed as e.g., UML collaboration/interaction diagrams. - There is a one-to-one correspondence between interaction time lines and collaboration roles. - The objects playing a particular role can be instances of unrelated classes. - A role can be played by many objects and an object can play many roles. - The collaboration is an external schema where each role is declared as a query on the conceptual schema. It is coded in e.g., the ODMG query language or a variant of OCL. - The role(s) played by an object can change over time. The external schema is, therefore, dynamic. (The external schema lives on the stack, so it is tied to an interaction occurence.) THE B-INTERNALS - The internal schema is an actual implementation of the conceptual schema. While default methods may be defined on the interaction level, variants and support methods are coded here. Cheers --Trygve -- Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway To: uml2-wg@omg.org Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 13 Jul 2005 11:33:42 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 07/13/2005 09:33:43, Serialize complete at 07/13/2005 09:33:43 My understanding is that use cases are a specification of the (requirements of the) interaction between a system and the interested stakeholders outside the system boundary. As a specification, it is not instantiatable, but is rather realized in some way. Realization of use cases and actors is formally defined in UML2, but the actual details of how a realizing classifier realizes a use case is not specified. As a result, it would seem to me that use cases are not executable but rather their realizations are. An execution of a realization could be captured as an interaction which could represent a particular scenario. One can then verify that the realization meets the use case requirements by comparing the scenario with the use case to see if they match. Due to the nature of use cases, the matching rules would be informal and could not be machine verified. robert france wrote on 07/07/2005 04:35:39 PM: > > >Wouldn't an instance of a use case (M0) be a scenario involving > specific actor > >instances interacting with a specific instance of the system under > >consideration? A use case instance could not be something that occupied real > >memory because a use case is not an abstraction of a system, but isinstead an > >abstraction of the interactions between actors and a system. > > This meshes with my understanding of use case instances. Is this not > the interpretation supported by the standard? > One point of clarification: what is a "specific actor instance"? My > view is that an actor "instance" is an entity (object, thing, whatever) that > plays the role represented by the actor. In this sense, the notion > of an actor as an instantiable classifier does not mesh with the notion of > an actor as a role (you do not instantiate > entities that play a role from a role). ... then again I may be confused ... > > Robert > > ==================================================================== > Robert B. France, Professor | Tel: 970-491-6356 > Computer Science Department | Fax: 970-491-2466 > Colorado State University | Email: france@cs.colostate.edu > Fort Collins, CO 80523 | www.cs.colostate.edu/~france/ > > Do not miss MoDELS/UML 2005 > http://www.modelsconference.org > 8th International Conference on Model Driven Engineering Languages and > Systems > (formerly the UML series of conferences) > Date: Wed, 13 Jul 2005 12:10:01 -0400 From: "Chonoles, Michael J" Subject: RE: actors and use cases Was: some issues To: uml2-wg@omg.org Thread-Topic: actors and use cases Was: some issues Thread-Index: AcWHwMBK2jyvX63VTRuMErbwphJi3AABIKuA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 13 Jul 2005 16:10:01.0850 (UTC) FILETIME=[52DDC5A0:01C587C5] Perhaps I.m being naïve, but considering a scenario as an instance of a use case and an instance of an actor as the specific entity playing the role of the actor in that scenario has a sort of practical simplicity. It also has the advantage of being consistent with most UML 1.x interpretations. There is an intuitive feel for the interpretation that a scenario or story is an instance of the Use Case. Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies mjchonoles Skype -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, July 13, 2005 11:34 AM To: uml2-wg@omg.org Subject: RE: actors and use cases Was: some issues My understanding is that use cases are a specification of the (requirements of the) interaction between a system and the interested stakeholders outside the system boundary. As a specification, it is not instantiatable, but is rather realized in some way. Realization of use cases and actors is formally defined in UML2, but the actual details of how a realizing classifier realizes a use case is not specified. As a result, it would seem to me that use cases are not executable but rather their realizations are. An execution of a realization could be captured as an interaction which could represent a particular scenario. One can then verify that the realization meets the use case requirements by comparing the scenario with the use case to see if they match. Due to the nature of use cases, the matching rules would be informal and could not be machine verified. robert france wrote on 07/07/2005 04:35:39 PM: > > >Wouldn't an instance of a use case (M0) be a scenario involving > specific actor > >instances interacting with a specific instance of the system under > >consideration? A use case instance could not be something that occupied real > >memory because a use case is not an abstraction of a system, but isinstead an > >abstraction of the interactions between actors and a system. > > This meshes with my understanding of use case instances. Is this not > the interpretation supported by the standard? > One point of clarification: what is a "specific actor instance"? My > view is that an actor "instance" is an entity (object, thing, whatever) that > plays the role represented by the actor. In this sense, the notion > of an actor as an instantiable classifier does not mesh with the notion of > an actor as a role (you do not instantiate > entities that play a role from a role). ... then again I may be confused ... > > Robert > > ==================================================================== > Robert B. France, Professor | Tel: 970-491-6356 > Computer Science Department | Fax: 970-491-2466 > Colorado State University | Email: france@cs.colostate.edu > Fort Collins, CO 80523 | www.cs.colostate.edu/~france/ > > Do not miss MoDELS/UML 2005 > http://www.modelsconference.org > 8th International Conference on Model Driven Engineering Languages and > Systems > (formerly the UML series of conferences) > Reply-To: To: uml2-wg@omg.org Sensitivity: Subject: RE: actors and use cases Was: some issues X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 13 Jul 2005 16:24:59 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 07/13/2005 14:25:02, Serialize complete at 07/13/2005 14:25:02 Michael, Maybe, but this may be making too big a leap. Interactions can be used to 1) discover use cases by describing observed or anticipated scenarios, and 2) to validate realizations of use cases. This provides a way of thinking about scenarios and their relationship to use cases from two directions, discovery and realization validation. However, the realization is a mediator between the use case requirements and something that executed and met those requirements. "Chonoles, Michael J" 07/13/2005 12:08 PM To Jim Amsden/Raleigh/IBM@IBMUS cc Subject RE: actors and use cases Was: some issues Perhaps I.m being naïve, but considering a scenario as an instance of a use case and an instance of an actor as the specific entity playing the role of the actor in that scenario has a sort of practical simplicity. It also has the advantage of being consistent with most UML 1.x interpretations. There is an intuitive feel for the interpretation that a scenario or story is an instance of the Use Case. Michael Jesse Chonoles Principal Member of Engineer Staff Enterprise Architecture Lockheed Martin Maritime Systems & Sensors (MS2) Lockheed Martin IS&S King of Prussia, PA michael.j.chonoles@lmco.com Co-author UML 2 For Dummies mjchonoles Skype -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, July 13, 2005 11:34 AM To: uml2-wg@omg.org Subject: RE: actors and use cases Was: some issues My understanding is that use cases are a specification of the (requirements of the) interaction between a system and the interested stakeholders outside the system boundary. As a specification, it is not instantiatable, but is rather realized in some way. Realization of use cases and actors is formally defined in UML2, but the actual details of how a realizing classifier realizes a use case is not specified. As a result, it would seem to me that use cases are not executable but rather their realizations are. An execution of a realization could be captured as an interaction which could represent a particular scenario. One can then verify that the realization meets the use case requirements by comparing the scenario with the use case to see if they match. Due to the nature of use cases, the matching rules would be informal and could not be machine verified. robert france wrote on 07/07/2005 04:35:39 PM: > > >Wouldn't an instance of a use case (M0) be a scenario involving > specific actor > >instances interacting with a specific instance of the system under > >consideration? A use case instance could not be something that occupied real > >memory because a use case is not an abstraction of a system, but isinstead an > >abstraction of the interactions between actors and a system. > > This meshes with my understanding of use case instances. Is this not > the interpretation supported by the standard? > One point of clarification: what is a "specific actor instance"? My > view is that an actor "instance" is an entity (object, thing, whatever) that > plays the role represented by the actor. In this sense, the notion > of an actor as an instantiable classifier does not mesh with the notion of > an actor as a role (you do not instantiate > entities that play a role from a role). ... then again I may be confused ... > > Robert > > ==================================================================== > Robert B. France, Professor | Tel: 970-491-6356 > Computer Science Department | Fax: 970-491-2466 > Colorado State University | Email: france@cs.colostate.edu > Fort Collins, CO 80523 | www.cs.colostate.edu/~france/ > > Do not miss MoDELS/UML 2005 > http://www.modelsconference.org > 8th International Conference on Model Driven Engineering Languages and > Systems > (formerly the UML series of conferences) > From: "Ed Seidewitz" To: Subject: RE: actors and use cases Was: some issues Date: Fri, 8 Jul 2005 10:48:30 -0400 Organization: Data Access Technologies X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWDG6Sr7x6nNtFsSYmf9E0kA+9QcQAArBSwABw9CsAADuOz4A== X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail4.opentransfer.com X-Spam-Status: No, hits=0.0 required=12.0 tests=none autolearn=no version=2.64 X-Spam-Level: Tim -- > Ed, > > I couldn't follow your point here: > > > Note also that, in UML 2.0 as finalized as in UML 1, I can declare > > navigability without requiring that the actor or the use > case own any > > property for the association, so there is no problem there. > > Navigation is the notation for property ownership. You can't > declare navigability without requiring that actors or use > cases own properties. As Bran pointed out, this is not the case in UML 2.0 as finalized (nor was it the case in UML 1). > I would propose to not use navigability in use case diagrams. > As already mentioned in this email thread navigation is often > interpreted as data flow. > I know this problem from many projects and my advice is > always to avoid navigability if ever possible. > In this case I think we have to change nothing in the specification. I agree that many people mis-interpret navigation as data flow, but this is just a misunderstanding of the notation. And it happens in lots of contexts, not just with use cases. I understand that, as a result, you may not want to use navigability on use case diagrams, or avoid it in other cases. On the other hand, I tend to use navigability whenever possible, because I find it to be very important to clearly understand the directional dependencies of things. In modeling, as in other things, there are different approaches and tastes. The specification should let either of us do what makes sense to each of us, which it currently does. > However if we allow navigation we must change the > specification (Nerijus issue). I think it is now established that this is not the case. > In addition it is very important to specify the semantics of > actor/use case navigation. There are so many interpretations > out there....... Well, I would say that it is very important to specify the semantics of a lot of UML! The semantics of actor/use case navigation are really no more ambiguous than the semantics of navigation in general, or the semantics of a lot of other constructs in UML. I don't think the RTF can or should settle on one interpretation of such things, at least not in the case when the multiple interpretations are exactly because of a lack of concensus. Instead, if there is a desire for a cummunity to establish a more rigorous specification of semantics in some area of UML, this should be handled through the RFP process (as is being done, for example, with the RFP fpr a Semantics of a Foundational Subset for Executable UML Models). -- Ed Subject: SUMMARY: actors and use cases Was: some issues Date: Thu, 21 Jul 2005 10:25:44 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SUMMARY: actors and use cases Was: some issues thread-index: AcWDG6Sr7x6nNtFsSYmf9E0kA+9QcQAArBSwABw9CsAADuOz4AJ+x6/g From: "Tim Weilkiens" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j6L8d4hh022080 I'd like to summarize the email discussion about the actor/use case relationship to assure that we have a common understanding. Nerijus issue: > Actor and UseCase can't own Properties, this means that associations in UseCase diagram are always non-navigable at both ends. > Is this correct? I propose to close the issue without change. That decision is based on the outcome of our email discussion: Tim> Navigation is the notation for property ownership. You can't declare navigability without requiring that actors or use cases own properties. Bran> Not true -- as of late last year. In the FTF we decided to separate the two concepts in order to better support the modeling of database systems. Bran> So, in principle, it is possible to separate the two. However, there is a hitch: we do not yet have a notation that allows us to denote that an Bran> association end is owned by the association rather than the classifiers at the ends. In the UML 2 spec, we finessed this by saying that we Bran> use the convention that navigability also implies ownership. There was no argument that asks for the feature that actors or use cases can own properties. Therefore it is sufficient to have navigation. We also had a discussion about the semantic of navigation: Ed> Well, I would say that it is very important to specify the semantics of a Ed> lot of UML! The semantics of actor/use case navigation are really no more Ed> ambiguous than the semantics of navigation in general, or the semantics of a Ed> lot of other constructs in UML. I don't think the RTF can or should settle Ed> on one interpretation of such things, at least not in the case when the Ed> multiple interpretations are exactly because of a lack of concensus. Ed> Instead, if there is a desire for a cummunity to establish a more rigorous Ed> specification of semantics in some area of UML, this should be handled Ed> through the RFP process (as is being done, for example, with the RFP fpr a Ed> Semantics of a Foundational Subset for Executable UML Models). The issue will be included in ballot 7. Tim --- Tim Weilkiens, E-Mail tim.weilkiens@oose.de Instructor, Consultant, Coach OMG Representative, INCOSE member UseCase can be connected with Actors using Association, but neither UseCase nor Actor can't own Properties (there are no subsets), so Association is always non-navigable, properties are owned by Association.