Hi,
Yes, we definitively could see the inheritance of classifierBehavior analogous to the transition guard. That I agree with. But on the other hand, I really do not see an issue with also creating the redefined state-machine automatically when the generalization is established. Then we have everything in place for the user to start redefining it (exactly as it works in the legacy tooling). I did some thinking along these lines and tried to summarize the different scenarios that I tried to enumerate earlier.
| Superclass | Subclass |
Case 1 | No state-machine | No state-machine |
Case 2 | State-machine | No state-machine |
Case 3 | No state-machine | State-machine |
Case 4 | State-machine | State-machine |
Then for each of these four cases, I made the following proposal what should happen for the a - f cases I listed earlier in this thread:
| Case 1 | Case 2 | Case 3 | Case 4 |
Establish generalization | Allowed | Allowed Create empty redefining state-machine and set classifierBehavior =>Case 4 | Not allowed | Not allowed |
Create state-machine in super-class | Not allowed (if it can be detected) | Not applicable | Not applicable and not allowed (if it can be detected) | Not applicable |
Create state-machine in sub-class | Not allowed | Not applicable | Not applicable | Not applicable |
Delete state-machine in super-class | Not applicable | Not allowed and not applicable (if it can be detected) | Not applicable | Not allowed (if it can be detected) |
Delete state-machine in sub-class | Not applicable | Not applicable | Not applicable | Not allowed |
Remove generalization | Allowed | Not applicable | Not applicable | Allowed Remove redefining state machine and unset classifierBehavior => Case 2 |
I tried to keep it simple, and actually make several cases being not allowed, e.g. case 4 I proposed to not be allowed to create a generalization, i.e. the user is only allowed to establish a generalization if the intended sub-class don't have a state-machine (to avoid the aspect of having to delete the 3 pre-created elements as you have in the legacy tooling). This also makes it clear that it mainly makes sense to start with an empty redefining state-machine (in the legacy tooling I myself find it pretty confusing that if I start to build up the state-machine in the sub-class, and then establish the generalization, and the two state-machines are now "combined",what does that mean really?) With this proposal, you make sure that you always start out with an empy state-machine in the subclass.
Then we simply always only have case 2 (which is the one that we mainly have discussed), and for that case we automatically can create the redefining state-machine to have everything prepared for the end-user (not further action is needed).
I do know that Bran don't agree with this, but I feel that this is a very pragmatic proposal, partly aligned with the legacy tooling (actually reducing one complex case when you need to support the "mixing" of existing state-machines, including the removal of the 3 initially created elements).
/Peter Cigéhn