=Paper=
{{Paper
|id=Vol-2019/mdebug_4
|storemode=property
|title=Domain-level Debugging for Compiled DSLs with the GEMOC Studio
|pdfUrl=https://ceur-ws.org/Vol-2019/mdebug_3.pdf
|volume=Vol-2019
|authors=Erwan Bousse,Tanja Mayerhofer,Manuel Wimmer
|dblpUrl=https://dblp.org/rec/conf/models/BousseMW17
}}
==Domain-level Debugging for Compiled DSLs with the GEMOC Studio==
https://ceur-ws.org/Vol-2019/mdebug_3.pdf
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).