Re: [papyrus-rt-dev] Are actions and guards redefinable? excludable?

[Peter Cigéhn <peter.cigehn@xxxxxxxxx>]

Hi,

I think we need to step back a bit to the basics regarding the work flows when using the code snippet view when editing code snippets in a state-machine. Let us disregard from the aspects of inheritance, redefinition and finally this aspect of exclusion for a moment.

First of all I would like to highlight a few important aspects when it comes to the visual cues we give to the user regarding the existence of any code snippets, i.e. we both have the cog-wheel decorator on the transition (and eventually we will have similar decorators for entry and exit of a state as tracked by bug 512699). Apart from that we also have the label on the relevant tab in the code snippet view itself, i.e. a bold label on the effect/entry/exit tab indicates that it do have some contents, i.e. an opaque behavior do exist in the model and its body is non-empty, i.e. it can very well just contain white-spaces or commented code. The bold label on the tab still gives a clear indication that the code snippet contains *something*. See bug 494288 and the attachment to that bug for some examples from the legacy tooling.

If I compare with how the legacy tooling works we have the following basic scenario:

1) The user have a state-machine with some transitions with no effect defined, i.e. no cog-wheel decorators and the effect tab in the code snippet view has a non-bold label

2) The user starts typing in some code in the effect tab for a transition. The cog-wheel decorator appears and the bold label on the effect tab now indicates clearly to the user that some effect code snippet now exist for this transition

3) The user realizes that the code was entered wrongly and the user simply uses back-space to "undo" and empty the code snippet.

4) The cog-wheel decorator disappears and the effect tab label goes back to non-bold, both indicating that there now is no effect code defined for the transition.

I think that these two visual cues gives the user are pretty good understanding about what "emptying" the code snippet means, and I personally find this behavior in the legacy tooling to be rather straight-forward and intuitive.

In practice what happened when the user "emptied" the code snippet was that the opaque behavior was removed from the model, which I think is also rather natural. If the opaque behavior was left behind in the model, but only with an empty body, would mean that the user could create lots of "garbage" opaque behaviors without even knowing or understanding. So I think it is rather fundamental to remove the opaque behavior when the code snippet is being "emptied" by the user, as a way of "undoing" code that was entered "incorrectly".

If we then extend this to the inheritance case and look at that. Since the legacy tooling have more limited use of decorators for the locally defined vs. inherited or redefined cases, I am basing this on how we intend this to be work in Papyrus-RT:

1) The user are editing an inherited state-machine with inherited and existing effect code on the transitions.

2) The gog-wheel decorator is washed out indicating existence of some inherited effect code, and the effect tab label shows in bold.

3) The user starts making some changes to the code-snippet, causing it to be redefined. The cog-wheel decorator gets the redefined decorator, which also the cog-wheel icon on the effect tab gets, to clearly indicate that it now is a redefined code snippet.

4) The user now decides to "empty" the code snippet to "remove" the inherited code, comparable to the basic scenario above.

5) When the code snippet becomes empty, the code snippet view should "delete" the opaque behavior, but since it is inherited it is then excluded (this is the same analogy that the same red x delete button is used for both deleting or excluding inherited elements) the opaque behavior is instead exlcuded.

6) The cog-wheel decorator on the transition now gets the excluded decorator, the icon on the effect tab in the code snippet view also gets the excluded decorator, and the effect label is now non-bold to indicate that the code snippet is "empty".

Regarding these aspects of editing the generated code using the CDT editor, we must consider the fact that the code snippet view eventually should have CDT integrated with it (if we want to get on par with what the legacy tooling provides). So the use cases when editing within the context of the complete generated code, will hopefully be a more uncommon case.

I would argue with the reasoning above, that the user intention of "emptying" the code snippet view for inheritance case is pretty natural to see it as an exclusion, given all the visual cues that is given to the user. Sure, we could present a popup asking the user, but to be honest I think that such a dialog would cause more confusion that add clarity. If the user intends the "emptying" the code snippet for further editing in the CDT editor, then I would (as already mentioned) say some TODO comment or at least leaving something left in the code snippet can be used (which is clearly indicated by the bold or non-bold label on the tab in the code snippet view), that then can be further edited in the CDT editor.

Personally I still think that the implicit "delete" (and thus also excluding) of the opaque behavior when the user "empties" the code snippet is a pretty natural gesture using the code snippet view. When the user knows that this is the behavior (which will be pretty obvious when having worked with it for a while), then the user can simply add/leave *something*, like a TODO commment, if the intention is to leave an opaque behavior in the model.

Of course, adding some code to an excluded code snippet using the code snippet view, should automatically switch it back to the redefined state, and the decorator on the cog-wheel should swich back to the redefinition and the label of the effect tab should become bold. So if the user realizes that too much was removed, and thus it ended up in the excluded state, then the user can simply type in a TODO comment to get it back to redefined state for further editing in the CDT editor.

