Debugging in Domain-Speciﬁc Modelling

Debugging in Domain-Specific Modelling

† Raphael Mannadiar and †,‡Hans Vangheluwe

Modelling, Simulation and Design Lab

† McGill University3480 University Street

Montreal, Quebec, Canada

‡ University of AntwerpMiddelheimlaan 1

2020 Antwerpen, Belgium

Abstract. An important obstacle to the wide-spread adoption of Model-Driven Development (MDD) in industry is the lack of proper debuggingfacilities. In the context of software development, debugging support isprovided by a combination of language and Integrated Development En-vironment (IDE) features which enable the monitoring and altering of arunning program’s state. In Domain-Specific Modelling (DSM) however,debugging activities have a wider scope: a model transformation designerneeds to debug transformations and/or synthesized artifacts. A domain-specific modeller needs to debug models at the level of models and notat the level of synthesized code. In this work, we survey the currentstate-of-the-art of debugging in the context of DSM. We then proposea conceptual mapping between debugging concepts such as breakpointsand assertions in the programming world and the DSM world.

1 Introduction

Domain-Specific Modelling (DSM) allows domain-experts to play an active rolein (software) development efforts. It provides them with means to manipulateconstructs they are familiar with and to automate the error-prone and time-consuming conceptual mapping between the (often very distant) problem andsolution domains. Empirical evidence suggests increases in productivity of upto one order of magnitude when using DSM and automatic artifact synthesis asopposed to traditional code-driven development approaches [14, 10, 13].

Model transformations can be used to specify the semantics of Domain-Specific Languages (DSLs) by either defining an interpreter (operational seman-tics) or by mapping onto formalisms whose semantics is well understood (suchas Petri Nets, Statecharts, Differential Equations or code). Numerous modeltransformation techniques exist ranging from explicit, operational to rule-based,declarative approaches. Czarnecki and Helsen provide a comprehensive and de-tailed feature-based classification in [6]. In this work, we restrict ourselves torule-based approaches. In these approaches, model transformation models arecomposed of a collection of rules. Each of these have a left-hand side (LHS)pattern, a right-hand side (RHS) pattern and optionally a negative applicationcondition (NAC) pattern, condition code, and action code. The LHS and NAC

R. Mannadiar and H. Vangheluwe. Software Language Engineering., pp. 1–20, 2010.c© Springer-Verlag Berlin Heidelberg 2010

2 † Raphael Mannadiar and †,‡Hans Vangheluwe

patterns respectively describe what sub-graphs should and should not be presentin the source model for the rule to be applicable. The RHS pattern describeshow the matched LHS pattern should be transformed by the application of therule. Further applicability conditions may be specified within the condition code,while actions to carry out after successful application of the rule may be specifiedwithin the action code.

The typical work flow of a DSM project consists of the specification of oneor more DSLs and of the model transformations that define their semantics.Subsequently, Domain-Specific models (DSms1) are created. In practice, mod-els, model transformations, and synthesized artifacts may require debugging andthus appropriate debugging facilities are needed.

In Section 2, we survey the current state-of-the-art of debugging in the con-text of DSM. In Section 3, we review common debugging concepts such as break-

points and assertions from the programming world. We then map these conceptsonto the DSM world in Section 4. Finally, future work is discussed in Section5. The main contributions of this work are our comparison-oriented mappingof debugging concepts from the programming world to the DSM world and thedemystification of the amount of effort required to produce DSM debuggers.

2 Related Work

Very little attention has been paid to debugging in DSM. In [14, 10], severalindustrial applications of DSM are presented. In all of these, the debugging ofthe models, of their associated ad hoc generators, and of the synthesized arti-facts is accomplished without any tool support. More importantly, debuggingis invariably performed at the code level rather than at the model level. This,despite being DSM efforts motivated by the general philosophy of improvedproductivity through the manipulation of domain-specific concepts. Debuggingdeals only with synthesized artifacts and modelling tool APIs (e.g., functionsfor viewing and manipulating internal representations of model entities). In thesofware realm, this would be equivalent to debugging compilers and bytecode tofind and resolve issues in an Object-Oriented (OO) program.

The most advanced DSm debugger to-date is that presented by Wu et al.in [21]. Their approach allows the re-use of existing, tried and familiar debug-ging facilities. By enabling the hidden and automatic construction of a detailedmapping between model entities and synthesized code, the approach allows thedesigner of textual DSms to use Eclipse’s built-in debugging facilities. Thus, thedomain-specific modeller is given means to set breakpoints within the domain-specific code, to pause/resume execution and more, without requiring any prior

1 Note that we refer to domain-specific modelling as DSM and to a domain-specificmodel as a DSm.

Debugging in Domain-Specific Modelling 3

knowledge about the synthesized code or the code generator. From a tool im-plementer’s point of view, the main advantage of this technique is that it doesnot require the implementation of a new debugger from scratch. However, theapproach is currently limited to textual languages, restricts the modeller to theEclipse tool, and assumes that the generated artifacts are code. Also, the ap-proach does not consider the debugging of the transformations that generateartifacts from models.

