Validation rules for interfaces are missing

[pefribeiro]

Currently it is possible (at least when using the textual language) to both require/use an Interface in a SimMachineDef, in addition to requiring/using interfaces in input context and output context. See example below:

stm SimSTM1 {

    cycleDef 1
    requires DVars
    uses M::IEvent

    input context { uses M::IEvent uses M::IControl requires DVars }
    output context { uses M::IEvent uses M::IControl }
    initial I
    final F

    transition T0 { from I to F } 
}

According to the RoboSim metamodel documentation:

Declarations in a simulation machine are partitioned into threeContexts: local declara-tions, inputs and outputs.

However, the metamodel as implemented, is not quite what is shown in Figure 3.1. Firstly, a StateMachineBody (even in RoboChart) is a Context, and a StateMachineDef is both a StateMachine and a StateMachineBody. A SimMachineDef is also a StateMachineDef, so it is a Context, rather than containing a Context. This class extends StateMachineDef by defining three attributes:

• cycleDef, which is the definition of the cycle as an Expression
• inputContext, which is a Context with cardinality 1+
• outputContext, which is also a Context with cardinality 1+

Note that although Figure 3.1 states that a SimMachineDef contains inputContext and outputContext of cardinality [0..1], the ECore model has lower bound 1. Currently the validator does not complain about missing input / output contexts. Nor does it check whether the StateMachineDef also requires/provides interfaces.

The following issues need to be addressed:

1. Are input and output contexts optional? If they are, then why isn't the lower bound in the ECore model 0? Related, can a SimMachineDef only receive inputs, or only produce outputs? I guess it can?
2. The Context attributes inherited from StateMachine, such as rInterfaces, pInterfaces and interfaces, as well as events and operations should not be used. But variableList should be permitted, as it is the only way to define variables and constants local to the state machine. We need validation rules for this in ECore.

@madielfilho do you agree with the above?

[madielfilho]

The following issues need to be addressed:

Are input and output contexts optional?

Yes, they are, as far as I am aware.

If they are, then why isn't the lower bound in the ECore model 0? There might be an error in the ECore.

Related, can a SimMachineDef only receive inputs, or only produce outputs? Yes

The Context attributes inherited from StateMachine, such as rInterfaces, pInterfaces and interfaces, as well as events and operations should not be used. But variableList should be permitted, as it is the only way to define variables and constants local to the state machine. We need validation rules for this in ECore. Events, operations and pInterfaces should not be used, but, as far I am aware, rInterfaces, interfaces and variableList should be permitted. I think we have an example that has rInterfaces outside the input/output context.

@pefribeiro, I will try to have a meeting with Augusto to discuss better about such issues.

[pefribeiro]

Events, operations and pInterfaces should not be used, but, as far I am aware, rInterfaces, interfaces and variableList should be permitted. I think we have an example that has rInterfaces outside the input/output context.

I suppose this is so that a software operation can be required by a SimMachineDef. Sorry I forgot about that case. But variables required by a SimMachineDef that are defined in a controller should be in the input/output contexts?

So I suppose software operations should not be in input and output contexts?

@pefribeiro, I will try to have a meeting with Augusto to discuss better about such issues.

Ok, thanks @madielfilho.

[pefribeiro]

In general, I don't think the observation in the manual is accurate:

Declarations in a simulation machine are partitioned into three Contexts: local declarations, inputs and outputs.

Strictly speaking it isn't a partition, and furthermore, as discussed above, SimMachineDef is itself already a Context. Some elements may appear in both input and output contexts:

1. Are variables required by a SimMachineDef, and defined in a controller, to appear in both input/output contexts?
2. Are variables required by a SimMachineDef, but provided in a platform, and thus required also by the controller, to appear in both input/output contexts, or should they only be required in the Context inherited by SimMachineDef? This is confusing for me at the moment.

I think we need a precise set of rules that characterise exactly what is, and isn't, an input or output.

Thanks again @madielfilho .