OBEO INRIA INRIA We present in this paper a complete solution to the Model Execution case of the Transformation Tool Contest 2015 using the GEMOC Studio. The solution proposes an implementation of the most complete version (variant 3) of the UML Activity Diagram language. The implementation uses different technologies integrated into the GEMOC Studio for implementing the various concerns of the language: Kermeta is used to modularly implement the operational semantics and to weave it into the provided metamodel, Melange is used to build the overall language runtime seamlessly integrated to EMF, Sirius Animator is used to develop a graphical animator, the GEMOC execution engine is used to execute the conforming models according to the operational semantics and to build a rich and efficient execution trace that can be manipulated through a powerful timeline, which provides common facilities like, for instance trace visualization, and step-by-step execution (incl. breakpoint, step forward and step backward). Finally, MoCCML is used to provide an alternative to the implementation with an explicit and formal concurrency model for activity diagrams supported by a solver and analysis tools. We evaluate our implementation with regard to the evaluation criteria provided in the case description and give evidence of the correctness, understandability, conciseness and performance of our solution.
Executability of models opens many possibilities in terms of early dynamic verification and validation
(V&V) of models, such as debugging [
In this paper, we present a solution to the most complete variant of this case (i.e., variant 3) using the GEMOC Studio2. The variant 3 of the Model Execution case considers the complete Activity Diagram metamodel provided. It includes various kinds of nodes (initial node, final node, fork node, join node, c Combemale et al.
This work is licensed under the Creative Commons Attribution License. decision node, merge node), opaque actions, Boolean and integer variables (either local or as input), and various Boolean and integer expression types.
In the rest of this paper we first present in Section 2 an overview of the solution using the GEMOC language workbench to design and implement the UML Activity Diagram language as defined in the variant 3 of the Model Execution case, as well as the resulting environment in the GEMOC modeling workbench. Then, in Section 3, we evaluate our implementation with regard to the evaluation criteria provided in the case description and provide evidence of the correctness, understandability, conciseness and performance of our solution. Finally, Section 4 concludes and gives some perspectives for the GEMOC Studio. Annex A gives a detailed description of the solution. 2
Our solution uses the GEMOC Studio, an Eclipse package atop the Eclipse Modeling Framework (EMF)3, which includes both a language workbench to design and implement tool-supported xDSMLs, and a modeling workbench where the xDSMLs are automatically deployed to allow system designers to edit, execute, simulate, and animate their models. As a result, our solution not only provides a model interpreter conforming to the proposed operational semantics of the UML Activity Diagram language, but also provides a graphical model animator, an advanced trace manager, as well as an alternative version that offers an explicit and formal model of computation supporting concurrency. All resources are available from http://gemoc.org/ttc15.
For designing and implementing the various concerns of an xDSML, the language workbench put
together the following tools seamlessly integrated into EMF:
• Kermeta, which offers specific annotations for Xtend4 to support the modular implementation of an
operational semantics (both runtime concepts and steps of computation) and its weaving into an
EMF-based metamodel (i.e., an Ecore model).
• Melange[
Once an xDSML is implemented with the aforementioned tools of the language workbench, the xDSML is automatically deployed into the modeling workbench, which provides an advanced environment integrated into the Eclipse debugger for model execution. In particular, the modeling workbench provides the following tools: • A Java-based execution engine (parameterized with the specification of the operational semantics), possibly coupled with TimeSquare6 (parameterized with the MoCC), to support the concurrent execution and analysis of any conforming models.
• A model animator parameterized by the graphical representation defined with Sirius Animator to animate executable models. • A generic trace manager, which allows a system designer to visualize, save, replay, and explore different execution traces of their models, as well as navigating step-by-step in a given execution trace (incl. breakpoint, step forward and step backward). • A generic event manager, which provides a user interface for injecting external stimuli in the form of events during the simulation (e.g., to simulate the environment).
The implementation of the UML Activity Diagram language (see details in Annex A) is automatically deployed in the GEMOC modeling workbench (see Fig. 1). The modeling workbench offers a powerful environment to system engineers for controlling the execution of their models with a debugger-like control panel7 (¨), visualizing the execution of their models thanks to the graphical animator (≠), and analyzing and exploring several execution traces with a graphical timeline that supports step forward and step backward (Æ). Finally, the modeling workbench offers several extension points that can be used to plug additional front-end or back-end, such as a timing diagram included into the modeling workbench. 3
We now evaluate our solution by using the evaluation criteria proposed in the case description [
The correctness of our solution is based on the test suites provided by the case. All the three versions of our solutions provide correct results. 3.2
Kermeta is used to design and implement the operational semantics. Based on Xtend, Kermeta provides a powerful Java-like imperative and statically typed meta-language. This last follows an object-oriented paradigm which makes it directly aligned with the object-oriented Ecore metamodel provided by the case.
The implementation of the operational semantics follows the well-known Interpreter design pattern which supports a modular design of the operational semantics with regard to the initial metamodel which is reused as is and not affected. There is no translation into a third formalism, and this approach easily supports the definition of different variants of the semantics (e.g., interpreter and compiler, different semantic variation points, etc.). Finally, the use of the open-class and static introduction mechanisms makes the design of the operational semantics even simpler than the interpreter pattern, avoiding to duplicate the initial structure into the interpreter. The operations of the operational semantics are directly weaved into the suitable classes of the initial metamodel.
The entire implementation of the operational semantics of the variant 3 of the Model Execution case comprises 441 LOC (version executionOnly). This includes the entire implementation of the interpreter sufficient for the execution of any conforming models. The other technologies Melange, Sirius Animator, and MoCCML are optional, and can be used only to provide the additional features such as model interoperability, trace management, model animation, and formal concurrency specification and analysis. Note also that the analysis tools that provide the modeling workbench are not only useful for the system engineer to analyse the models, but also for the language designer to analyse the language semantics implementation. 3.3
Table 1 shows the execution time (without load and save times) of the models provided for the performance evaluation (Test perf 1, Test perf 2, Test perf 3_1 and Test perf 3_2) in . The execution time is provided for all the models, according to the three versions of our solution. Performance evaluation has been performed using an Ubuntu VirtualBox image with Java 8 and the last Gemoc Studio. This virtual machine ran on top of a HP EliteBook 820 computer with an Intel Core i7 processor and 16GB of memory. Note that in We present in this paper our solution using the GEMOC Studio to the most complete variant 3 of the TTC’15 Model Execution case. The solution provides not only an EMF-based interpreter for UML activity diagrams, but also comes with a well-integrated model debugging environment based on Eclipse, including advanced features for graphical model animation and execution trace management. We also propose an enhanced version of our solution which integrate into the operational semantics a formal and explicit model of concurrency supported by analysis tools. The GEMOC Studio integrates different technologies to implement the various concerns of the executability (runtime concepts, steps of computation, animator, concurrency). We evaluate our solution regarding both the benchmark provided by the case, and the criteria proposed in the case description. In particular, we give evidence for the correctness, the understandability and conciseness, and the performance of our solution.
The GEMOC Studio is a play ground for research activities related to Software Language Engineering, including model executability. Various studies are currently investigated on related topics, including the integration with continuous time, formal analysis, optimizing compilers, semantic variability and adaptation, and application to other domains (e.g., enterprise architecture and scientific modeling).
In this annex we describe the design and implementation of the UML Activity Diagram language as
defined in the variant 3 of the TTC’15 Model Execution case [
A.1
Kermeta is used to implement the operational semantics. Kermeta complements Xtend to support the definition of both the runtime concepts and the steps of computation in a separate file rather than in the initial metamodel, and to statically weave them in the initial metamodel. Kermeta provides static typing to safely define the operational semantics, and a compilation scheme of the operational semantics which results in a Java-based runtime seamlessly integrated to the Java code generated by EMF from the initial metamodel.
The runtime concepts can be additional classes that will be merged with the initial metamodel, or new structural features (attributes or references) either in the existing classes of the initial metamodel or in the newly added classes. When new structural features have to be added to a class existing in the initial metamodel, the annotation @Aspect is used to re-open the class.
Listing 1 shows an excerpt of the modular definition of the runtime concepts. Token and ForkToken are new concepts, while the content of ActivityNodeAspect, a collection of Token, will be merged into the concept ActivityNode from the abstract syntax (cf. annotation @Aspect). All the runtime concepts of the case have been defined similarly.
Listing 1: Modular definition of the runtime concepts with Kermeta
The steps of computation are defined in terms of operations weaved into the suitable classes, either from the initial metamodel or from the newly added classes of the runtime concepts. Similarly to the structural features of the runtime concepts, when an operation has to be added to a class existing in the initial metamodel, the annotation @Aspect is used to re-open the class.
Listing 2 shows an excerpt of the definition of the steps of computation (i.e., the interpreter), which manipulates the runtime concepts previously defined. The implementation follows the Interpreter design pattern 8, defining one operation execute per concept of the abstract syntax to be interpreted. Each method is modularly defined in an aspect, and then weaved into the suitable class of the abstract syntax. Listing 2
shows the overall execution of an Activity. All the steps of computation of the most complete variant of the case have been defined similarly.
def void execute(Context c) { _self.locals.forEach[v|v.init(c)] _self.nodes.filter[node|node instanceof InitialNode].get(0).execute(c) var list = _self.nodes.filter[node|node.hasOffers] while (list!=null && list.size>0 ){ list.get(0).execute(c) list = _self.nodes.filter[node|node.hasOffers]
The definition of the runtime concepts and the steps of computation in a separate file offers a modular mechanism to implement the operational semantics. In addition to support the separation of concerns (abstract syntax and operational semantics), this is also a way to support different implementations of the operational semantics for the same abstract syntax (e.g., in case of semantic variation points). A.2
Once the operational semantics is defined with Kermeta, Melange9 can be used from the language workbench for assembling the initial metamodel and the chosen operational semantics into an xDSML. 1 language UMLActivityDiagram { 2 syntax "platform:/resource/.../activitydiagram.ecore" 3 with org.gemoc.ad.sequential.dynamic.* 4 exactType UMLActivityDiagramMT 5 }
Listing 3: Assembling an xDSML with Melange
As a result, Melange provides the xDSML as well as a structural interface (aka. model type [
A.3
Based on the resulting xDSML, the language workbench includes a generative approach that automatically
provides a rich and efficient domain-specific trace metamodel. Instead of relying on complete snapshots
of the executed model to construct a trace, this metamodel precisely captures what the execution state of a
model conforming to the xDSML is through an efficient object-oriented structure based on the runtime
concepts of the xDSML. In addition, the structure provides rich navigation facilities to browse a trace
according to various dimensions (e.g. the value of a field or the occurrences of an event). For more details
we refer the reader to [
A.4
Optionally, Sirius Animator can be used to complement the xDSML with a graphical model animator. Sirius Animator allows to either extend the graphical representation of an existing model editor defined with Sirius, or to define a separate graphical representation, based on the runtime concepts. This graphical representation is then used to visualize the state of a model during its execution.
In our solution, we defined a new graphical representation (called viewpoint specification in Sirius) on top of the provided metamodel for UML activity diagrams, augmented with the runtime concepts to be visualized at runtime.
A.5
Because concurrency is a more and more important concept, one can use MoCCML to specify the MoCC.
A MoCC specifies the possibly timed causalities and synchronizations among the steps of computation in
a formal way. Based on MoCCML, non-determinism and parallelism are clearly and formally identified in
the operational semantics and can be varied or refined [
Listing 4 shows an excerpt of the MoCC specification. Lines 1 and 2 define an event in the context of an ActivityNode (i.e., for all its instances). For each occurrence of this event the execute function is called. All these events are constrained by some relations. For instance, in the classical case, the execution of a node is done after its predecessor has been executed (see the Precedes relation line 6). In the context of Activity appears a kind of loop since the activity can not start if not stop (line 11) and its start actually executes the initial node of the activity (line 15), i.e., the starting point of the causality chain written in Line 6. From such a specification, and for a specific model, a symbolic event structure is automatically derived.
1 context ActivityNode 2 def : executeIt : Event = self.execute() 3 inv waitControlToExecute: 4 (not self.oclIsKindOf(MergeNode)) implies 5 Relation Precedes(self.incoming.source.executeIt, self.executeIt)) 6 7 context Activity 8 def : start : Event = self.initialize() 9 def : finish : Event = self.finish() 10 inv NonReentrant: 11 Relation Alternates(self.start, self.finish) 12 13 context InitialNode 14 inv startedWhenActivityStart: 15 Relation Precedes(self.activity.start, self.executeIt )
Listing 4: Excerpt of the explicit and formal model of concurrency for activity diagrams