In [12], we laid the basis for extending Wu et al.’s work to visual modellinglanguages. Graph transformation rules that translate DSms of mobile device ap-plications to Google Android code are instrumented such that backward links(also known as traceability links) are maintained between constructs at differentlevels of abstraction. Ultimately, these links are realized in the form of code.Running the synthesized applications (either in an emulator or on a Google An-droid device) causes the associated DSm, displayed within a visual modellingtool, to be animated and it state updated. In the approach described in thispaper, the above-mentioned backward links can be further exploited and usedas “forward links” to propagate debugging commands such as break and update

value to running applications.

Tools such as AToM3 [7] enable some form of transformation debugging viastep-by-step rule execution. Instead of having transformations always run tocompletion, these tools allow the execution of rules one at a time, the manualselection of which rule to execute in cases where multiple rules are simultane-ously applicable, the choice of which of multiple matches to transform, and eventhe modification of the source model between rule applications. This enables therule designer to observe the effects of each rule in isolation and to perform someform of transformation debugging. However, more advanced functionality suchas “pause the transformation when rule ri is encountered” or “when a patternp appears in the destination model” are not natively supported.

Finally, in [16], Syriani et al. propose the modelling of exceptions and theirhandlers at the level of abstraction of Model Transformation Languages (MTLs).They propose a categorization of model transformation exceptions and extenda control flow environment for rule execution with provisions for specifying ex-ception handlers. Their technique for the modelling of flow interruptions byexceptions can readily be extended to model flow interruptions caused by de-bugging commands as well as the specification of arbitrary breakpoints withinthe transformation model. This possibility will be further explored in Section 4.1.

3 Debugging Code

Debugging forms a central part of any programming effort. Several authors havelooked into common sources of bugs, into what makes certain bugs more insidi-ous than others, and into popular debugging activities [8, 22]. Not surprisingly,


presenting information about program state as well as hand-simulation (i.e.,interrupting execution and stepping through code) are often used for trackingdown and resolving bugs. Means to carry out these activities are thus commonlyfound in modern programming languages and Integrated Development Environ-ments (IDEs). Below, a brief overview is given of the most common debuggingfacilities featured in OO languages and popular IDEs.

3.1 Language Primitives

The following concepts are commonly used to create a “poor man’s debugger”when a full-fledged debugger is not available.

Print Statements The central part of every programmer’s2 first program:“Hello World!”. Print statements are commonly used to output variable contentsand to verify that other statements or code blocks are executed.

Assertions A slightly more advanced feature than print statements, asser-tions enable programmers to verify that arbitrary conditions are satisfied at agiven point in the program’s execution. Assertions traditionally have two par-ticularities. The first is that they cause the execution to be aborted when theircondition fails. The second is that the source language or its compiler usuallyprovide means to enable or disable assertions (e.g., Java’s compiler has a flag toenable assertions, compiling C++ in “release” mode rather than “debug” modedisables assertions). This implies that assertions are not required to be removedor commented out (as is the case with print statements) in order to avoid unde-sired output or computation in deliverables.

Exceptions Exceptions, the third and most advanced enabler for debuggingcommonly found in programming languages, are thrown at runtime to indicatethe system is in a problematic state. An exception encapsulates information onthe system’s state (exception context) as well as on the problem that occurred.Numerous exceptions are built into languages to report events such as I/O prob-lems and null-pointer dereferencing. Exceptions may halt the execution of a pro-gram. Programmer-defined exception handlers may however catch an exceptionand attempt to take appropriate action (such as recover from the identified prob-lem), forward them higher along the call stack or gracefully terminate. Lastly,provisions for defining new types of exceptions are also usually made available toprogrammers to enable support for application-specific exceptional situations.

3.2 Debugger Primitives

The following facilities are commonly provided in modern IDEs.

2 In the following, the term programmer is loosely used to describe both the code’simplementer and the person debugging it.


Execution Modes To our knowledge, every IDE debugger has provisions toexecute a program continuously (i.e., until either termination or user interrup-tion) or step-by-step (i.e., one program statement at a time). “Stop” and “pause”commands allow for the terminating or non-terminating halt of the executionrespectively. When the execution is paused, the user (re-)enters continuous modeusing a “play” command or the step-by-step mode using the “step” command. Itis important to note however that most IDE’s enable programmers to run theircode in release mode (as opposed to debug mode) in which case only playingand stopping functionality is available.

Steps There are usually three step commands: step over, step into and step

out (or step return). The first executes the current statement as one atomic block.The second tells the debugger to display the execution of any sub-statements(e.g., function calls) contained within the current statement. Stepping into sub-statements implies a change of scope. Moreover, certain debuggers allow steppinginto seemingly atomic constructs into their corresponding lower-level represen-tations. For instance, it is possible in Eclipse to step through Java bytecode.The available level of granularity (or abstraction level) is obviously dependenton tool support and programming language implementation. Finally, steppingout tells the debugger to run until it has exited the current scope and is onelevel higher in the call stack.

Runtime Variable I/O IDE debuggers usually provide means to read (andchange) global and local variables when the program’s execution is paused. Thisfeature effectively removes the need to insert debugging-related print statementsinto the code. To our knowledge, no popular debugger imposes any constraints(beyond basic type constraints) on the values one can assign to variables whenthe execution is paused.

