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
