Modelling a Finite State Machine

The objectives of this step are the following:

  • Create a metamodel dedicated to a given problem;
  • Tool the model with code generation capabilities;
  • Reach an execution environment.

Metamodel description

As stated in the previous step, a finite state machine is a good abstraction for the blinking LED example. We define a meta-model to express such pieces of software, where an App contains several States, and interact with Actuators. In each state, a sequence of Actions identify which SIGNAL must be sent to the Actuators for this very state. Finally, a State contains a single transition with the next one.

Instantiating models at the code level

As the meta-model is naive in terms of implementation (plain Java classes with getters and setters), so creating a model that conforms to this meta-model (here objects instantiated from the classes) is quite verbose.

Actuator led = new Actuator();
led.setName("LED");
led.setPin(13);

// Declaring states
State on = new State();
on.setName(“on”);

State off = new State();
off.setName(“off”);

// Creating actions
Action switchTheLightOn = new Action();
switchTheLightOn.setActuator(led);
switchTheLightOn.setValue(SIGNAL.HIGH);

Action switchTheLightOff = new Action();
switchTheLightOff.setActuator(led);
switchTheLightOff.setValue(SIGNAL.LOW);

// Binding actions to states
on.setActions(Arrays.asList(switchTheLightOn));
off.setActions(Arrays.asList(switchTheLightOff));

// Binding transitions to states
on.setNext(off);
off.setNext(on);

// Building the App
App theApp = new App();
theApp.setName(“Led!”);
theApp.setBricks(Arrays.asList(led));
theApp.setStates(Arrays.asList(on, off));
theApp.setInitial(on);

Generating code

To generate the FSM code, we use the Visitor design pattern. A Visitor is used to walk through a given model, externalizing the behaviour associated with such a visit. Using this pattern, it is possible to implement several visitors for the same meta-model, for different code generations for example.

For a meta-model element to be compatible with the visitor pattern, it should implement the Visitable interface. This is an invasive modification of the meta-model, but it actually helps maintenance as to create a new visit, one simply extend a Visitor class and do not have to modify the meta-model again.

The pattern relies on the double dispatch mechanism to trick the java compiler. Each meta-model element accepts an instance of a Visitor, and dispatches it to the visit method of the given visitor. Thanks to Java’s overloading method mechanism, the JVM selects the right method of the Visitor, i.e., the one with the right signature.

Expected Work

  • Read the Java code in the step5 directory to understand how the metamodel is implemented as Java classes;
  • Read the provided Visitor code to understand how the visit works;
  • Run the code generator
  • Modify the meta-model to introduce sensors used to transition from one state to another (like pressing a button). Adapt the code generation too.
  • Identify the right meta-model element to support the 7-segments display

Stepback questions

  • What are the pros/cons associated with this metamodeling approach? What is the cost of defining a meta-model? What is difficult in this activity?
  • From the user’s point of view, what does it change? Is the approach usable for large apps?
  • Consider the LED app and the counter one as two separate models. Is it possible to automate the creation of the final app based on these two models?
  • What about the readability of the generated code compared to the previous one “by hand”? Its debugging capabilities? Its extensiveness?
  • Explain the interest of modelling in terms of genericity, functional property verification.