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.