Breakpoints Breakpoints allow the programmer to specify when the de-bugger should interrupt normal program execution. This avoids having to stepthrough the code line by line. Breakpoints are commonly set on statements in-dicating that the execution should be paused before the debugger executes thegiven statement. Most debuggers also support associating hit counts or booleanconditions with breakpoints. These respectively enable the programmer to spec-ify that a breakpoint should only halt the execution when the statement hasbeen executed some arbitrary number of times or if an arbitrary condition overthe state (context) is satisfied.

Jump To Certain debuggers allow the programmer to “jump” from the cur-rent statement to some other statement without executing the statements inbetween. This is akin to changing variable values where the variable in questionis the program counter. In other words, the debugger’s state rather than the pro-gram’s state is what is being modified. Though this feature may be convenient,


it may bring the program into an unstable state.

Stack Traces Stack traces allow the programmer to see which function callsled the program into its current state. Stack traces become visible when the ex-ecution is paused. Most debuggers support navigating from the current contextto that of any other level in the stack trace for variable viewing and editingpurposes.

The concepts above are by no means an exhaustive list of all debugging facil-ities available to modern programmers. However, together they form an effectivebasis for writing debugable code and debugging it.

4 Debugging in DSM

The development process in DSM has two important facets: (1) developing mod-els and (2) developing model transformations – which may describe a formalism’soperational semantics, or transform DSms into lower level (i.e., closer to code)models or artifacts –. These two facets introduce two very important differencesbetween the programming and DSM worlds. The first is that, in the latter realm,the artifacts to debug are no longer restricted to code but also include hand-crafted models, model transformations, synthesized models and other arbitrarynon-code artifacts. The second is that the counterparts of the common DSMactivities of designing and debugging model transformations – which are respec-tively designing and debugging code compilers/interpreters – are both rare andspecialized activities in the coding realm. In the following section, we explorehow the previous concepts translate into the debugging stages of both facets ofDSM development.

4.1 Debugging Transformations

One could easily argue that the number of programs to debug (and their do-mains) is orders of magnitude larger than the number of existing compilers andinterpreters for the languages these programs are implemented in. This is a side-effect of the nature of General Purpose programming Languages (GPLs) whichare designed to enable programmers to develop applications for an unboundedset of domains. Domain-specific modelling languages, however, target restricteddomains and as such the number of DSLs is much more closely related to thenumber of DSms. To carry any meaning and be anything more than metamodelsfor blueprints, DSLs must have associated operational or denotational semanticswhich the Model-Driven paradigm dictates should be specified as model trans-formations [4]. Operational semantics can be described as a collection of ruleseach describing the transformation between valid system states (e.g., for PetriNets, a rule describes the model before and after the firing of an enabled transi-

tion). Executing these rules effectively executes/interprets/simulates the model.As for denotational semantics, they essentially define the meaning of a DSL by


mapping its concepts onto other formalisms for which semantics are well defined.A common approach in DSM is to encode the denotational semantics mappingwithin code generators that transform DSms to code3 [14, 10]. We demonstratedin [12] that modelling this mapping onto intermediate modelling formalisms (asopposed to directly onto code) is modular, adheres closely to the Multi-ParadigmModelling (MPM) philosophy [7], and considerably facilitates debugging by eas-ing the specification, display and maintenance of backward links between modelsand synthesized artifacts.

Regardless of the type of semantics the DSL designer and/or model trans-formation modeller require, the resulting transformation model will describe aflow of rule applications which may require debugging. Below, we re-visit thedebugging concepts described in the previous section and see how they translateto model transformation debugging.

Print Statements A contrived means of reproducing print statements formodel transformations is to create rules with their action code set to appro-priately parameterized calls to output functions in a supported action language(e.g., Python). Such a rule could be permanently enabled allowing it to be runas needed by the modeller4 or it could specify a pattern causing the printing tooccur only when the given pattern is matched. Unfortunately, this technique isnot void of accidental complexity: the LHS and RHS patterns would need to beidentical to avoid modifications to the source model which further implies thatmeans to prevent the rule from looping forever might need to be included in theaction code and/or as NAC patterns. A similar but neater and more domain-specific solution would be to enhance MTLs with printing functionality. Thiscould be done by augmenting traditional rules with a “printing code” parameteror by introducing special “print rules” that could be included within the trans-formation model (e.g., a print rule rprt could be inserted between rules ri and rj

as shown in Fig. 1). In the latter case, the print rules would have only three pa-rameters: a single pattern (as opposed to the two patterns in traditional rules),condition code and printing code. The natural semantics of such rules would beto execute the printing code if the condition code is satisfied when the pattern isfound in the host model. Print rules could easily and automatically be translatedto the contrived traditional rules described above using higher-order transfor-mation rules5 such as to leave the transformation execution engine unchanged.Although it may seem counter-intuitive to support a language construct whoseusefulness is mostly restricted to debugging purposes, we should remember thatprint statements (whose usefulness is mostly restricted to debugging purposes)are supported in every modern GPL.

3 Note that non-code artifacts such as configuration files, documentation, and modelsmay also be synthesized.

4 This requires tool support for manual on-the-fly rule selection.5 Rules that take other rules as input and/or output.


Fig. 1: An example transformation model where a print rule prt is inserted betweentraditional rules i and j.

