=Paper=
{{Paper
|id=Vol-2019/exe_1
|storemode=property
|title=Create and Play Your Pac-Man Game with the GEMOC Studio
|pdfUrl=https://ceur-ws.org/Vol-2019/exe_1.pdf
|volume=Vol-2019
|authors=Dorian Leroy,Manuel Wimmer,Erwan Bousse,Benoit Combemale,Wieland Schwinger
|dblpUrl=https://dblp.org/rec/conf/models/LeroyWBCS17
}}
==Create and Play Your Pac-Man Game with the GEMOC Studio==
https://ceur-ws.org/Vol-2019/exe_1.pdf
Create and Play your Pac-Man Game
with the GEMOC Studio
(Tool Demonstration)
Dorian Leroy∗ , Erwan Bousse† , Manuel Wimmer‡ , Benoit Combemale§ , Wieland Schwinger¶
∗¶ JKU Linz (Austria), †‡ TU Wien (Austria), ‡ CDL-MINT (Austria), § Université de Rennes 1 (France)
dorian.leroy@cis.jku.at, erwan.bousse@tuwien.ac.at, wimmer@big.tuwien.ac.at,
benoit.combemale@irisa.fr, wieland.schwinger@jku.ac.at
Abstract—Executable Domain-Specific Languages (DSLs) are The demonstrated tool aims to solve this problem. It is
used for defining the behaviors of systems. The operational developed as an extension to the GEMOC Studio [7], an Eclipse-
semantics of such DSLs may define how conforming models based language and modeling workbench for executable DSLs.
react to stimuli from their environment. This commonly requires
adapting the semantics to define both the possible domain- It provides a non-intrusive and modular way to define both
level stimuli, and their handling during the execution. However, the possible domain-specific events and their handling logic
manually adapting the semantics for such cross-cutting concern within the operational semantics of a DSL. It then generates
is a complex and error-prone task. In this paper, we present an an interface to safely send event occurrences to a model being
approach and a tool addressing this problem by augmenting the executed, i.e., only when the model is in a consistent state. An
operational semantics for handling stimuli, and by automatically
generating a complete behavioral language interface from this extension to the execution environment has been developed
augmentation. At runtime, this interface can receive stimuli to use this interface. The use of this tool is illustrated with a
sent to models, and can safely handle them by interrupting the Pac-Man DSL ([8], [9]) allowing to define customized versions
execution flow. This tool has been developed for the GEMOC of the world-famous Pac-Man video game, which can then be
Studio, a language and modeling workbench for executable DSLs. played. The tooling as well as the example presented in this
We demonstrate how it can be used to implement a Pac-Man DSL
enabling the creation and execution of Pac-Man games. paper are available on Github12 .
Index Terms—Model Execution; Reactive DSLs; Code Gener- The remainder of this paper is structured as follows. In
ation Section II, we provide an overview of the architecture of the
tool. Section III details the Pac-Man use case. Finally, future
I. I NTRODUCTION research directions are given in Section IV.
A large number of Domain-Specific Languages (DSLs)
II. A RCHITECTURE
geared toward the description of the behavior of systems
(e.g., [1], [2], [3], [4], [5]). Enabling the execution of their In this section we present the architecture of the tool, which
conforming models allows to make the most out of those is developed as a reactive extension to the GEMOC Studio
models. This requires the definition of the execution semantics and is written in Java and Xtend.
of these languages, including how conforming models react to A. Executable DSLs and Event Handlers Annotation
stimuli from their environment [6]. This includes the definition
The tool presented in this paper supports DSLs whose
both of possible domain-specific events—i.e., the different types
abstract syntax is provided as a metamodel and whose execution
of stimuli in the considered domain—and of how occurrences
semantics is provided as an operational semantics. The con-
of said events are to be handled.
sidered operational semantics can be decomposed in i) a data
But incorporating events handling logic within operational
structure representing the model state and ii) a set of execution
semantics is a difficult task, as it impacts both the content
rules. The model state is defined in an execution metamodel
(e.g., adding event-processing code in existing execution rules)
extending the abstract syntax metamodel. Before the execution,
and the scheduling of execution rules (e.g., defining instants in
models are initialized through a transformation from the
the execution when stimuli should be handled). In addition, at
abstract syntax to the execution metamodel. Model execution
runtime, it is necessary to provide an interface to allow external
is performed by an endogenous, in-place transformation on
actors (e.g., a simulator, a test engine, other models, etc.) to
this model state, using the set of execution rules constituting
send event occurrences to models being executed. Depending
the operational semantics of the DSL. The approach relies on
on how a semantics is structured, this may require a mechanism
providing an annotation mechanism to tag execution rules
to temporarily interrupt the execution of the model (similarly
as event handlers. This allows the identification of both
to interruptable models in the DEVS formalism [6]), in order to
events and their corresponding handler. In the GEMOC Studio,
react to event occurrences by triggering their handling. Overall,
Ecore [10] is used as a metamodeling language to define
manually defining such interface and its integration with the
semantics can be a tedious and error-prone task, which must 1 https://github.com/eclipse/gemoc-studio
be repeated for each executable DSL. 2 https://github.com/tetrabox/pacman-example.git
PacMan
PacManInterpreter EventManager ExecutionEngine
EventInterpreter
gameLoop()
loop [while !gameOver()]
update(dt)
notify()
processEvents()
loop [for evt in eventQueue]
opt [canProcess(evt)] dispatchEvent(evt)
executeRule
(evt.name,evt.params)
Fig. 1: Sequence diagram of a call to manageEvents.
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 [11] and the xMOF parameters stored within the provided event model and calls
language [12]. For example, in Kermeta, an @Step annotation the corresponding execution rule with these parameters.
allows to tag methods as execution steps. This annotation has
been extended with the eventHandler boolean parameter. D. Event manager
This parameter fulfills the role required to tag execution rules The event manager is the component linking the execution
as event handlers. engine to the generated event interpreter. It has a dynamic state
composed of the event queue which is a list of models con-
B. 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 External components use the behavioral language interface
rules of the operational semantics, and notifies the execution to interact with executed models, through the event manager.
engine when such a rule is executed (here the update rule). The These components can listen to the execution by registering as
execution engine then delegates the handling of events to the listeners to the execution engine. This way they are notified
event manager, through the processEvent service. In turn, the when the execution starts, stops or reaches a consistent state,
event manager iterates over its event queue and delegates for which allows them to perform their intended task with reliable
each event the call of the corresponding execution rule to the data (i.e., the model’s dynamic state). These components also
(generated) DSL event interpreter, through the dispatchEvent have access to the services provided by the event interpreter
service. These two components are detailed below. to check if particular stimuli can be processed in the current
execution state and to push stimuli to the queue. The Pac-
C. Behavioral Language Interface Man GUI (presented below) is such an external component,
The behavioral language interface of an executable DSL refreshing the view when receiving notifications from the
allows external actors to send stimuli to executed models. It engine, and forwarding the user’s inputs to the behavioral
can be decomposed as a domain-specific event metamodel and interface of the Pac-Man DSL under the form of instances
a domain-specific event interpreter. These artifacts are both from its event metamodel.
generated from the annotated execution semantics of the DSL
by a generator implemented in Xtend taking the definition of the III. T HE PAC -M AN EXAMPLE
DSL as input. This generator uses the annotation mechanism In this section we detail the Pac-Man DSL used in this tool
provided by the approach to detect execution rules that are demonstration.
Abstract Syntax Execution Metamodel
bottom AbstractTile AbstractPellet
top 0..1
0..1 AbstractTile Board targetTile 0..1
tiles
left 1 pellet
0..1
0..* PassableTile
right
0..1
merges currentTile Tile
entities 1
initialTile 0..*
Entity
WallTile PassableTile 1 Entity SuperPellet Pellet
+speed: int
Pacman
Ghost +pelletsEaten: int
Tile GhostHouseTile Pacman Ghost +lives: int
+energized: boolean
Execution Rules imports
gameLoop(Board: board) update(Entity: entity, int: deltaTime) activate(Ghost: ghost)
update(Board: board, int: deltaTime) enterNextTile(Entity: entity) energize(Pacman: pacman)
modifySpeed(Entity: entity, int: speed)
@EventHandler @EventHandler @EventHandler @EventHandler
up(Pacman: pacman) down(Pacman: pacman) left(Pacman: pacman) right(Pacman: pacman)
Fig. 2: Overview of the Pac-Man DSL.
event pacman Algorithm 1: gameLoop
<> Input: board
Pacman
Event 1 begin
2 previousTime ← nanoTime()
pacman 1 3 while ¬gameOver () do
pacman.event 4 currentTime ← nanoTime()
<>
5 δt ← currentTime − previousTime
<> 6 board.update(δt)
PacmanEvent
PacmanDSLEvent 7 if δt < targetFrameRate then
+pacman: Pacman 8 sleep(targetFrameRate − δt)
9 previousTime ← currentTime
PacmanUpEvent PacmanDownEvent
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 [10] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks, EMF: Eclipse
in Figure 3. Modeling Framework, 2nd Edition. Eclipse Series, Addison-Wesley
Professional, 2008.
User Interface: The user interface has been specifically [11] J.-M. Jézéquel, B. Combemale, O. Barais, M. Monperrus, and F. Fouquet,
developed for the Pac-Man DSL. It is implemented in JavaFX “Mashup of metalanguages and its implementation in the Kermeta
and consists of two parts: an editor presenting useful tools to language workbench,” Software and Systems Modeling, vol. 14, no. 2,
2013.
build a Pac-Man game, and the actual game interface, which [12] T. Mayerhofer, P. Langer, M. Wimmer, and G. Kappel, “xMOF: Exe-
receives events from the keyboards and delegates them to the cutable DSMLs based on fUML,” in Proceedings of the 6th International
behavioral interface through the event manager. The game Conference on Software Language Engineering (SLE’13), vol. 8225 of
LNCS, Springer, 2013.
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. F UTURE W ORK
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 Aus-
trian 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 Min-
istry of Education, Higher Education and Research (MENESR);
Austrian Federal Ministry of Science, Research and Economy
and the National Foundation for Research, Technology and
Development.
R EFERENCES
[1] Object Management Group, “Semantics of a Foundational Subset for
Executable UML Models, V 1.1,” August 2013.
[2] R. Bendraou, B. Combemale, X. Crégut, and M. P. Gervais, “Definition
of an executable SPEM 2.0,” in Proceedings of the 14th Asia-Pacific
Software Engineering Conference (APSEC’07), pp. 390–397, IEEE, 2007.
[3] T. Fischer, J. Niere, L. Torunski, and A. Zündorf, “Story Diagrams: A
New Graph Rewrite Language Based on the Unified Modeling Language
and Java,” in Proceedings of the 6th International Workshop Theory and
Application of Graph Transformations (TAGT’98), vol. 1764, pp. 157–167,
2000.
[4] D. Harel, H. Lachover, A. Naamad, A. Pnuelli, M. Politi, R. Sherman,
A. Shtull-trauring, and M. Trakhtenbrot, “STATEMATE: a working
environment for the development of complex reactive systems,” IEEE
Transactions on software engineering, vol. 16, no. 4, pp. 403–414, 1990.
[5] OASIS, “Web Services Business Process Execution Language Version
2.0,” 2007.
[6] Y. V. Tendeloo and H. Vangheluwe, “An introduction to classic DEVS,”
CoRR, vol. abs/1701.07697, 2017.
[7] E. Bousse, T. Degueule, D. Vojtisek, T. Mayerhofer, J. Deantoni, and
B. Combemale, “Execution Framework of the GEMOC Studio (Tool
Demo),” in Proceedings of the 9th International Conference on Software
Language Engineering (SLE’16), SLE 2016, p. 8, 2016.
[8] R. Heckel, “Graph transformation in a nutshell,” Electr. Notes Theor.
Comput. Sci., vol. 148, no. 1, pp. 187–198, 2006.
[9] E. Syriani and H. Vangheluwe, “A modular timed graph transformation
language for simulation-based design,” Software and System Modeling,
vol. 12, no. 2, pp. 387–414, 2013.