Tutorial: Language Design & Model Execution with xMOF and GEMOC Studio

By Tobias Ortmayr and Tanja Mayerhofer

Introduction

This tutorial demonstrates how to use xMOF in GEMOC Studio for developing executable domain-specific modeling languages (xDSMLs) and executing models. For this, it will show you how to make the predefined FSM language, a simple Ecore-based language for defining finite state machines, executable with xMOF, and how to execute and debug FSM models. To achieve this, you will learn how to perform the following steps:

1. Setup GEMOC Studio with xMOF
2. Import the (not yet executable) FSM language
3. Create an xMOF project for the FSM language
4. Define the execution semantics of the FSM language with xMOF
5. Generate code for the FSM xMOF model
6. Create an xDSML project for the FSM language
7. Create an animator project for the FSM language
8. Launch the modeling workbench for the FSM language
9. Execute an FSM model

The complete FSM example is also provided together with the xMOF component of GEMOC Studio. In the end of the tutorial, you find instructions on how to install the example.

1. Setup GEMOC Studio with xMOF

For setting up GEMOC Studio, download the latest version of GEMOC Studio from gemoc.org. The download will deliver a compressed zip or tar.gz archive. Decompress this archive into a directory of your choice and ensure you have full read and execute permissions for this directory. Start GEMOC Studio by running GemocStudio.exe on Windows or GemocStudio on other platforms.
xMOF is provided as an additional component of GEMOC Studio. To install it, open the menu Help and select Install Additional GEMOC Components. Select from the category Alternative GEMOC based Engines the component GEMOC xMOF Engine.

After selecting the component GEMOC xMOF Engine, hit the Finish button. Confirm the Install and Install Details dialogs by hitting Next, read and accept the license agreement and hit Finish. Confirm the warning about installing unsigned content and restart GEMOC Studio.

2. Import the FSM Language

The FSM language is a simple language for defining finite state machines. Its abstract syntax is defined by an Ecore model. For graphically visualizing FSM models, a Sirius-based editor is also provided for the language.
We will see in this section how we can import the EMF projects implementing the FSM language and have a look inside these projects.

Download the FSM Implementation Projects

The EMF projects implementing the FSM language can be downloaded as an archive file fsa-tutorial.zip from modelexecution.org.

Import the FSM Implementation Projects

For importing the downloaded projects, open the menu File and select Import... In the opening Import wizard, select General / Existing Projects into Workspace. Chose the downloaded archive file fsa-tutorial.zip under the option Select archive file and select all projects located in the directory language_workbench.

Abstract Syntax

FSM models are simple I/O state machines. The abstract syntax of the FSM language is defined by the Ecore model fsm.ecore located in the imported project org.modelexecution.xmof.examples.fsm.

As you can see from the Ecore model, a finite state machine (FSM) is a set as of states and transitions. One state serves as initial state. Each transition has exactly one source state and exactly one target state. In addition, each transition defines an input String and an output String. For each state, the inputs of outgoing transitions must be distinct to avoid non-deterministic state machines.

Concrete Syntax

The graphical concrete syntax for visualizing FSM models is defined by the Sirius viewpoint specification model fsm.odesign contained by the imported project org.modelexecution.xmof.examples.fsm.design. It depicts states as circles and transitions as edges with their input / output Strings as label.

The example shows a simple finite state machine that accepts the input String “HELLO!” and produces the output String “WORLD!”.

3. Create an xMOF Project

To make the FSM language executable, we have to first create a new xMOF project for the FSM language.
To create a new xMOF project, open the menu File and select New &gt Other.... Select in the category xMOF the entry xMOF Project.

In the appearing dialog New xMOF Project, you have to provide the name of the xMOF project and the name of the executable language that is going to be developed.
For the FSM example, we chose the following names:

• Project name: org.modelexecution.xmof.examples.fsm.xmof.dynamic
• Language name: FSM

Confirm the input by hitting the Next button.

On the next page Ecore Metamodel File, you have to select the Ecore model defining the abstract syntax of your language. For this, click on Browse Workspace, unfold the project org.modelexecution.xmof.examples.fsm, select the file fsm.ecore and hit OK. The content of the Ecore model will then be displayed in the wizard page.
As last step you have to select the main class of your Ecore model. This class will serve as entry point for the execution of FSM models. Select the class FSM as main class and hit Finish.

The wizard created for you the new xMOF project org.modelexecution.xmof.examples.fsm.xmof.dynamic containing a new xMOF model fsm.xmof. This xMOF model provides configuration classes for all classes of the FSM Ecore model and will be used in the next step for defining the execution semantics of our FSM language.

