Graphical Debugging of QVT Relations using Transformation Nets

Contents

1. Introduction
1.1. Motivation
1.2. Problem Statement
1.3. Solution
1.4. Structure of the Thesis

2. Model Transformation Fundamentals
2.1. Model Driven Engineering
2.2. Model Transformation

3. Model Transformation Technologies
3.1. Query/View/Transformations (QVT)
3.1.1. QVT Relations (QVT-R)
3.2. Transformation On Petri Nets In Color (TROPIC)
3.2.1. Core concepts of TROPIC
3.3. Comparison of QVT Relations and TROPIC at a glance

4. Transforming QVT Relations to TROPIC
4.1. Overview
4.1.1. Execution Semantics of QVT-R
4.2. Types
4.2.1. Domains
4.2.2. Primitive Domains
4.2.3. Primitive types
4.2.4. Complex types
4.3. Relationships
4.4. Dependencies
4.4.1. Where- and When-Clauses
4.4.2. Hierarchical Data Passing
4.5. Finding Correspondence of Source and Target Objects
4.5.1. Heavyweight Approach
4.5.2. Lightweight Approach
4.6. Realization of Correspondences
4.6.1. Transition “Owners”
4.6.2. Relationships
4.6.3. Referred Relations
4.7. Complexity and Effort

5. Supporting Advanced Features of QVT Relations
5.1. Inheritance
5.2. Incremental Changes
5.2.1. Introduction
5.2.2. Model Synchronization
5.3. Summary

6. Realization
6.1. Environments
6.1.1. Eclipse and its Plugins
6.1.2. QVT-R Parser
6.2. Implementation Specifics
6.2.1. Data Types
6.2.2. Information Encapsulation
6.2.3. Class Structure
6.3. Execution Process
6.3.1. Course of Execution
6.3.2. Managing Flow Information
6.3.3. Managing colours in TROPIC
6.3.4. Adding Model Information
6.3.5. Element Arrangement
6.4. Summary

7. Evaluation
7.1. Capability of Erroneous Code Recognition
7.1.1. Pitfall Detection
7.2. Visualization
7.2.1. Performance
7.2.2. Unavailable Language Elements
7.2.3. Effort Increase Analysis for Transformation Net Creations
7.3. Model Synchronization
7.4. Summary

8. Related Work
8.1. Testing
8.1.1. Trial & Error
8.1.2. Test-Driven-Development
8.2. Debugging
8.2.1. Model-based Debugging
8.2.2. QVT-R Debuggers
8.2.3. Forensic Debugging Techniques
8.2.4. Backwards Debugging
8.3. Verification
8.3.1. Verification by Translation
8.3.2. Verification of Graph Transformations
8.3.3. Verification based on CPN
8.4. Summary

9. Conclusion
9.1. Summary
9.2. Future Work

A. Appendix

Bibliography

1. Introduction

1.1. Motivation

Over the last years Model Driven Engineering (MDE) experienced a strong im- petus, placing models as first class artifacts throughout the software lifecycle. Although models are used in software development since several decades up to now [7], documentation was their main purpose only. In contrast to that, models in MDE not only serve for documentation, but the main promise of MDE is to raise the level of abstraction from technology and platform-specific concepts to platform-independent and computation-independent modeling [3].

This success exceptionally qualifies and advocates models – such as models from the Unified Modeling Language (UML) standard – to be used for architec- tural issues to create a common understanding. Typically several model types are used which is apparently related to the complexity that modern software devel- opment has to face. Therefore, it is often necessary to use a set of different model types for representing a particular environment that is directly related to a single domain specific model (or to all other models). Hence, automatization or even synchronization mechanisms for model transformations (MT) from certain source models to desired target models are needed as they can improve the consistency of models and can reduce the effort.

