By Alexander Eigner and Paramvir ParharIntroduction
The aim of this project was to get first hands-on-experience in the Meta Programming System by implementing an own domain specific language in MPS. This DSL should be based on some main ideas from the fields of systems engineering and executable UML. By taking the structuring aspect of systems engineering into account this DSL should allow the user to model a system that is composed out of interlinked components. Following some ideas of executable UML this DSL should also allow the user to model behavioral aspects of a system and to execute (e.g. simulate) this system already during the design phase by means of code generation.
The Meta Programming System
For implementing our DSL we used a relatively new language workbench, namely Meta Programming System developed by JetBreains. JetBrains MPS is an open-source language workbench for language engineering. MPS itself is implemented in Java. It runs on the JVM and allows defining general-purpose as well as domain-specific languages. Unlike other implementa- tions MPS does not use a parser or grammer at all, but it uses structural editors, in which the textual syntax represents a projection of the abstract syntax tree (AST), hence the user edits directly on the abstract syntax tree. Therefore, MPS supports mixed notations like textual, symbolic, or graphical. The fact that MPS does not use a parser allows users to enable language modularization and com- position more easily. The projection of the AST guides the user through the development as it knows what is allowed and what not. MPS supports combining and extending different languages. In order to trans- late the DSL code into another language like Java it is necessary to do a model transformation.
Implemented DSL: ComponentStateCharts (CSC)
The name of the implemented domain specific language origins from two well known modeling diagram-types, the component diagram and the statechart diagram. CSC offers the possibility to model the structure of a system by allowing the user to define components and connect them with eachother via ports, which shows the similarity of our DSL to component diagrams. CSC also allows the user to define the behavior of a system by letting the user define a state machine for each component. Therefore the domain of CSC extends to the modeling of structured systems that consist out of interlinked components with specific behavioral features. CSC moreover allows the user to define a simple execution sequence, which is a sequence of function-calls of the components, in order to simulate a sequence of events on these components. In addition to that a CSC-to-Java generator was implemented that can generate a Java class for each component as well as a simulation class to simulate a concrete behavior of the components according to the defined execution sequence.
The main part of the evaluation was conducted by counting the number of code-lines that were needed to model a sample systen in CSC against the number of Java code-lines that were generated via the CSC-to-Java generator. This evaluation showed, that there was a huge saving in code-lines in CSC due to its laconic and error-tolerant syntax. Besides the saving of code-lines CSC also has some shortcomings. Due to the lack of time of this project it was not possible to implement a sophisticated concept for component-functions that e.g. could allow the user to define return types. This fact can lead the user to tedious coding-bypasses if he or she wishes to overcome that lack of return types.
There are several upgrade possibilities for CSC. Component-functions could for example have return types. The transitions of a component's statechart diagram could have guard conditions. Components could interact with eachother sophisticatedly via data streams. The use of Realtime UML could allow a wider range of analysis during the execution of a CSC model.