Domain-Level Debugging for Compiled DSLs with the GEMOC Studio (Tool Demo) Erwan Bousse Tanja Mayerhofer Manuel Wimmer TU Wien TU Wien CDL-MINT, TU Wien Vienna, Austria Vienna, Austria Vienna, Austria Email: erwan.bousse@tuwien.ac.at Email: mayerhofer@big.tuwien.ac.at Email: wimmer@big.tuwien.ac.at Abstract—Executable Domain-Specific Languages (DSLs) are resulting execution yields information specific to the target commonly defined with either operational semantics (i.e., in- language instead of the considered DSL, i.e., there is no terpretation) or translational semantics (i.e., compilation). An feedback at the domain level. For instance, when lower-level interpreted DSL relies on domain concepts to specify the pos- sible execution states and steps of conforming models, which code or models are generated from a model, it is common to facilitates the observation and control of the execution using only rely on the debugger of the target language to debug the very same domain concepts. In contrast, a compiled DSL the execution, but without the possibility to directly relate relies on a transformation to an arbitrarily different executable information back to the original model. target language, which creates a conceptual and technical gap In this paper, we present the implementation of our approach between the considered domain and the target domain. In this tool demonstration paper, we present the implementation of to supplement a compiled DSL with a feedback manager. our approach to supplement a compiled DSL with a feedback During the execution of a model, this component translates manager, which during execution translates execution steps and execution steps and states of the target model back to the states of the target model back to the source domain. This enables source domain. Generic tools, such as an omniscient debugger the development and use of tools such as an omniscient debugger (i.e., a tool to explore past and future execution states) and a and a trace constructor for debugging compiled models. Our implementation was achieved for the GEMOC Studio, a language trace constructor, can thereby be used for debugging compiled and modeling workbench that provides generic model debugging models at the domain level. We realized this implementation tools for interpreted DSLs. With our approach, these debugging for the GEMOC Studio, a language and modeling workbench. tools can be also used for compiled DSLs. Our demonstration Our demonstration shows the definition of a feedback manager features the definition of a feedback manager for a subset of for a subset of fUML that compiles to Petri nets. fUML that compiles to Petri nets. II. T HE GEMOC S TUDIO I. I NTRODUCTION The GEMOC Studio (http://gemoc.org/studio) is a work- A large amount of Domain-Specific Languages (DSLs) have bench atop the Eclipse Modeling Framework (EMF) including: been proposed to describe the dynamic aspects of systems. • The GEMOC Language Workbench, used by language Defining the execution semantics of such DSLs opens the designers to build and compose new executable DSLs. possibility to use dynamic verification and validation (V&V) • The GEMOC Modeling Workbench, used by domain techniques, such as interactive debugging or tracing. Two designers to create, execute models conforming to DSLs. approaches are commonly used to define the semantics of The different concerns of an executable DSL, as defined an executable DSL: operational semantics (i.e., interpretation) with the tools of the language workbench, are deployed into resulting in an interpreted DSL, and translational semantics the modeling workbench. This configures a generic execution (i.e., compilation) resulting in a compiled DSL. framework that provides various generic runtime services, such Dynamic V&V techniques rely on two key tasks: the as graphical animation, omniscient debugging, trace and event observation of the progress of the execution (e.g., which managers, timeline visualizations, etc. Originally, the GEMOC execution steps are occurring), and the control of the execution Studio focused on providing facilities to design and implement (e.g., pausing and resuming). In the case of an interpreted interpreted DSLs. In this work, we extend GEMOC Studio to DSL, the dynamic state of a model is defined along with also support the design and implementation of compiled DSLs, the possible execution steps that modify such state over time. thereby enabling the application of existing runtime services These definitions can directly rely on domain-specific con- and model execution tools for compiled models. cepts, opening the possibility to observe and control executions from a domain perspective (e.g., visualizing the current token III. C OMPILED DSL S IN THE GEMOC S TUDIO distribution in an activity diagram). However, in the case of a We extended the GEMOC Studio with facilities to define compiled DSL, a model is translated into a model conforming and use compiled DSLs. The source code of the presented to another executable language. By default, observing the extension to the GEMOC Studio, along with the example, is Language workbench Language (target while implementing an fUML activities DSL that compiles to (source DSL) workbench language) Petri nets. Figure 2 is a screenshot of the expected workbench. Source Target abstract Compiler abstract At the top-left corner, the Ecore abstract syntaxes of both syntax syntax languages are shown. At the top-right corner, the Kermeta Source Source Target Target semantics of the target language is shown. At the bottom left Compilation state definition executed model links executed model state definition corner, an excerpt of the compiler is shown. Although it is implemented in Xtend, any model transformation language can Feedback Feedback Runtime services Target Execution be used. At the bottom right corner, an excerpt of the feedback manager Engine Engine rules ... manager is shown, also written in Xtend. Tracer The second part of the demonstration consists in showing Source Target steps Debugger steps the point of view of the modeler while executing an fUML Modeling workbench activity diagram model in the debugging environment of the GEMOC Modeling Workbench. Figure 3 is a screenshot of the Depends on / Uses Conforms to Input/output Modifies Procedure Model Generated Model expected workbench. At the bottom left corner, the executed activity is shown, while the target Petri net obtained by compilation is shown to its right. This Petri net is executed Fig. 1. Overview of the architecture. by an interpreter, while the feedback manager of the activity diagram DSL continuously translates target steps and states currently available on Github1 under the EPL 1.0 license, and back to the activity diagram model. Thanks to the feedback, consists in multiple Eclipse plugins written in Xtend and Java. the activity diagram is automatically animated during the Figure 1 shows an overview of the approach. The source execution of the Petri net (i.e., the token flow is displayed). DSL is shown on the left, with translational semantics real- The remaining panels are all dedicated to debugging, and in- ized by a compiler. This compiler is a model transformation directly rely on information provided by the feedback manager. from the source abstract syntax to the target abstract syntax, At the top left, the stack panel displays all ongoing activity defined with any model transformation language compatible diagram execution steps. Thanks to the feedback manager, it with Ecore metamodels. The core part of our approach is the shows that the activity fork node is currently offering a token, feedback manager of the source DSL, which translates target instead of showing that a transition of the Petri net is being states and steps into source states and steps. It is defined by fired. At the top right, the variable view shows the dynamic the language engineer using any Java-compatible language. data contained in the activity diagram state updated by the The language designer must also define what is the state of a feedback manager, i.e., the tokens held by nodes and edges. model conforming to the source DSL. Both source and target At the bottom right, the execution trace being constructed is languages are defined in the GEMOC Language Workbench. shown, which represents the activity diagram execution instead In the middle, the execution of the source model in the of the Petri net execution. This trace is used by the underlying GEMOC Modeling Workbench is shown. First, the source omniscient debugger, which can be used to revisit past states model is compiled into a target model. Then, the execution of the activity diagram by double clicking on the states. of the target model is performed by an execution engine V. C ONCLUSION using execution semantics of the target language2 . Using this mechanism, the feedback manager of the source DSL We have shown the implementation of our approach to registers itself as a listener of the target engine. Then, the provide domain-level debugging facilities for compiled DSLs feedback manager is used by the generic feedback engine to in the GEMOC Studio. Future work includes the management translate at runtime the target states and steps into source states of compilers written as code generators, and more generally fa- and steps. The feedback engine finally notifies its own set cilitating the use of target languages not initially implemented of listeners (e.g., an interactive debugger or a tracer) about with the GEMOC Language Workbench. occurring source execution steps, i.e., at the domain-level. ACKNOWLEDGMENTS Concretely, these listeners are oblivious of the underlying This work has been funded by: the Austrian Science Fund target model execution, and only perceive that the source (FWF): P 28519-N31; the Austrian Agency for International model is actually being executed. They can therefore be used Mobility and Cooperation in Education, Science and Research both with interpreted and compiled DSLs. (OeAD) on behalf of the Federal Ministry for Science, Re- IV. D EMO search and Economy (BMWFW) under the grand number The first part of the demonstration shows the point of view FR 08/2017, by the French Ministries of Foreign Affairs and of the language engineer in the GEMOC Language Workbench International Development (MAEDI), and the French Ministry of Education, Higher Education and Research (MENESR); and 1 https://github.com/ebousse/gemoc-compilation-engine the Austrian Federal Ministry of Science, Research and Econ- 2 If the target language is interpreted, the execution engine uses the omy and the National Foundation for Research, Technology operational semantics of the DSL. If the target language is compiled, then the engine is a feedback engine itself and behaves as explained in this section. and Development. Fig. 2. Screenshot of the GEMOC Language workbench, while implementing a compiled activity diagram DSL. The abstract syntaxes of the source language (activity diagram, top left) and target language (Petri nets, top middle) are shown, along with the semantics of the target language (top right), the compiler (bottom left) and the feedback manager (bottom right). Fig. 3. Screenshot of the GEMOC Modeling Workbench, during an omniscient debugging session of an activity diagram (bottom left) compiled to a Petri net (bottom center). While the underlying Petri net is being executed, feedback is provided by animating the activity diagram (bottom left), showing the stack of domain-level steps (top left), current domain-level dynamic data (top right), and a domain-level execution trace (bottom right).