To fulfill this promise, the availability of appropriate model transformation languages is the crucial factor, since transformation languages are as important for MDE as compilers are for high-level programming languages. Transformation scenarios can be divided into vertical model transformations and horizontal model transformations. Vertical model transformations lower the level of abstraction, e.g., generation code from UML class diagrams, whereas horizontal model trans- formations transform models between two different representations on the same level of abstraction, which is the focus of the rest of this thesis, e.g., a UML class model is transformed to an entity relationship diagram. There already exist sev- eral model transformation languages (MTL) that provide the transformation from one model (conforming to a meta model) to another model (conforming to an- other meta model), e.g., the Query/View/Transformation (QVT) standard [22]. Typically a rich set of transformation rules – defined by the developer – is nec- essary to determine which structure(s) of the source model correspond to which structure(s) of the target model.

1.2. Problem Statement

In this thesis the declarative model transformation language QVT Relations (QVT-R) is used which has been standardized by the Object Management Group.

Although model transformations are highly necessary in the context of model driven approaches, not even the QVT standard was able to attract sufficient in- terest until now. A main factor for this weak adoption results from the lack of adequate debugging facilities. Such facilities are highly necessary according to the three particular identified problem areas:

First, declarative languages like QVT-R cannot make the operational seman- tics of transformation specifications explicit to the transformation designer. Only the information provided by the interpreter, as well as the tendered inputs and returned outputs are available for tracking the progress of transformations. Even the ordering of rule application is hidden by the MT execution engine which is provided as a black-box to the users. This can lead to the problem of impedance mismatches between designtime and runtime. This characteristic of QVT-R is a valuable asset for developers as they need not specify these details, but for de- bugging this can be seen as severe handicap. Second, QVT-R code is specified on a high-level of abstraction whereas its execution and state-of-the-art debugging mechanisms are positioned on significant lower level of abstraction. This deterio- rates the ability to deduce causes from produced results. Third, the information content responsible for operating MTs is spread over several artifacts including the input model, a resulting target model and a comprehensive QVT-R code. As a consequence, the reasons for a particular outcome are hard to be derived from the involved artifacts. This severely harms the ease of debugging.

These three problem areas are, moreover, influenced by the complexity of typ- ical model transformation rules and the unclear semantics of some QVT-R lan- guage elements – e.g., “check” and “enforce”.

1.3. Solution

This master thesis concentrates on several areas of improving the ease and quality of debugging. It discusses the possibilities of visualizing QVT-R in “Transforma- tions On Petri Nets In Color” (TROPIC) – which uses Transformation Nets based on Colored Petri Nets (CPN). This can be seen as an explicit definition of the operational semantics providing a white-box view for debugging QVT-R. This thesis proposes a conceptual approach that is transposed into a prototypi- cal implementation. It strives for bridging the existing gap between the desired operational semantics for debugging and the declarative language elements (as used in QVT-R) by mapping the concepts of QVT-R to TROPIC. TROPIC can provide a white-box-view – as paths from source to target representation by using Arcs and Transitions – of the code on a high-level of abstraction by visualizing the involved metamodel structures (as Places) and the concrete model informa- tion (as Tokens). It, therefore, allows the analyzation of the before scattered content in one single visualization. In the first step the focus lies on the detec- tion of solutions for unidirectional transformation mappings. This is deepened in the second step by providing support for advanced features such as inheritance used in input or output models. The third will concentrate on the fundamental problem of incremental changes by proposing synchronization mechanism theo- rems and providing a simple prototypic implementation. Incremental changes are modifications of a previously created model whereas synchronization approaches can assist to hold related models consistent in the case of modifications.

The thesis finalizes by an evaluation of how the proposed concepts are appro- priate for the specified context and which challenges and possible exploitations of the TROPIC runtime model, e.g., complex Object Constraint Language (OCL) statements [21], remain for future research.

1.4. Structure of the Thesis

