Re: [papyrus-rt-dev] State machine inheritance

[Bran Selic <selic@xxxxxxx>]

On Mon, Feb 27, 2017 at 10:33 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

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.

​​

​[bvs] Happy to hear that. This is the solution I prefer as well.​

 ​

 

	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

​​

​[bvs] I am not sure I understand all the entries in this table. For example, surely I should be allowed to remove the generalization for capsule classes even for case 2. (I don't think you are talking about a generalization between state machines, since that is not how it should be done).​

 ​

 

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. 

​​

​[bvs] Again, I am confused by your explanation. When you say "empty" state machine, do you mean a non-existent state machine, a state machine that "inherits" the elements of its superclass, or a state machine that is completely new and unrelated to the state machine of its supers? ​

 

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).

​​

​[bvs] Actually, I thought I agreed with you about how we deal with case 2 (see my earlier messages), but, after reading the table, I am no longer sure.

Apologies again for entering the discussion so late.... Bran​

 ​