-Executable Domain-Specific Languages (DSLs) are used for defining the behaviors of systems. The operational semantics of such DSLs may define how conforming models react to stimuli from their environment. This commonly requires adapting the semantics to define both the possible domainlevel stimuli, and their handling during the execution. However, manually adapting the semantics for such cross-cutting concern is a complex and error-prone task. In this paper, we present an approach and a tool addressing this problem by augmenting the operational semantics for handling stimuli, and by automatically generating a complete behavioral language interface from this augmentation. At runtime, this interface can receive stimuli sent to models, and can safely handle them by interrupting the execution flow. This tool has been developed for the GEMOC Studio, a language and modeling workbench for executable DSLs. We demonstrate how it can be used to implement a Pac-Man DSL enabling the creation and execution of Pac-Man games. Index Terms-Model Execution; Reactive DSLs; Code Generation
I. INTRODUCTION
A large number of Domain-Specific Languages (DSLs)
geared toward the description of the behavior of systems
(e.g., [
But incorporating events handling logic within operational
semantics is a difficult task, as it impacts both the content
(e.g., adding event-processing code in existing execution rules)
and the scheduling of execution rules (e.g., defining instants in
the execution when stimuli should be handled). In addition, at
runtime, it is necessary to provide an interface to allow external
actors (e.g., a simulator, a test engine, other models, etc.) to
send event occurrences to models being executed. Depending
on how a semantics is structured, this may require a mechanism
to temporarily interrupt the execution of the model (similarly
to interruptable models in the DEVS formalism [
The demonstrated tool aims to solve this problem. It is
developed as an extension to the GEMOC Studio [
The remainder of this paper is structured as follows. In Section II, we provide an overview of the architecture of the tool. Section III details the Pac-Man use case. Finally, future research directions are given in Section IV.
The tool presented in this paper supports DSLs whose
abstract syntax is provided as a metamodel and whose execution
semantics is provided as an operational semantics. The
considered operational semantics can be decomposed in i) a data
structure representing the model state and ii) a set of execution
rules. The model state is defined in an execution metamodel
extending the abstract syntax metamodel. Before the execution,
models are initialized through a transformation from the
abstract syntax to the execution metamodel. Model execution
is performed by an endogenous, in-place transformation on
this model state, using the set of execution rules constituting
the operational semantics of the DSL. The approach relies on
providing an annotation mechanism to tag execution rules
as event handlers. This allows the identification of both
events and their corresponding handler. In the GEMOC Studio,
Ecore [
gameLoop()
loop
[while !gameOver()] update(dt) loop opt [for evt in eventQueue] [canProcess(evt)] executeRule (evt.name,evt.params) notify() dispatchEvent(evt) processEvents()
the abstract syntax and the execution metamodel of DSLs. event handlers. The outputs of the generator are an Ecore
One goal of the underlying approach is to support multiple event metamodel and a Java class providing the dispatchEvent
metaprogramming languages to define the operational semantics service. As shown on Figure 1, this service retrieves the
of DSLs. We support the Kermeta language [
The event manager is the component linking the execution engine to the generated event interpreter. It has a dynamic state composed of the event queue which is a list of models conB. Execution Engine forming to the domain-specific event metamodel (i.e., domain
Within the GEMOC Studio, model execution is orchestrated specific stimuli) part of the behavioral language interface. The by a component called the execution engine. Among other event manager provides the queueEvent service, which is used things, this component is responsible for starting and stopping by external components to push event occurrences to the event the execution. It is notified whenever the execution of a rule is queue. The processEvents service of the event interpreter is about to begin or comes to an end. During such notifications, called by the execution engine each time the execution reaches the engine guarantees that there is no ongoing atomic execution a new consistent state. It leads to the temporary interruption step, which means that the executed model is in a consistent of the planned scheduling of execution rules in order to call state. A component can be notified each time the model reaches the handling rule corresponding to each event occurrence in such a state by registering as a listener to the execution engine. the event queue.
Figure 1 shows how we leverage the notifications sent to the execution engine to introduce event processing in the execution E. External Components loop. The DSL (Pac-Man in Figure 1) interpreter executes the rules of the operational semantics, and notifies the execution engine when such a rule is executed (here the update rule). The execution engine then delegates the handling of events to the event manager, through the processEvent service. In turn, the event manager iterates over its event queue and delegates for each event the call of the corresponding execution rule to the (generated) DSL event interpreter, through the dispatchEvent service. These two components are detailed below.
External components use the behavioral language interface to interact with executed models, through the event manager.
These components can listen to the execution by registering as listeners to the execution engine. This way they are notified when the execution starts, stops or reaches a consistent state, which allows them to perform their intended task with reliable data (i.e., the model’s dynamic state). These components also have access to the services provided by the event interpreter to check if particular stimuli can be processed in the current execution state and to push stimuli to the queue. The PacMan GUI (presented below) is such an external component, refreshing the view when receiving notifications from the engine, and forwarding the user’s inputs to the behavioral interface of the Pac-Man DSL under the form of instances from its event metamodel.
The behavioral language interface of an executable DSL allows external actors to send stimuli to executed models. It can be decomposed as a domain-specific event metamodel and a domain-specific event interpreter. These artifacts are both generated from the annotated execution semantics of the DSL by a generator implemented in Xtend taking the definition of the DSL as input. This generator uses the annotation mechanism provided by the approach to detect execution rules that are
top 0..1 left 0..1 1 targetTile
PassableTile 1
Entity +speed: int Ghost 0..1 pellet
SuperPellet Pellet
Pacman +pelletsEaten: int +lives: int +energized: boolean
imports activate(Ghost: ghost) energize(Pacman: pacman) Execution Rules gameLoop(Board: board) update(Board: board, int: deltaTime) update(Entity: entity, int: deltaTime) enterNextTile(Entity: entity) modifySpeed(Entity: entity, int: speed) @EventHandler @EventHandler down(Pacman: pacman) left(Pacman: pacman) @EventHandler right(Pacman: pacman) PacmanLeftEvent PacmanRightEvent and a Pacman has a number of initialLives.
The domain targeted by this DSL is thus the definition of
Pac-Man games, including the topology of the level (walls, Fig. 3: Event metamodel generated for the Pacman DSL. ghost house and pellets), the number of ghosts, their behavior and the starting positions and number of ghosts and pacmen.
Operational Semantics: The real-time aspect of the
Abstract Syntax: Figure 2 shows the abstract syntax execution semantics is obtained by using a classic game loop, of the Pac-Man DSL as well as its execution metamodel. illustrated by Algorithm 1. Thread sleeps are used in order to A Board is composed of AbstractTiles and Entities. An reach a target frame rate. The lower part of Figure 2 shows a AbstractTile can be a PassableTile or a WallTile. PassableTiles subset of the execution rules of the Pac-Man DSL. Entities have are further refined into Tiles and GhostHouseTiles. Tile an update rule used to check whether they reached a new has an initialPellet attribute indicating which type of Tile according to their speed and the time they already spent pellet the tile contains, if any. Lastly, an AbstractTile has in their current Tile. Entities also have an enterNextTile two bidirectional references to its neighboring AbstractTiles: rule that takes care of the actual move and deals with the right (the opposite being left), and bottom (the opposite consequences of this move (e.g., killing the Pacman if a Ghost being top). An Entity can either be a Pacman or a Ghost and reaches the same Tile, eating the Pellet present on the Tile, points to an initial PassableTile where it starts the game and etc.). The Pacman entity has a set of rules (up, down, left where its position is reset when a Pacman loses a life or a and right) allowing it to change its direction. These rules are Ghost is eaten. Not shown on the class diagram, a Ghost also annotated as an event handlers, which means that events can be has a personality dictating its behavior during the game, sent to the model to change the direction of the pacman. The event metamodel generated from these annotations is shown in Figure 3.
User Interface: The user interface has been specifically developed for the Pac-Man DSL. It is implemented in JavaFX and consists of two parts: an editor presenting useful tools to build a Pac-Man game, and the actual game interface, which receives events from the keyboards and delegates them to the behavioral interface through the event manager. The game interface is implemented as an execution engine listener and updates its view when notified by the engine that a call to the update execution rule of the Board has been completed.
IV. FUTURE WORK
The direct perspectives of this work include the three following research topics. First, defining and the handling of output events occurrences sent by an executed model to its environment. This would be a first step toward enabling co-simulation in a generic way. Second, the combined use of behavioral language interfaces and temporal property languages would allow to investigate activities such as testing or runtime monitoring for executable DSLs. Third, the implementation of the underlying approach with another meta-programming language such as xMOF.
Acknowledgements—This work has been funded by: the Austrian Science Fund (FWF): P 28519-N31; the Austrian Agency for International Mobility and Cooperation in Education, Science and Research (OeAD) on behalf of the Federal Ministry for Science, Research and Economy (BMWFW) under the grand number FR 08/2017, by the French Ministries of Foreign Affairs and International Development (MAEDI), and the French Ministry of Education, Higher Education and Research (MENESR); Austrian Federal Ministry of Science, Research and Economy and the National Foundation for Research, Technology and Development.