Friday, August 21, 2015

Enhancement of the xMOF Editor and Debugger

Tooling for Executable Metamodelling with xMOF

By Simon Georg Hecht, Christoph Kubin, Melanie Nothmüller, and Angela Purker

Model execution is very useful for fast prototyping, trace analysis, and many other areas. One important executable modeling language is foundational UML (fUML) - a subset of UML that is executable thanks to a standardized execution semantics. xMOF lifts fUML a meta-level up to the meta-metamodel level M3 to enable the precise specification of the execution semantics of behavioral modelling languages. Therewith, it allows leveraging fUML’s execution semantics for executing models compliant to such behavioral modeling languages defined with xMOF. 

Model execution - and especially model execution of fUML and xMOF models - is a very young topic in the modelling domain and therefore also the tools for model execution are not yet in a mature state. However, to enable the work with executable models like xMOF, it is necessary to have tools providing efficient and effective support for the modelling process. To bring this to a different context, a Java developer needs a good IDE to ease his/her development process. It is the same for the model-based approach. To ease the modelling process, good tools are needed. But model execution is not as old as Java development, so the tools do not support all needed tasks yet.

In this work we focus on two important tools for xMOF, namely the xMOF editor that allows the creation of xMOF models for the definition of execution semantics, and the xMOF debugger that supports the verification process of the defined execution semantics. 

Improvements of the xMOF Editor and Debugger

The purpose of the xMOF editor is to allow an efficient and effective creation of xMOF models. Besides editing support, it is very important to have a debugger to trace the model execution and thereby simplify troubleshooting when errors occur. Both tools can also improve the understandability of the created model itself.

xMOF Editor

There is already an editor available for xMOF providing basic editing functionality needed to create xMOF models. 

The structure of the xMOF editor is subdivided in 4 major parts as you can see in the figure above. On the left hand side (1) there is the tree-based structural view similar to the standard Ecore modelling view. In the middle (2) there is the activity editor itself, based on Graphiti. It is the editor for creating activities in a graphical way. On the right hand side (3) there is the feature palette for the activity editor. At the bottom (4) there is the standard property view for editing the elements in the diagram as well as in the structural view.

Our goal was to enhance the efficiency, effectiveness, and usability of the xMOF editor. Therefore, we extended the original xMOF editor in the following way: 
  1. First, we implemented and improved the initialization of xMOF model elements to speed up the modeling process and reduce potential error sources.
  2. Second, we added support for the visualization and editing of xMOF model elements contained within other elements, which could before be only edited in the tree-based structural view.
  3. Third, we automated the modeling steps needed when overriding the behavior of operations defined in xMOF models.
  4. Fourth, we implemented some heretofore missing usability features of the editor, in particular, the closing and moving of tabs opened within the xMOF editor.
  5. Fifth, we implemented a specialized validation for xMOF facilitating the localization of potential bugs in xMOF models.

xMOF Debugger

xMOF Debugger

For debugging, an fUML debug plugin was already available, which was taken as basis for the new xMOF debug plugin. While the fUML debug plugin was able to debug plain fUML models, our goal was to expand its applicability to xMOF models. Therefore, the most important step was the generalization of the debug functionality for both languages fUML and xMOF in order to avoid code duplicates in the two debug plugins. Another improvement - which is a result of the generalization - is the implementation of the stepping mechanism (use of the debugging methods stepInto(), stepOver() and stepReturn() from the Eclipse debug toolbar) for the xMOF debug plugin. The figure above gives an overview of the newly created classes in the generalized plugin and shows the elements in the Eclipse debug perspective for xMOF.

Outlook

Throughout the project we identified many more interesting improvements of the xMOF editor and debugger. Further improvements for the xMOF editor in detail could be:
  • A more customized property view showing only the necessary properties
  • Direct editing features for the diagram components
  • Context buttons for object suggestions
  • Enabling the creation and setting of pins in the graphical representation
  • Layouting of diagrams, e.g. allowing color for any activity object 
  • Decorating the activity diagrams based on the errors of validation
  • A better validation/error output 
  • A more sophisticated approach on the modularity of validators, for example a setting window where you can choose which validators are needed for your project
  • Live validation and markers
The xMOF debugger currently supports basic debug functionality, such as stepping through activity diagrams. However, interesting further and more advanced features include trace visualization, such as the visualization of a debugged model’s state as an object diagram. 

Implementation

xMOF is part of the moliz project. The source code of the project is publicly available at https://github.com/moliz.

Tuesday, August 04, 2015

Repairing model constraint violations with MOMoT

Introduction

Model Transformation are the key concept of the Model Driven Engineering today. Usually, Model Transformations are applied through Transformation Rules. However, the orchestration of the rules is a very complex task. Manually, it is very hard to determine what would be the best order to apply such rules. One possible way to tackle this, is to apply Search-based optimization techniques. Therefore, a framework called MOMoT has been created which combines two worlds, Model Transformations and Search-based Software Engineering. It is a new framework which has already been applied on 3 problem domains - Stack, Modularization and Refactoring problem. Our goal is to define a new problem domain to apply MOMoT and to evaluate behaviour, vulnerabilities and threats of such an approach.

Problem Definition

Often, models represent real-world problems. As such, they also have constraints and restrictions that need to be fulfilled. Such constraints can be violated and one of the essential tasks in model engineering is to repair such model so that they satisfy all the constraints. Our goal is apply MOMoT approach on such models and to repair them so that at the end they satisfy all the constraints. We applied this approach to many different constraints sequentially and observed their results. In the following, we describe very simple model and have MOMoT can be applied on that. We tested this approach on many different constraint violations including:
  • Multiplicity upper bound
  • ID not set
  • Duplicate id
  • Not-Null attribute
  • OCL constraint(s)
  • Unique attribute
  • Value aggregation and counting
All the projects can be found at public repository at GitHub.

Running Example

In order to apply this approach on this specific problem domain, we need to define a model which violates some of the constraints. First step would naturally be to define meta-model with some specific constraints. In this example we define a very simple meta-model which represents a university.

Meta-model of the university

Here, we see that an university consists of student and courses, where course should have at least 5 students. Now we create a model which doesn't satisfy this constraint. Our model consists of 8 students and 3 courses where each course has 5, 3 and 2 students assigned to it respectively. In order to repair such models we need to define transformation rules which are applied on the models to resolve the constraint violations. We use Henshin to define them.

Henshin transformation rules for our example

We can see that first rule creates a new student while the second rule assigns new student to a course. Orchestration of those rules is defined in a Java class.

Evaluation 

With such approach we were able to repair almost all models. Models that have manipulated ID (null or duplicate) were not able to get repaired since parsing of such models already produces an exception. Therefore, we have removed the ID attribute and replaced it by an equivalent unique, not-null attribute for which a constraint in OCL has been defined.
Concluding, we have discovered that it is very important how a specific OCL is defined in our approach. For example, one way to define that students have unique numbers would be to define it in a class University. However, this would lead to only one constraint violation no matter how many students actually violate that constraint. When we try to minimize the number of constraint violations in the search, a better guidance can be given by defining the constraint in the context of the Student class resulting in a better representation of the actual number of constraint violations.