NEW IN 1.1
Towards Object-Oriented Modeling in SCCharts. Alexander Schulz-Rosengarten and Steven Smyth and Michael Mendler. In Proc. Forum on Specification and Design Languages (FDL ’19), Southampton, UK, 2019.
SCCharts support inheritance, similar to the concept of referenced SCCharts (macro expansion).
Each root state can extend multiple base states (since the name super states is already used) by listing them after the extends keyword.
Such a state will inherit all declarations, action and regions of the base states. If conflicts arise or a state has a cyclic inheritance hierarchy, a warning will be displayed. If a state is contained multiple times in the inheritance hierarchy its content will inherited only once.
Declarations can have the private keyword to prevent extending SCCharts from accessing these variables.
Root-level regions of base states can be overridden with the override keyword and consequently replace the behavior by the new definition. Anonymous regions (defined without an ID) cannot be overridden.
Regions can also be references similar to states by using the is keyword. If the reference should refer to the implementation in the base state, the super keyword must be used.
Class declarations allow to define hierarchical data structures. They may contain variable and method declarations as members. This includes inner class declarations.
In SCCharts, variables of a class type are statically instantiated. Hence, read/write access is only permitted on members.
Note there are also struct declarations that are a subset of class declarations since they prohibit the optional declaration of methods.
As an alternative to class declarations, classes can also be modeled using SCCharts. Every SCChart, that has no input or output variables can be used as a class definition.
The most important advantage is that you can use inheritance in your class design. It is also possible to declare variables with a protected visibility. Furthermore, SCCharts now can define methods in addition to variables and regions, that might be helpful even if the SCChart is not used as an class definition.
Use ref declarations, as in SCCharts' Dataflow, to declare SCCharts-based classes. Same as class declarations these classes are statically instantiated for each variable. All regions in the SCCharts class instances will immediately start when the scope of the variable is entered.
Methods can be declared in classes, states and regions. They can be invoked in expressions, effects on transitions, and entry/exit/during actions w.r.t. scoping and visibility. Methods can take parameters and return a value. They can also access any variable in their scope (enclosing states/classes).
Method bodies contain imperative immediate code sections consisting of a restricted set of SCL (assignments, method calls, labels, gotos, return statements, if/else statements, and for or while loops).
To handle method calls the compiler usually inlines the body. Hence, each method call acts as a macro expansion. However, since the netlist-based approach does not support loops it uses a different strategy. If the method body contains loops or is rather long it will not be inlined but kept as a function even in the generated code. As a consequence, this approach cannot handle method calls in a concurrent context that require interleaving because without inlining the method calla are considered atomic. Hence, some programs might be rejected by the compiler. You can annotate method declarations with @inline to advice the compiler to inline this method.
The priority-based approach will always inline all method calls.
You can influence the default handling of methods in a compilation system by setting the respective compiler properties (see MethodProcessor)
Code effects are a shortcut notation for anonymous parameter-less method calls in effects of transitions and entry/exit/during actions.
Code effects follow the same rules as method bodies.
Class declarations also allow more advanced object oriented host code integration. Using the host keyword, the class will be treated as a host code type. The declaration allows to mimic the objects API with fields and methods by defining members. These members do not affect the code generation since the host class will be used directly from the host languages. However, in the SCChart itself this allows proper oo access to the host object.
Host classes can be augmented by Scheduling Directives that will affect the ordering of method calls in the SCChart.
Note that the this host class integration is not limited to Java, since host structs can be used for C. Additionally, the generated C code is usually c++ compatible.
You might have to annotate your host class/struct with a @typedef annotation to advice the C code generation to expect the class/struct to be defined via a typedef instead of a named struct.
#resource includes external files in the compilation and simulation of SCCharts.
#hostcode allows to insert host code above the generated code.