Though there is no rigorous definition of an action language in DCharts, it is a rule that each piece of action code in the output, enter/exit actions and all other parts of a model that allow actions, is composed of a series of statements. Those action statements are primitive commands that are not modeled explicitly. (The only exceptions are the extensions added by SVM, such as initializer, interactor and finalizer. Those constructs do not belong to the DCharts formalism.)
The problem whether DCharts are capable of modeling more complex programming structures is interesting. On the one hand, designers who are familiar with programming languages tend to think in a programming way. If a formalism allows the specification similar to a programming language, it is much friendly to those designers. On the other hand, this capability demonstrates the expressiveness of the formalism. It is possible to explicitly model any control structure with such a formalism. As a result, theoretically all the control structures in a system can be formally checked by modeling them in the formalism. When the model is checked thoroughly, part of it can be converted into native code or hardware to achieve better run-time performance.
This section discusses several programming constructs of programming languages in general (e.g., the C language [32]), and their mappings to DCharts submodels. Most of the submodels introduced here can be directly imported into larger models to simplify the task of designers.