=Paper=
{{Paper
|id=Vol-2019/mdebug_1
|storemode=property
|title=Transformations Debugging Transformations
|pdfUrl=https://ceur-ws.org/Vol-2019/mdebug_1.pdf
|volume=Vol-2019
|authors=Māris Jukšs,Clark Verbrugge,Hans Vangheluwe
|dblpUrl=https://dblp.org/rec/conf/models/JukssVV17
}}
==Transformations Debugging Transformations==
https://ceur-ws.org/Vol-2019/mdebug_1.pdf
Transformations Debugging Transformations
Māris Jukšs Clark Verbrugge Hans Vangheluwe
School of Computer Science School of Computer Science University of Antwerp
McGill University McGill University Flanders Make vzw
Montréal, Québec, Canada Montréal, Québec, Canada McGill University
Email: mjukss@cs.mcgill.ca Email: clump@cs.mcgill.ca Email: hans.vangheluwe@uantwerp.be
Abstract—Practical model transformation (MT) frameworks realizing such a debugger in AToMPM, a research-based MT
are usually composed of multiple execution contexts, building an tool. Specific contributions of our work include the following.
overall workflow by abstracting different aspects of execution.
• We describe a structured view of a debugging process
This heterogeneity brings additional challenges to debugging,
which must address a combination of quite different graphical that lends a unified way of navigating the debug target.
and textual formalisms. In this work we describe a layered • We describe a simple language for automated debugging
approach to debugging, mapping familiar debugging operations of MTs using declarative queries and breakpoints span-
to different formalisms, as well as the transitions between them. ning the levels of the MT stack.
Our design allows for seamless debugging through different
• Our declarative approach subsumes a separate control
abstractions, and supports both traditional imperative debugging
as well as declarative, query-based approaches. We demonstrate scheme for direct user interaction. In this way our design
our approach by prototyping a MT debugger in the AToMPM provides a unified debugging model, suitable for automa-
research tool. Our approach shows that it can be applied to other tion.
MT tools as well.
II. S TRUCTURED V IEW OF D EBUGGING
I. I NTRODUCTION In this section we present a general view of debugging in
a structured way. We will use this approach in order to have
Debugging Model Transformations (MT) brings additional a uniform operational semantics for debugging in situations
complexity due to the presence of a hierarchical execution where a general programming language paradigm may be
stack. Multiple execution layers are used, consisting of dif- less applicable, such as in debugging DSLs and in particular
ferent languages/formalisms at different levels of abstraction. MTs. In particular, this lets us clarify the notion of basic
A schedule language, for example, contains the rules, which debugger operations, such as step, which may be ambiguous
themselves hold patterns based on action code. Further down in declarative debugging contexts.
the stack, we find the pattern matching and application rou- Navigating the Debugging Target. To take a generic view
tines. As problems can manifest at each layer, or between layer of debugging control flow (process) we can imagine it to
interactions, thorough debugging requires a tool permitting be somewhat similar to navigating the multi-story building
inspection and modification throughout the execution stack. representing the debugging target. On the vertical dimension
In this work we describe the design of a MT debugger that (here we use the term without adhering to its strict definition)
addresses debugging of the whole MT stack, from the schedule we have a multitude of floors representing the many levels of
level down to the pattern matching and application routines nested structures. These hierarchical levels can be found in
details. Our design avoids resorting to code-level debugging, nested function calls, hierarchical models, etc. We call these
aiming instead to remain at the level of abstraction similar nested levels vertical levels (VL) and the movement between
to the Domain-Specific Language (DSL) of the models being them as vertical movement.
transformed. Each vertical level also has a horizontal dimension, this
The declarative nature of models and MTs has a further can be imagined as the apartments on a floor. If we use the
benefit in that it is a natural setting for many debugging tasks, programming language analogy, these levels represent a single
particularly event or watch-based goals, such as pausing exe- kind of scope. We call this horizontal dimension a horizontal
cution when a pattern matcher accumulates a certain portion of level (HL) and the movement within that level as horizontal
the match, or when an undesirable pattern appears in the output movement. Each horizontal level contains items of interest for
model. In this context, query-based debugging techniques [1] the debugging. These can be statements, expressions, nodes
yield further inspiration for our debugger design, allowing us and edges in the model. The unifying characteristic of these
to inspect all the relevant MT stack levels with declarative items is the fact that when the debugging target has processed,
queries during the debugging session. visited or executed one item, it will move to the next item—
Our goal is to provide a practical and flexible solution for items on a horizontal level are dynamically enumerated as
MT debugging for modern tools. We here show an initial a result of executing general step-over operations on the
validation of our design by describing our experience with debug target. In Figure 1, we show the horizontal and vertical
Fig. 2. Navigation pointer evolution. Red arrows represent a step-over
debugging scenario.
Fig. 1. Horizontal and vertical dimensions or levels. Arrows between items on (ordered) siblings, into child nodes, or back to parent nodes.
a horizontal level represent horizontal movement operation. Vertical operations
are dashed arrows and labeled.
The effect of these operations includes the modification of LP
and IP pointers, and presumes an execution stack of horizontal
item pointers, σ. We begin execution at (FIRST,TOP), with σ
dimensions1 of a debugging control flow. Some of the items empty.
on the horizontal level can contain other items (nested) and • Next. This operation processes the current item on
therefore lead to lower vertical levels. For example, these can a HL and move on to the next item at the same
be hierarchical model elements or function calls to descend level. Given non-NULL values for (IP,LP) and stack σ,
into. Therefore, the vertical dimension in a debug process is
((IP + 1, LP), σ) if ∃ IP + 1
explored in moving up and down between the hierarchical Next((IP, LP), σ) =
((NULL, LP), σ) if @ IP + 1
items (as illustrated by the dashed arrows in Figure 1).
Given (NULL,LP),σ, a Next operation delegates to an Up.
Figure 1 gives us a conceptual graph structure reminis-
• Down. This operation moves one vertical level down if
cent of the general forms of stack-based program execution.
possible, pushing the current state and setting the IP to
Each vertical level embodies a particular behavior, execution
the first item on the next level. If no deeper level exists
scope, or level of abstraction. The horizontal elements then
from this item, this delegates to a Next operation.
correspond to the smallest units of processing, computation,
execution, or specification within that level of abstraction. ((FIRST, LP + 1), IP : σ) if ∃ LP + 1
Down((IP, LP), σ) =
Next((IP, LP), σ) if @ LP + 1
Program execution, whether procedural or MT-based, can then
be understood in terms of navigating this 2D hierarchy. • Up. This operation completes processing of all
Navigation Pointers. For our purposes we need to be aware remaining items on the current horizontal level and move
of the control flow position during debugging with respect to one level up vertically. This is idempotent, and implies
the horizontal and vertical dimensions. Horizontally we are terminating the program if it attempts to ascend past TOP.
((IP’, LP − 1), σ 0 ) if LP 6= TOP ∧ σ = IP’ : σ 0
concerned with the item pointer (IP) and vertically with the Up((IP, LP), σ) =
level pointer (LP). We can then use the navigation pointer tuple ((NULL, TOP), ∅) if LP = TOP
(IP,LP) to describe the control flow position in the debugging We can now describe the program execution in terms of the
target, similar to the position of a point on a plane, described navigation pointer evolution. Using a simple textual example,
by its two coordinates. We also define certain constant values Figure 2 demonstrates a graph of possible pointer values in
for the navigation pointers. These allow us to refer to the the nodes and the operations that result in the changes as
typical positions and the debugging situations within the target. edges. In this example the items were the statements of the
The following are the constant values the IP can take. program and were identified by the line number. At each point
• NULL - this value indicates that the pointer is not a debugger may move to the next statement at a given level,
initialized and is not pointing to any item on the HL. either as a typical step-into (black Next arrow) or step-over
This value is useful in describing the situation when the (red arrow) any lower levels (the latter being Down operations
IP moves past the last item on the HL. that delegate to Next). An actual Down operation can be
• FIRST - the first item of interest on the HL. performed on the method call to enter the method body, at
The following is the constant value the LP can take. which point an Up operation can be requested to complete
• TOP - the very top VL in a debugging target. execution, skip debugging the method body and return to the
Taking the above values into account, the end of the caller, or Next can be used to flow through the execution
debugging (termination) for example, can be specified with of the increment statement, and Up executed when no more
a tuple (NULL,TOP). horizontal execution is possible.
Operations. We now propose the operations that allow us to Debugger behavior is of course not entirely addressed
navigate the vertical and horizontal dimensions in a debugging by this control flow model. We also need to consider how
target. Operational semantics essentially follows a controlled and when a debugger accesses data. Global, static data is
stack-based traversal, giving us operations to move between universally available, but access to other, local data can depend
on the language semantics given by the position in the control
1 In this paper we use the terms level and dimension interchangeably. flow (such as with local, stack variables in a procedural
language). As this depends on the language being debugged, parts (with an optional NAC), each in turn containing patterns.
we will require the target-language context provide a means to We need to decide on the VL and HL items. We do this by
expose (and represent) data, given a (current) navigation state, analyzing the possible movement in horizontal and vertical
allowing the debugger read and write access in accordance dimensions. In this case, in terms of debugging we would
with the expected semantics. navigate horizontally from a rule to a following rule in the
schedule, as the rules are processed at the same level of
III. S TRUCTURED V IEW OF MT S TACK abstraction. The actual rule transformation is at a different
In this section we apply our structured view of debugging level of abstraction from rule scheduling, and represents a
to a MT stack typically found in rule-based MT systems. descent into a deeper, vertical level, wherein there is horizontal
Usually, in MT debugging we are mainly concerned with movement between the process of applying first the LHS, and
the MT specification, its use of the source model and the final then the RHS parts of the rule.
effect on the target model. Inside the transformation specifica- The execution of the LHS and RHS parts contains further,
tion we can discover the hierarchical structure of the schedule nested execution complexity. That is the presence of some
encompassing MT rules. Further down, we find individual action code (AC) used to specify imperative constructs other-
patterns contained within the pre/post-condition parts of the wise too complex to express declaratively. The model element
rule. These individual patterns are used for matching in the attribute evaluation is one example of AC use. Treatment of
source model and modifying the target model. AC requires a context switch in interpreting the MT specifi-
In Figure 3 we outline a conceptual, level-based view of cation. Execution semantics depend on the action language,
the MT stack. Rectangles represent the components such and so requires a formal view of the language in terms of the
as static models and dynamic routines. Nesting relationship debugger navigation pointer values, or would need to relay to
represents hierarchy or containment. There is a clear separation the underlying general purpose language debugging facilities.
of data where the model artifacts are concerned. The data We utilize those facilities in our prototype evaluation to deal
found inside the operational semantics of related components, with AC.
however, such as the matcher used for patterns, is not clearly In summary, for this part of MT stack, the VL can be
distinguishable on the diagram. We will clarify this concern obtained by exploring the containment relationship in the MT
below. In the following paragraphs we investigate how the MT schedule presented. If the schedule is presented in textual
stack fits within our debugger. format the hierarchical relationship could also be explored
by descending into the function/procedure calls. In turn, a
horizontal dimension of each VL is exposed by enumerating
the items without exploring the hierarchy, as in the case of the
LHS and the RHS parts of one rule.
Pattern Matching Level. Going a level down into the
pattern matching process we necessarily encounter a tool
specific implementation. We unify pattern matching through a
generic, algorithm-agnostic view of the major steps involved.
Generally, a pattern matcher must first find a set of candidates
for constructing bindings for the pattern elements. Candidates
that are successfully bound form a set of bindings. A complete
set of bindings that matches the input pattern is called a match,
and a set of valid matches constitutes a matchset. Movement
Fig. 3. A MT stack view. Nesting of boxes represents hierarchy. in the horizontal dimension within these stages happens by
iterating over the corresponding set items. Finally, the sets
Input/Output Model Level. Shown on the right of Figure can also be considered as data that we can query during
3, this is the main data part of a model transformation. In debugging. Note that non-determinism may be present in terms
our prototype example we perform in-place transformations, of which match is actually selected for pattern application from
and therefore we expose that single model as the global data the matchset. This can be approached simply as exposing the
accessible to the debugger. Of course the model may contain selected match.
sensitive data, to which the debugging target may want to limit Pattern Application Level. For the pattern application
access, depending on requirements. process in the RHS part of the MT rule we also need
Schedule/Rule Model Level. The MT specification de- unified execution concepts, as again this design can be quite
scribes the control flow of the MT execution. This level implementation specific. As a general solution we rely on basic
is the heart of the debugging target. The nested structure Create, Read, Update, Delete (CRUD) operations affecting the
of MT specification is giving us hints to the vertical and input model, and define queryable sets related to each one
horizontal dimensions for the debugging. Note that schedule (except for the Read, in this context, as it belongs to the
also represents data for our debugger to query. The MT rule matching domain). Our interpretation of the CRUD operations
contained in the schedule typically consists of LHS and RHS is based on the unique labels on pattern elements used to assist
in identifying elements meant to be created or deleted. The
navigation in the horizontal dimension here is approached just
as in the case of pattern matching.
IV. D EBUGGING L ANGUAGE
Our debugger design builds on a custom debugging lan-
guage expressed through debugging rules, which follow the
familiar MT rule structure, including LHS and RHS parts. This
approach allows us to incorporate domain-specific syntax for
different layers. Debugging rules can also be chained to form
debugging scenarios, which can be executed separately from
a target MT, facilitating automated debugging.
Querying. We embed debugging operations into MT rules
Fig. 4. A debugging scenario that steps through the MT execution until the
based on the fact that the LHS of a MT rule is a pre-condition circle pattern in found resulting in a trace message.
for the application of the RHS. The LHS patterns are matched
in the input model, essentially acting as queries over the
debugging target state. These queries can include inspecting of AC. A visual representation, however, better fits the MT
the input/output model, as well as the MT specification. paradigm and we show a possible iconic representation of a
The MT problem domain formalisms are then reused in the Next command in Figure 4. In terms of common debugging
debugging rule without the need for any extra effort on the parlance, the Next operation represents step over, while step
part of an engineer. into maps to Down, and the Up operation maps to the step out
The data involved in the pattern matching and application operation.
process can also be the target of queries. For example, a match An example of usage is shown in Figure 4. In this automated
containing the bindings between the pattern and the input debugging scenario, we want to step through execution until a
model or any other such data can be exposed to the debugger. given query (detecting a circle node) is satisfied. The scenario
In this context we also reserve certain keywords for the match works through two rules, stepping through the execution by
sets described in Section III for more precise querying. issuing Next commands (with an unconditional query) until
In order to reason about the location within the debugging the creation of a circle in the input model can be detected by
target we may need to form a query based on the navigation a second rule. Rule scheduling applies the first rule (which
pointer pair, or some part of it. This is useful in order to always succeeds), then the second, returning to the first rule
perform an action when the MT control flow enters a desired when the second fails to apply. Upon success of the second rule
location in the MT specification, such as an execution of a a debugging action is performed, in this case a trace is done
particular rule. Due to variability in specification of navigation using action code. The pace of debugging is here given by
pointers and pattern matching/application related data we may the use of a Next operation, which depends on the navigation
need to resort to the use of AC instead of declarative queries. pointer position at the time the command is issued; it may
Action. After successful query discovery (or simply a pre- also be desirable to step execution at finer granularity, such as
condition satisfaction), we want to perform an action. For this, by using a Down operation in the first rule to model a fine-
we use the RHS of the rule, specifying traditional debugger grain (step-into) execution. Note, that given the many sources
actions, as well as modification of the various parts of the of data described in this paper, the second rule in Figure 4 is
query domains. We focus mainly on the former in this work, ambiguous in terms of which input model is applicable to the
but many other effects of the RHS action are possible, includ- query, this discussion we omit for brevity.
ing modifications to the input/output and the MT specification The second rule in Figure 4 represents a slight semantic
models. The latter, for example, allows us to perform the departure from typical MT rule design. In traditional MT rule
adaptation of MT specification for the exploration of new design, the absence of the LHS pattern in the RHS of Figure 4
execution scenarios. We may also want to influence the pattern indicates that the occurrence of the LHS pattern should be
matching and application process. More detailed investigation deleted (as well as the trace action performed). As this is
of execution adaptation and pattern matching/application in- not typically the combined intent of a debugger action, we
fluence represents an advanced debugging session, which we assume that when a navigation command is present in the RHS
leave for future work. the rule becomes read-only, and the occurrence of the query
Navigation Commands. One of the goals of our debug- present in the LHS will not be modified. When modifications
ger is to control the execution of the program by means to the occurrence of a query in combination with navigation
of issuing navigation commands. To issue basic debugging is desired, the user will need to perform this action with two
target navigation commands we embed them within the RHS. rules in sequence, one to perform the modification, and another
Application of the rule, and successful matching of the LHS to issue the navigation command.
pattern then results in the command being performed. Such Other debugging actions are of course possible. A pause
debugger commands can be simply issued through the use action, for example, could be performed (when the debugging
target is running continuously) instead to realize a break- such as rule names, action code line numbers, etc. These are
pointing functionality. In this case, the debugger still needs processed in the separate parallel state called DomainSpecifi-
to ensure that the target state does not change during query cActions. Here we can perform such actions as visualization,
evaluation. Depending on a query, we may need to implicitly highlighting or ensure that the data is shared properly between
pause the target’s execution on every, fine-grained naviga- components. This state is intended to be more implementation
tion pointer change before each query evaluation. Additional, specific as opposed to other states aiming to be as generic
higher level syntactic constructs can be used to encapsulate as possible. In fact, this Statecharts model was reused almost
verbose debugging scenarios, such as one in Figure 4, for without modification in another MT tool, AToM3 [5] to specify
convenience. the debugger. AToMPM and AToM3 implementations share the
Statecharts model’s compilation target language Python.
V. E VALUATION IN AT O MPM We now discuss the tool specific changes necessary to
Evidence of the utility and practicality of our design is given communicate with the Statecharts model described above. We
by a sample implementation in AToMPM [2], a browser-based identify all locations in the Python back-end code that are
Tool for Multi-Paradigm Modeling. relevant to the changes in navigation pointers. These places
The heart of our debugger is implemented using the well- are mainly processing the schedule, individual rules, the LHS
known Statecharts formalism [3]. Statecharts were chosen followed by the RHS, down to relevant action code evaluation
because of their convenience in describing autonomous, con- and pattern matching/application routines. From each new
current, and reactive systems. The inspiration for our solution navigation pointer location we send events to the Statecharts
comes from work by others on reimplementing existing model model and the MT tool immediately waits on a response
execution engines in Statecharts with the addition of a debug- from the Statecharts to proceed. This trivially enables pausing
ger related functionality [4]. We chose a different path and im- functionality. If the DebuggerControl is in the running state
plement the main logic in a central Statecharts model (Python- the execution may or may not be interrupted, according to the
based). This model deals with the navigation commands, navigation commands.
receives navigation pointer values from the debugging target, The action code treatment is approached utilizing the AC’s
and permits the target to advance the execution. In Figure 5 language facilities. In this case the AC is Python, which
we demonstrate the modified version of the actual Statecharts provides an interface to develop custom Python debuggers
generated from importing the SCXML file 2 into QTCreator’s called BdB. By extending the class we can process Python
3 code specific events and initiate communication with the
Statecharts editing facility. The navigation pointer events
Statecharts model to announce the navigation pointers change.
The navigation pointers change on events when the control
flow descends into the function or the next line/statement is
processed. The navigation pointers can carry line numbers
that we can highlight in the action code as demonstrated in
Figure 6. In addition, we can inspect variables. In the similar
Fig. 5. A Statecharts model of the debugger. Orthogonal components are
responsible for processing navigation commands, navigation pointers, and
implementation specific items corresponding to navigation pointers.
from the debugging target are processed in the ProcessingItems
state. The debugging target is then allowed to proceed with
the execution in the transition from the NavigationPointerNew
state according to the guard condition in the particular runtime
Fig. 6. A screenshot of our tool and processing of action code
context. This context is maintained in the DebuggerControl
state, where we process the navigation commands. Finally,
the navigation pointer changes can also carry information fashion of dealing with AC, we envision dealing with the MTs
specified entirely in AC (a loop calling a function representing
2 https://www.w3.org/TR/scxml/ the MT rule for example).
3 https://www.qt.io/ide/ Finally, our design supports automated debugging, but also
manual, user-triggered debugging actions. We can have a to debugging has other benefits as well. Debugging scenarios
debugging rule for each navigation/debugging operation, and can be exchanged between engineers, reused and analyzed.
we simply model the button press as the execution of a Our approach was further based on a structured view over
debugging rule (and essentially a MT) with a required action. the general debugging process. This allows us to bring clarity
Efficiency Considerations. It is evident that the context into the notion of a step in the declarative context of model
switching from the MT to the debugger MT will impact transformations. Our non-trivial prototype implementation,
performance. Generally, query evaluation in debugger rules based on this view, allows us to evaluate the feasibility of
is based on the same computationally expensive pattern- our debugger and demonstrate the treatment of AC as well.
matching problem as in general MTs. A comprehensive perfor- For future work we look to address the performance evalu-
mance evaluation is well beyond the scope of the basic design ation of debugging scenarios and their in-depth usage. We ex-
we introduce here (or our initial prototype). pect however, that the ability to debug model transformations
in a way presented in this paper may outweigh the runtime
VI. R ELATED W ORK effects on the whole system.
A variety of approaches exists for framing debugging de- The authors would like to thank Simon Van Mierlo for his
signs. A prominent approach is to follow an event-based insight into Statecharts-based implementation of debuggers.
view of a debugging process. One example is found in the
R EFERENCES
moldable debugger (MD) [6]. This flexible approach is based
on several primitive debugging events resulting from a debug- [1] R. Lencevicius, U. Hölzle, and A. K. Singh, “Query-based debugging
of object-oriented programs,” in Proceedings of the SIGPLAN OOPSLA
ging target operations combined to produce domain specific 1997. ACM, pp. 304–317.
events/operations. This approach can be used to implement [2] R. Mannadiar, “A multi-paradigm modelling approach to the foundations
the event-based part of our debugger. We, however, take a of domain-specific modelling,” Ph.D. dissertation, McGill University,
2012.
more structure-focused perspective, considering debugging as [3] D. Harel, “Statecharts: a visual formalism for complex systems,” Science
a process of navigating execution within and across hierarchi- of Computer Programming, vol. 8, no. 3, pp. 231–274, June 1987.
cal levels. [4] S. Van Mierlo, “Explicitly modelling model debugging environments,”
in Proceedings of the ACM Student Research Competition at MODELS
Query-based debugging from the general purpose language 2015 co-located with the ACM/IEEE 18th International Conference
domain was used as an inspiration in this paper [1], [7], [8]. MODELS 2015, 2015, pp. 24–29.
Whyline debugger [9] generates useful queries that can be ap- [5] J. de Lara and H. L. Vangheluwe, “Using AToM3 as a meta-CASE en-
vironment,” in 4th International Conference On Enterprise Information
plied to the recorded program execution traces. Generic query Systems, 2002, pp. 642–649.
designs can of course bring performance concerns. EMF- [6] A. Chiş, T. Gı̂rba, and O. Nierstrasz, “The moldable debugger: A
IncQuery tool [10] performs efficient, incremental declarative framework for developing domain-specific debuggers,” in SLE 2014,
Västerås, Sweden, Proceedings. Springer International Publishing, pp.
query evaluations for MT verification. We can potentially 102–121.
utilize similar incremental pattern matchings to improve the [7] A. Potanin, J. Noble, and R. Biddle, “Snapshot query-based debugging,”
performance of our query evaluation. in 2004 Australian Software Engineering Conference. Proceedings.,
2004, pp. 251–259.
The GDL debugging language [11] defines debugging op- [8] R. Lencevicius, “On-the-fly query-based debugging with examples,” in
erations that are embedded into a general programming lan- Proceedings Fourth International Workshop on Automated Debugging,
guage, and complex debugging scenarios can then be specified 2000.
[9] A. J. Ko and B. A. Myers, “Debugging reinvented: Asking and answer-
programmatically. Similarly, we embed the MT debugging ing why and why not questions about program behavior,” in Proceedings
language elements into the MT language. This allows us of the ICSE 2008 Leipzig, Germany. ACM, pp. 301–310.
to use branch and loop constructs and create user specified [10] M. Búr, Z. Ujhelyi, Á. Horváth, and D. Varró, “Local search-based
pattern matching features in EMF-IncQuery,” in ICGT 2015, L’Aquila
transformations for the purpose of debugging. Italy, Proceedings, pp. 275–282.
MT and model debugging have of course been explored [11] R. H. Crawford, R. A. Olsson, W. W. Ho, and C. E. Wee, “Semantic
in the past. AToMPM, for instance, already supports MT issues in the design of languages for debugging,” Comput. Lang., pp.
17–37.
debugging at the level of the MT schedule and down to [12] R. Mannadiar and H. Vangheluwe, “Debugging in domain-specific
individual rules, as previously described [12]. Other MT modelling,” in Proceedings, SLE 2010 Eindhoven, The Netherlands.
debugging solutions have also been described [13]–[16]. Springer-Verlag, pp. 276–285.
[13] R. T. Lindeman, L. C. Kats, and E. Visser, “Declaratively defining
domain-specific language debuggers,” in Proceedings GPCE 2011 Port-
VII. C ONCLUSIONS AND F UTURE W ORK land, Oregon USA. ACM, pp. 127–136.
In this chapter we explored the design of a MT transfor- [14] L. Geiger, “Model level debugging with Fujaba,” in Proceedings of 6th
International Fujaba Days 2008.
mation debugger based on model transformations themselves. [15] T. Mészáros and T. Levendovszky, “Visual specification of a DSL
The debugger allows for specification of debugging scenarios processor debugger,” in Proceedings OOPSLA Workshop on Domain-
aiming at discovering complex MT execution artifacts, using Specific Modeling 2008, Nashville, USA, pp. 67–72.
[16] M. Lawley and J. Steel, “Practical declarative model transformation with
the syntax and semantics of MTs. This reduces the learning tefkat,” in Satellite Events at the MoDELS 2005 Conference: MoDELS
curve as the user is operating within the familiar domain of 2005 International Workshops Doctoral Symposium, Educators Sympo-
MTs and reuses existing DSLs. The advantage of a debugging sium Montego Bay, Jamaica, October 2-7, 2005 Revised Selected Papers,
J.-M. Bruel, Ed. Springer Berlin Heidelberg, pp. 139–150.
scenario, just like the MT itself, is that it can be left to run
unattended and perform the desired tasks. A modeled solution