The rest of the thesis is structured as follows. Section 2 introduces the fundamen- tals of model transformations and debugging facilities. This thesis proceeds with the used technologies and standards. The major component of this theses is the practical part according to the focus on a set of scientific solution concepts and considerations. This part starts with an introduction of the conceptual approach of this paper in section 4 leading to advanced problems in section 5. The actual realization is presented in section 6 and is evaluated in chapter 7. This thesis finalizes with the presentation of related works and approaches (section 8), and a summarization of results (9).

2. Model Transformation Fundamentals

There exist some fundamental areas in the field of modeling and metamodeling that are introduced in this section. The differentiation between abstraction levels is essential for the usage of model-driven approaches. How such model-driven ap- proaches can be integrated in modern software development is introduced as well. As a result of the spreading of model-based approaches for software development, model-to-model transformations are necessary and, therefore, introduced in this section.

2.1. Model Driven Engineering

Model Driven Engineering (MDE) places models as first class artifacts through- out the software lifecycle. A particular approach for MDE is presented by the Object Management Group with their Model Driven Architecture (MDA) ap- proach [23]. In MDA this means the usage of a Platform-Independent-Model (PIM) as abstract architectural representation that is transformed to more con- crete Platform-Specific-Models (PSM) or even source code. The usage of several models on different levels of abstraction for different purposes and the intended generation of the more specific models from a more general representation clearly states the importance of model transformations in the context of MDE.

Furthermore, it is necessary for the understandability and usage of MDE to specify the abstraction levels of models. The execution of a program is placed on level M0. From this execution a model (M1) can be built abstracting “real world” problems to make it ascertainable for humans. But normally models are not built by just drawing some lines and boxes, they actually follow grammars consisting of rules how to build this type of model. For example a UML class diagram has restrictions according to types that can be used and in which relations they have to stand (and many more rules that have to be followed). This structure is defined on meta level (M2) by a metamodel. One abstraction level higher (M3), it reaches the abstraction level of metamodeling languages like the recursively defined Meta Object Facility (MOF). At this level the boundaries for building metamodels and Modeling languages respectively are set.

A simple overview of the abstract levels provides Figure 2.1. The left branch of the diagram shows the source model Ma (input) that conforms to its metamodel MMa. On the right branch the target model Mb (output) is placed that conforms to the metamodel MMb.

illustration not visible in this excerpt

Figure 2.1.: Abstraction levels in the context of model transformation [13]

2.2. Model Transformation

Transformations languages like QVT transform models (M1) to other models. To be able to transform all models conforming to a metamodel (M2) to a model con- forming to another metamodel, the metamodels are used for defining the particu- lar transformation rules. Metamodels ares used as they provide the knowledge of which elements can occur in a particular model. In Figure 2.1 the central branch is the transformation combining source and target models conforming to a meta- model MMt. Tab represents the actual transformation program. All metamodels (MMa, MMb, MMt) again conform to a more abstract model – the MOF metameta- model. The execution engine consumes some input and produces some output data and interacts with the transformation code of the program.

In MDA the transformation form PIM to PSM is a vertical transformation. Additionally, there are horizontal transformations that do not change the ab- straction level, but transform the model to fulfill the needs of another language (according to domains and special needs) or perspective. In the context of this thesis the focus is on horizontal model to model transformations.

According to Juan de Lara and Esther Guera [7] model transformations can be divided into: “Inter-Formalism (also known as exogenous)”, specifying a trans- formation between different source and target metamodels, and “Intra-formalism (also known as endogenous)”, specifying a transformation where source and target metamodels are equal.

The actual transformation from a source to a target model is done using a trans- formation language like QVT-R or Atlas Transformation Language (ATL). There exist some requirements and some desired features for transformation languages which are declared in the thesis of Thomas Reiter [25]).

Furthermore, according to Juan de Lara et al. [7] transformation languages can be categorized by “three orthogonal characteristics in the transformation language”: (i) visual or textual, (ii) imperative, declarative, (iii) formal or semi- formal.

