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