Issue 8899: reply messages in interactions (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: Similar situation with reply messages in interactions. <messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name> [‘(‘ [<argument> [‘,’<argument>]* ‘)’] [‘:’ <return-value>]) | ‘*’ 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. Resolution: Revised Text: Actions taken: June 20, 2005: received issue Discussion: End of Annotations:===== s is issue # 8899 reply messages in interactions 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. 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 Date: Thu, 23 Jun 2005 21:28:08 +0200 From: Oystein Haugen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Nerijus Jankevicius CC: Branislav Selic , Juergen Boldt , uml2-rtf@omg.org Subject: Re: some issues X-UiO-Spam-info: not spam, SpamAssassin (score=-7.085, required 12, autolearn=disabled, ALL_TRUSTED -2.82, AWL 0.59, HTML_50_60 0.10, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.04, UIO_MAIL_IS_INTERNAL -5.00) 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 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