4. Define the Execution Semantics of FSM with xMOF

In this step, we will define the execution semantics of the FSM language. This is done in the created xMOF model fsm.xmof. We will have to define the following components common to the execution semantics of xDSMLs:

1. Dynamic elements defining the runtime states of models
2. Input parameters accepted for the execution of models
3. Behavior of the model elements

Before we go into the details on how to define these elements for FSM, we will first have a look at the desired execution behavior of FSM models.

Desired Execution Behavior

When executing an FSM model we want to process a sequence of input Strings and determine the output String produced by the finite state machine. For doing that, it is checked for each String in the input sequence whether one of the outgoing transitions of the currently active state can process it. A transition can process a String when it is equal to the input String defined by the transition. A finite state machine starts with the initial state as first active state. If a transition can process the current input String, the transition is fired. When a transition is fired, the transition output String is added to the output String starting with an empty String, and the target state of the transition is set as the new active state.

4.1. Define Dynamic Elements

To achieve the desired execution behavior we need a way to define the currently active state of a finite state machine as well as the output String of a state machine. In addition, we also need to store information about the accepted input sequence of Strings. This is referred to as the runtime state of a finite state machine.
To define the runtime state of an FSM model, we therefore extend the configuration class FSMLConfiguration with a reference currentState to the State class, and the multi-valued String attributes producedSeq and acceptedSeq.

4.2. Define Input Parameters

Input Elements

The input processed by a finite state machine is an arbitrary sequence of input Strings. To enable the user of the FSM language to define such an input String sequence, we introduce the class Input into the xMOF model owning the multi-valued String attribute inputSeq. Note that the property unique of this attribute has to be set to false to allow duplicate elements in the sequence.

Input Parameters

Finally, we have to define that an input String sequence, i.e., an instance of the newly defined class Input, has to be provided for executing an FSML model. To do that, we have to add an input parameter to the main operation that was automatically added to the main class of our FSM language FSMConfiguration.
To add this input parameter right-click on the operation main and select New Child > DirectedParameter. Change the name of the input parameter to input and set its type to Input.

4.3. Define Behavior

To define the above described execution behavior of finite state machines, we have to define four operations and their behavior:

1. The main operation of the configuration class FSMConfiguration serving as entry point of the execution.
2. The run operation of the configuration class FSMConfiguration defining the behavior of finite state machines.
3. The process operation of the configuration class StateConfiguration defining the behavior of a state when processing an input String.
4. The fire operation of the configuration class TransitionConfiguration defining the behavior of a transition when firing.

Add Operations

To add a new operation, right-click on the respective configuration class and select New Child > BehavioredEOperation. Set the name accordingly and add appropriate parameters.

Create Activities

With xMOF, the behavior of operations is defined with UML activities. To create the activity defining the behavior of an operation, simply double-click on the operation. The activity will be created and initialized with parameters corresponding to the parameters defined for the respective operation. For instance, by double-clicking on the main operation, an activity named main_FSMConfiguration is created.

Define Behavior of Activities

Now we can define the behavior of the created activities. Double-clicking on an activity or operation will initialize and open the corresponding activity diagram. We will start with the main operation.

The palette on the right provides tools for the creation of activity nodes and activity edges. xMOF is based on the UML action language. Detailed descriptions of action types and other UML node types can be found in the UML specification.
The modeling of the main activity is covered in detail in this tutorial. For the other activities only the final activity diagrams are shown. Information on how to install the complete example are given in the end of the tutorial.

main Activity

The main activity has to first set the initial state of the finite state machine as currently active state and then to process the provided input by calling the operation run. Finally, it has to provide the output sequence produced by the run operation as output of the finite state machine.
For doing this, we first need to add a Read Self Action named read fsm to the activity. This action will retrieve the executing FSM element. Select the Read Self Action element in the tool palette and click on the diagram. In the appearing dialog, enter the name read fsm and click OK.

In the same fashion, we create the remaining needed actions. To access the initial state of an FSM, we define a Read Structural Feature Action called read initialState and set its property Structural feature to initialState. To set the retrieved state as currently active state, we furthermore create an Add Structural Feature Value Action named set currentState and set its property Structural feature to currentState. To call the operation run, we define a Call Operation Action named call run and set its property Operation to run. Furthermore, to pass the executing FSM element on to these actions, we create a Fork Node.
Use the properties view to set the properties Structural feature and Operation.

