Hi,
Good question! I actually already provided some input regarding this in
bug 510315 comment 2. Since the fact that the state-machine (and the state-machine profile) now is optional is not something that have had to be considered before in legacy models. In the earlier generations of UML-RT, the state-machine have been mandatory, and creating a capsule have always created the state-machine at the same time (you cannot even create a capsule without a state-machine in the legacy tooling, and trying to remove it casues a live validation kicking in that blocks the removal of the state-machine). So comparing with our legacy, this has been non-issue, and the redefinition relation of the state-machine ins the subclass have been established as soon as the generalization for the capsule have been established.
But with the introduction of an optional state-machine profile, and thus an optional state-machine, e.g. to make it possible to have pure structure capsules without behavior, we have quite a few "corner cases" and different combinations to consider, i.e. superclass/subclass with/without state-machine at the time the generalization is established, and adding/removing a state-machine in the superclass/subclass *after* the generalization already have been established.
Regarding the specific example that Christian showed his video, i.e. the state-machine did not exist in the subclass capsule at the time when the generalization was established, is a good example to discuss around.
I am not fully sure what you mean when you say "It looks like the capsule state machines are not automatically inherited". How could we conclude that from the video? What happened was that no redefinition of the state-machine was established automatically. That happened when the state-machine was explicitly created at a later point in time. The semantic could still be that the state-machine is inherited "as-is". But to be able to start-redefining the state-machine, we need to establish the redefinition. This is kind of the same discussion that Christian brought up regarding the nested state-machine diagram for composite states, i.e. to be able to redefine the "inside" of a composite state, it first have to be redefined so that the redefined diagram have a place-holder.
So yes, one alternative is that the state-machine is considered to be inherited by default, even if the subclass does not have a state-machine itself. But to be able to redefine it in the context of the subclass the state-machine needs to be added explicitly (and a redefinition is established automatically as shown in Christians demo). Another alternative is to explicitly create a state-machine in subclass (if it does not have one yet) at the time the generalization is established, and establish the redefinition. But this would make us bump into another "corner case" if the subclass capsule is in another model that the superclass, and the optional state-machine profile is not applied on that model. So maybe the former alternative is better, and the user have to explicitly add the state-machine in the subclass to be able to start redefining it.
Regarding the last question, when the capsule owns other behavior such as interactions and activities, I am not sure what you mean "should they be inherited too"? If you by "inherited" mean that they should have the same kind of redefinition relation established and graphical layout inheritance, then the answer is "no". That is only applicable to the state-machine.
/Peter Cigéhn
