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

[Peter Cigéhn <peter.cigehn@xxxxxxxxx>]

Hi,

Some comments inline below.

/Peter Cigéhn

On 5 March 2017 at 22:34, Bran Selic <selic@xxxxxxx> wrote:

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

​Sounds really good that we agree on that. As I indicated in my previous mail, I must have completely misunderstood you, since I thought that you did not like this approach of automatically creating the redefining state-machine already when the generalization is established (which is how it work in the legacy tooling also),.​

 ​

 

	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 made this table very quickly, and did not want to "over do it", since I did not even think that you would approve of it. So I was probably a bit too unclear, and did not explain all details hidden "between the lines".​ What I mean with "Not applicable" for case 2, e.g. regarding removing the generalization, is that already when the generalization is created case 2 is transformed into a case 4. So if we accept that a redefining state-machine is created in the subclass already when the generalization is created, you *only* have case 2 prior to the generalization being created.

So if we now accept the idea of creating a redefining state-machine automatically when we create the generalization we actually only have two case (not four). and the table can be collapsed and simplified even further! 

So basically we have the case with structure inheritance, i.e. no state-machine in superclass nor in subclass, and structure+behavior inheritance which we only allow for the case that the superclass to be owns a state-machine, and the subclass to be does not own a state-machine already. All other cases we disallow (to make things simple).

And yes, I only refer to generalization between capsules (only redefinition between the state-machines as you expect).

 ​

 

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? ​

​What I mean with "empty" state-machine is that since we in the normal case create "non-empty" state-machine with three "initial" elements, i.e. an initial pseudo-state, and first state and an transition between the initial pseudo-state and the first state, to give the user a "head start" with creating the state-machine (this is something that the legacy tooling provides also)​. One "problem" with the legacy tooling is that these three "initial" elements needs to be removed from the state-machine in the subclass. But with my proposal of not allowing a state-machine to exist in the subclass to be, we don't have to bother about this "removal" of the three initial elements, since the redefining state-machine that we create when setting up the generalization can be created "empty" and just inherit the three initial elements from its superclass.

 

 

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.

​Yes, in your previous response (sent yesterday) you agreed. But when I wrote the above last week, I ​had obviously misunderstood one of your even earlier responses. Now that we apparently both agree on that creating the redefining state-machine automatically at the time when the generalization is setup, everything falls into place (at least for me), and my proposed table starts to make sense.

 

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

 ​