Now we can connect the created activity nodes with object flows and control flows. To add a new flow, select the required flow type in the tool palette and then click on the nodes you want to connect.
To pass along the executing FSM element, we need to connect the output of the read fsm action with the created fork node and the fork node with the target and object inputs of the actions call run, read initialState, and set currentState. Furthermore, the initial state retrieved by the read initialState action has to be provided to the value input of the set currentState action. Finally, the provided input parameter value has to be passed on to the run operation. All of these flows are object flows.

However, these object flows cannot ensure that the run operation is invoked only after the currently active state has been set to the initial state of the finite state machine. Thus, we also need to define an additional control flow from the set currentState action to the call run action.
The final main activity looks as follows:

run Activity

The run activity reads the input String sequence provided by the input parameter value and then processes each element in the input String sequence by calling the process operation of the current state. The iteration over the input String sequence can be defined with an Expansion Region. The activity nodes contained by the expansion region are executed for each element of the provided input String sequence.

process Activity

The process activity determines for the current state whether one of its outgoing transitions can process the currently processed input String, i.e., whether one of its outgoing transitions defined the String as processable input. If such a transition is found, this transition is fired by calling its fire operation.

Note that for the outgoing control flow of the decision node, a guard has to be defined. This has to be done in the tree editor. Switch to the tree editor by clicking on the Selection tab shown in the bottom left corner of the editor. Right-click on the object flow and select New Child > Guard Literal Boolean. Then set its Value property to true using the properties view.

fire Activity

The fire activity of a transition has to perform the following tasks: It has to set the target state of the transition as the new current state of the FSM, add the output of the transition to the produced String sequence, and add the processed input String to the accepted String sequence.

5. Generate Code for an xMOF Model

After the xMOF model has been completely defined, we have to generate Java code for it. To do this, right-click in the project explorer on the xMOF project org.modelexecution.xmof.examples.fsm.xmof.dynamic and select xMOF > Generate Code. The Java code is generated in the src foder of the xMOF project.
Please note that the Java code has to be re-generated whenever the xMOF model is updated.

6. Create an xDSML Project

As a next step, we have to create a GEMOC xDSML project for the FSM language that identifies the FSM language as executable language. The GEMOC xDSML project can be automatically generated for an xMOF project. For this, right-click in the project explorer on the xMOF project org.modelexecution.xmof.examples.fsm.xmof.dynamic and select xMOF > Generate xDSML Project.
The generation of the Java code an the xDSML project can be also achieved in one step by right-clicking in the project explorer on the xMOF project org.modelexecution.xmof.examples.fsm.xmof.dynamic and selecting xMOF > Generate All.

7. Create an Animator Project

After completing the previous steps, you can already execute FSM models. If you are not interested in animating executing FSM models, you can skip this step and proceed with Step 9.

Desired Animation

During the execution of an FSM model, we want to visualize:

• The currently active state in red color
• The String sequence that the FSM has accepted so far
• The String sequence that the FSM has produced so far

Add Animation Layer

To implement the desired animation, we first need to add an animation layer and corresponding animation service classes to the Sirius viewpoint specification model. For this, open the Sirius viewpoint specification model of the FSM language fsm.odesign located in the project org.modelexecution.xmof.examples.fsm.design. Right-click on the FSMDiagram element and select xMOF > Add Animation Layer. This adds a dedicated layer called Animation to the diagram and initializes the FsmdiagramAnimationServices class.

Extend Animation Service Class

To display the produced and accepted String sequences we need simple methods that concatenate all elements of the sequence to one single String. In addition, the order needs to be reversed as the elements are added in last-in/first-out order during execution.
For this, we extend the class FsmdiagramAnimationServices with two simple service methods as shown below:

Note that after adding the methods you may get some import errors which can be easily resolved with the Eclipse Quickfix feature.

Extend Animation Layer to Highlight the Current State

To display the currently active state in red color, we can use a style customization. In the Sirius specification editor navigate to the Animation layer. Then right-click on Style customizations and select New Customization > Style Customization. As predicate expression for this customization define [self.containingFSM.oclAsType(fsmConfiguration::FSMConfiguration).currentState=self/]. Then right-click on the the style customization and select New Customization > Property Customization (by selection) and set the property values as shown below:

Extend Animation Layer to Display Information on the Accepted and Produced String Sequences

To display the accepted and produced Strings, we create a container mapping called ExecutionInfo in the Animation layer and contained node mappings called AcceptedString and ProducedString as shown below. For these mappings set the property Domain Class to fsm.Fsm and the Semantic Candidate Expression to [self/]. In addition, change the property Child Representation of ExecutionInfo to list.

