SCC (StateChart Compiler) 0.1 Documentation

Thomas Huining Feng
MSDL, School of Computer Science, McGill
http://msdl.cs.mcgill.ca/people/tfeng/
hfeng2@cs.mcgill.ca

Abstract:

SCC is a compiler for the extended statechart formalism. It generates efficient Java source code from textural description of models. This document gives a general overview of its design. Major algorithms and sample usage are also discussed here.

Before starting to read this document, the readers may want to take a look at the spectacular on-line demonstration:

an example model (from which Java code is generated) with a Java applet interface

Contents

• Motivation
• License
• Using SCC

Motivation

Simulation in SVM (Statechart Virtual Machine) is not efficient. It is not for practical purpose but just for testing or debugging. It is not attractive to run extended statechart models at such a speed, even if the formalism itself is modular, expressive and user-friendly.

The reasons for this slow speed can be summarized here:

• Python as a flexible interpretative programming language is very slow. It is impossible to achieve high speed with this language. It is only used as a prototyping language.
• Though the extended statechart formalism is highly expressive, it is an easy job to interpret it at run-time. The same problem exists in statecharts, which allows such constructs as state hierarchy, orthogonal components and history.
• Because of the above reasons, performance is not among the initial goals of SVM, and thus its design focus more on extensibility and functionality.

Moreover, dependence on Python makes it difficult to integrate models with other analysis and checking tools, simulation frameworks and hand-written libraries.

Because of all these reasons, SCC project is originated to compile models into source code. People can easily reuse this source code by including it in their own applications or modify it by hand. This code, as a result of optimization, will also give a boost in performance.

As an ultimate goal, SCC will be able to generate code in different programming languages such as Java, C++ and Python. This is to maximize reusability, since the same model can be compiled into different targets, depending on a command-line parameter. However, Java is chosen as the first language that is supported, though itself is not very efficient. This is because:

• Java is popular.
• Java is different enough from Python, so that the designer of SCC will not misuse language-specific constructs or packages, that may not be available in other languages.
• Java is platform-independent. This maximizes the use of the generated code.

License

SCC is distributed with SVM. This is because it reuses the intermediate result of the SVM parser and interpreter. In fact, SCC is a plugin module for SVM, which, instead of simulating the interpreted model as other modules, writes the model structure into a Java source file (after possible optimization).

Because of this, it has a GNU GPL (General Public License) as SVM.

Using SCC

SCC can be invoked from the command line, with a parameter as the file name of a model description (usually with .des postfix). It produces one single Java source file, which has the same name as the description, but with the postfix changed to .java.

A series of classes are defined in the generated Java file. These classes include super classes that serve a general purpose ( State, History, EventList, StringList and StateMachine) and model-specific classes. The model-specific classes extend StateMachine and define the structure and behavior of the model. The first model-specific class always has the same name as the Java file with its postfix removed. It is referred as main class.

Under the main class there may or may not be other classes that also extend StateMachine. These are the submodels that will be imported into the main model or other submodels in the same file.

The generated Java file can be compiled with javac in Java SDK 1.3 or higher. After it is compiled, a number of .class files are generated, each of which corresponds to a class in the source code. Among them, the class file with the same name (except postfix) as the source file and the model description can be executed with java. It has a default textural user interface implemented in the main function, which simply takes user input, trigger events, and display the current state.

As an example, write the following model description in sample.des:

  STATECHART:
    S1 [DS] [HS*]
      S2 [DS] [CS]
        S3 [DS]
        S4
      S5 [DS] [CS]
      S6 [DS] [CS]
    S7

  TRANSITION:
    S: S1.S2.S3
    N: S1.S2.S4
    E: 3-4

  TRANSITION:
    S: S1
    N: S7
    E: 1-7

  TRANSITION: [HS]
    S: S7
    N: S1
    E: 7-1h

This model tests orthogonal components ([CS]) and history states ([HS*]). Use the following commands to compile and execute it:

scc sample.des
# sample.java will be generated
javac sample.java
# EventList.class, History.class, State.class, StringList.class, Hierarchy.class, sample.class and StateMachine.class will be generated
java sample
# a textural interface is shown

To test the model in this interface:

1. When started, [S1.S6, S1.S5, S1.S2.S3] is shown as the current state of the model. It is a set of states (whose order is not important). As specified in the description, the default state is S1, and S1 has 3 orthogonal substates. The default substate of S1.S2 is S1.S2.S3. So the model is in 3 orthogonal leaf-states at the same time.
2. Type in 3-4 and enter. This will change the model to state [S1.S2.S4, S1.S6, S1.S5]. S1.S2.S4 is a non-default substate of S1.S2.
3. Send event 1-7. The model goes to [S7]. As it leaves S1, it is no longer in any of S1's orthogonal substates.
4. Send event 7-1h. The model goes to the deep history of S1. So the current state ([S1.S6, S1.S5, S1.S2.S4]) is the exactly same as the result of step 2 (before it leaves S1).

The complete output trace is shown below:

  $ java sample
  [S1.S6, S1.S5, S1.S2.S3] > 3-4
  [S1.S2.S4, S1.S6, S1.S5] > 1-7
  [S7] > 7-1h
  [S1.S6, S1.S5, S1.S2.S4] > exit
  $