I actually was planning on providing feedback on the code snippet view, regarding the automatic removal of the opaque behavior, already when I verified bug 494288, but I wanted to include the aspects of inheritance and the then ongoing discussions regarding redefinition and exclusion (which I am now doing).

Does these explanations makes more sense?

/Peter Cigéhn

On 13 March 2017 at 18:14, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

That raises an interesting question:  does the code-to-model synchronization detect the case were the user adds an override of an action in a subclass, to create the corresponding redefinition in the subclass capsule/state machine?  Otherwise, the user might be inclined to create a blank redefinition in the model then switch over to CDT to fill it in.  Although, the user could just as well add a TODO comment to effect the redefinition.

However that may be, my main hesitation is that I’m uncertain about interpreting the user’s intent when clearing out the text in the Code Snippet View as trying to exclude/un-define the behaviour.  It could just be an intermediate action, so this side-effect of exclusion may not be appropriate.  It certainly isn’t necessary in the way that it is necessary to create a re-definition in order to edit the inherited snippet.

We could have the tool prompt the user to ask whether the action should just be excluded when the snippet is cleared, with of course the “don’t ask me again” toggle to remember the decision.  It seems to me appropriate to ask the user’s intention and let her decide what she wants her edit to mean.

Cheers,

Christian

On Mar 13, 2017, 12:10 -0400, Peter Cigéhn <peter.cigehn@xxxxxxxxx>, wrote:

Hi,

Regarding this about getting an "empty" opaque behavior, the user would have to enter something into the code snippet view in the first place to get an opaque behavior to be created in the first place. Which then can be edited in the CDT editor on the generated code (but you need to generate code first to do that).

So I am not really sure that I see this case of "leaving an empty opaque behavior" if the user explicitly decides to empty the code snippet view (when it already have had something).

/Peter Cigéhn

On 13 March 2017 at 16:58, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:

There might be a potential use-case for leaving an empty opaque behaviour without wanting to exclude it: the case where the user wants to use the CDT editor rather than the code snippet view. The user could create an empty opaque behaviour and then do an Edit->Effect, or equivalent, which will open the CDT editor focused on the function for that action. Of course, once the user edits code there, the opaque behaviour is no longer empty (as the model is synchronized with the generated code). Furthermore, this might be a rare use-case.

In any case, I think that the case where the user has only comments should not be deleted. If it is considered as an excluded element, then no code will be generated for it, but maybe the user intends to have those comments in generated code. In such case, it should not be considered as an excluded element.

On Mon, Mar 13, 2017 at 11:48 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Peter,

My gut feeling is that I don’t like the idea of editing text to be empty should imply exclusion.  But, then again, I can’t really think of any way in which this would not be equivalent to “un-definition” of the inherited behaviour.  It is, literally, replacing the inherited behaviour with no behaviour.  But as an accident of text editing, it feels wrong.

If we do adopt this workflow, then what about these similar cases?

• text that is not empty but contains only whitespace (no jokes about Python as default action language, please)
• text that comprises only comments.  Do users temporarily “comment-out” code in their UML-RT models, too?

In any case, the from a technical perspective, the exclusion of an element is accomplished by means of an ExcludeRequest processed by the Element Types Framework’s edit-helpers.  And the façade API provides a query for the inheritance disposition of any object, which includes the case of exclusion.  So, the Code Snippet View needs not be concerned with the details of how exclusion is modelled.

Cheers,

Christian

On Mar 13, 2017, 11:27 -0400, Peter Cigéhn <peter.cigehn@xxxxxxxxx>, wrote:

Hi,

Since there seem to be some consensus that opaque behaviors should support redefinition, and thus also support exclusion. 

The redefinition support has already been implemented, i.e. if a user "redefines" the entry/exit/effect using the code snippet view, i.e. simply changes the code snippet, then a redefinition association is established and a RTRedefinedElement stereotype is applied.

What is left is to write a bug tracking the change in the import tool, to ensure that this is done also for legacy models (which only have a "local" opaque behavior with no formal redefinition assocation or corresponding RTRedefinedElement stereotype applied).

I was then thinking a bit about the "gesture" for the user to use for excluding some inherited entry/exit/effect. Since it is not equally obvious as excluding a state or transition, i.e. simply right-click on it in the diagram and selected "Exclude Element", due to that we don't have a good "representation" of the entry/exit/effect in the diagram. Yes, we have the decorator for the effect of a transition, and we have discussed similar decorators for entry and exit of a state (or having them as elements in a compartment of the state), which you could right-click and get up a context menu in a similar way.

But I was more thinking along the lines regarding the gesture to "redefine" entry/exit/effect using the code snippet view. How do the user "exclude" entry/exit/effect in the legacy tooling today? Well, simply by making the code snippet empty. 

