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. A struct in C used as a host variable is expected to be defined as typedef not a named struct.
#resource includes external files in the compilation and simulation of SCCharts.
#hostcode allows to insert host code above the generated code.
UPCOMING 1.3 (NIGHTLY)
Even if enumerations are not a part of object orientation, they are added to SCCharts using the same object principle and notation.
Syntax and usage is inspired by Java rather than C, especially w.r.t. scoping.
An enum declaration declares the enumeration itself not a variable of this type (c.f. static instantiation of classes). A ref declaration then creates a variables that can hold enum values.
To access an enum type declared in a different SCChart the scchart accessor can be used to access the declaration (see example HostEnum)
The transformation will completely remove enumerations and will replace them by integer values. Hence, enumeration can be considered and alternative to named constants.
An enumeration can be declared as host enum requiring it to be present in the host language.