For the label expressions of the basic shapes of AcceptedString and ProducedString use the following values:

• ['Accepted String: '+self.getAcceptedString()/]
• ['Produced String: '+self.getProducedString()/]

8. Launch the Modeling Workbench

Now we have completely implemented the executable FSM language and a corresponding animator, and are ready to execute and debug FSM models. For this, we start the FSM modeling workbench. Expand the Run control in the menu bar and select Run Configurations....

Double-click on Eclipse Application, change the name to FSM Modeling Workbench, and click on Run to start the FSM modeling workbench.

Import the project org.modelexecution.xmof.examples.fsm.samplemodels from the folder modeling_workbench of the downloaded archive file fsm-tutorial.zip into the modeling workbench. For this, open the menu File, select Import... > General / Existing Projects into Workspace, browse to the archive file, select the sample model project, and hit Finish.
The imported project contains the introduced Hello World example and another example defining a finite state machine for traffic lights. To open an example model make sure that you are in the Modeling perspective. The perspective can be changed with the menu Window   > Open Perspective   > Others.
Open the Hello World example by double-clicking on the HelloWorld.aird file. Then, expand the aird file until the FSMDiagram appears. Open it by double-clicking.

9. Execute an FSM Model

To execute the Hello World finite state machine, expand the Debug control in the menu bar and select Debug Configurations...

Double-click on xMOF Executable Model. Change the name of the new configuration to HelloWorld. Select HelloWorld.fsm as the model to execute and HelloWorld.parameters1.xmi as the initialization model. Select the melange language org.modelexecution.xmof.examples.fsm.Fsm and the animator HelloWorld.aird. Finally, click on Debug.

The Hello World FSM model now starts executing. After the execution engine has been started, a dialog Confirm Perspective Switch will appear. Click on Yes and the debugging perspective will be opened.
Interact with the debugging model using the usual Eclipse debug commands. Use the control Step Into from the menu bar to execute the Hello World model step-by-step. The model will be animated showing the currently active state, the processed input Strings and the produced output Strings. The stack trace view shows the next execution step to be performed and the variables view shows the current values of the different model elements.
Below you can see the animation of the model after stepping three times.

Congratulations! You have defined your first xDSML with xMOF.

Getting the Complete Example

The complete FSM example is delivered with the xMOF component of GEMOC Studio. To install it open the File menu, select New > Other... > Examples / xMOF Language Examples / xMOF FSM Language, and hit Finish. All projects implementing the FSM language will be imported in your language workbench.
In the same way you can also import the sample model project. Open the File menu, select New > Other... > Examples / xMOF Modeling Examples / Model Example for xMOF FSM Language, and hit Finish.

Implementation of Piping and Instrumentation Diagrams for Enterprise Architect

Piping and Instrumentation Diagrams (P&IDs) are a common way to model systems in process engineering. However, currently very few modeling tools support this kind of diagrams.

The complexity of modern process plants is steadily increasing. To overcome this potential source of error it is obvious that a abstract way to model such systems is needed. Piping and Instrumentation Diagrams or P&IDs are used in various areas to model these complex plants. To evolve the usage of P&IDs in the industry, significant support of modeling tools is needed. Our research showed that currently few tools allow modeling of such diagrams.

P&ID

The Piping and Instrumentation Diagram (P&ID), is primarily derived from the Process Flow Diagram (PFD). P&ID is used to support or guide the design and construction of process plants. P&ID helps to communicate between designers, constructors, operators and owners of the plant by providing a schematic representation. The schematic representation elaborates important details of piping and instrumentation and should tie together the system description, system flow, electric control schematic and the control logic. The semantic of the diagram should help to demonstrate the physical sequence and connectivity of equipment in a system. Another important concept is the isometric drawing scheme or the orthographic physical layout. In other words the  placement of elements in the diagram should practically represent the physical placement of components in a plant.

UML Extension Techniques

Although UML offers a broad range of diagrams to model systems there will always be a need to model domain specific characteristics. Another fact is that it will always need time to take care of new technologies in the UML standard.

Two overcome these drawbacks UML allows to adapt the standard. 

Basically there are two different approaches: lightweight extensions through profiles and heavyweight extensions through meta-model modifications. Enterprise Architect mainly features extension through UML Profiles, this is why we chose this approach.

Implementation of P&ID Profiles in Enterprise Architect

