Community
Participate
Working Groups
If you attach a message to an execution specification, then several aspects of wrong semantic ordering can be seen, e.g. the limitation that a message never can go "upwards" is not checked as it is done with a "standalone" message not attached to an execution specification, which causes completely wrong order of fragments, e.g. the send message occurrence specification comes after the receive message occurrence specification. Also the border case when the user tries to make the message horizontal can cause the wrong order where the execution specification itself incorrectly comes before the receive message occurrence specification which is specified as the start of the execution specification. Steps to reproduce: 1) Create a UML model 2) Create a sequence diagram 3) Create two lifelines in the sequence diagram 4) Draw an asynchronous message between the two lifelines 5) Create a behavior execution specification on the receiving lifeline slightly below the receive of the message 6) Rearrange the message so that the receive end is attached to the start of the execution specification 7) Result: The order of fragments are now send message occurrence specification, behavior execution specification, receive message occurrence and execution occurrence specification 8) Expected result: The receive message occurrence should come before the behavior execution specification. Since the the receive message occurrence is specified as the start of the behavior execution specification it needs to come before (this is also the order produced by the legacy tooling). 9) Now click-and-drag the behavior execution specification upwards. 10) Result: You are able to drag the behavior execution specification upwards without limitations causing the message to go "upwards". The fragments now have a order where the send message occurrence specification comes *after* the receive message occurrence. Event the execution specification comes before the receive message occurrence specification, which does make sense either. 11) Expected result: The same kind of limitation/constraint as already exist for "standalone" messages is relevant here as well. The same kind of stop-sign should be shown to the user if the user tries to move the execution specification to far up, i.e. when the message is horizontal. The expected order of fragments should be the same as at 8), i.e. send message occurrence specification, receive message occurrence specification, execution specification, execution occurrence specification (marking the finish of the execution specification). 12) Now adjust the behavior execution specification down to make the message (seemingly) horizontal. 13) Result: Sometimes you are able to get the correct order of fragments (as detailed in 11), and sometimes you get the wrong order (as described in 7). It seem a bit non-deterministic which order you get. 14) Expected result: The user should not have to deal with "pixel pushing" adjusting the position of the execution specification in very small steps to ensure that the semantic order of fragments is the correct one when aligning the message to be horizontal (which also is related to Bug 507458 I guess). In general it must be ensured that whenever a message is attached to an execution specification, the order shall always be send message occurrence specification, receive message occurrence specification (which defines the start of the execution specification) and then the execution specification itself. This is related to the automatic creation of execution specification in Bug 507409 which of course also much ensure the correct semantic order. It can actually be discussed if the execution specification itself should be possible to move at all like this. Compare to the legacy tooling, you are unable to move an execution specification attached to a message. You move the execution specification by moving the message itself (in which case the execution specification just moves along). I can't say which principle is the best, since it must fit with rest of the editing gestures. This aspect is also highly related to the proposal and discussion in Bug 507348.
As I understand it, this bug raises two distinct issues: - the need to ensure the right semantic ordering when a message is attached to an execution specification - the need to prevent a message from going uphill even when attached to an execution specification for the sake of consistency In relation to Bug 507348, differentiating between move and reorder would lead to the following behavior: - if the user moves an execution specification, all attached messages move together with it - if the user wants to reorder the execution specification, it is only possible so far as attached messages do not end up going uphill
(In reply to Mathilde Arnaud from comment #1) > As I understand it, this bug raises two distinct issues: > - the need to ensure the right semantic ordering when a message is attached > to an execution specification > - the need to prevent a message from going uphill even when attached to an > execution specification for the sake of consistency Yes, that summarizes the two main issues. > > In relation to Bug 507348, differentiating between move and reorder would > lead to the following behavior: > - if the user moves an execution specification, all attached messages move > together with it Not sure what you mean with attached *messages* (in plural). One and only one message receive can be attached, in the meaning that it triggers the start of the execution specification. But if you with "attached" means all messages that are sent from the execution specification, then those should follow along, yes. As I indicated last in Comment 0, if I compare with legacy tooling, it is not possible to grab and drag the execution specification itself, since it is now attached to, i.e. being triggered by, the message. You always grab and drag the (triggering) message itself, and then the attached/triggered execution specification follows along. This of course ensures that you never are able to change the "slope" of the message (neither up or down). You can only change the "slope" of the message by actually moving the message receive (or send) end of the message, up or down. So depending on how this is solved in conjunction with the proposal in Bug 507348, it might even be prohibited to move the execution specification itself, but it should be moved by dragging the attached/triggering message. > - if the user wants to reorder the execution specification, it is only > possible so far as attached messages do not end up going uphill I am not sure what you mean with "reorder" in this case. Since the message is attached/triggering the execution specification, it is the message that is reordered, and the attached/triggered execution specification follows along when re-ordering the message. It really does not make sense to reorder the execution specification itself. The end of the execution specification can be adjusted, i.e. the position of the execution occurrence specification that marks the end of the execution specification, and "reordered", but then this is a "resize" gesture if the execution specification. I suggest that you take a look at how the legacy tooling behaves to see what I mean. I am willing to have a phone conference and a screen sharing session if you would like me to demo a bit regarding how the legacy tooling behaves.
(In reply to Peter Cigehn from comment #2) > I suggest that you take a look at how the legacy tooling behaves to see what > I mean. I am willing to have a phone conference and a screen sharing session > if you would like me to demo a bit regarding how the legacy tooling behaves. I am aware of the behavior you describe, but I don't really understand why moving or reordering an execution specification should be prevented as long as the messages attached (the one at the origin of the execution specification and the ones originating from it) are taken care of in a logical way. It may be easier to implement from a technical point of view, though.
(In reply to Mathilde Arnaud from comment #3) > I am aware of the behavior you describe, but I don't really understand why > moving or reordering an execution specification should be prevented as long > as the messages attached (the one at the origin of the execution > specification and the ones originating from it) are taken care of in a > logical way. > It may be easier to implement from a technical point of view, though. Yes, sure if the messages attached to the execution specification (both the received triggering one and the ones sent), moves along in exactly the same way as if you drag the triggering message, then it does not matter. Once again, it is very hard for me to "read between the lines" in your descriptions, and it is very easy to interpret things based on how it works currently in Papyrus. But if you say that the idea was to have exactly the same behavior for both cases, then I agree that it does not matter. I was just confused about the aspect of "reordering an execution specification", since it did not make sense to me to *only* reorder the execution specification itself in case it has a triggering message. In that case, as you say, the attached messages should of course also be reordered/moved.
(In reply to Peter Cigehn from comment #4) > Once again, it is very hard for me to "read between the lines" in your > descriptions, and it is very easy to interpret things based on how it works > currently in Papyrus. Sorry about that. The idea for me is to give requirements and describe the ideal behavior we want to achieve first without thinking about current behavior and then see how to achieve it. The discussion allows to clarify things. In this instance, I suspect that the faulty behavior when moving execution specifications would be fixed in Bug 507348, but the other one is independent.