(i) Most transformation and programming languages can be considered as tex- tual representations. For example Java [7] and ATL are obviously textual as they use text in lieu of graphical representations such as boxes, or graphs. In contrast to graph transformations can be considered to be visual.
(ii) Declarative languages are comfortable to use and reduce the lines of code necessary. If all elements in all facets from a source model can be fully mapped using declarations, such usages are to be favoured according to its simpleness. The model transformation language engine is then responsible for changing these declarations in clear imperative commands in the back-end. This ensures qual- ity and performance and reduces avoidable mistakes such as mixing commands, variables or names, or the improper ordering of rules, because such facets are automatically and implicitly handled by the transformation engines.

Imperative languages are very similar to normal programming languages and, therefore, very flexible. Writing many commands for one actual transformation rule seems somehow unpurified and makes it hard to fined errors. Therefore, it is considered good practice only using imperative languages, if declarative mappings cannot be used.

For the scenario of complex transformation rules in the same transformation process, hybrid languages can be used trying to combine the benefits of both parts. Hybrid languages like the Atlas Transformation Language (ATL) allow declarative statement blocks as well as imperative statement blocks.

(iii) Formal languages are defined by a clear alphabet used to form a gram- mar that specifies the combination of elements from the alphabet. A full formal languages does leave any gap for interpretation. This not the case for typical pro- gramming – like Java – and model transformation languages. For example Java and QVT-R (and similar languages) are semi-formal as they provide a formal alphabet and grammar, but leave gaps for interpretability.

3. Model Transformation Technologies

To be able to run model transformations, a set of technologies and standards are necessary to be used. In the approach presented in this thesis, the model transformation language QVT Relations is used and visualized in TROPIC Nets. Both QVT Relations and TROPIC are presented isolated in this section as prepa- ration for combining them later on. Finally, QVT Relations and TROPIC are compared with each other to identify possible ways of transforming elements of QVT Relations to TROPIC in following sections.

3.1. Query/View/Transformations (QVT)

This thesis uses the Object Management Group (OMG) standard Query/View/- Transformations (QVT) [22] ; a part of the Meta/Object/Facility (MOF) for model transformations. QVT is a transformation language that can be split into the three parts (1) Core, (2) Relations and (3) Operational transformations, shown in Figure 3.1). The Core and Relations component build up the declarative part of the language. Imperative transformations are done using the Operational component which is not used in this thesis. There also exists the possibility of transforming code from the Relations to the Core language to specify the opera- tional semantics of QVT-R.

Furthermore, codes written in another programming language offering a “MOF binding” [22] can be plugged-in as black-box systems. They have to be considered as black-box, because their actual implementation is not accessible or visible from the QVT code.

illustration not visible in this excerpt

Figure 3.1.: QVT components and interactions [22]

The possibility of using different transformation approaches (declarative, op- erational) is reflected in the component-oriented architecture of this MTL. Ad- ditionally, QVT is not a standalone language. For example OCL expressions are used for the definition of QVT Relations. QVT is a very versatile language that allows many different queries according to its powerful definition. Besides this integration of other languages QVT also relies on other standards, e.g., the Meta Object Facility (MOF).

Although the QVT specification has already reached a professional and utiliz- able level, there exist some open issues. For example it is unclear how the ordering of rules should be accomplished by the engines. Such issues do not directly reflect the particular elements of the MTL, but their conversion to real systems.

3.1.1. QVT Relations (QVT-R)

QVT-Relations can be used for uni- and bidirectional transformations. After creating a certain QVT-R code, it can be executed by QVT-R engines using a source model, an source metamodel and an target metamodel. There is even the possibility of translating QVT-R transformations to QVT-C to execute them on QVT-C engines. However, the QVT-R and QVT-C engines are rare.

In the following section technical details of the QVT-R language are presented.

Language introduction

In QVT Relations “a transformation between candidate models is specified as a set of relations that must hold for the transformation to be successful” [22].

Transformations have to be invoked in a specific direction. This means that it has to be defined which model with which metamodel acts as source model and which model acts as target model. Typically QVT-R is used to read model elements from the source model, to check if some conditions are fulfilled and to finally produce the target model. However, QVT-R can also be used to compare source and target model with each other.

Available QVT Relations (QVT-R) engines/tools supporting many features of this language – according an article of Ivan Kurtev [14] - are IK++ medini QVT, Eclipse M2M, Relations2ATLVM or Tata Consultancy ModelMorf. In the context of this thesis there will be a strong focus on the usage of medini QVT¹, because it has been widely used at the moment of writing and is able to handle many features of the QVT-R language.

The term “mapping” in the context of QVT (QVT-Relations) refers to the rules for transformations. One rule, therefore, is a mapping. In the context of this thesis the term “mapping” is, therefore, used synonymously.

Relations and Domains

A Relation is a definition holding concrete transformations and pre- and post- conditions that are directly related to this particular set of transformation state- ments. Such transformations can be compared to constraints that need to be fulfilled to allow the execution for a particular object. A Relation is defined by at least two Domains and optional When-/Where-Clauses.

“A domain is a distinguished typed variable that can be matched in a model of a given model type. ” [22]. A domain follows a pattern that represents a number of included types.

The example listing on the left side of Figure 3.2 shows the definition of a Relation to transform a class to a table – conforming to the source and target metamodel depicted on the right side of Figure 3.2 – including Domains as well as Where and When Clauses. The Domain c:Class holds several variables – the pattern of this Domain – representing specific constraints that need to hold. For example kind=’Persistent’ means that the variable kind has to have the type ’Persistent’. On the other side name = cn in the Domains c:Class and t:Table means that the names have to be the same – cn is a placeholder for this constraint.

Where and When

The Where-Clause specifies a post condition for a Relation. This means that the stated Relation has to be called, if the calling Relation itself has been called. This has to be interpreted as explicit call of the stated other Relation with the specified parameters, i.e. variables identifying the actual Domain. In contrast When-Clauses specify preconditions that have to hold before a Relation can be executed. This does not mean that the When-Clause forces the referred Relation to be called, but it waits for its execution. If the referred Relations is never called from somewhere else, the Relations holding this When-Clause cannot be executed.

See the listing in Figure 3.2 for the usage of When- and Where-Clauses within a Transition. The When-Clauses refers to the Relation PackageToSchema and involves the variables p and s. The Where-Clause explicitly calls the Relation AttributeToColumn with the date of the variables c and t.

Top level

The transformations discussed so far were non-top level Relations. These Rela- tions have to be invoked directly or indirectly (transitively using where clauses). Beyond that there also exists the type of top level Relations. They hold the key- word top. All top level Relations have to executed. Non-top level need not to be executed, if they are not invoked. See Listing 3.1 for the specification of the different types of Relations. The top level Relation ClassToTable invokes the non-top level Relation AttributeToColumn in its Where Clause.

Listing 3.1: A QVT transformation holding different types of Relations [22]

illustration not visible in this excerpt

Figure 3.2.: Left side: QVT Relation with Domains and When- and Where- Clauses. Right side: Related source and target metamodel. [22]

Check and Enforce The Relations language makes use of the Check (Checking) and Enforce (Enforcement) elements, as depicted in Listing 3.1.

- Checking: The checking is a “weaker” mode than the enforcement mode. It simply checks, if the constraints of models are fulfilled in the context of this transformation, and reports errors if any constraints are violated. However, this mode implies that nothing is “produced” in the sense of model transformations.
- Enforcement: The use of enforcement mode defines the transformation di- rection. This means “the selection of one of the candidate models as the tar- get model. The execution of transformation proceeds by, first checking the constraints, and secondly attempting to make all the violated constraints hold by modifying only the target model and the trace model.” [22]

Listing 3.2: Checkable and enforceable Domains [22]

illustration not visible in this excerpt

Metamodel

The grammar of the QVT-R language is defined by its metamodel (see Figure 3.3). This metamodel describes available language elements (the alphabet), possible combinations and dependencies. Therefore, it is essential for the QVT-R usage. The metamodel has one obvious root tag named RelationTransformation.

This item is equivalent to transformation in the QVT-R code. Relation and TypedModel instances are in a composition-relationship to RelationTransformation. The TypedModel expresses the modelParameters. Such parameters define the used models for the model transformation. Objects of Relation have a boolean attribute isTopLevel which refers to the top level property discussed in previous.

When and Where Clauses make use of Patterns which are aggregated by the corresponding Relation. Such a pattern can hold several Predicates for calling referred Relations. For each call of a Relation another instance of Predicate is added to the pattern. This call is accomplished using the type RelationCallExp which is a subtype of OclExpression.

illustration not visible in this excerpt

Figure 3.3.: The basic meta model of QVT Relations [29]

The basic transformation, however, takes place on another path from the Relation objects. Using another composition RelationDomain (a subtype of Domain). The RelationDomain represents the Domain as it is specified in the QVT standardization. Therefore, it has to belong to the source or target model which is determined by an instance of TypedModel. This instance belongs to the RelationTransformation and is reused here to highlight its model corre- spondence. In addition, such objects of RelationDomain hold the boolean at- tributes isCheckable – checkonly in the QVT-R code – and isEnforceable – enforce in the QVT-R code. The RelationDomain holds zero or one instances of DomainPattern – classically one. In this pattern the actual mappings take place. At least one complex type (ObjectTemplateExp) is contained that can hold several other types. PropertyTemplateItem objects are used to match for attributes in the Domain pattern. Primitive (several types) and complex types refer to subtypes of the OclExpression which represents a detail left out in the shown metamodel.

QVT-R can be transformed to QVT Core to represent the formal semantics behind the statements such as Relations.

3.2. Transformation On Petri Nets In Color (TROPIC)

“Transformations On Petri Nets In Color” (TROPIC) [25] is a project presented in the thesis of Thomas Reiter - Johannes Kepler Universit¨at Linz at the Institute of Bioinformatics - to propose “a dedicated transformation execution model based on Colored Petri Nets, which allows to combine the statefulness of imperative ap- proaches as well as raised level of abstraction from declarative approaches” [25]. This master thesis uses TROPIC to improve the ease of debugging of “classical” transformation languages – respectively QVT-R. In particular, for every meta- model element corresponding Places in TROPIC are derived, whereby a Place is created for every class, every attribute and every reference. Model elements are represented by Tokens which are put into the according Places. Finally, the ac- tual transformation logic is represented by Transitions. The existence of certain model elements (i.e., Tokens) allows Transitions to fire and thus stream these Tokens from source places to target Places representing instances of the target metamodel to be created (see Figure 3.4).

illustration not visible in this excerpt

Figure 3.4.: The involved artifacts in TROPIC [30]

The stepwise firing of the Transitions makes the operational semantics of the transformation logic explicit and thereby enables simulation. The ability to combine all the artifacts involved, i.e., metamodels, models, as well as the ac- tual transformation logic, into a single representation makes the formalism espe- cially suited for gaining an understanding of the intricacies of a specific model transformation. Moreover, TROPIC form a runtime model, serving as an execu- tion engine for diverse model transformation languages, e.g., QVT-R. Therefore, TROPIC exceptionally qualifies for trying to uncover the elements hidden by the QVT-R declarations as black-box statements.

In this section the main features of TROPIC nets are explained that together with QVT built up the basis for the later on proposed method to translate QVT-R code to TROPIC in order to debug model transformations.

3.2.1. Core concepts of TROPIC

TROPIC uses a different perspective on transformation problems as MTLs like QVT-R. Since TROPIC is based on Colored Petri Nets, the main parts of the TROPIC metamodel (see Figure 3.7) consists of Places, Tokens and Transitions.

The Net is the root element holding all other TROPIC items. There exist one- and two-coloured – represented by a doubled border – Places represent- ing (concrete or abstract) classes (see Figure 3.5). The objects (the instances of these classes) are represented by Tokens. One-coloured Tokens can only be added to one-coloured Places and two-coloured Tokens to two-coloured Places. Places itself are, therefore, the holders of the state in TROPIC. The colours of Tokens are used to differentiate between different object instances they repre- sent. TropicUnit can be used for clustering other TROPIC units together in meaningful groups.

Models in this thesis - including the TROPIC models – are based on Ecore. Ecore is an implementation for a subset of MOF and allows the usage of so called EClasses, EAttribute and EReference. EClasses are comparable with classes in UML class diagrams holding relationships – EReference – and attributes – ECAttribute. Such a mapping of MOF model concepts to TROPIC can be seen in Figure 3.5 – in this Figure EClass, EAttribute and EReference are named as Class, Attribute and Reference.

Transitions consist of input placeholders (LHS of the Transition) represent- ing the preconditions of a certain trans- formation, whereas output placeholders (RHS of the transition) depict its postcondition. Those placeholders are expressed by the classes InPlacement (LHS) and OutPlacement (RHS) in the metamodel as shown in Figure 3.7. Every Placement is connected to a source or target Place using Arcs, whereby incoming and outgoing Arcs are represented by the classes PTArc and TPArc, respectively. To express these pre- and postconditions, so-called MetaTokens (see class MetaToken in the metamodel in Figure 3.7) are used, pre- scribing a certain Token configuration by means of colour patterns which can be used in two different ways, either as Query Token (LHS) or as Production Token (RHS), as shown in Figure 3.6. The Transitions, therefore, provide the construction of a transformation flow by using certain colour patterns. Query Tokens and Production Tokens using same colours imply a correspondence of LHS and RHS elements. Colours only used on one side represent unique or new colours (if used as Production Tokens).

Different colours – although they are not forced to be used – are necessary

illustration not visible in this excerpt

Figure 3.5.: Comparing MOF and TROPIC elements on model and metamodel level [15]

for aggregating and differentiation between different values of Tokens. How- ever, two-coloured MetaTokens can be used for aggregating values from two one- coloured objects. This is achieved by placing two one-coloured MetaTokens in InPlacements of the same Transition. Furthermore, a two-coloured MetaToken is placed in an OutPlacement of the same Transition holding the same colours as both MetaTokens in the InPlacements. Naturally, this procedure can be used to split up values or to newly address values, but it clearly states that colours are the only method that can be used in TROPIC to differentiate between different values.

The importance of colouring MetaTokens is also describable by using Tokens as conditions to fire Transitions. For example it can be defined that the Token “isPersistent=true” is a necessary condition for a Transition that transform the Token “Class” to a “Table” (Place). Hence, many Tokens can be necessary to fire a Transition that produces just a single output Token. To be able to pro- duce comprehensive transformations there is the possibility to create sequences of Transitions. A Transition delivering a Token to a Place need not be the first nor the last Transition in a row. The receiving Place can again have an outgo- ing Arc to another Transition or even Arcs to a handful of Transitions. This also implies the possibility for a Place to have several Arcs from Transitions filling it with Tokens.

Furthermore, Transitions can hold InPlacements that are hungry or not hungry (standard). Hungry means that by firing a Transition the used inputs are removed from its original Place. The overall principle of passing Tokens on (or even modifying them) stays the same.

illustration not visible in this excerpt

Figure 3.6.: Colour binding example of TROPIC [31]

