Hi, Team,
The inheritance support for state machines currently implemented in the master branch has raised a question.
In general, in UML-RT, we use the capability of RedefinableElements from UML to link model elements to the definitions that they redefine. So, for example, a Transition that in the state machine of a subclass overrides its inherited effect code is created as a redefinition that references the parent state machine’s transition as its redefinedTransition and gets the «RTRedefinedElement» stereotype applied to it. Also, because the effect is an OpaqueBehavior that, like all behaviours in UML, is redefinable, the overriding effect likewise references the redefined transition’s effect as a redefinedBehavior and has the stereotype applied.
This seems to be different to what RSA-RTE does, which tool ignores the redefinable-ness of behaviours in the role of transition effect or state entry/exit behaviour. It happens to be an automatic consequence of the framework that I implemented for UML-RT in which all RedefinableElements are treated in the same way when they are redefined in the tooling.
What shall we do, and in which release? We can
- align with RSA-RTE, which requires that
-
- we code a special case in our UML-RT metamodel to unimplement the RedefinableElement-ness of OpaqueBehaviors in these roles
- let OpaqueBehaviors be redefinable as in UML, which requires that
-
- we update the model importer to set the redefinition associations in OpaqueBehaviors that RSA-RTE did not set, similar to processing that we do to apply stereotypes (e.g., «RTGuard») in the state machines that RSA-RTE does not have
- we make sure that all paths through the current Properties View UI (sans Code Snippet View) result in the same OpaqueBehavior redefinition pattern (currently there is a case that is incomplete)
AFAICS, the UML-RT Profile Specification suggests that our implementation is on the right track: the «RTRedefinedElement» constraint indicates that it may be applied to “Behavior (if it is a state machine, a method of an operation, a transition effect, an entry or exit action)” which does seem to cover this situation. And it would be odd to apply the stereotype without also setting the UML-ish redefinition association of the bahaviour element. But I would like us to be clear on the intent of the usage in our tooling.
