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