Hi, Peter,
It appears to me that the inheritance of the classifierBehavior state machine is analogous to the transition guard. Our UML-RT implementation provides for transitions to inherit their ownedRule constraints, including its guard, trigger guards, and whatever other constraints may be serving an information/documentary purpose. The one that is singled out as the guard is inherited as the guard, also. Similarly, we can let a class inherit all of the ownedBehavior state machines and also inherit the classifierBehavior subset. (I say "ownedBehavior state machines" specifically because we don’t have incremental inheritance of the details of other kinds of behaviours, apart from the OpaqueBehavior).
This is all at the level of the model implementation, without reference to how it should be presented in the UI.
In the tooling UI we have, as you say, to make a decision. I can propose at least two alternatives that I think would be workable. First, and probably simplest to fit into the way Papyrus works, is to ensure that the subclass actually manifests the redefining state machine in the model, but initially with its region and all that it contains inherited. So that we have a “real” state machine that is a stub. This, then, can have a diagram that presents the inherited contents of this state machine to let the user start editing it. It also ensures that the user will see the subclass’s state machine regardless of whether the Model Explorer is configured with the facet that shows inherited elements.
The alternative would be to update the Model Explorer’s default facet configuration to present the inherited classifierBehavior state machine always, even if it is not redefined. In this case, it could not have a diagram for the same reason that an inherited composite state cannot have a nested diagram until it is redefined (that reason being the Viewpoint framework). But, of course, the tooling would automatically redefine the state machine when the user creates a diagram, which then essentially puts the model in the first case as described in the previous paragraph.
I would further propose that I can prototype one or both of these solutions for us to get a better idea of how they feel.
On the subject of exclusion of pseudostates, I think it may be worth noting that the exceptional exclusion mechanism (the false constraint) as implemented in Papyrus-RT already works for pseudostates and anything else owned by a Namespace. It’s just that we have trained the UI not to let pseudostates be excluded. This is easily changed if we got it wrong.
On Feb 27, 2017, 03:08 -0500, Peter Cigéhn <peter.cigehn@xxxxxxxxx>, wrote:
Hi,
Some comments inline below.
/Peter Cigéhn