There is already the special case in the legacy tooling for the non-inheritance case where making the code snippet empty, then removes the opaque behavior. For the inheritance case when the user "redefines" the code snippet, then an empty opaque behavior is left indicating that the opaque behavior has been "redefined" with nothing, i.e. the same as "excluding" it.

So my proposal would then be to let the code snippet view handle the case when making the code snippet empty to:

1) For the non-inheritance case simply remove the opaque behavior

2) For the inheritance case, establish a redefinition association and apply a RTRedefinedElement stereotype with rootFragment=null to indicate that the opaque behavior is now formally excluded.

The second rule could of course also be used for legacy models as well, in case the import tool detects that the locally added opaque behavior is empty, and thus it should do the same as for the redefinition case but leave rootFragment=null.

This principle can of course be combined with some suitable exclude menu-choices on context menus, if we find suitable elements in the diagram, or possibly on the context menu for the code-snippet view. But I think that having such a simple "gesture" of editing the code snippet for both redefinition and the special case of redefining with nothing for excluding would be good also.

Any comments? 

If we agree with this, I will then write a bug tracking the changes needed in the import tool (both for the redefinition and the exclusion case) as well as the improvements to the code snippet view (for either removing the opaque behavior or setting up exlusion) when the code snippet is made empty by the user.

/Peter Cigéhn

On 6 March 2017 at 21:13, Bran Selic <selic@xxxxxxx> wrote:

Regarding redefinition and exclusion of entry and exit behaviors and transition actions:

In a very concrete sense, these things are very much analogous to methods of operations. Hence, they should be redefinable.

Exclusion is conceptually similar to redefinition (i.e., redefinition with a null element). So, in principle, anything that supports redefinition should also support exclusion.

Cheers... Bran

On Wed, Mar 1, 2017 at 3:13 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

This question is partly the same question as Christian asked on this list just the other day, related to "Redefinition of Opaque Behaviors". As discussed in that thread, the legacy tool have not really utilized the fact that an Opaque Behavior is redefinable. Instead a new local Opaque Behavior, with no redefinition relation to the Opaque Behavior in the superclass, has been used.

But as proposed (but I do not feel that we finally have decided) in that mail-thread we should utilize the redefinability of Opaque Behavior in UML, which then also means that we should add functionality to the import tool to establish the redefinition relation (and also applying the RTRedefinedElement stereotype and setting rootFragment). I was just testing these different cases and provided some feedback in bug 510323 related to this.

If we formally decide (whoever makes such a formal decision) to go forward with this, then yes, the Opaque Behaivor for effect/entry/exit should all be redefined. But to be honest, I do not see any big difference if the Opaque Behavior was only locally added (without the redefined relation and the RTRedefinedElement stereotype applied). In the end it should have exactly the same effect in the generated code, so from the code-generator perspective, I think that both approaches should be supported. In fact, in both approach the state/transition is redefined anyway, and references the locally "redefined" Opaque Behavior disregarding if its itself have the redefinition relation or not.

And since we have entered this new path, then the question of excluding them comes. Sure, if we decide to start using the redefinition relation and applying the RTRedefinedElement stereotype, we *could* also make them excludable. In the legacy tooling this have never been supported (since it has not had them truly redefinable and never used the RTRedefinedElement stereotype on the OpaqueBehavior). In practice, if you want to "exclude" the effect/entry/exit you would simply have "redefined" with an empty code snippet (using the code snippet view). But sure, if we now formally decide the make use of the redefinement-ness of the Opaque Behavior, then we could also decide to make the excludable. But personally I would like such "language decisions" to really consider the UI and work-flow. It feels pretty pointless to introduce a new construct in the language if it does not make sense in the work-flows for the end-user. I think that it very well is "good enough" if the user simply makes the code-snippet empty, instead of explicitly excluding it. But sure, if we can find a good work-flow for excluding then we could have it in the language as well.

Since you explicitly wanted this to be a "pure" language question, I will leave the tooling discussion for now then.

Regarding guards, they are not redefinable as such (which we also have some issues with right now in the UI, where I provided some feedback on bug 510323). In both the transition and trigger guard cases, you simply add a new local constraint (and opaque _expression_) in the subclass (since a constraint in UML is not a redefinable element).

I hope that Bran and Christian can fill in and provide more information if needed.

/Peter Cigéhn

On 28 February 2017 at 21:35, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:

Another question about the language (not the tooling support): are state entry and exit actions, and transition actions redefinable? excludable? How about transition guards? trigger guards?

My guess is that in these cases you redefine a state or transition and modify the action or guard, rather than the action redefining another, isn't that right?

PS: Bran, you can subscribe to the developers mailing list at https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

--

Ernesto Posse

Zeligsoft

--

Ernesto Posse

Zeligsoft

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

--

Ernesto Posse

Zeligsoft

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev