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

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

Hi,

Well, it can always be discussed if it is an "accident of text editing". I came up with this comparing how the legacy tooling behaves when "emptying" the code snippet, which for the non-inheritance case removes the opaque behavior, and for the inheritance case leaves the opaque behavior, which in practice (from the perspective of the end-user) is redefining it with nothing, which basically is the same excluding.

Once again, the legacy tooling have never supported the explicit notion of excluding opaque behaviors. So there has in practice never been a need for it. The only need that has existed is to leave the code snippet empty, doing a redefinition of nothing (and the user has not even bothered that a true redefinition has been made either).

Of course there should be a visual feed-back, that the exclusion have happened, i.e. the icon on the effect/entry/exit tab should use the excluded decorator as one would expect. So the user would see on the tab whether the code snippet is left only redefined, e.g. if there are whitespaces left or if the user makes comments (in which case the user should get that commented code snippet should be included in the generated code as one would expect).

Since the code snippet view stills needs to be aware of the case of deleting the opaque behavior for the non-inheriting case, we could make this into the same as the combined delete/exclude buttons, i.e. the code snippet view should always "delete" the opaque behavior when it becomes empty, but for the inheritance case an exclusion should be made. So I don't see that the code snippet view really need to know about the exclusion case, since it should be possible for it to only know about a "delete" case.

I'm just sorry, that this proposal didn't appealed. Personally I liked it a lot when I came up with it, since it was so simple, and it was aligned with how the legacy tooling behaves. 

Back to the drawing board then... :(

/Peter Cigéhn

On 13 March 2017 at 16:45, 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