Assertions Assertions in transformation models can be implemented in avery similar manner as print statements. The conditions they are meant to checkcan be encoded in rule condition code or as patterns. In [16], Syriani et al. pro-pose specifying assertions in just this manner; in case of failure, the rule’s actioncode throws a user-specified exception that either interrupts and terminates theexecution of the transformation or is caught and handled by exception handlersspecified at the transformation language level. Unfortunately, forcing the mod-eller to reproduce assertions using the default rule mechanism carries the samelimitations as those mentioned for print statements, namely the necessity foridentical RHS and LHS patterns and for loop prevention action code and/orNAC patterns. A similar solution applies though: enhancing the MTL with spe-cial “assertion rules” (see Fig. 2a) that could be sequenced arbitrarily with otherrules. Analogous reasoning applies regarding their parameters and the validityof their inclusion in a MTL. An added benefit of this approach is that it wouldfacilitate the implementation of the crucial assertion property mentioned earlier:the ability to enable and disable assertions without having to comment, removeor alter them. Achieving this using contrived rules may be possible by comingup with fancy action code but is clearly a less elegant solution. Furthermore,more advanced modelling tools could support hiding and unhiding assertionsto improve the transformation model’s readability. Such features would be in-creasingly difficult to implement if assertions where indistinguishable (or lessdistinguishable) from common rules.

Exceptions Exceptions and their handlers in the context of model trans-formation debugging were extensively studied in [16]. Syriani et al. provide aclassification of several relevant exceptions ranging from synchronization prob-lems brought on by incorrectly parallelizing transformations to action languageerrors, and even support the creation of user-defined exception types. They pro-pose enhancing MTLs with exception handler rules to which traditional rulescan be sequenced to in case of exceptions (as shown in Fig.2b). The applicabilityof these handlers is specified via patterns and/or constraints.

Execution Modes As mentioned in Section 2, the transformation enginesin tools such as AToM3 natively support continuous and step-by-step execution


(a) (b)

Fig. 2: (a) An example assertion rule. Sensible behaviour would be for an exceptionto be fired if the pattern is found but the condition fails. (b) Modelling resuming,restarting and terminating after handling an exception.[16]

modes. In the former, the transformation is executed until none of its rules applywith user input optionally solicited when more than one rule applies simultane-ously. In the latter mode, after every rule application the user is prompted to runthe remainder of the transformation in continuous mode or to step over a singleapplicable rule. To our knowledge, only the Visual Modeling and TransformationSystem (VMTS) [11] offers means to pause the execution of an ongoing transfor-mation. The meaning of such an action is not as trivial as it may seem. Pausingthe transformation exactly between the application of two rules should providethe user with means to continue in either continuous or step-by-step mode. How-ever, if the pause request were to be triggered during the application of a rule,what should be the appropriate response? In a system where rule application isimplemented following a transactional approach, sensible behaviours might beto let the current rule complete or to roll-back to before its application beforepausing. In a system based on T-Core [19] where rules may not only be com-posed but also decomposed into primitive operations (e.g., match, rewrite), idealbehaviours might be to pause the execution before invoking the next primitiveoperation. A third option is immediate interruption. Either choice has its merits;the only truly important concern is the nature of the debugging information thatis made available to the modeller when the execution has paused. Thus, it seemsunreasonable to offer immediate interruption in a context where rule applicationis atomic and no means of observing the intermediate state of the system areavailable. Finally, it may be desired to run a transformation in debug or releasemodes. As in the context of code debugging, pausing and stepping functionalityshould only be enabled in debug mode.

Steps The notion of stepping over in the context of rule-based model trans-formations is trivial. It corresponds to the execution of one, possibly composed,rule. Stepping into, however, is very dependent on the features of the MTL and


engine – much like the aforementioned pause feature –. For instance, in lan-guages like MoTif [18], GReAT [2], QVT [1], VIATRA [20] and VMTS whichsupport rule composition, stepping into a composite rule would conceivably al-low the modeller to “enter” the rule and execute its sub-rules one at a time. Thisprocess could of course be repeated recursively in the event of several layers ofcomposition. For more advanced languages like MoTif-Core [19] – or any otherlanguage based on T-Core for that matter – where rules are no longer atomicblocks but are instead arbitrarily composed sets of primitive components suchas “matchers” (which locate a rule’s pre-condition pattern in the host graph),“rewriters” (which effect the transformation of a given match into the rule’s post-condition pattern) and “iterators” (which choose one match for the rewriter towork on given several matches reported by the matcher), it is sensible for themodeller to be able to step into even a non-composite rule. Doing so would en-able him to execute each primitive in turn and possibly perform such actions asmodifying a match before it is given to the rewriter. Finally, stepping out obvi-ously only makes sense for MTLs and engines where stepping into is meaningful.In such languages, stepping out would perform a very analogous task to thatwhich it performs in code debugging. Stepping out of a composite rule wouldcause the continuous execution of any remaining rules within the composite rulewhile stepping out of an “exploded” T-Core rule would cause the continuousexecution of any remaining primitives within that rule.

