Executable DSMLs (xDSMLs) are becoming more popular as a means of eficiently 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 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 Studio 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.
Executable modelling languages have been discussed for some time
[
The key issue, then, is how to specify the operational semantics
for an xDSML. Two diferent approaches have been taken: (1) Using
imperative definitions—for example added to the abstract syntax
through new operations [
Imperative definitions are close to how programmers think and
can be expressed in languages programmers are already familiar
with (e.g., Kermeta-based languages use Xtend to express individual
operations). However, their imperative nature also makes it more
dificult to reason about the semantics of such languages and to
safely compose diferent language semantics. The primary means of
composition of languages with imperatively expressed operational
semantics is by a variant of role-based composition [
On the other hand, declarative definitions of operational
semantics using graph transformations (e.g., [
Figure 1 shows an example model in a (toy) language for
describing production-line systems [
In this paper, I report on my experience building a new
execution engine for the GEMOC Studio [
Beyond the execution engine itself, I hope that this paper can make two contributions to the community: (1) Provide some insights into the current flexibility of GEMOC Studio and, potentially, some lessons about which areas may benefit from further refactoring and generalisation; and (2) Provide some guidance to others integrating new execution engines for operational semantics expressed in other formats.
The remainder of this paper is structured as follows: In Sect. 2, I introduce the key elements of the GEMOC-Studio architecture that are relevant to the introduction of a new execution engine. This is followed, in Sect. 3, by a description of key aspects of the HenshinEngine implementation and some lessons learned in Sect. 4. Finally, Sect. 5 concludes the paper. 2
GEMOC Studio is a language workbench for developing xDSMLs [
GEMOC Studio currently ofers execution engines that can
interpret language semantics defined in Kermeta, fUML, and a
concurrency coordination language called BCOoL [
Studio (see below); (2) Initialise model, if needed—for example to create initial dynamic-state elements; and (3) Execute individual semantics steps in a loop.
The final step in the execution is the central step. For existing engines, this invokes a so-called execution-entry point, an operation of one of the model elements, specially annotated to mark it as the entry point. This will usually run a loop in which individual steps, operations annotated as semantic steps are executed. For each step, GEMOC inserts some functionality before and after the step which allow it to trace model execution and provide additional functionality, including debugging and animation, on top of the execution. For GTS-based xDSMLs such an entry-point method does not exist. Instead, we will need to provide our own interpretation of steps and communicate these to GEMOC Studio. To this end, we can build on functionality encapsulated in AbstractSequentialExecutionEngine: before each step is executed, we invoke a beforeStep method. After each step is executed, we invoke an afterStep method. These two calls enable GEMOC Studio to trace model execution as well as ofer users control and allow them to stop execution at any time. 3
I consider the semantics of a model to be given by a graph grammar with the model as the starting graph, and the metamodel and the Algorithm 1 performStep algorithm 1: function findNextMatch 2: rules ← semanticRules 3: while rules not empty do 4: rule ← remove random element from rules 5: match ← find match for rule 6: if match not null then 7: return match 8: return null 9: procedure performStep 10: match ← findNextMatch 11: if match not null then 12: beforeStep(match.rule.name) 13: apply match.rule at match 14: afterStep semantics rules as the graph-transformation system.4 Thus, any sequence of rule applications from the starting model is considered to be a valid trace in the semantics. Such semantics can be nondeterministic. Non-determinism is useful to represent the degree of concurrency in our problem: heads and handles are generated independently of each other, and hammers are produced independently of the generators, as long as suficient numbers of heads and handles are available.
In my execution engine, I implement these semantics by executing one randomly chosen trace5. As a result, two individual executions of the same model may produce diferent results.
Deciding which rule to apply is a two-stage process: we first randomly pick a rule and then we pick a random match for this rule in the current model. An arbitrarily picked rule may well not have a match in the current model, so we need to know about rule matches before picking rules. Checking whether a rule matches is, however, the computationally hard part of graph transformation, so we want to do as little as possible of it. The easiest solution would be to hand all of this work to Henshin, by asking the matching engine to try to apply a randomly chosen rule: if the application succeeds a step has been taken and we move on. Otherwise, we randomly pick a diferent rule to try. If none of the rules can be applied, the execution stops. In the process, we make use of Henshin’s capability for non-deterministic matching, which ensures we get a diferent match for rules with multiple matches at every execution.
However, GEMOC Studio requires a step operation name before executing a step6. With the above naïve implementation, we can only provide a generic name, such as ‘invokeRule’ as we do not yet know which rule will be invoked. We solve this by splitting the processing of a single step into two sub-steps: (1) determine the rule and (non-deterministic) match to apply; (2) apply the identified match. We then call beforeStep between these two sub-steps and can thus provide more precise tracing information. Algorithm 1 shows a summary of the core execution-engine behaviour.
The current launch infrastructure of GEMOC Studio assumes
Melange-defined languages [
In this paper, I have reported on a deep embedding of GTS-based semantics into GEMOC Studio. An alternative would have been to create a shallow embedding, reusing the existing K3 engine, which expects the semantics to be expressed as operations on the meta-model. Our execution entry point could have been an operation that invokes the performStep operation in an infinite loop. performStep would look like the operation above except for the beforeStep and afterStep calls. Instead, the operation would have been annotated as a @Step. The obvious advantage of such a shallow embedding is that it can completely reuse the implementation of existing execution engines and launch infrastructure. However, a shallow embedding also means that the actual semantics become a second-class citizen, only indirectly loaded and referenced from a K3-based ‘meta-semantics’. As a result, details of the semantics, such as rule names become more dificult to report to the wider GEMOC infrastructure, which only sees the K3 semantics. This creates problems when debugging models and recording traces. More importantly, it would create challenges when later trying to provide more dedicated support based on the specific semantics expression, such as advanced support for concurrency and analysis.
Implementing and integrating this new execution engine into GEMOC Studio has highlighted some areas of dificulty, where GEMOC Studio may benefit from some additional refactoring: (1) Assumption of operations-based semantics. GEMOC has a builtin assumption that all semantics are defined through operations on the meta-model. For every step, GEMOC logs the name of a meta-class and meta-operation that was ‘executed’. These information are, for example, exposed to the user in the generic debug interface. Rule-based semantics do not have meta-operations. Instead, these need to be mocked up when tracing a step. This may cause problems, in particular where some operations exist and their names (perhaps accidentally) overlap with rule names. (2) Inflexible launch infrastructure. The current launcher infrastructure is tightly linked in with Melange-based language definitions. For languages that are not defined in Melange, it is necessary to implement a new launcher and launch configuration. Unfortunately, the Melange-dependent and independent launcher code is not well separated and reusable, which leads to code cloning in any new launchers.
Overall, integrating the Henshin engine has been surprisingly straightforward: the core engine consists of only 2 classes with a total of 268 LOC Xtend code. Infrastructure made up the bulk of the code: 567 LOC of Xtend and Java code over 6 classes7 implement the launcher infrastructure; only 2 classes provide bespoke behaviour. There are some 47 LOC of configuration data. Including investigating parts of the GEMOC-Studio sources in depth to identify appropriate hooks for extension, the engine was developed in a week. While improvements are still clearly possible, I consider this a reasonable amount of efort to spend on a task that will not need to be repeated for every new language. 7Some copied from existing code in GEMOC Studio because of export settings
I have integrated a new execution engine for Henshin-based language semantics into GEMOC Studio. Overall, the claim that GEMOC Studio is easy to extend has been upheld. Developers of new extensions can choose between deep embeddings (by developing a new execution engine, as shown here) or shallow embeddings (by encoding the interpretation of semantics in a K3-based semantics). Some areas of the GEMOC-Studio framework are currently still tightly coupled to languages whose operational semantics are deifned using operations on the meta-model, and where the language definition can be expressed in Melange. Refactoring these areas of GEMOC Studio would substantially increase the ease with which new execution engines can be integrated.
Language semantics expressed as a GTS are inherently
nondeterministic, typically, capturing concurrent execution. Latombe et
al. [