Enterprise Architect offers a powerful extension mechanism based on the standardized UML Profile principles. Enterprise Architect lets you access this functionality via the Model Driven Generation Technologies SDK. Enterprise Architect has a built in MDG Technology Creation Wizard which eases initial contact with the overwhelming size of the tool.

Visualizing P&ID elements with Shape Script

Elements and connectors which were extended via UML stereotyping conform to the standard UML notation in terms of shape, color and labeling. Enterprise Architect offers the possibility to define the appearance of extended elements and connectors using their proprietary Shape Scripts language. Shape Script allows the developer to define size, shape, orientation and color of custom elements. Furthermore Shape Script provides some methods for reflection, with which the graphical representation can react to the properties of the given instance of the element. Shape Script uses a C-like syntax.

Comparison of the Eclipse Modeling Framework (EMF) with the Meta Programming System (MPS)

By Romana Jakob, Julian Lehner, Alexander Schörghuber

Introduction

In the last decade a dramatic growth of software intricacy and different methodologies and techniques have been proposed to support the development of complex systems. Model Driven Engineering lays the focus more on modelling than on coding and lets software architects harness the opportunity of dealing with higher-level abstractions.

Basically said, programming is completely based on abstraction, which increases the need for models in order to get a better understanding of the whole problem. Nowadays, there is a huge amount of diverse tools to create languages. Therefore, the need for objective empirical tool comparison increases.

Models can only develop their full potential if they can be manipulated by means of automated transformation to obtain different kinds of artifacts. These artifacts may range from other models to documentation or even implemented code. At this point it is vital, that the designers and developers are able to comprehend the overall possibilities of the framework used for development. It is left to say, that each system focuses on different outcomes and therefore it is important to know the differences and the advantages and drawbacks of the used system within the applied field.

Thus, when it comes to evolving a system it is crucial to obtain an accurate picture of the quality requirements of the system. In this work, the focus especially lies on frameworks for the realization of a model-driven approach to language development. The concrete tools used in this comparison are the Eclipse Modeling Framework (EMF) which is used for the definition of a metamodel together

with Xtext which is used for defining a textual notation and JetBrain's Meta programming system (MPS).

The core topic of the project is the comparison of these tools. EMF may be more established as it enjoys a longer market presence but MPS has definitely made up its delay. The paper tries to develop neutral criteria to compare modeling frameworks and apply them on EMF and MPS based on an example implementation of IML (Intermediate Modeling Layer).

Evaluation

By implementing a pre-defined language named IML in these two meta modeling systems, the knowledge was gained to accomplish the evaluation. In each of these two implementations, the focus was held on using system specific elements and do not focus on details and syntactic sugar.

To summarize the outcome of the evaluation it is important to say that each of the considered systems has its own advantages and disadvantages regarding the used evaluation criteria. To pick out some of the features there are for example those that are really good in both systems, like Feature coverage, Functionality or Scalability. Then, there are criteria that are very different in both systems like Lines of code (or better the textual overhead) because of the spread files approach of MPS. A little bit surprising is that, there is no criteria that has got a bad grade in both systems. This as much more shows that the existence of both meta modelling systems is legitimate.

Outlook

The work gives only a small overview about some parts of those very powerful meta modeling tools. The focus was on analyzing an existing language in EMF and implementing this language completely from scratch in MPS by focusing on the Meta-Modeling and defining and implementing of the abstract syntax.

And then to analyze the different approaches and make a comparison of those two systems. Because MPS is not so well known and more new than EMF, it was also a bigger part of the project to describe some basics of MPS. The task for the future would be to work out more examples about the additional features of MPS and to compare them with the existing implementations of EMF.

EMF is a very powerful and wide meta modeling system with a big community and because of using eclipse also continously enhanced, for example in the area of creating View Models and using renderer based on the Ecore Domain Model to achieve user interfaces. A study would be interesting on how these approaches could be realized in MPS. Maybe this is more work to do to fit it into a single project, but some fundamental research would be fine.

For more information on the project, we kindly refer to the full report and the source code of the implementation.

Realizing a DSL in MPS

By Alexander Eigner and Paramvir Parhar

Introduction
The aim of this project was to get first hands-on-experience in the Meta Programming System by implementing an own domain specific language in MPS. This DSL should be based on some main ideas from the fields of systems engineering and executable UML. By taking the structuring aspect of systems engineering into account this DSL should allow the user to model a system that is composed out of interlinked components. Following some ideas of executable UML this DSL should also allow the user to model behavioral aspects of a system and to execute (e.g. simulate) this system already during the design phase by means of code generation.