A colour that is not used for MetaTokens on both sides like the blue MetaToken in Figure 3.6, represents a newly created colour. This represents one-sided condi- tions. Colours used on both sides represent value correspondences. Colours reused on the same side (LHS or RHS) represent model dependencies such a from a class to its attributes. This accomplished by using two-coloured MetaTokens.

Furthermore, configurations can be used that describe the Transition be- haviour that should be applied when firing it. Such configurations can be used by defining functional constraints. A configuration is directly applied to the Transition and is not automatically used for predecessors or successors.

Some typical Transitions are explained in the Figure 3.8. A simple Transition just “waits” for an incoming Token and passes it in the same colour to the out-

illustration not visible in this excerpt

Figure 3.7.: Metamodel of TROPIC [29]

put Place (cf. Figure 3.8 (a)). Transitions for Two-coloured Tokens can also be used to invert the colours of incoming Tokens (cf. Figure 3.8 (b)). Fur- thermore, two one-coloured incoming Tokens can produce a two-coloured output Token (cf. Figure 3.8 (c)). More complex Transitions could use some incoming two-coloured (or even one-coloured Tokens) and mix the colours to new one or two coloured Tokens (cf. Figure 3.8 (d)). Another interesting example is the us- age of horizontally aligned Tokens which can be compared to a logical disjunction (“or”-expression). Vertically aligned MetaTokens can be used that again express a logical disjunction (cf. Figure 3.8 (e)). This means that whenever a two-coloured Token with black (outer) and white (inner) – representing two different colours – or a Token with black (outer) and black (inner) – representing the same colour

– is available in the Place related to this Transition it can fire and produces a Token with turned colours (according to the configuration of white (outer) and black (inner) for the MetaToken on the right side.). This example produces a two-coloured Token using two colours what can lead to unambiguous results. In the case of a two-coloured Token that is built up by just one colour (the right alternative of the incoming MetaTokens is addressed) it is not clear which colour should be used. This problem can be addressed by using ColorMaps.

illustration not visible in this excerpt

Figure 3.8.: Typical variants of Transitions [25]

So far only “positive” conditions were introduced. This means that for example a Token is expected to be able to fire a Transition from a certain Place. The other way round is the possibility to use “Negations” that negate the specified condition. Enabling the negation of this condition for the net (and the related formula) transfers the meaning in its opposite. E.g., a Transition can be fired, if a certain “Class” Token is unavailable for this Transition.

3.3. Comparison of QVT Relations and TROPIC at a glance

A simple element to element mapping from QVT-R to TROPIC is summarized in Table 3.1 and also described in [29]. The most essential element in QVT- R code is the RelationTransformation that holds all Relations responsible for the transformation execution. Such a RelationTransformation can be con- sidered as the full transformation net (Net). As a consequence only a single RelationTransformation can be held by a Net.

In TROPIC, Tokens represent a certain object instance, whereas in QVT-R there are no means to explicitly represent model elements. The passing of data from source to target side is done in QVT-R by variables and in TROPIC this can be visualized with the colour of the used MetaToken and Token (for the instance itself).

The Relation is compared with a TropicUnit which represents a modulariza- tion concept for the actual transformation logic. DomainPatterns representing the transformation mappings, can be compared with a Transition. The proper- ties included in the Domain - or rather the Pattern of the Domain - can have the type ObjectTemplateExp or PropertyTemplateItem as described in more details later on. They can be compared with a Placement and a OneColoredMetaToken or TwoColoredMetaToken respectively. The concept of a When- and Where-clause can be visualized using an InPlacement / OutPlacement and an Arc from or to a trace place.

Abbildung in dieser Leseprobe nicht enthalten

Table 3.1.: Mapping QVT Relations to TROPIC [29]

How this transformation from QVT-R to TROPIC – including the usage of input models – can be accomplished in an application, is described in detail in the course of the presentation of the solution approach.

[...]

---

¹ http://www.ikv.de/ - last accessed: November 27 2009