=Paper=
{{Paper
|id=Vol-2019/mdebug_2
|storemode=property
|title=Towards Debugging the Matching of Henshin Model Transformations Rules
|pdfUrl=https://ceur-ws.org/Vol-2019/mdebug_2.pdf
|volume=Vol-2019
|authors=Matthias Tichy,Luis Beaucamp,Stefan Kögel
|dblpUrl=https://dblp.org/rec/conf/models/TichyBK17
}}
==Towards Debugging the Matching of Henshin Model Transformations Rules==
https://ceur-ws.org/Vol-2019/mdebug_2.pdf
Towards Debugging the Matching of Henshin
Model Transformations Rules
Matthias Tichy, Luis Beaucamp, and Stefan Kögel
Institute of Software Engineering and Programing Languages, Ulm University, Germany
Email: @uni-ulm.de
Abstract—Model Driven Engineering aims at improving ef- finding a match of the left hand side on the model resp. host
fectiveness and efficiency of software engineering. Model trans- graph (typically a subgraph isomorphism) and then changing
formations are a key artifact in model driven engineering as the match such that it is a match of the right hand side.
they enable transforming models into other artifacts for further
processing, e.g. analysis models or executable code. However, We illustrate the techniques presented in this paper using the
particularly graph transformation based model transformation transferMoney rule from the Bank Example [6] provided
tools often lack detailed debugging capabilities. In this paper, with Henshin (cf. Figure 1). It represents the possibility to
we sketch how to debug the matching step of the execution of transfer some amount of money from one account to another
Henshin model transformation rules. while ensuring that the sender’s credit is sufficient and that the
I. I NTRODUCTION sender cannot transfer money to himself from the receiver’s
account by entering a negative amount.
Software engineering with models often requires the appli-
cation of model transformations, e.g., chains of model transfor- transferMoney(in client:Estring, in fromId:Eint, in toId:Eint,
mations to translate state machines into code or operations in in amount:EDouble, var x:EDouble, var y: Edouble)
the editor to change the models. Hence, model transformations <> <>
are a key element of model-driven software engineering. <>
from:Account to:Account
:Client
Existing research has identified the ability to analyze models <> credit=x->x-amount credit=y->y+amount
as a key driver w.r.t. to successful application of model- name=client accounts id=fromId id=toId
driven engineering in practice [1]. Debugging is a specific
analysis technique – not only with respect to finding defects ? Condition financial covering ? Condition positive transfer only
x > amount amount > 0
but also to understanding how the model transformation works,
e.g. for adding functionality. Debugging Henshin rules, a Fig. 1. Bank example - transformation rule
graph-transformation based model transformation tool, has the
challenge that its execution process does not follow the typical Henshin uses a constraint based approach for finding
sequential order of imperative languages where one usually matches of the left hand side in the host graph [7]. In a
executes statement after statement. first step, a search plan is derived containing a variable
Several model transformation frameworks offer debugging for every node in the left hand side. For each variable, a
support that offers at least basic break points and stepwise corresponding domain slot is created which contains a set of
execution on the transformation rule level. Some frameworks all potential candidates for this node – initially all instances
extend this support by offering undo/redo (e.g. QVT-o [2]), of the node’s type. Furthermore, the search plan also defines
conditional breakpoints (e.g. QVT-o, VIATRA [3]), visualiza- which constraints should be enforced, e.g., constraints on
tion of matchings (e.g. GReAT [4], VMTS [5]), or even the attributes as well as on references between nodes.
modification of the current match during debugging [5]. All
of the above debugging features work on the rule level, i.e.,
:Client from: Account to: Account
they step over the matching phase of a rule. To the best of
checkAttr(id=toID)
checkAttr(credit=y)
checkType(Account)
checkType(Account)
checkType(Client)
checkAttr(credit=x)
checkAttr(id=fromID)
checkAttr(name = client)
our knowledge, there is no graph transformation approach that restrictBy
(accounts)
enables developers to debug the matching step of a rule.
The contribution of this paper is a sketch how the matching
step can be debugged, which is the most important part of the
execution of single Henshin transformation rules.
II. H ENSHIN T RANSFORMATION L ANGUAGE Fig. 2. Bank example - search plan
Henshin supports single rules, containing a left hand side
(LHS) describing the precondition of the rule and a right Figure 2 shows the search plan of the Henshin rule
hand side (RHS) describing the postcondition of the rule. transferMoney of the bank example. The order of matching
Informally, a Henshin transformation rule is executed by first the variables is shown by the rectangles and the big arrows.
Furthermore, for each variable the constraints are annotated. and then attribute constraints like name == ‘‘Bob’’. Unfor-
For example, for the :Client variable first the type is checked tunately, the current candidate has the name ‘‘Charles’’.
and then the attribute constraint is checked. Finally, the set of Hence, the attribute constraint is not fulfilled and stepping
candidates for the from:Account is restricted to those which further leads to considering the next candidate (Bob). Here,
are reachable via the accounts reference from the current the type and attribute constraints are satisfied. Executing the
candidate for the :Client variable. reference constraint ensures that the set of candidates for the
The match of the left hand side is then computed by account variable from:Account is restricted to the candidate
a recursive back-tracking algorithm which binds potential 2:Account as this is the only account Bob has. However, we
candidates, i.e., objects in the model (the model provided see later that this account does not have enough credit. The
with the Henshin example contains the clients Alice, Bob, final candidate for the :Client variable also does not satisfy
Charles), to variables while removing impossible candidates all constraints.
from the domain slots by imposing the constraints derived While step into covers all states, step over usually stays on
from the left hand side. the same “call stack” level, e.g., iterating over all candidates
for a variable or iterating over all constraint types. Step return
III. D EBUG S TEPS FOR H ENSHIN RULES simply executes all other activities until a higher level is
Our approach follows the usual debugging steps (step into, reached, e.g. if the current debug state is investigating the
step over, step return, run until) found in all typical debugging candidate Charles, step return executes all steps until the
environments. As described above the Henshin interpreter matching process of the variable from:Account starts.
uses a recursive backtracking algorithm to find a match for Finally, run until executes all steps until a certain activity
the left hand side of the rule. Each recursive call covers the takes place, e.g., until a certain candidate is investigated,
matching of a single variable. a certain constraint is checked, or a matching of a certain
The matching of a single variable consists of several ac- variable starts.
tivities of the matching process as indicated in the search
plan (cf. Figure 2): selection of a candidate as well as IV. C ONCLUSION AND F UTURE W ORK
checking/enforcing the different types of constraints. Multiple Currently, we have implemented the debugging steps
instances of each constraint type are possible, e.g., multiple outlined in Section III in Henshin and refactored the
attribute constraints. Each of these activities is similar to interpreter in order to enable step-wise execution of the
a function in an imperative program that “call” each other, matching process. We are currently working on integrating
e.g., the function responsible for selection of candidates calls the different step actions into the standard Eclipse debugging
the different functions for checking/enforcing constraints, and environment and are developing specific visualizations for
the function responsible for checking/enforcing all attribute the variable view as well as the call stack. Whether and
constraints calls a function for checking an individual attribute. how much our approach actually improve efficiency and
Hence, a specific state during matching in our running example effectiveness will be a focus of future user studies.
has a “call stack” (cf. Table I).
Acknowledgment This work was funded by the German
TABLE I Research Foundation (DFG) as part of the DFG Priority
C ALL STACK FOR A SPECIFIC STATE DURING DEBUGGING . Programme 1593 (TI 803/2-2 and TI 803/4-1).
activity example R EFERENCES
4. Constraint Instance check attribute constraint: name == “Bob” [1] G. Liebel, N. Marko, M. Tichy, A. Leitner, and J. Hansson, “Model-based
3. Constraint Type check all attribute constraints engineering in the embedded systems domain: an industrial survey on the
2. Candidate check the candidate bob state-of-practice,” Software & Systems Modeling, pp. 1–23, 2016.
1. Variable select candidate for the variable :Client [2] M. Wimmer et al., “Reviving QVT relations: model-based debugging
using colored petri nets,” Model driven engineering languages and
systems, pp. 727–732, 2009.
The search plan (cf. Figure 2) shows that the vari- [3] “Advanced features of the viatra framework,”
ables are matched in the order :Client, from:Account, http://static.incquerylabs.com/projects/viatra/viatra-
docs/ViatraAdvanced.html, (Accessed on 07/14/2017).
to:Account. Hence, the first debugging state is matching
[4] D. Balasubramanian, A. Narayanan, C. van Buskirk, and G. Karsai,
the variable :Client. With step over, we would complete “The graph rewriting and transformation language: Great,” Electronic
the matching of the variable, i.e., selecting a candidate which Communications of the EASST, vol. 1, 2007.
[5] T. Mészáros, P. Fehér, and L. Lengyel, “Visual debugging support for
satisfies all constraints, which in our running example is Bob. graph rewriting-based model transformations,” in EUROCON, 2013 IEEE.
However, if we step into, the debugging state changes to IEEE, 2013, pp. 482–488.
selecting the candidate Charles as it is the first object in [6] C. Krause, “Henshin bank example,”
https://www.eclipse.org/henshin/examples.php?example=bank.
the model. This step into allows us to iterate with subsequent [7] M. Tichy, C. Krause, and G. Liebel, “Detecting performance bad smells
step overs over all candidates for the variable. for henshin model transformations,” in Proceedings of the Second Work-
But, if we further step into, we can iterate over constraint shop on the Analysis of Model Transformations (AMT 2013), Miami, FL,
USA, September 29, 2013, 2013.
type and instances of the constraint type. In our running
example, we first check the type (Client in our example)