The Meta Programming System
For implementing our DSL we used a relatively new language workbench, namely Meta Programming System developed by JetBreains. JetBrains MPS is an open-source language workbench for language engineering. MPS itself is implemented in Java. It runs on the JVM and allows defining general-purpose as well as domain-specific languages. Unlike other implementa- tions MPS does not use a parser or grammer at all, but it uses structural editors, in which the textual syntax represents a projection of the abstract syntax tree (AST), hence the user edits directly on the abstract syntax tree. Therefore, MPS supports mixed notations like textual, symbolic, or graphical. The fact that MPS does not use a parser allows users to enable language modularization and com- position more easily. The projection of the AST guides the user through the development as it knows what is allowed and what not. MPS supports combining and extending different languages. In order to trans- late the DSL code into another language like Java it is necessary to do a model transformation.

Implemented DSL: ComponentStateCharts (CSC)
The name of the implemented domain specific language origins from two well known modeling diagram-types, the component diagram and the statechart diagram. CSC offers the possibility to model the structure of a system by allowing the user to define components and connect them with eachother via ports, which shows the similarity of our DSL to component diagrams. CSC also allows the user to define the behavior of a system by letting the user define a state machine for each component. Therefore the domain of CSC extends to the modeling of structured systems that consist out of interlinked components with specific behavioral features. CSC moreover allows the user to define a simple execution sequence, which is a sequence of function-calls of the components, in order to simulate a sequence of events on these components. In addition to that a CSC-to-Java generator was implemented that can generate a Java class for each component as well as a simulation class to simulate a concrete behavior of the components according to the defined execution sequence.

Evaluation
The main part of the evaluation was conducted by counting the number of code-lines that were needed to model a sample systen in CSC against the number of Java code-lines that were generated via the CSC-to-Java generator. This evaluation showed, that there was a huge saving in code-lines in CSC due to its laconic and error-tolerant syntax. Besides the saving of code-lines CSC also has some shortcomings. Due to the lack of time of this project it was not possible to implement a sophisticated concept for component-functions that e.g. could allow the user to define return types. This fact can lead the user to tedious coding-bypasses if he or she wishes to overcome that lack of return types.

Future work
There are several upgrade possibilities for CSC. Component-functions could for example have return types. The transitions of a component's statechart diagram could have guard conditions. Components could interact with eachother sophisticatedly via data streams. The use of Realtime UML could allow a wider range of analysis during the execution of a CSC model.

Diagram Centric Model Versioning

By Stefan Schefberger and Matthias Winkelhofer

Introduction

Model driven engineering becomes more and more important in the area of software development. As with any engineering project, you need to collaborate as a team sharing the source code, as well as models, through a version control system. EMF Compare and EGit provide a sufficient mechanism to support model versioning. However, the model comparison viewer always strictly separates between changes applied to the model and the diagram. Many users however do not consider these two worlds, the model and the diagram, as separate artifacts, but rather as a unified concept. They prefer to interact mainly with the diagrams since the graphical representations are closer their way of thinking. For such diagram-centric user scenarios, the separation as in EMF compare is counter-intuitive. Therefore, we present in this post a new diagram-centric plug-in that supports the combination the model and diagram changes in a common view.

Diagram Example:

Before

After

Requirements

But before we were able to work on our approach to satisfy the diagram-centric users, we had to think about their requirements and demands. After some extensive discussions we gathered the following main points:

• no strict separation in model and diagram differences
• keep control over the management of model changes
• full functionality of the versioning mechanism
• implementation compatible to the already existing groups

Approach

To be able to tell EMF Compare how we want to change the way it displays the tree of changes, we first of all initialized a new Eclipse plug-in and, of course. Within the plugin.xml configuration file we had to register an additional org.eclipse.emf.compare.rcp.ui.group by adding it with assistance of the so called Extension Point Selection Wizard. After doing that we were able to add our new EMF Compare group extension and finally add the corresponding class and a proper label.

But of course this was only the basic prerequisite. We still needed a way to logically implement our desired solution. Therefore we had to link the already described model and diagram representation. To have a specific use case for this project, we chose the modelling framework Papyrus and its implementation of UML. Looking at the corresponding XML files in EMF, you can see a link which points from the diagram to the model side. This is the case, because for one logical element, there are several graphical ones.