Runtime Variable I/O The notion of what is a variable per se in thecontext of model transformations is unclear. The parameters of a rule or the se-quencing of the rules themselves may all be considered variables. Thus, when theexecution is paused, the modeller could choose to edit LHS and RHS patterns,condition code, action code and even the scheduling of the transformation rules– provided he has access to it –. All of the previous propositions share a crucialrequirement though: if the rules and/or the transformation model need to becompiled before they can be executed by the transformation engine, modifyingeither of them on-the-fly might be unfeasible6. This is of course analogous tomodifications to running C++ or Java code being ignored by IDE debuggersuntil the next compilation. Control flow- (e.g., GReAT, MoTif) and T-Core-based languages lend themselves more intuitively to traditional runtime variableI/O operations because of their notions of inputs and outputs. It is conceivablethat the modeller may want to observe or change the inputs or outputs of a ruleor a T-Core primitive. This implies that a model transformation debugging toolshould clearly expose these variables and offer means to modify them. Ideally,this should be done at the appropriate level of abstraction. For instance, if themodeller wants to observe the pattern given to a T-Core rewriter block, thispattern should be represented using domain-specific constructs rather than insome internal format. Similarly, if the modeller wants to modify a pattern, heshould be provided with a domain-specific model editor pre-loaded with appro-

6 To our knowledge, no existing modelling or model transformation tools currrentlysupport on-the-fly rule scheduling modifications.


Fig. 3: An example breakpoint and its property dialog.

priate metamodels. Finally, as for code debuggers, ensuring that modificationsdon’t leave the system in an unstable state is a desired but complex task. In thiscontext, one such verification could be to ensure that the modified input of aT-Core rewriter block still contains exactly one instance of the specified patternto match.

Breakpoints Breakpoints very intuitively translate to the model transfor-mation debugging world. Given proper tooling, breakpoints could be associatedto composite rules, non-composite rules and primitive T-Core blocks causing theexecution to pause when they are encountered. Hit counts and boolean condi-tions (written in a supported action language) could conceivably be specified inthe same manner as in code IDEs. Figure 3 suggests a possible rendering of abreakpoint annotating a rule.

Jump To The jump to operation also readily translates to the model trans-formation debugging context. Rather than jumping to arbitrary statements, themodeller could move to arbitrary rules. This feature is of course dependent onthe debugging tool clearly identifying the next rule to execute and providingmeans for the modeller to modify the scheduling on-the-fly – which as we’vementioned earlier remains beyond the capability of current tools –. As in thecode world, jumping can easily lead the system into unstable and unexpectedstates.

Stack Traces Like the stepping into and out operations, the availabilityof stack traces and their meaning depend on the MTL and engine; specifically,on their levels of granularity. Hence, for languages where rules can neither becomposed nor decomposed, stack traces would do little more than report thecurrent rule and would thus be of very little use. However, for more complexlanguages, they would enable the modeller to navigate between the contexts ofsub-rules and their parent composite rules, or between the contexts of T-Coreprimitives and their enclosing rule.


4.2 Creating Debuggable Artifacts

Before proceeding to map code debugging concepts onto the realm of debuggingDSms and artifacts, we briefly overview the technique for artifact synthesis fromDSms we present in [12]. As we have already hinted above and will often re-peat below, the availability of backward links between corresponding constructsat different levels of abstraction greatly facilitates numerous complex activitiesincluding debugging. They accomplish this by, amongst other things, enablingelegant two-way information propagation between DSms and generated artifacts,and providing implicit and navigable relationships between related concepts.

In [12], we proposed a means of generating backward links between DSmsof mobile device applications, generated Google Android code and intermedi-ate representations in between. Our technique is based on triple graph rules(TGRs)[15], which essentially provide means of generically relating constructsin source (i.e., LHS) and destination (i.e., RHS) rule patterns. Thus, by describ-ing the denotational semantics of our DSms with a collection of TGRs, we areleft with a web of traceability links that connect related elements at all levelsof abstraction. Figure 4 shows four different perspectives of the same system: aconference registration application modelled in our DSL for mobile devive ap-plications, a generated model which contains only the layout-related aspects ofthe DSm, a generated Statechart [9] which contains only the behavioural aspectof the DSm, and a trivial generated model of the to-be-generated files on disk.Connecting the four subgraphs is a complex network of correspondence links thatreflects the application of numerous TGRs. This web of connections is quite ob-viously not intended for direct human consumption. However, as we will discussin more detail in Section 4.3, it can considerably facilitate the implementationof numerous components of a DSM model and artifact debugger.

4.3 Debugging Models and Artifacts

Despite the importance and need for model transformation debugging facilities,they may not be sufficient for debugging models whose semantics are specifieddenotationally. Indeed, running such models implies the execution of the synthe-sized artifacts7 rather than of model transformations. Although not always thecase in academic DSM efforts, it is sensible to assume that in industry, DSLsand their semantics will often be defined by actors different than the end-usersof the DSLs. Similarly, most C++ and Java programmers did not play activeroles in the development of those languages nor of their compilers. Thus, inthe following section, we distinguish between two types of users. Designers arefully aware of the model transformations that describe the semantics of theirmodels and generate lower level artifacts. On the other hand, modellers havean implicit understanding of the semantics of their models but have little or

7 Although numerous non-executable artifacts can be generated from DSms, we re-strict our attention here to programs and models.


Fig. 4: Four perspectives of the same conference registration mobile device applicationconnected via traceability links.

