Engineering processes are often inherently concurrent, involving multiple stakeholders working in parallel, each with their own tools and artefacts. Ensuring and restoring the consistency of such artefacts is a crucial task, which can be appropriately addressed with a bidirectional transformation (bx ) language. Although there exist numerous bx languages, often with corresponding tool support, it is still a substantial challenge to learn how to actually use such bx languages. Triple Graph Grammars (TGGs) are a fairly established bx language for which multiple and actively developed tools exist. Learning how to master TGGs is, however, currently a frustrating undertaking: a typical paper on TGGs dutifully explains the basic “rules of the game” in a few lines, then goes on to present the latest groundbreaking and advanced results. There do exist tutorials and handbooks for TGG tools but these are mainly focussed on how to use a particular tool (screenshots, tool workflow), often presenting exemplary TGGs but certainly not how to derive them systematically. Based on 20 years of experience working with and, more importantly, explaining how to work with TGGs, we present in this paper a systematic approach and guidelines to developing a TGG from a clear, but unformalised understanding of a bx.
Triple Graph Grammars (TGGs) [
To the best of our knowledge, the only existing work in this direction is from Kindler and Wagner [
Based on 20 years’ experience working together with industrial partners and students, learning how to understand and use TGG specifications, our contribution in this paper is, therefore, to provide a systematic approach to creating and extending TGGs. Our aim with the resulting step-by-step process, is to substantially lower the initial hurdle of concretely working with TGGs, especially for other users and researchers in the bx community.
The rest of the paper is organized as follows: Sect. 2 reviews the preliminaries of TGGs and provides our
running example that is available as Ecore2Html from the bx example repository [
The running example used in the rest of this paper is a bidirectional transformation between class diagrams and a corresponding HTML documentation. Consider, for instance, a software development project for implementing a TGG-based tool. The project consists of two groups of developers: (i) core developers who are responsible for establishing and maintaining the main data structures and API provided by the tool, and (ii) other developers who mainly use the API and work with the tool (functioning as beta testers for the project). The latter group does not define the data structures involved, but is probably in a better position to document all packages, classes, and methods. It thus makes sense to maintain two types of artefacts for the two groups of stakeholders: (1) class diagrams, maintained by core developers, and (2) HTML documents, maintained by API users in, e.g., a wiki-like manner. The class diagram to the left of Fig. 1 depicts the main data structures of a TGG tool, with a corresponding folder structure containing HTML files to the right.
The outermost package TGGLanguage corresponds to the top-most folder TGGLanguage, and contains subpackages and classes, which correspond to subfolders and HTML files, respectively. TripleGraphGrammars consist of TGGRules, which are in essence graph patterns (referred to as StoryPatterns) consisting of variables that stand for objects (ObjectVariables) and links (LinkVariables) in a model. This general concept of a graph pattern is extended for TGGs by attaching a Domain to each concept. Each Domain references a Metamodel, a wrapper for the supported metamodelling standard.2 The classes StoryPattern, LinkVariable, ObjectVariable, and EPackage are imported from other class diagrams (greyed out) and are not part of the documentation of TGGLanguage. The corresponding documentation model is much simpler: it consists of a folder structure mirroring the package structure in the class diagram, and an HTML file for each class. Note that packages are also documented in corresponding files, which start with “ ” to distinguish them from class documentation files (e.g.,
TGGLanguage.html). Inheritance and references are irrelevant for the documentation model, but all methods of each class (excluding inherited methods) are to be documented as a table with two columns (name of the method and documentation) in the corresponding class documentation file.
1http://is.ieis.tue.nl/staff/pvgorp/share/?page=LookupImage&bNameSearch=eMoflon 2In this case EPackage for Ecore, the de facto standard of the Eclipse Modeling Framework (EMF). TripleGraphGrammar tripleGraphGrammar 1 1 tripleGraphGrammar metamodel outermostPackage 2..3 Metamodel 1 EPackage metamodel 1
eSubpackages 0..* eSuperPackage 0..1 source correspondence 1 target 1 1 domain 1
TGGLinkVariable TGGObjectVariable domain 1 analysis tripleGraphGrammar
1 tggRule 0..* TGGRule refines 0..* linkVariable
0..* LinkVariable pattern 1 incomingLink 0..* outgoingLink 0..* StoryPattern pattern 1
target 1 objectVariable 0..* ObjectVariable
source 1
The following points are noteworthy: (1) Information loss is incurred when transforming class diagrams to documentation models (e.g., inheritance relations and references) and when transforming documentation models to class diagrams (all entered documentation is lost!). This is the main reason why the change propagation strategy required for this example must take the old version of the respective output artefact into account. (2) Not all possible changes make sense: it is arguable whether API users should be able to rename elements in the documentation and propagate such changes to the corresponding class diagrams. Even more arguable are changes such as adding new elements in the documentation that do not yet exist in the class diagram. Such changes may be interpreted as feature requests, but are probably not primary use cases.
TGGs and of Model-Driven Engineering (MDE) concepts, and refer readers having a hard time understanding
the following to, e.g., the eMoflon handbook3 for a gentle, tutorial-like introduction. Readers more interested in
a formal and detailed introduction to TGGs are referred to, e.g., [
In the following, we introduce core terms and notation as they are to be understood (informally) in this paper. Based on this understanding, we then propose a systematic, iterative TGG development process in Sect. 3, together with a set of guidelines or best practices. This process is then demonstrated by applying it to develop a TGG for our running example.
A model is an abstraction (a simplification) of something else, chosen to be suitable for a certain task. In an MDE context, metamodels, essentially simplified UML class diagrams, are used to define languages of models.
Given two languages of models and their respective metamodels, say a source and a target language, a consistency relation over source and target models is a set of pairs of a source and a target model, which are to be seen as being consistent with each other.
Given a consistent pair of source and target models, a change applied to the source model is referred to as a source delta, and a change to the target model is called a target delta. As models are graph-like structures consisting of attributed nodes and edges, we may decide that atomic deltas are one of: element (node/edge) creation, element deletion, and attribute changes. Atomic deltas can be composed to yield a composite delta. A composite delta that only involves element creation is called a creating delta. A source/target delta that does nothing is called an idle source/target delta, respectively.
Given a consistent pair of source and target models, and a source delta, the task of computing a corresponding target delta that restores consistency by changing the target model appropriately is referred to as forward model synchronization, or just model synchronization. This applies analogously to target deltas and computed source deltas, i.e., backward model synchronization. The more general task of restoring consistency given both a source and a target delta is referred to as model integration, which is outside the scope of this paper.
A Triple Graph Grammar (TGG) is a finite set of rules that each pair a creating source/target delta with either a corresponding creating target/source delta or with an idle target/source delta, respectively. 3Available from www.emoflon.org
Each TGG rule states that applying the specified pair of deltas together will extend a given pair of source and target models consistently. To keep track of correspondences between consistent source and target models on an element-to-element basis, a third correspondence model can be maintained consisting of explicit correspondence elements connecting certain source and target elements with each other. These correspondence elements are typed with a correspondence metamodel, which can be chosen as required. In general, a TGG can thus be used to generate a language of triples, consisting of connected source, correspondence, and target models. A triple is denoted as GS ← GC → GT (G for graph). A TGG induces a consistency relation as follows: A pair of source and target models (GS , GT ) is consistent if there exists a triple GS ← GC → GT that can be generated by applying a sequence of deltas, as specified by the rules of the TGG.
A TGG tool is able to perform model synchronization using a given TGG as the specification of consistency. A
TGG tool is correct if it only produces results that are consistent according to the given TGG used to govern the
synchronization process [
Example: To explain these basics further, Fig. 2 depicts the source and target metamodels chosen for the running example. The source metamodel (to the left) is Ecore, a well-known standard for simple class diagrams. Class diagrams basically consist of packages (EPackages) containing subpackages, and classes (EClasses) with methods (EOperations). The target metamodel (to the right) is MocaTree, a generic tree-like target metamodel providing concepts to represent a hierarchy of folders with files, where each file contains a tree consisting of Nodes. Objects of type Text but not of type Node are used to represent leaves in the tree that cannot have children. In this manner, it is possible to represent arbitrary (X)HTML trees. The correspondence metamodel consists of types connecting source and target elements as required for the rules and is omitted here. parentFolder 10..1 ENamedElement
TreeElement subFolder *
EPackage eSubpackages 0..*
To introduce the notation and language features used in this paper to specify TGG rules, let us consider two TGG rules for handling (sub)packages and their corresponding documentation. The TGG rule for handling root packages is depicted to the left of Fig. 3. The source and target deltas paired by this rule are: (i) creating a new EPackage in the source model, and (ii) creating a Folder with a single HTML File. The basic structure of the HTML file, consisting of a header and a paragraph where a description of the package can be entered, is also created in the same target delta. The package and folder are connected with a correspondence node of type EPackageToFolder. In standard TGG visual notation, all elements created in a rule are depicted in green with an additional "++" markup for black and white printouts. Correspondence nodes are additionally depicted as hexagons to clearly differentiate them from source and target elements.
A set of attribute constraints specifies the relationship between attribute values of the elements in a TGG rule. All TGG tools provide an extra, typically simple textual language for expressing such attribute constraints. In this case, the eq constraint expresses that ePackage has the same name as docuFolder. To express that the name of the htmlFile should start with " ", end with ".html", and contain the name of ePackage, two attribute constraints addSuffix and addPrefix are used, where withSuffix is a temporary variable.
«Rule» HTMLFileAndHeader
For cases where an attribute is simply assigned a constant, this can be “inlined” in the respective node, e.g., name := "html" in rootNode. If we consider Fig. 1 again, we can now compare the creating deltas in the TGG rule to the package TGGLanguage, the folder TGGLanguage and the HTML file TGGLanguage.html, and see that all attribute constraints are fulfilled.
It is often useful to extract parts of a rule into a basis rule, so that these parts can be reused in other subrules.
Apart from possibly enabling reuse, readability can also be increased by decomposing a rule into modular
fragments that each handle a well-defined concern. Many TGG tools support some form of rule refinement [
Fig. 4 depicts a further TGG rule SubPackageToDocuFolder for handling subpackages (EPackages with a super package). SubPackageToDocuFolder refines RootPackageToDocuFolder and additionally places the created package into a super package, and the corresponding subfolder into a parent folder (determined using the correspondence node superToFolder). Finally, the title is adjusted for subpackages by overriding it in SubPackageToDocuFolder. This rule shows how context can be demanded; the context elements superPackage, superToFolder, superFolder, and connecting source and target links are depicted in black and must be present (created by some other rule) before the rule can be applied. In this sense, the context elements form a precondition for the application of the rule.
Our current TGG consists of two concrete rules and one abstract rule, and can be used to generate consistent package hierarchies and corresponding folder structures with HTML files for documenting the packages. To introduce basic concepts we have already specified a TGG to handle package structures and their HTML documentation. This was done in a relatively ad-hoc fashion, choosing source and target metamodels, deciding to start with handling packages, and specifying the required TGG rules without consciously applying any systematic process. Although this might work fine for simple cases or for seasoned TGG experts, we propose the following process depicted in Fig. 5, which consists of four steps outlined in the following sections. In each step, we give guidelines that represent current best practice and provide guidance when making design decisions. 1 2 3 4 Choose and adjust your abstractions
Extend your testsuite of supported deltas
Extend your TGG to pass the new tests
Profile for hotspots and scalability In practice, the final artefacts to be synchronized are typically fixed for a certain application scenario, e.g., XML files, a certain textual format, a tool’s API, or programs in some programming language. As TGG tools do not usually operate directly on these final artefacts, a parser/unparser component, referred to as an adapter in the following, is required to produce a graph-like abstraction of the artefacts. The choice of source/target metamodels thus becomes a degree of freedom with a direct impact on the complexity of the required adapter. Guideline 1 (Adapter complexity vs. rule complexity). Choosing very high-level source and target metamodels might lead to simple, elegant TGG rules but also requires complex adapters in form of (un)parsers or some other import/export code. As this shifts complexity away from the TGG, strive to keep such pre/post-processing adapter logic to a minimum. Decomposing the synchronization into multiple steps by introducing an intermediate metamodel and developing two TGGs instead of one can be a viable alternative.
Example: For our running example, the source artefacts are XMI files representing class diagrams, while target artefacts are XHTML files. As the class diagrams already conform to Ecore, choosing Ecore as the source metamodel means that the standard EMF XMI reader and writer can be used. To handle XHTML files, a simple and generic XML adapter is used that produces instances of a basic, tree-like metamodel MocaTree, as depicted in Fig. 2. Although these choices reduce the required adapter logic to a minimum (G1), our TGG rules are rather verbose, especially in the target domain (cf. Fig. 3). We addressed this with rule refinement (any form of modularity concept could be beneficial in this case if supported by the chosen TGG tool), but could also have chosen a richer target metamodel and shifted most of the complexity to a problem-specific XHTML parser and unparser instead. 3.2
Although it is generally accepted best practice in software development to work iteratively and to apply regression testing, beginners still tend to specify multiple rules or even a complete TGG without testing. This is particularly problematic because the understanding of the consistency relation often grows and changes while specifying a TGG. The following guideline highlights that any non-trivial TGG should be supported by a test suite. Guideline 2 (Take an iterative, test-driven approach). When specifying a TGG, take a test-driven approach to prevent regression as the rules are adjusted and extended. Run your test suite after every change to your TGG. In this context, a source test case consists of: (i) a consistent triple (possibly empty), (ii) a source delta to be applied to the triple, and (iii) a new target model representing the expected result of forward synchronizing the source delta. Target test cases are defined analogously. Although all important deltas for an application scenario should eventually be tested, it makes sense to focus first on creating deltas as these can be almost directly translated into TGG rules.
Guideline 3 (Think in terms of creating source and target deltas). Think primarily in terms of consistent pairs of creating source and target deltas and derive corresponding test cases. This simplifies the transition to a TGG. The following two guidelines propose to handle “easy” cases first before going into details. Concerning creating deltas, “easy” translates to “not dependent on context”.
Guideline 4 (Start with context-free creating deltas). Start with context-free pairs of creating deltas as these are usually simpler. A context-free delta can always be propagated in the same way, independent of what the elements it creates will be later connected with.
Although graphs do not have a “top” or “bottom” in general, in many cases models do have an underlying containment tree. Top-down thus means container before contents. As containers typically do not depend on their contents, we get the following guideline as a corollary of Guideline 4: Guideline 5 (Prefer top-down to bottom-up). If possible, start top-down with roots/containers of the source and target metamodels as containers typically do not depend on their contents.
Example: Applying these guidelines to our running example, we chose to handle package hierarchies in a first iteration (G2). We started thinking about creating a root package in the class diagram as a source delta, whose corresponding target delta is creating a folder containing a single HTML file named “ ” + ePackage.name, which is to contain the documentation for the root package (G3). This is always the case irrespective of what the root package/folder later contains and is thus a context-free pair of creating deltas (G4). We took a top-down approach (G5) handling root packages before subpackages (cf. Fig. 3 and Fig. 4). 3.3
After discussing with domain experts and collecting test cases addressing a certain aspect, e.g., (sub)packages and folders, the next step is to specify new, or adjust existing, TGG rules to pass these tests. To accomplish this, it is crucial to understand that there are only a few basic kinds of TGG rules as depicted schematically in Fig. 6. The names are chosen to give a geographical intuition, where green and black clouds/arrows denote created and context elements, respectively: Islands are context-free rules that do not demand any context. An island may either be idle, creating either source or target elements, or it may create both, source and target elements. After applying such a rule, an isolated “island” of elements is created.
Extensions require a context island and then extend it by creating and directly attaching new elements to it. Bridges connect two context islands by creating new elements to form a bridge between the islands. Bridges can of course be generalized to connect multiple islands, but remain fundamentally the same. Bridges connecting more than two islands are rare in practice, probably because they become increasingly complex to comprehend. Ignore rules (not depicted) are TGG rules that do not create any elements in either the source or target domain. Such rules state explicitly that applying a certain creating delta in one domain has no effect on the other domain. Based on these basic kinds of TGG rules, we propose the following guidelines.
Guideline 6 (Prefer islands and bridges to extensions). When specifying an extension, always ask domain experts if it is acceptable to split the extension into an island and a bridge, as this often improves derived synchronizers. Extensions should only be used if an island would have to change once it is connected via a bridge. An extension states that all created elements are dependent on the specified context. In many cases, this introduces unnecessary dependencies between islands. In general, TGG-based synchronization works better, the fewer context dependencies are specified in rules.
Guideline 7 (Formalize information loss via explicit ignore rules). Most TGG tools attempt to ignore irrelevant elements automatically, as specifying this explicitly with ignore rules can be tedious, especially in the first few iterations, when the TGG covers only a small subset of the source and target metamodels. Explicit ignore rules are nonetheless better than tool-specific heuristics and automatic ignore support, and should be preferred. Example: Applying these guidelines to our running example, we now discuss the current TGG (handling package/folder hierarchies) as well as new rules for handling classes and methods, together with their respective documentation. Reflecting on rules RootPackageToDocuFolder and SubPackageToDocuFolder (cf. Fig 3 and 4) now in the light of our guidelines, we can identify RootPackageToDocuFolder as an island, and SubPackageToDocuFolder as an extension thereof. Can we split the extension into an island and a bridge (G6)? Although subpackages are treated just like root packages, it must be clear from the corresponding documentation file that this is the documentation for a subpackage and not a root package. The heading in the file (title in RootPackageToDocuFolder) must, therefore, be adjusted appropriately. Interestingly, if a (sub)package p is deleted in the source model, all subpackages of p consequently become root packages and must now be (re)translated differently! This also applies to making a former root package a subpackage by connecting it to a super package. In this case, the root package is now a subpackage and must also be (re)translated appropriately. Creating and documenting subpackages in this manner is an example of creating deltas that cannot be handled as an island.
Creating a class c corresponds to creating an HTML file named <c.name> + “.html”, this time with a header “EClass” + <c.name>. In addition, an empty HTML table to contain all methods of the class should be created in the file. Adding a class c to a package p corresponds to simply placing the documentation file for c into the documentation folder for p. This time around, these consistency requirements can be transferred directly to an island and a bridge: Fig. 7 depicts the island EClassToHTMLFile for handling the creation of an EClass and its documentation file with internal HTML structure. EClassToHTMLFile once again refines HTMLFileAndHeader to reuse the basic structure of an HTML file. The body of the HTML file is extended, however, by a table node methodTable and an extra subheader for the table. Attribute constraints are used to ensure that the name and header of the file correspond appropriately to the created class. Specifying this as an island means that classes and their documentation are created in this manner, independent of what package the class is later placed in.
Fig. 7 also depicts the bridge EClassToFileBridge used to handle adding classes to packages and their documentation files to the corresponding documentation folder. In this case the “bridge” consists of an edge in each domain. In general, however, an arbitrary number of elements can be created to connect the context clouds as required. The primary advantage of using a bridge here instead of an extension (G6) is that unnecessary dependencies are avoided; a class can be moved to a different package without losing its documentation. Finally, Fig. 7 depicts an ignore rule IgnoreFileDocu (no elements are created in the source domain), which states explicitly that adding documentation to an HTML file does not affect the source domain (G7). Note that this handles documentation for both packages and classes as the basic structure of the HTML file is identical.
Fig. 8 depicts an island DocumentMethod, a bridge EOperationTableBridge, and an ignore rule IgnoreMethodDocu used to handle creating methods and their corresponding documentation. «Rule» RootPackageToDocuFolder
«Rule»
EClassToHTMLFile EClassToFileBridge folder
file ++ htmlFile : File documentation :
Node name == "p" index == 1 parentNode children ++ ++
docu : Text
IgnoreFileDocu
Creating a method of a class corresponds to creating a row in an HTML table with two column entries: the first for the name of the method, and the second for its documentation (initially empty). Connecting a method to a class corresponds to adding this row to the method table of the class that was created by EClassToHTMLFile. A row in an HTML table is a tr element, while column entries are td elements. Indices are used in DocumentMethod to ensure that the column entries are always in the same order (name before documentation). EOperationTableBridge connects a method to a class, and adds its HTML row node to the method table of the class. Analogously to IgnoreFileDocu, the ignore rule IgnoreMethodDocu states that documenting a method does not affect the source domain. Note that the node documentation is constrained to be a column entry.
According to G7, we would actually need to specify ignore rules for all irrelevant concepts in the source domain (cf. Fig. 2) including inheritance relations, attributes, references, and datatypes. This guideline can be relaxed, however, for types that do not occur in any TGG rule. It is, for instance, easy to automatically ignore the reference eSuperTypes denoting inheritance, but difficult to automatically ignore Text documentation nodes (as in IgnoreMethodDocu), as the type Text does occur, e.g., as ref:Text in DocumentMethod. 3.4
Declarative languages such as TGGs certainly have their advantages, but one must reserve some time for
profiling and testing for scalability. Depending on the TGG tool and the underlying modelling framework and
transformation engine, certain patterns and constructs can be, especially for beginners, surprisingly inefficient.
Guideline 8 (Use a profiler to test regularly for hotspots). Regularly profiling the synchronization for medium
and large sized models is important to avoid bad design decisions early enough in the development process4.
To support such a scalability analysis, some TGG tools [
Concrete optimization strategies for TGGs are discussed in detail in [
In this section we try to bring our TGG to life in the synchronization scenario depicted in Fig. 9. Our goal is
to impart a high-level intuition for how TGG-based synchronization algorithms work in general. This provides
not only a rationale for the guidelines already provided in the previous section, but also an understanding for
how arbitrary deltas (and not only the explicitly specified creating deltas) are propagated. How this propagation
works arguably depends on the chosen TGG tool, in our case eMoflon whose algorithm is described in [
A common restriction is demanding some variant of confluence, a well-known property of transition systems,
which can be checked for statically using a so-called critical pair analysis. The interested reader is referred
to, e.g., [
Handling Deleted and Added Elements 5 , 6 : After discussing two simple cases, we now demonstrate how the choice between extensions and bridges affects the behaviour of a TGG-based synchronizer. Let us consider a more general source delta 5 , which “moves” the subpackage precompiler from TGGLanguage to compiler.
This is accomplished by (i) deleting the link between TGGLanguage and precompiler, and (ii) creating a new link between compiler and precompiler. Propagating this source delta 6 thus entails handling a deletion and an addition. The synchronization is, therefore, executed in three phases: a deletion phase, an addition phase, and a translation phase: for all deletions: revoke all dependent rule applications for all additions: revoke all dependent rule applications translate all revoked and newly added elements To revoke means to rollback a rule application, i.e., for forward synchronization, all correspondence and target elements created by the rule application to be revoked are deleted, while all created source elements are considered as revoked and to be (re)translated in the ensuing translation phase.
For every element that has been deleted, all rule applications that require the element as context and thus depend on the deleted element become invalid and must be revoked. Note that this must be done transitively.
In general, additions also have to be handled analogously to deletions, i.e., sometimes rule applications must be revoked as a consequence of newly added elements. For our running example, consider adding a new root package eMoflonLanguages that contains the current root package TGGLanguage. This must lead to revoking TGGLanguage and re-translating it as a subpackage of the new root package eMoflonLanguages!
To explain this further with our synchronization scenario, Fig. 10 depicts a relevant excerpt of the source and target models involved (top left). The deleted link is depicted bold and red with a “--” markup for emphasis. A TGG-based synchronizer typically keeps track of the translation by grouping links and objects into rule applications. This grouping is depicted visually in Fig. 10 for all rule applications required to create the current triple. For example, the rule application 3:SubPackageToDocuFolder comprises the deleted link between TGGLanguage and precompiler, the subpackage precompiler, as well as the corresponding target elements: the link between the root folder TGGLanguage and subfolder precompiler, the folder precompiler, and the HTML file precompiler.html. Note that the rule applications also comprise all relevant correspondence elements, which are abstracted from in Fig. 10 to simplify the explanation.
This grouping into rule applications, which can be reconstructed by simulating the creation of a consistent triple from scratch if necessary, is used to determine dependencies between the groups of elements. This is depicted visually in Fig. 10 (top right) as a dependency graph, showing that, for example, the rule application 5:EClassFileBridge depends on (shown as an arrow) 3:SubPackageToDocuFolder and 4:EClassToHTMLFile, as these two rule applications create objects that are required as context in 5:EClassFileBridge.
Given a source delta and calculated dependencies between rule applications, the deletion phase is carried out by revoking all rule application containing deleted elements, recursively revoking all rule applications that directly or transitively depend on revoked rule applications, and finally removing the deleted source elements from all data structures. This process is depicted in Fig. 10 (top right) showing (with a bold, red outline and “--” markup) that 3:SubPackageToDocuFolder is to be revoked as it contains the deleted source link between TGGLanguage and precompiler. In this case, the only dependent rule application is 5:EClassFileBridge, which must also be revoked (bottom right of Fig. 10).
In the translation phase, all revoked source elements are treated as if they were newly added, i.e., they are translated together with all added elements. This is depicted in Fig. 10 (bottom left) showing (bold, green outline and “++” markup) the revoked source elements precompiler and the link between precompiler and RefinementPrecompiler, as well as the newly added link between compiler and precompiler from the source delta. In this state, the same translation strategy as explained for 2 and 4 can be applied, however, only for all added and revoked source elements. Due to this process, the documentation added to RefinementPrecompiler.html in 3 is retained as its corresponding class is not revoked (Fig. 10, bottom left). As the subpackage precompiler is, however, revoked and re-translated, its documentation file precompiler.html is deleted, losing the changes made in 3 , and is re-created afresh.
This is a direct consequence of using an extension rule for handling subpackages, but a bridge to connect classes to their parent packages. Similarly, the decision to use a bridge to connect methods to their classes enables, e.g., a pull-up method refactoring in the class diagram without having to revoke the method and lose its documentation. One can certainly argue that this behaviour is not always optimal, but it is what can currently be expected from state-of-the-art TGG-based synchronizers, given the choices we made when designing our TGG. Further improving current TGG synchronization algorithms to handle extensions as bridges during change propagation and still guarantee correctness is ongoing research. -
We consider three different groups of related work in the following: (1) previous TGG publications with a focus
similar to this work, (2) guidelines for bx approaches based on QVT-R which, similar to TGGs, address bx in
an MDE context, and (3) other approaches to systematically developing model transformation rules in general.
Other approaches to systematically developing a TGG: Kindler and Wagner [
Engineering guidelines are presented in [
Guidelines for bx with QVT-R: Similar to TGGs, QVT-Relations (QVT-R) addresses bx in an MDE context.
The standard QVT-R reference [
In this paper, we have presented not only a basic introduction to TGGs, but also a process and a set of guidelines to support the systematic development of a TGG from a clear, but unformalised understanding of a bx.
We have, however, only been able to handle the basics and leave guidelines for advanced language features and techniques to future work including: negative application conditions, multi-amalgamation, user-defined attribute manipulation, test generation, and how best to specify the correspondence metamodel.
Acknowledgements. The first author of this paper received partial funding from the European Union’s Seventh Framework Program (FP7/2007-2013) for CRYSTAL-Critical System Engineering Acceleration Joint Undertaking under grant agreement No 332830 and from Vinnova under DIARIENR 2012-04304.