Community
Participate
Working Groups
The label of the Messages in the sequence diagrams are not complaint to the UML 2.5 interaction notation as described in the UML 2.5 specifications (17.4.4.1 Message). The refresh of the message labels is weird also, it change from displaying the name of the message to the signature of signal / operation associated with the message. This should be fixed and display the label with coherence. Assuming that there is a signature (signal / operation) set to the message, currently the label of the messages in the sequence diagrams are displayed as signatures of operations with the properties of the (signal / operation) as parameters and It ignores the parameter defined in the message. The semantic defined in UML 2.5 specifies, in the case the message has a signature (operation or signal): 1) The name of the message must be the same as the name of the operation / signal. 2) For message with signature as Operation with messageSort asynchCall, the arguments of the Message correspond to the in and inout ownedParameters of the Operation, in the order of the ownedParameters. 3) For message with signature as Operation with messageSort synchCall, the arguments of the Message correspond to the in and inout ownedParameters of the Operation, in the order of the ownedParameters. 4) For message with signature as Operation with messageSort reply (as response of a previous send synchCall message), the arguments of the Message correspond to the out, inout and return ownedParameters of the Operation, in the order of the ownedParameters. 5) For message with signature as Signal, the messageSort must be asynchCall and the arguments of the Message correspond to the in and inout ownedParameters of the Operation, in the order of the ownedParameters. For the message arguments of message with signature defined, the UML 2.5 specifies: 1) The name correspond to the name of the argument and should be equal to the name of one of the parameters of the operations or property of a signal. 2) If it is an expression with no operands and empty symbol string, it corresponds to a wildcarded value. 3) Or All the arguments in the message must name or no one has it and the argument are identify by order. 4) The type of the argument must correspond with the type of the parameter of the operation or the property of the signal. 5) For the request message (messageSort synchCall or asynchCall): 5.1) The symbol of the expression has not semantical meaning. 5.2) If it is an expression the operands value are the value / values of the argument, evaluated at the point of sending the message. 6) For reply messages: 6.1) The arguments must be expressions and the symbol string represents the assignment specification: 6.1.1) Unknown: An empty string, which represents an unknown assignment target. An argument with unknown assignment target and no modeled returned value is an output wildcard. 6.1.2) Interaction Parameter: The unqualified name of an ownedParameter of the enclosing Interaction, which must be an out, inout or return Parameter. The type of the Operation Parameter corresponding to the argument must conform to the type of the target ownedParameter of the Interaction. 6.1.3) Attribute: The (possibly qualified) name of an attribute of the context Behavior of the enclosing interaction or of the receiving Lifeline of the Message (which is the lifeline that sent the original message to which this is a reply). If an Interaction does not have a context Behavior, then the Interaction itself is considered to be the context. The type of the output parameter corresponding to the argument must conform to the type of the attribute. (Note that a qualified name may be used to distinguish attributes of the context and the Lifeline with the same names, or an attribute from an Interaction Parameter with the same name.) 7) The textual representation of the ValueSpecification are defined in the UML 2.5 specification (8 Values). The label of the messages should be displayed as defined in the UML specification 2.5 (17.4.4.1 Message): 1) Request Messages: <message-name> [‘(‘ [ [<in-parameter-name> ‘=’] <value-specification> [ ‘,’ [<in-parameter-name> ‘=’] <value-specification> | ‘-’ ]* ] ’)’] 2) Request Messages: [<assignment-target> ‘=’] <message-name> [‘(’ [<output-argument> [‘,’<output-argument>]*] ‘)’] [‘:’ <value-specification>] <output-argument> ::= <out-parameter-name> ‘:’ <value-specification> | <assignment-target> ‘=’ <out-parameter-name> [‘:’ <value-specification>] A direct editor (directly on the diagram) for the message label should be provided to edit the message and the message argument list. The editor should be provide a content assistance following the grammar defined in the UML specification 2.5 (17.4.4.1 Message).
I defined a new bug for the refresh issue described in the second paragraph: Bug 502237 - [Sequence Diagram] Message label refreshment does not work properly (https://bugs.eclipse.org/bugs/show_bug.cgi?id=502237)
I am planning to upload a change to gerrit (on the latest streams/2.0-mantenance) providing an advance editor (org.eclipse.papyrus.uml.textedit.xxx) for the messages in the sequence diagram. I have implemented the advance editor for the message request kind. I also needed to provide a MessageUtil class to format the messages properly. I found some doubts about how to handle: 1) It looks that you guys have a lot of XxxUtil classes in the uml.tools.utils plugin, so I guess I should put mine there. I guess I can put it here, better, or? 2) There is a current uml.textedit.message.xtext plugins (But that is used for communication diagrams). Should we rename those plugins, to something like uml.textedit.sequence.message.xtext? The ones I implemented are called uml.textedit.sequence.message. 3) It kind of complex to fix a single xtext parser for the request and reply messages, as the reply with all default is not possible to differentiate from a request, so is it ok to create a set of plugin uml.textedit.sequence.message.replay.xtext and uml.textedit. sequence.message.replay.xtext.ui for the replay messages in case I don’t manage to get all in one plugin set?
New Gerrit change created: https://git.eclipse.org/r/83790
New Gerrit change created: https://git.eclipse.org/r/85194
(In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/85194 This PatchSet is for master
While reviewing the latest Gerrit change, I wondered about message name edition. The name of a message is supposed to be the same as the name of the operation or signal referenced in the signature, right ? So what happens if you try to change the name of the message once it has a signature ? Should the change be allowed ? That means that the name of the operation or signal referenced must change also (and the names of all other messages with the same signature). Or that a new signature should be created referencing a new operation or signal with this name. What is the expected behavior in such cases ? The latter seems to have less impact on other model elements. What do you think ?
That is a discussion I have had with my collegues before and it is not an clear choice. That are my views and how I try to implement it on the patch: a) Signals that are semantically correct to have as signatures, are the the ones received by a reception (or any specialization) defined in the classifier that the target lifeline represents, any of its parents (inheritance) or any of the interfaces it or its ports provides and that are consumed by the classifer that the source lifeline represents. Signal can only be used for asynchronous messages. b) The operations that are semantically correct to have as signatures, are the operations defined in the same way as in a) but for operations instead of receptions. Operations can be used for both asynchronous or synchronous messages. c) Reply messages: It should identify the operation triggering the current ExecutionOccurrenceSpecification and select that operation as signature of the reply message, which possible arguments are the INOUT and OUT parameter of the operation and the its return type. Now, the name of the message does not need to match the name of the operation / signal. Messages are NamedElements and should be possible to identify them by name. But if the signal name / operation part of the label is modified (edited by the user), there are several alternatives: 1) If the name is qualified, we choose the first signal matching that qalified name (2 signals with identical qualified name, it is a semantic error in the model, so we ignore that case) 2) If the name is not qualified and only one signal match the signal, we choose it. 3) If there are a signal that is in the same namespace than the context of the interaction, we choose that one. 4.a) Alternative I: We ask the user to choose which of the signals to use. 4.b) Alternative II: If there are several signal that match that name, we use the arguments (using names and types or the implicit order and the types) to identify the signal, if possible, and choose the best match. 4.c) Alternative III: Choose the one defined in the namespace closest to the context of the interaction. 5) If no signal match the name we let the signature empty and allow the user to freely specify arguments and the name for the signal for case wher the label is defiend not formally such as : 'The signal is received and processed' For the operations we proceed similarly, just taking in account that the operation can be overloaded (same name and different parameters) and that if the message type is asynchronous, the operation used should not have any return type or OUT/ INOUT parameters, if we strictly follow the UML specifications. For signals, I like Alternative I, but has implications on the content assistance UI as we will have to deal with the direct editor lost focus or reuse some how the content assistance lists for the selection, force to trigger it or something like that. But for operation i think it is better to match the arguments against the operation parameters to identify to which overloaded operation it correspond. This imply also that changes in the arguments may trigger the selection of a new operation. Also the content assistance implementation is also affected for the selection of signal / operation in order to identify the number and types of the possible arguments. The patch I provided it not implement all of that as it is a first draft that it was intended to trigger the discussion on which way to go, and analyze the possible alternatives we may have for different aspects. So what I have implemented is a) and b) for selecting the possible signals / operation to be used as signatures and for the selection, just 1 and 2. Reply messages are not supported either at that point. Another discussion that come up is when an argument that it is not matching any property of a signal (normally by name, or exceed the number of properties) or for the operation the n+1 argument when the operation has only n parameters, if the user should be asked if want to add a new property to the signal or a new argument to the operation. We decided to implemented as an extended editor that we use in our deployments. I just mention it because it won't be any problem to contribute it here also. And the second discussion is if we should do the same for operations or signals when the label name part can not be bind to any signature. If implemented, this could replace, in part, the dialog that it is shown when creating the messages, and that after a while becomes kind of annoying, thinking that the signal / operation is selected when the label is edited. And I also this could be a better usability option, that could be turned on / off by preferences. About the ValueSpecification parser, the existing one, it is pretty limited and it does not has support for expressions (such as +,-, etc... with operators) or InstanceSpecifications, neither implemented the fall back to free text defined arguments, such as ,'user tag 1'. Note: The "free" label it has a small issue that throws a NPE, the issue is identify and fixed, just pending to upload it. What makes me think, the patch in gerrit is growing and I wonder if it will be better to start to use a topic, to be able to handled several patch sets and maybe easy for several people to work on that. So what do you think about the use of a topic?
(In reply to Antonio Campesino from comment #7) > Another discussion that come up is when an argument that it is not matching > any property of a signal (normally by name, or exceed the number of > properties) or for the operation the n+1 argument when the operation has > only n parameters, if the user should be asked if want to add a new property > to the signal or a new argument to the operation. We decided to implemented > as an extended editor that we use in our deployments. I just mention it > because it won't be any problem to contribute it here also. > This looks like a useful feature, yes. > And the second discussion is if we should do the same for operations or > signals when the label name part can not be bind to any signature. If > implemented, this could replace, in part, the dialog that it is shown when > creating the messages, and that after a while becomes kind of annoying, > thinking that the signal / operation is selected when the label is edited. > And I also this could be a better usability option, that could be turned on > / off by preferences. > I am not sure of what you mean here, so let me try to rephrase: an option would be, when the label of a message does not match an existing element, to create the missing element ? Or is it something else ? > About the ValueSpecification parser, the existing one, it is pretty limited > and it does not has support for expressions (such as +,-, etc... with > operators) or InstanceSpecifications, neither implemented the fall back to > free text defined arguments, such as ,'user tag 1'. > Duly noted. But is it possible to extend it, do you think ? Or maybe try to see what can be done with ALF (I guess this would allow support for expression) ? > Note: The "free" label it has a small issue that throws a NPE, the issue is > identify and fixed, just pending to upload it. What makes me think, the > patch in gerrit is growing and I wonder if it will be better to start to use > a topic, to be able to handled several patch sets and maybe easy for several > people to work on that. So what do you think about the use of a topic? For maintainability, a topic could be troublesome, furthermore only a small portion of the code is impacted, so it does not seem really necessary. It would be better to have several small contributions building on one another if you fear that the patch is too large.
I will proceed with related changes on top of that one, I will try to not rebase often, so the number of patches doesn't grow. I will update the fix for the NPE, then I will fix the xtext edit for the replay messages, then the other improvements. What about the label display customizations by appearances flags? I think there are some issues related to that, maybe is better fix those ones, once this one here is done.