no knowledge about how their models are given these semantics. Nevertheless,they should be aware of the end-products generated from their models – whyelse would they bother creating them? –. As a concrete example, consider a DSLfor modelling mobile device applications such as the one presented in [12]. Adesigner should be aware of the DSm, the generated lower level models, Javaand XML code, and running application on a target device. A modeller shouldhowever only be concerned with his DSm and the generated running application.

As a consequence of their different expertise, the debugging scenarios for de-signers and modellers differ. Designer artifact debugging is akin to programmerbytecode debugging. The goal is to ensure the correctness of the output of themodel transformations. Modellers on the other hand may assume that the modeltransformations applied to their models are flawless and must instead establishthe correctness of their models. Thus, their task is more akin to traditional codedebugging but with model and executing artifact being compared instead of codeand executing program. In both debugging scenarios though, the basic work flowwill entail observing the evolution of the model with respect to the evolution ofthe synthesized artifact with the designer possibly paying special attention to in-termediate representations, if any. Note that we assume that DSms change theirstate as a result of artifact execution. This idea stems from program debuggingwhere variables take on values (that can be viewed using runtime variable I/O


debugger facilities) and change dynamically as a result of program execution.A formal discussion on how to implement this feature in the context of modelsand artifacts is beyond the scope of this paper. However, the approach for ar-tifact synthesis we present in [12] and reviewed in Section 4.2 enables the sortof two-way communication between model and artifact that would be required.Below, we re-visit the debugging concepts described in the previous sections andtranslate them to DSm and artifact debugging.

Print Statements Print statements seem less useful in this context. Forone, most modern DSm editors offer means to display pertinent information aspart of the concrete syntax of modelling constructs. It is for example commonin Petri Net editors for the graphical representation of a place to include itscurrent number of tokens. Moreover, model editors allow for easy reading (andwriting) of construct parameters. Nevertheless, it is conceivable for a modelleror domain expert to require explicit output for debugging purposes. A simi-lar solution to the one proposed for the model transformation context applies.DSM tools could provide means to specify print rules that output arbitrary in-formation about models upon detecting conditions specified by the modeller inthe form of patterns (e.g., state s is enabled, any place contains at least thani tokens). Recall though that modellers may have no knowledge about modeltransformations and might need to be introduced to the foreign concepts of rulepatterns, conditions and actions. An added challenge from a tool implementer’spoint of view is that means to verify rule applicability and execute them con-currently with model execution8 would be required. Print rules as we describethem here are very powerful: they can essentially print anything, anytime. How-ever, they are somewhat orthogonal to the rest of the DSm creation process. Abetter solution might to be (semi-)automatically integrate appropriate outputconstructs in DSLs themselves at DSL design time. This solution is indeed moreclosely related to what we propose for MTLs and what is done in GPLs.

Assertions Assertions can be thought of in a very similar manner as printstatements: they can be implemented via orthogonal assertion rules or as explicitDSL constructs. The main differences are that provisions to enable and disablethem should be provided, and that they may halt the execution of the modelwhen fired. The latter implies that means to halt the execution of running ar-tifacts are required. For code artifacts, this might be accomplished by invokingthread sleeping (or waiting) methods; for model artifacts, appropriate tool APIscould be used to halt execution of operational semantics transformations. In ei-ther case, such tasks and the generation of any needed facilities (e.g., dummyrules or callback functions) can and should be automated. Note that we restrictour definition of assertions to conditions that are verified during model executionrather than during model editing. Thus, “static” DSL constraints should not beconfused with assertions. Such a static DSL constraint specifies for example that

8 This is of course an abuse of notation since, in this context, executing models meansexecuting artifacts.


before creating an edge of type “is-parent” from node n1 to node n2, the non-existence of an “is-parent” edge from n2 to n1 should be established. Note thatthis implies the checking of different constraints at different times during themodelling process. A single metamodel will thus not suffice.

Exceptions The notion of exception in the context of debugging models issomewhat deferred. The reason for this is that exceptions occur at runtime andthat although models may be animated and updated, what is truly being exe-cuted are the synthesized artifacts. Consequently, exceptions will originate fromthese artifacts and will be described in terms of their metamodel (e.g., Java).Such exceptions may be caused by I/O errors, by bugs in third party code li-braries, by errors in designer or modeller provided code9, by problems within theoperational semantics transformation of lower level models, etc. Some of theseexceptions may be straight-forward to translate back into domain-specific terms;others may be describe transient issues that are entirely irrelevant to the mod-eller; others may describe issues that are only of interest to the designer. Thehandling of these exceptions is thus a design choice of the DSL architect. “Silent”exception handlers for irrelevant exceptions should be generated along with therest of the synthesized artifacts. For relevant exceptions, propagation and trans-lation facilities for presentation to the designer or modeller should be available.This is thus yet another scenario where the web of links left behind by the ap-proach for artifact synthesis we reviewed in Section 4.2 can be beneficial. Figure 5shows a possible rendering of exception translation specification facilities graftedonto a traditional rule. The rule specifies the mapping of a domain-specific con-struct to a modelled code file. The proposed exception translation specificationindicates that if a given error message is produced while executing the real fileassociated to the designated modelled file, the corresponding domain-specificconstruct’s concrete syntax should reflect a high-level version of the error.

