Thomas Huining Feng
MSDL, School of Computer Science, McGill
Before starting to read this document, the readers may want to take a look at the spectacular on-line demonstration:
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:
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:
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.
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:
# sample.java will be generated
# EventList.class, History.class, State.class, StringList.class, Hierarchy.class, sample.class and StateMachine.class will be generated
# a textural interface is shown
To test the model in this interface:
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 $