EMF Compare already provides a hierarchical data structure that inherits this property. The root level for one versioning process is called Comparison and contains several Matches which are created for identical elements that reside on the different versioning sides (Left, Origin, Right). Since within this context everything is built up as a tree, each Match can contain a list of Sub-Matches (containments) and of course because we are talking about versioning, on each level there is the possibility to have multiple differences, that shall be displayed within the Diagram-Centric group later on.

To be able to work with this already given data structure we decided to reuse some logical components of the BasicDifferenceGroupImpl.java. Finally we were able to fulfill our purpose via using a HashMap to store the Diagram Matches that corresponds to the desired Model elements.

Solution

For better understanding we provide two different representation of the comparison tree. In the first image you can see the default representation without any additional grouping. As we already mentioned during several sections of our paper, again there is the strict separation of the tree representation in the Diagram and Model perspective.

In contrast to this, the second one shows our final implementation, which unifies these two worlds and provides the user with a diagram-centric versioning tree.

Default representation without grouping

Diagram-Centric representation

Outlook

Now, after the hard work, we are able to show them in the desired way. But there are several areas with improvement potential. First of all this group was initially designed to work with UML and can be understood as a prototype. So to make this group applicable for end users, a lot more modelling languages have to be taken into account and tested against a huge amount of special cases. Another point of improvement is the compatibility of our implementation to get along with the pre-implemented filtering functions of EMF Compare. And finally during our examinations we were focused on the logical correctness of our solution.

But as a closing statement, once more we would like to note, that the Diagram Centric group implementation is the first step in a specialized model oriented perspective of representing the changes of graphical and logical models.

Interactive Model Animator for xMOF Models

By Matthias Hoellthaler and Tobias Ortmayr

Introduction

Model-driven Development (MDD) gained significant popularity over the last couple of years. Because of the higher abstraction of domain-specific languages it is possible to minimize redundant activities and improve the understandability of complex problems. This leads to a software development process which is less code-centric and more model-centric. Models are no longer only used to document design decisions, but became the main development artifact and source for code generation. Therefore, adequate techniques for ensuring the quality of models and their correctness in terms of expected behavior are necessary.

Existing ecosystems like the Eclipse Modelling Framework (EMF) provide profound tooling support for well-established concepts but are lagging behind current trends and developments like executable Domain Specific Modelling Languages (xDSML). The research field of xDSML is in comparison a relative young one. Unfortunately, this results in a lack of well established standards. The Moliz project provides with xMOF a promising approach for specifying xDSMLs based on the OMG standards MOF and fUML.

The aim of this project was to build a prototype of a model animator for xMOF models to improve the tool support for xMOF. This animator extends the debugging functionality of the Moliz model execution engine by interpreting debugging events to retrieve information about the current execution state of the model and using this information to visualize the state in the graphical representation (in this case activity diagrams). The animator supports node-wise stepping of xMOF activities and animates the activity diagrams to give the language designer a visual feedback about the state of the ongoing execution. To facilitate the integration into the Moliz project the model animator is implemented as an Eclipse plug-in. We implemented the animation in Graphiti and Sirius to demonstrate the differences between the two approaches.

Animation with Graphiti

In Figure 1 we see the Graphiti-based animator during the execution of a Petri net. As we can see in the bottom right, the nodes of the activity diagram are animated. Even after the end of an activity they are still animated for better traceability. They will only be reset if the activity diagram is executed again.

Figure 1: Animation with Graphiti

Animation with Sirius 

In Figure 2 we can see the same model. This time it is animated with Sirius. Both animators provide comparable functionality, however, the Sirius-based animator provides a more sophisticated animation of activity diagrams.

Figure 2: Animation with Sirius

Outlook 

The project should be extended in the future to further improve the tooling support. The following features are the most promising ones:

• Animation support for simultaneously executing activities should be supported. In particular, if two or more caller execute the same activity, the current state of the diagram is currently overwritten by the newest caller.
• Interactive stack traces are a useful addition to give the possibility for navigating between activity diagrams.
• The Sirius editor should be capable of representing all xMOF metaclasses. At the moment only the Activity metaclass and associated elements are represented.
• A better mapping algorithm should be implemented to guarantee a correct mapping between model elements and diagram elements. At the moment the name property of an element needs to be unique. A violation of this constraint can cause unexpected behavior.

Implementation

The source code of the project can be found on Github.

Modernizing Software Languages through the Application of Model-Driven Engineering

From XML Schema to Xtext

By Agnes Fröschl, Bernd Landauer, and Bernhard Müller.

Introduction