Execution Modes Similarly to exceptions and assertions, the play, pause,stop and step functionalities require two-way communication means betweenmodel and artifact. Playing and stopping simply imply that means to remotelyrun or kill the generated model or program are available. Stepping presentsmore of a challenge. First, the meaning of what taking one step in an arbitraryDSm should be is not obvious. To this end, we propose a very general defini-tion: any modification of the state of a DSm constitutes a step, where the notionof state encompasses the values of the parameters of every construct in themodel. Second, (semi-)automatic instrumentation of the artifacts to enable run-ning only arbitrary parts of them at a time may be required10. Pausing presentssimilar challenges as in the model transformation debugging context. The idealbehaviour of a pause should thus depend on the structure and semantics of theDSm and artifacts. However, a widely applicable and sensible approach is to

9 This applies to languages with support for escape semantics.10 The specifics of such instrumentation are outside the scope of this paper but we

believe the web links left behind by the approach for artifact synthesis we reviewedin Section 4.2 would considerably ease the process


Fig. 5: An example a high-level Downloader construct, its mapping to code, and apossible rendering of exception translation specification facilities.

pause the execution before executing what would have been the next step (atthe DSm level). Finally, it may be desirable for the traditional debug mode tobe further refined. For instance, although immediate pausing or stepping at thelevel of generated code statements may be absurd for a modeller, it might beadvantageous and even necessary for designers.

Steps The notions of stepping over, into and out may be considered fromtwo orthogonal perpectives. On the one hand, all three notions intuitively trans-late to DSLs which support hierarchy and composition. For instance, given aStatechart-based language (i.e, some DSL constructs are transformed to Stat-echart constructs and eventually translated to code), if the current state werewithin a composite state, stepping out could execute the Statechart continuouslyuntil the parent state was exited. On the other hand, the fact that artifactsare generated from DSms creates an implicit hierarchy between them. Hence,for a designer, appropriate behaviour for the step into operation might be totake a step at the level of corresponding lower level entities. Keeping with theStatechart-based language example, stepping into might allow the designer tostep through the underlying Statechart. Further stepping into might allow himto step through statements of the compiled Statechart’s code. This scenario isdepicted in Figure 6 where two successive step into operations lead a designerfrom a domain-specific traffic light model entity to a corresponding Statechart


Fig. 6: Stepping into from the designer’s perspective. Stepping into a TrafficLight

model entity leads into a corresponding Statechart state. Further stepping into leadsinto the generated code.

state and finally to an appropriate function in the compiled code11. Conversely,stepping out would bring the designer back to higher level entities and steppingover would perform an appropriate step given the current formalism (e.g., onestatement for code, one operational semantics rule application for models). Thisidea is somewhat akin to stepping into code libraries (which is only possible whenthey were compiled in debug mode, making symbol table information available).These distinct stepping modes further motivate our previous proposal of sepa-rate debug modes for designers and modellers.

11 Notice again how the availability of intermediate representations between DSms andend artifacts, and of traceability links between them eases the debugging process.


Runtime Variable I/O At a first glance, runtime variable I/O seems themost straight-forward of the debugger operations. For DSms and lower levelgenerated models, the model editing tool itself can be used to view and modifyvariable values when the execution is paused, whereas code IDE debugger fa-cilities can be used for synthesized coded artifacts. The hidden challenge is topropagate changes: changing a variable value should be reflected appropriatelyat every level of abstraction – higher and lower – to ensure continued overallconsistency. Once again, the correspondence links left behind by the approachfor artifact synthesis we reviewed in Section 4.2 would facilitate the automaticgeneration of appropriate change propagation facilities.

Breakpoints Breakpoints translate more or less intuitively to the model andartifact debugging world. Ideally, it should be possible for the designer to specifybreakpoints at any level of abstraction from DSm to end artifact. Of course, themodeller is only expected to specify them at the DSm level. The challenge hereis how to specify the said breakpoints. For modelling languages with an explicitrepresentation of state (e.g., Statecharts), the trivial answer is to mark certainstates as breakpoints causing the execution to pause whenever they become en-abled12. However, this is impossible for languages with an implicit representationof state (e.g., Petri Nets where the state is encoded in the marking). For suchformalisms, we propose that breakpoints instead be specified as patterns (e.g., apartial or complete Petri Net marking) causing the execution to pause when thepatterns are matched in the model. Once again, hit counts and boolean condi-tions (written in a supported action language) could conceivably be specified inthe same manner as in code IDEs.

Jump To The jump to operation does not have a clear-cut mapping to thiscontext. This is due in part to the conceptual gap between DSm and artifact:modifying variables in a DSm may effectively translate to a jump to operationin the lower level models or code. To illustrate this phenomenon, consider theconsequence of altering the marking of a Petri Net or changing the enabled statein Statechart-based languages. Thus, in the context of model and artifact de-bugging, the jump to operation is absorbed within the runtime variable I/Ooperation.

Stack Traces Like in the code and model transformation debugging con-texts, stack traces in the context of model and artifact debugging are tightlybound to the notions of stepping into and out. Thus, for the designer debugmode, they might display sequences of related actions between DSm and artifact.On the other hand, for the modeller debug mode, they might reflect constructcomposition if applicable.

12 This of course assumes tool support for such markings.


5 Conclusion and Future Work

