Adding a HenshinEngine to GEMOC Studio An experience report Steffen Zschaler Department of Informatics, King’s College London London, UK szschaler@acm.org ABSTRACT Executable DSMLs (xDSMLs) are becoming more popular as a means of efficiently building domain-specific high-level models that are testable through simulations. To develop an xDSML, one needs to provide the abstract and concrete syntax, but also the operational semantics of the language. GEMOC Studio provides a language workbench for developing xDSMLs and their associated tooling. To date, it supports the expression of operational semantics Figure 1: A production-line system model in a number of imperative formats. GEMOC Studio is intended to easily support also operational semantics in other formats, but this idea has so far not been tested. In this paper, I report on my experience implementing a new execution engine for GEMOC Stu- dio that allows operational semantics to be expressed declaratively using graph-transformation rules written in Henshin. I hope that this experience report helps to (a) explore the current flexibility of GEMOC Studio and provide insights into areas that may benefit from refactoring, and (b) give some guidance to others wishing to develop their own execution engines for GEMOC Studio. 1 INTRODUCTION Executable modelling languages have been discussed for some time [9], but recently have seen increased interest through projects such as GEMOC1 and MOLIZ2 . The key idea is that by specifying op- Figure 2: Henshin rules for PLS-system semantics erational semantics in addition to abstract and concrete syntax, simulators and other dynamic analysis tools can be easily (and pos- opportunities, including giving guarantees for semantics preser- sibly automatically) derived for these executable domain-specific vation in the face of composition [4]. However, they are currently modelling languages (xDSMLs). somewhat underrepresented in the xDSML literature. The key issue, then, is how to specify the operational semantics Figure 1 shows an example model in a (toy) language for de- for an xDSML. Two different approaches have been taken: (1) Using scribing production-line systems [5]. I show here only the concrete imperative definitions—for example added to the abstract syntax syntax in a Sirius-based diagram. The language allows modelling the through new operations [1] or by defining fUML-based action- flow of parts (heads, handles, and hammers) through a production- s—and (2) Using declarative definitions—typically using endogenic line system. In Fig. 1, for example, we can see that a handle has graph-transformation systems (GTSs) [2, 10]. been produced and is currently waiting to be processed by the as- Imperative definitions are close to how programmers think and sembly machine. Figure 2 shows the rules defining the operational can be expressed in languages programmers are already familiar semantics of this language. The two generate. . . rules define with (e.g., Kermeta-based languages use Xtend to express individual the behaviour of generators, while the assemble rule defines how operations). However, their imperative nature also makes it more hammers are assembled. Finally, rule moveAlong defines how parts difficult to reason about the semantics of such languages and to are transferred from conveyors onto trays. safely compose different language semantics. The primary means of In this paper, I report on my experience building a new execu- composition of languages with imperatively expressed operational tion engine for the GEMOC Studio [1], a state-of-the-art language semantics is by a variant of role-based composition [13], but this workbench for xDSML development. The resulting implementation cannot easily provide guarantees about semantic preservation. is available on Github3 . One aim of the GEMOC Studio was to easily On the other hand, declarative definitions of operational se- support the integration of different forms of operational seman- mantics using graph transformations (e.g., [2, 10]) may be less tics, but so far this has only been tested for imperatively defined immediately intuitive for programmers, but offer strong reasoning semantics. Here, I explore what it takes to extend GEMOC Studio with support for xDSMLs with GTS-defined semantics. Specifically, 1 http://gemoc.org/ 2 http://www.modelexecution.org/?page_id=2 3 https://github.com/szschaler/henshin_xdsmls I report on building a GEMOC HenshinEngine, for semantics ex- Algorithm 1 performStep algorithm pressed using the popular Henshin graph-transformation tool [11]. 1: function findNextMatch Beyond the execution engine itself, I hope that this paper can 2: rules ← semanticRules make two contributions to the community: 3: while rules not empty do (1) Provide some insights into the current flexibility of GEMOC 4: rule ← remove random element from rules Studio and, potentially, some lessons about which areas may 5: match ← find match for rule benefit from further refactoring and generalisation; and 6: if match not null then (2) Provide some guidance to others integrating new execution 7: return match 8: return null engines for operational semantics expressed in other formats. 9: procedure performStep The remainder of this paper is structured as follows: In Sect. 2, I 10: match ← findNextMatch introduce the key elements of the GEMOC-Studio architecture that 11: if match not null then are relevant to the introduction of a new execution engine. This 12: beforeStep(match.rule.name) is followed, in Sect. 3, by a description of key aspects of the Hen- 13: apply match.rule at match shinEngine implementation and some lessons learned in Sect. 4. 14: afterStep Finally, Sect. 5 concludes the paper. 2 GEMOC STUDIO semantics rules as the graph-transformation system.4 Thus, any GEMOC Studio is a language workbench for developing xDSMLs [1]. sequence of rule applications from the starting model is considered It provides an interpreter infrastructure that takes a language with to be a valid trace in the semantics. Such semantics can be non- abstract syntax defined in Ecore [6], concrete syntax defined in Sir- deterministic. Non-determinism is useful to represent the degree ius [12], and an operational semantics that can be interpreted by one of concurrency in our problem: heads and handles are generated of the existing execution engines. From this, the infrastructure pro- independently of each other, and hammers are produced indepen- vides integration with Eclipse’s launch mechanism so that models dently of the generators, as long as sufficient numbers of heads and can be executed like other programs. When models are executing, handles are available. GEMOC can use Sirius to provide visual animation of execution In my execution engine, I implement these semantics by ex- progress as well as language-agnostic debug functionality. ecuting one randomly chosen trace5 . As a result, two individual GEMOC Studio currently offers execution engines that can in- executions of the same model may produce different results. terpret language semantics defined in Kermeta, fUML, and a con- Deciding which rule to apply is a two-stage process: we first currency coordination language called BCOoL [7]. An execution randomly pick a rule and then we pick a random match for this rule engine, essentially, performs the following steps: in the current model. An arbitrarily picked rule may well not have a (1) Initialise engine, using the model already pre-loaded by GEMOC match in the current model, so we need to know about rule matches Studio (see below); before picking rules. Checking whether a rule matches is, however, (2) Initialise model, if needed—for example to create initial dyna- the computationally hard part of graph transformation, so we want mic-state elements; and to do as little as possible of it. The easiest solution would be to (3) Execute individual semantics steps in a loop. hand all of this work to Henshin, by asking the matching engine The final step in the execution is the central step. For existing to try to apply a randomly chosen rule: if the application succeeds engines, this invokes a so-called execution-entry point, an oper- a step has been taken and we move on. Otherwise, we randomly ation of one of the model elements, specially annotated to mark pick a different rule to try. If none of the rules can be applied, the it as the entry point. This will usually run a loop in which indi- execution stops. In the process, we make use of Henshin’s capability vidual steps, operations annotated as semantic steps are executed. for non-deterministic matching, which ensures we get a different For each step, GEMOC inserts some functionality before and af- match for rules with multiple matches at every execution. ter the step which allow it to trace model execution and provide However, GEMOC Studio requires a step operation name before additional functionality, including debugging and animation, on executing a step6 . With the above naïve implementation, we can top of the execution. For GTS-based xDSMLs such an entry-point only provide a generic name, such as ‘invokeRule’ as we do not method does not exist. Instead, we will need to provide our own yet know which rule will be invoked. We solve this by splitting the interpretation of steps and communicate these to GEMOC Stu- processing of a single step into two sub-steps: (1) determine the dio. To this end, we can build on functionality encapsulated in rule and (non-deterministic) match to apply; (2) apply the identified AbstractSequentialExecutionEngine: before each step is exe- match. We then call beforeStep between these two sub-steps and cuted, we invoke a beforeStep method. After each step is executed, can thus provide more precise tracing information. Algorithm 1 we invoke an afterStep method. These two calls enable GEMOC shows a summary of the core execution-engine behaviour. Studio to trace model execution as well as offer users control and The current launch infrastructure of GEMOC Studio assumes allow them to stop execution at any time. Melange-defined languages [3]. Melange only supports a limited 4 A graph grammar defines a language of graphs from a starting graph and a graph- 3 CREATING THE HENSHINENGINE transformation system. Any graph reachable from the starting graph is considered part of the language. I consider the semantics of a model to be given by a graph grammar 5 See the discussion in Sect. 5 for other options with the model as the starting graph, and the metamodel and the 6 In the call to the beforeStep operation number of ways in which language-semantics are defined, all of 5 CONCLUSIONS them imperative in nature. As a result, I had to create my own I have integrated a new execution engine for Henshin-based lan- launcher, which takes a model and a set of Henshin rules as input. guage semantics into GEMOC Studio. Overall, the claim that GEMOC Studio is easy to extend has been upheld. Developers of new ex- 4 LESSONS LEARNED tensions can choose between deep embeddings (by developing a In this paper, I have reported on a deep embedding of GTS-based new execution engine, as shown here) or shallow embeddings (by semantics into GEMOC Studio. An alternative would have been encoding the interpretation of semantics in a K3-based semantics). to create a shallow embedding, reusing the existing K3 engine, Some areas of the GEMOC-Studio framework are currently still which expects the semantics to be expressed as operations on the tightly coupled to languages whose operational semantics are de- meta-model. Our execution entry point could have been an oper- fined using operations on the meta-model, and where the language ation that invokes the performStep operation in an infinite loop. definition can be expressed in Melange. Refactoring these areas of performStep would look like the operation above except for the GEMOC Studio would substantially increase the ease with which beforeStep and afterStep calls. Instead, the operation would new execution engines can be integrated. have been annotated as a @Step. The obvious advantage of such Language semantics expressed as a GTS are inherently non- a shallow embedding is that it can completely reuse the imple- deterministic, typically, capturing concurrent execution. Latombe et mentation of existing execution engines and launch infrastructure. al. [8] describe support for concurrent semantics in GEMOC. In fu- However, a shallow embedding also means that the actual semantics ture work, I intend to build on this for a new version of the Henshin become a second-class citizen, only indirectly loaded and referenced Engine. Support for concurrent execution is less well abstracted in from a K3-based ‘meta-semantics’. As a result, details of the seman- GEMOC Studion and, therefore, more difficult to reuse and extend. tics, such as rule names become more difficult to report to the wider Latombe [8] introduces a separate specification of the concurrency GEMOC infrastructure, which only sees the K3 semantics. This model of a language. Such a concurrency model is very useful for creates problems when debugging models and recording traces. further analysis and efficient execution. With a GTS-based seman- More importantly, it would create challenges when later trying to tics it should be possible to infer the concurrency model instead. I provide more dedicated support based on the specific semantics hope to explore this in future work. Additionally, I would like to expression, such as advanced support for concurrency and analysis. extend the current Henshin Engine to support timed rules in a sim- Implementing and integrating this new execution engine into ilar fashion to e-Motions [10], which would open up opportunities GEMOC Studio has highlighted some areas of difficulty, where for building bespoke advanced analysers for high-level, domain- GEMOC Studio may benefit from some additional refactoring: specific models. Finally, I will explore supporting more complex (1) Assumption of operations-based semantics. GEMOC has a built- operational semantics that use rule scheduling (called units in Hen- in assumption that all semantics are defined through operations shin). This creates challenges around identifying execution steps on the meta-model. For every step, GEMOC logs the name of a and larger-scale rollback. meta-class and meta-operation that was ‘executed’. These infor- mation are, for example, exposed to the user in the generic debug REFERENCES interface. Rule-based semantics do not have meta-operations. [1] E Bousse, T Degueule, et al. 2016. Execution framework of the GEMOC studio (tool demo). In SLE’16. Instead, these need to be mocked up when tracing a step. This [2] A Corradini, R Heckel, and U Montanari. 2000. Graphical Operational Semantics. may cause problems, in particular where some operations exist In Workshop on Graph Transformation and Visual Modelling Techniques. and their names (perhaps accidentally) overlap with rule names. [3] T Degueule, B Combemale, et al. 2015. Melange: A Meta-language for Modular and Reusable Development of DSLs. In SLE’15. https://doi.org/10.1145/2814251. (2) Inflexible launch infrastructure. The current launcher infras- 2814252 tructure is tightly linked in with Melange-based language def- [4] F Durán, A Moreno-Delgado, et al. 2017. Amalgamation of Domain Specific initions. For languages that are not defined in Melange, it is Languages with Behaviour. JLAMP 86 (Jan. 2017). Issue 1. https://doi.org/10. 1016/j.jlamp.2015.09.005 necessary to implement a new launcher and launch configura- [5] F Durán, S Zschaler, and J Troya. 2013. On the Reusable Specification of Non- tion. Unfortunately, the Melange-dependent and independent functional Properties in DSLs. In SLE’12 (LNCS), Vol. 7745. [6] IBM. 2006. Ecore API Documentation. http://download.eclipse.org/modeling/ launcher code is not well separated and reusable, which leads emf/emf/javadoc/2.4.0/org/eclipse/emf/ecore/package-summary.html. (2006). to code cloning in any new launchers. [7] M. E. Vara Larsen, J. DeAntoni, et al. 2015. A Behavioral Coordination Opera- Overall, integrating the Henshin engine has been surprisingly tor Language (BCOoL). In MODELS’15. https://doi.org/10.1109/MODELS.2015. 7338249 straightforward: the core engine consists of only 2 classes with a [8] F Latombe, X Crégut, et al. 2015. Weaving concurrency in executable domain- total of 268 LOC Xtend code. Infrastructure made up the bulk of specific modeling languages. In SLE’15. 125–136. https://doi.org/10.1145/2814251. the code: 567 LOC of Xtend and Java code over 6 classes7 imple- 2814261 [9] S. Mellor and M. Balcer. 2002. Executable UML: A Foundation for Model-Driven ment the launcher infrastructure; only 2 classes provide bespoke Architecture. Addison Wesley. behaviour. There are some 47 LOC of configuration data. Including [10] J Rivera, F Durán, and A Vallecillo. 2009. A graphical approach for modeling time-dependent behavior of DSLs. In VL/HCC’09. https://doi.org/10.1109/VLHCC. investigating parts of the GEMOC-Studio sources in depth to iden- 2009.5295300 tify appropriate hooks for extension, the engine was developed in [11] D Strüber, K Born, et al. 2017. Henshin: A Usability-Focused Framework for EMF a week. While improvements are still clearly possible, I consider Model Transformation Development. In ICGT’17. [12] V. Viyović, M. Maksimović, and B. Perisić. 2014. Sirius: A rapid development of this a reasonable amount of effort to spend on a task that will not DSM graphical editor. In INES’14. https://doi.org/10.1109/INES.2014.6909375 need to be repeated for every new language. [13] C Wende, N Thieme, and S Zschaler. 2010. A Role-Based Approach towards Modular Language Engineering. In SLE’09 (LNCS), Vol. 5969. https://doi.org/10. 7 Some copied from existing code in GEMOC Studio because of export settings 1007/978-3-642-12107-4_19