Since the invention of Extensible Markup Language (XML) [Harold], it has gained a great popularity. The language is nowadays used as configuration and exchange format for a vast amount of applications. Some examples are the GPS Exchange Format (GPX), Scalable Vector Graphics (SVG) or configuration files for Computer Numeric Control (CNC) machines for production data. To make sure a provided XML file is valid, XML Schema Definition (XSD) [Gao] was introduced. However, XML and XSD are both optimized for machine processing and not human readability [Badros].

To bring language engineers, i.e., for example, the person who designed the instruction reader for a CNC machine and domain experts, i.e., for example, the person who operates the CNC machine, together, the XMLText Framework [Neubauer] has been introduced. It provides a transformation from XSD to Xtext-based Domain Specific Language (DSL) [Eysholdt, Tolvanen] with a more comprehensive and easily human readable concrete syntax.

In this work, we describe various XSD features that are not yet supported or limited by the XMLText transformation as well as our efforts to extend it [3]. The target is to escape fixed concrete syntax and provide an easy to use and customizable syntax for non-language engineers. Another important key feature is to keep backward compatibility, such that systems, which rely on XML files as an input source, do not need to be adapted to fit the new syntax.

 

Extension of the XMLText framework

Although some features are already implemented in XMLText, XSD provides an extensive amount of advanced features, for which support has still to be created. Our work mainly focused on extending the Ecore and Xtext Grammar generation.

Data types were our first area of contribution. Instead of proper Xtext Terminals, only stubs were created. We implemented valid Terminals for various data types. With this extension, only minor efforts were necessary to implement the support of various length restrictions for strings.

A more advanced feature was the implementation of mixed content, i.e., the support for the mixed=true XSD attribute. This construct allows the mixing of various newly defined elements in the created syntax or, in other words, text content with arbitrary text elements between tags.

Finally, we implemented ID and IDREF to ensure unique values for certain elements to which others can refer to. The related features KEY and KEYREF have been examined but their support has not been implemented due to the usage of complex XPath rules which are beyond the scope of our project.

 

Concrete Syntax DSL

Making the concrete syntax DSL even more readable and customizable, we explored the possibilities of Xtext to adapt the concrete syntax and style the appearance in the editor.

The figure below shows an example how a customized concrete syntax for a company hierarchy could look like. Other implemented extensions can be seen too, like date data type which yields an error if the date is not valid, e.g. month greater than 12. Auto-completion for IDREF values referencing available ID values. An arbitrary text content element between the named tags.

customized concrete syntax DSL

 

Future Work

The XMLText framework targets a quite complex problem, not least because of the feature richness of XSD and respectively XML. There are several topics for further extensions. Future work may include following Topics:

• Implementation of further XSD features closing existing gaps,
• an XPath to OCL [Warmer] converter to fully support for example KEY and KEYREF XSD features,
• a fully automized generation of customized concrete syntax DSL, which includes a configuration wizard for syntax adaption,
• and a CSS interpreter for concrete syntax DSL styling.

 

Resources

[Badros] Badros, G.J.: JavaML: A Markup Language for Java Source Code. Computer Networks 33(1), 159-177 (2000).

[Eysholdt] Eysholdt, M., Behrens, H.: Xtext: Implement your Language Faster than the Quick and Dirty Way. In: Companion Proc. of OOPSLA. pp. 307-309. ACM (2010).

[Gao] Gao, Shudi, et al. W3C XML schema definition language (XSD) 1.1 part 1: Structures. In: W3C Candidate Recommendation 30.7.2 (2009).

[Harold] Harold, E.R., Means, W.S., Udemadu, K.: XML in a Nutshell, vol. 8. O'reilly Sebastopol, CA (2004).

[Neubauer] Neubauer, P., Bergmayr, A., Mayerhofer, T., Troya, J., Wimmer, M.: XMLText: From XML Schema to Xtext. In: Proceedings of the International Conference on Software Language Engineering. pp. 71-76. ACM, New York, NY, USA (2015).

[Tolvanen] Tolvanen, J., Kelly, S.: De ning domain-speci c modeling languages to automate product derivation: Collected experiences. In: Proc. of SPLC. pp. 198-209 (2005).

[Warmer] Warmer, Jos B., and Anneke G. Kleppe. The Object Constraint Language: Precise Modeling With UML. In: Addison-Wesley Object Technology Series (1998).

XMLText framework website: http://xmltext.big.tuwien.ac.at/

XMLText framework source code: https://github.com/patrickneubauer/XMLText
XMLText framework fork including extensions: https://github.com/syrenio/XMLText