We have proposed a conceptual mapping between debugging concepts in the soft-ware development realm and concepts in the DSM realm. These form a startingpoint for DSM debugger development. In our mapping, we distinguished betweenthe two different facets of DSM debugging: the debugging of model transforma-tions (such as models of operational or denotational semantics) and the debug-ging of DSms. We made a further distinction between debugging scenarios fortwo types of users of DSM. On the one hand, there are the designers who arefully aware of the model transformations that describe the semantics of theirmodels and generate lower level artifacts. On the other hand, there are the mod-

ellers who understand the semantics of their models and are aware of synthesizedartifacts but have little or no knowledge about how these are produced.

Our work demystifies the amount of effort required to build DSM debuggers:numerous model transformation debugger features can be built-in to MTLs andengines themselves, while appropriate artifact synthesis based on TGRs can con-siderably facilitate the implementation of numerous model and artifact debuggerfeatures. We have prototyped the concepts described in this paper in our tool formulti-formalism and meta-modelling, AToM3. We will fully integrate our pro-posed debugging facilities in AToMPM, the successor of AToM3 we are currentlydeveloping.

6 Acknowledgments

We thank Eugene Syriani for sharing his expertise on model transformation toolsand languages and for his valuable editorial comments on this paper.

References

1. Meta Object Facility (MOF) 2.0 Query/View/Transformation (QVT).http://www.omg.org/spec/QVT/index.htm.

2. Aditya Agrawal, Gabor Karsai, Sandeep Neema, Feng Shi, and Attila Vizhanyo.The design of a language for model transformations. Software and Systems Mod-eling (SoSym), 5:261–288, 2006.

3. Jean Bezivin. On the unification power of models. Software and Systems Modeling(SoSym), 4:171–188, 2005.

4. Alan W. Brown. Model driven architecture: Principles and practice. Software andSystems Modeling (SoSym), 3:314–327, 2004.

5. Krzysztof Czarnecki and Ulrich Eisenecker. Generative Programming: Methods,Tools, and Applications. Addison-Wesley, 2000. 832 pages.

6. Krzysztof Czarnecki and Simon Helsen. Feature-based survey of model transfor-mation approaches. IBM Systems Journal (IBMS), 45:621–645, 2006.

7. Juan de Lara, Hans Vangheluwe, and Manuel Alfonseca. Meta-modelling andgraph grammars for multi-paradigm modelling in AToM3. Software and SystemsModeling (SoSym), 3:194–209, 2004.


8. Marc Eisenstadt. “My Hairiest Bug” war stories. Communications of the ACM(CACM), 40:30–37, 1997.

9. David Harel. Statecharts: A visual formalism for complex systems. The Science ofComputer Programming, 8:231–274, 1987.

10. Steven Kelly and Juha-Pekka Tolvanen. Domain-Specific Modeling : Enabling FullCode Generation. Wiley-Interscience, 2008. 427 pages.

11. Laszlo Lengyel, Tihamer Levendovszky, Gergely Mezei, and Hassan Charaf. Modeltransformation with a visual control flow language. International Journal of Com-puter Science (IJCS), 1:45–53, 2006.

12. Raphael Mannadiar and Hans Vangheluwe. Modular synthesis of mobile deviceapplications from domain-specific models. Technical Report SOCS-TR-2010.5,McGill University, 2010.

13. MetaCase. Domain-specific modeling with MetaEdit+: 10 times faster than UML.http://www.metacase.com/resources.html; June 2009.

14. Laurent Safa. The making of user-interface designer a proprietary DSM tool.In 7th OOPSLA Workshop on Domain-Specific Modeling (DSM), page 14,http://www.dsmforum.org/events/DSM07/papers.html, 2007.

15. Andy Schurr. Specification of graph translators with triple graph grammars. InProceedings of the 20th International Workshop on Graph-Theoretic Concepts inComputer Science, 1995.

16. Eugene Syriani, Jorg Kienzle, and Hans Vangheluwe. Exceptional transforma-tions. In International Conference on Model Transformation (ICMT), volumeLNCS 6142, pages 199–214, 2010.

17. Eugene Syriani and Hans Vangheluwe. De-/re-constructing model transformationlanguages. Technical Report SOCS-TR-2009.7, McGill University, 2009.

18. Eugene Syriani and Hans Vangheluwe. Discrete-Event Modeling and Simulation:Theory and Applications., chapter DEVS as a Semantic Domain for ProgrammedGraph Transformation. CRC Press, 2009. never read this... eugene sites this forMoTif.

19. Eugene Syriani and Hans Vangheluwe. De-/re-constructing model transformationlanguages. In 9th International Workshop on Graph Transformation and VisualModeling Techniques (GT-VMT), 2010.

20. Daniel Varro, , and Andras Balogh. The model transformation language of theviatra2 framework. Science of Computer Programming, 68:214–234, 2007.

21. Hui Wu, Jeff Gray, and Marjan Mernik. Grammar-driven generation of domain-specific language debuggers. Software : Practice and Experience, 38:1073–1103,2008.

22. Andreas Zeller. Why Programs Fail: A Guide to Systematic Debugging. MorganKaufmann, second edition, 2009. 480 pages.

Debugging in Domain-Speciﬁc Modelling

Documents

Transcript of Debugging in Domain-Speciﬁc Modelling