Figure 6 - uploaded by Robert Wagner
Content may be subject to copyright.
Source publication
Triple Graph Grammars (TGGs) are a technique for defining the correspondence between two different types of models in a declara-tive way. The power of TGGs comes from the fact that the relation between the two models cannot only be defined, but the definition can be made operational so that one model can be transformed into the other in either dire...
Contexts in source publication
Context 1
... the context of our paper, all rules will be non-deleting rules. Non-deleting rules can be represented in a more concise way: Figure 6 shows the short hand form for the rule from Fig. 4. The black objects and links represent the elements that occur on both sides of the graph grammar rule; the green objects and links, which in addition are labeled with ++, represent the elements occurring on the right-hand side of the rule only. The labels ++ emphasize their meaning: these are the nodes to be added to the object diagram once the black nodes are matched in the original object diagram and the rule is applied. ...
Context 2
... models, and we would like to see the correspondences between them. Technically, the setting is very similar to the transformation approach. Since we have models for both domains, we do not need to generate the models -both models are already there. We need to introduce the correspondence node between the root elements of these models as shown in Fig. 26. From there, we match both domains of the TGG-rules on the existing models and introduce the correspondence nodes of the matching TGG-rule. When both models are fully matched, we have established the legal correspondences between the two initial models. We call this model ...
Context 3
... and model integration can be considered as a special case of model synchronization. For a transformation, we start with the situation in Fig. 23 and changes of the source domain are not allowed, but we may introduce elements to the target domain and to the correspondence domain. For the integration of two models, we start with the situation in Fig. 26 and only changes in the correspondence domain are allowed. Since the setting for transformation and integration are much simpler than general synchronization, it is easier to implement them directly. Therefore, we consider transformation and integration as separate ...
Context 4
... the translation into the TGG-formalism, the synthesis checks if some already synthesized rules exist which have to be checked against this new exam- ple pair. Since this is the first example pair, no further rules have to examined. Therefore, our synthesis algorithm introduces a correspondence node between the Project and PetriNet objects. In Fig. 36, the extracted TGG-rule is shown. At the moment, the extracted TGG-rule has an empty left-hand side and provides only objects on the right-hand side which are therefore marked with ++ labels. Hence, the synthesized rule does not correspond to the so far known structure of TGG-rules. In fact, it is similar to the axiom shown in Fig. 16. ...
Context 5
... as shown in the top of Fig. 35. Once again, the synthesis starts with the translation of the example pair to a TGG-rule. The result of this translation is shown in Fig. 37. Now, the synthesis algorithm checks if some other rules exist that could be matched to the extracted object structure of the example pair. In our case, only the rule shown in Fig. 36 has to be considered. The algorithm matches the objects from the already synthesized rule with the new example pair according to their domains. This is similar to the integration scenario presented earlier except for the fact, that the correspondence node is not considered during the matching procedure. Since the correspondence node of ...
Context 6
... the example pairs given in the new order, our algorithm will once again synthesize three TGG-rules. From the first example pair once again the TGG-rule presented in Fig. 36 is synthesized. From the second example pair the TGG-rule shown in Fig. 51 is synthesized whereas the TGG-rule synthesized from the third example pair is once again the TGG-rule presented in Fig. 39. Fig. 36 is available when our second example pair is considered by our synthesis algorithm. Therefore, only one rule is matched with the ...
Context 7
... in the new order, our algorithm will once again synthesize three TGG-rules. From the first example pair once again the TGG-rule presented in Fig. 36 is synthesized. From the second example pair the TGG-rule shown in Fig. 51 is synthesized whereas the TGG-rule synthesized from the third example pair is once again the TGG-rule presented in Fig. 39. Fig. 36 is available when our second example pair is considered by our synthesis algorithm. Therefore, only one rule is matched with the second example pair, whereas, in the previous ordering, already two synthesized rules have been taken into account. This results in fewer matched objects and leads to a quite large ...
Context 8
... the left-hand side, i. e., in our case from a Petri net to a project, is called reverse or backward rule. It is derived from the TGG-rule in the same way as the forward rule: we just remove the ++ labels from all elements that belong to the model domain rendered on the right-hand side, i. e., from the elements of the Petri net. It is presented in Fig. 60. The third rule derived from the TGG-rule is responsible for the correspon- dence analysis between the involved models, i. e., for model integration. The rule is executed in the case that both models already exist and only the in- terrelation between the models has to be established, i. e. the rule creates the correspondence nodes and ...
Context 9
... derived forward graph transformation rule including the marking facil- ity is shown in Fig. 62. The marking set is implemented using handled links. For example, in the forward rule from Fig. 62 it is checked whether the Con- nection node is not yet matched using a negative link between the Task node and the affected Connection node. If no such negative link exists, i. e., if the negative application condition evaluates to true, ...
Context 10
... derived forward graph transformation rule including the marking facil- ity is shown in Fig. 62. The marking set is implemented using handled links. For example, in the forward rule from Fig. 62 it is checked whether the Con- nection node is not yet matched using a negative link between the Task node and the affected Connection node. If no such negative link exists, i. e., if the negative application condition evaluates to true, a valid match is found and the affected node is marked by creating such a link. In addition, the ...
Context 11
... the extended correspondence model with the succ links into account. With the additional links between the cor- respondence nodes, the correspondence model can be interpreted as a directed acyclic graph (DAG). It is a graph rather than a tree due to the fact that rules are allowed to have more than one correspondence node as a precondition (cf. Fig. 62). The graph is acyclic since in a rule application, we never connect already existing correspondence nodes by a ...
Context 12
... Fig. 63 an overview of the realized incremental algorithm is shown. The presented algorithm comprises several activities which in turn are implemented using the aforementioned graph transformation rules. The combination of an activity diagram with embedded graph transformation rules is also called a story diagram [43]. The story diagram is ...
Context 13
... side of the rule) of this rule map to nodes and links which are marked with an asterisk already. The green nodes of the TGG-rule in domain project map to the corresponding nodes of the project which are not yet marked with an asterisk. The green nodes of the TGG-rule in domain corresp and petrinet cannot be mapped. This mapping is shown in Fig. ...
Context 14
... the visual specification of TGG-rules we use the TGGEditor presented in Fig. 68. This editor is implemented as a Fujaba plug-in and ensures con- formance to the source, the correspondence, and the target meta-models. For this purpose, the required meta-models have to be specified in Fujaba as class diagrams. In addition to the editor, there is also a plug-in implementing the specification by example approach. This ...
Context 15
... was enhanced by further features increasing the usability of the editor. For example, when selecting a particular node, the editor proposes to create fur- ther nodes that are potentially reachable from the selected node. This eases the specification of TGG-rules and makes it more comfortable. A screenshot of the generated editor is shown in Fig. 69 The TGG-rules specified within the editor are used by the TGG-interpreter engine to perform transformations of EMF instance models. For this purpose, the specified TGG-rules are stored using EMF's default XML persistence fa- cilities. In addition, the interpreter has to be configured step by step using a configuration wizard. A ...
Similar publications
This paper shows how the correspondence between a unordered dependency tree and a sentence that expresses it can be achieved by transforming the tree into a string where each linear precedence link corresponds to one specific syntactic relation. We propose a formal grammar with a distributed architecture that can be used for both synthesis and anal...
This article presents a method to interface a sentential grammar and a discourse grammar without resorting to an intermediate processing step. The method is general enough to build discourse structures that are direct acyclic graphs (DAG) and not only trees. Our analysis is based on Discourse Synchronous TAG (D-STAG), a Tree-Adjoining Grammar (TAG)...
An implementation of the Palladian grammar using a graph grammar and a graph to shape mapping is presented. The application is embedded in a parametric CAD environment and allows the exploration of Palladian villas by hand or by using a random generator.
Acquisition of new terminology from specific domains and its adequate description within terminological dictionaries is a complex task, especially for languages that are morphologically complex such as Serbian. In this paper we present an approach to solving this task semi-automatically on basis of lexical resources and local grammars developed for...
Citations
... While this technique can be applied to strings, lists, or trees, the most prominent representative are Triple Graph Grammars (TGG) [5]. TGGs have been implemented by various tools, such as eMoflon [26] or TGG Interpreter [27], just to name a few. The basic idea behind TGGs is to interpret both source and target models as graphs and additionally have a correspondence graph, whose nodes reference corresponding elements from both source and target graphs, respectively. ...
Model transformations are a major driving force behind model-driven software development (MDSD), when typically an initial model is refined throughout the development process over several steps until eventually code is generated. Strict forward engineering processes require unidirectional model transformations, where an initial requirements model is refined through various model transformation steps. Roundtrip engineering on the other hand calls for bidirectional and incremental model transformations instead, where changes may be propagated back and forth while retaining manual modifications to the models involved. In this paper, we present BXtendDSL, a framework for bidirectional incremental model transformations. BXtendDSL combines two languages: a light-weight declarative language for defining correspondences between model elements, and an imperative language that allows to implement behavior that cannot be specified in the declarative language. We demonstrate our approach by a case study. We also include an evaluation of this case study that demonstrates conciseness, expressiveness, and scalability of our hybrid approach.
... This is similar to the approach taken by Varró (2006) who suggest specifying rules by example of the matching instances. Kindler and Wagner (2007) take the approach one step further and suggest a semi-automatic derivation of rules from exemplary instance graphs. However, we keep the rule creation process (e.g., the selection and correlation of the source and target instance pieces) manual. ...
Conversion of Industry Foundation Classes (IFC) building models into CityGML city models is one of the operational scenarios for BIM–GIS integration, with a variety of applications producing and consuming data on either side. Given the in‐depth cross‐domain knowledge required to specify such conversions, the heterogeneity of the IFC input data and the use cases for the resulting CityGML, flexible and configurable solutions are needed that make conversion details accessible to domain specialists. Graph transformation as a conversion method fulfils these requirements. We propose to extend the modularity given by single transformation rules at a more coarse‐grained level and identify four layers with modules of associated rules. We describe a self‐contained set of rules across these modules and demonstrate its application to a range of building models.
... In subsequent work [5], concurrency and tolerance were added as further dimensions. Regarding expressiveness in particular, an overview of TGG language features is given by Kindler and Wagner [32], while features are only described on an intuitive level. A precise definition of expressiveness is lacking as well as an analysis of features increasing the expressiveness. ...
Bidirectional model transformations are a way to keep two models synchronized and propagate changes in one model to the other one. Triple Graph Grammars (TGGs) are a rule-based approach to define consistency bidirectionally, with applications e.g. in the development of textual and visual languages. Although the underlying formalism is relatively uniform in different TGG tools, there are various TGG variants supporting different sets of language features, such as attribute conditions, (negative) application conditions, and multi-amalgamation. This makes it difficult to evaluate the expressiveness of a specific TGG tool, to check whether the tool supports all features required to specify a given consistency relation.
In this paper, we provide an overview of the most common language features of TGGs. Based on this, we discuss different TGG variants formally and develop a classification of TGG approaches with respect to their expressiveness. We evaluate whether certain language features increase the expressiveness of TGGs or just improve the usability and simplify the specification, which can be important when choosing a software tool depending on the concrete problem at hand. Additionally, examples implemented in the TGG tool eMoflon::IBeX are discussed, which particularly illustrate how the various TGG variants differ in their expressiveness.
... A triple graph grammar that formally relates two typed object graphs, can be operationalised in different ways [44]: ...
The Singapore Government has embarked on a project to establish a three-dimensional city model and collaborative data platform for Singapore. The research herein contributes to this endeavour by developing a methodology and algorithms to automate the conversion of Building Information Models (BIM), in the Industry Foundation Classes (IFC) data format, into CityGML building models, capturing both geometric and semantic information as available in the BIM models, and including exterior as well as interior structures. We adopt a Triple Graph Grammar (TGG) to formally relate IFC and CityGML, both semantically and geometrically, and to transform a building information model, expressed as an IFC object graph, into a city model expressed as a CityGML object graph. The work pipeline includes extending the CityGML data model with an Application Domain Extension (ADE), which allows capturing information from IFC that is relevant in the geospatial context but at the same time not supported by CityGML in its standard form. In this paper, we elaborate on the triple graph grammar approach and the motivation and roadmap for the development of the ADE. While a fully complete and lossless conversion may never be achieved, this paper suggests that both a TGG and an ADE are natural choices for supporting the conversion between IFC and CityGML.
... For example, a conceptually-similar method to the double-pushout approach is the use of a triple-graph grammar (TGG) [134,80]. A TGG relates structures in the source and target meta-models through a explicitly defined correspondence model. ...
As the complexity of software systems increases, the engineering effort for developing those systems must deal with that complexity. One paradigm for software development is model-driven engineering, where the models of the system become the first-order artefacts. These models may be used for simulation or analysis of the system, or be transformed into executable code or documentation. The intention is to represent each facet in the system in the most appropriate formalism at the most appropriate level of abstraction. For example, one approach to managing complexity is to write models in a domain-specific language, which captures domain concepts such that experts can more easily reason about the system.
Model transformations provide a structured and understandable way of manipulating these models, and are often rooted in a mathematical approach which enables precise specification and analysis. However, it may be difficult for a user to reason about what elements will be matched and written by a particular transformation.
Our research is focused on the verification of model transformations for a particular model transformation language. In particular, we are interested in the proving of pre-condition / post-condition contracts, which relate the elements in the input models to the transformation with the elements present in the corresponding output elements.
DSLTrans
The model transformation language involved in our research is DSLTrans. This transformation language was selected because of the properties guaranteed by construction: termination and confluence. This means that all executions of the transformation must finish, and that transformation executions are repeatable. In this thesis, we provide a description of the semantics of DSLTrans in the double push-out approach, which brings DSLTrans to the state-of-the-art in model transformation. As well, we provide semantics for other DSLTrans constructs not considered in earlier works. These constructs include negative elements, indirect links, and Exists elements.
Contract Proving
Following the definition of DSLTrans, this thesis also details our contract proving approach on DSLTrans transformations. The core idea of our approach is to build path conditions for the transformation through a symbolic execution procedure. That is, our technique determines all valid combinations of rules in the transformation. Each of these path conditions will explicitly represent the input and output elements present when that combination of transformation rules execute through an abstraction relation.
We then prove pre-condition / post-condition contracts on these path conditions. If a path condition does not satisfy the contract, then the path condition serves as a counter-example. Examination of this counter-example allows for reasoning about rules and rule interaction in the transformation.
As a contribution of this thesis, we consider all constructs in the DSLTrans language and thus we can verify all DSLTrans transformations, including those that contain negative elements. As well, we also define the unique split morphism in this thesis, which allows for the vertices in the pattern graph to 'split' over the vertices in the target graph. The use of this morphism allows us to create fewer path conditions than in previous research, enabling our technique to scale to larger transformations.
SyVOLT Tool
Another contribution of this thesis is to present the SyVOLT tool, which is our implementation of the path condition generation and contract proof techniques. This tool is able to prove multiple contracts on our case studies within a reasonable amount of time, as shown on our case studies. In this thesis, we discuss the work-flow and implementation details of the prover, with a focus on discussing the multi-paradigm and multi-formalism nature of the tool.
We also present a number of techniques to improve the scalability and analysis results of the tool. These techniques include a) parallelization of the prover, b) slicing the transformation to the minimum number of rules required to prove a contract, c) examining the set of path conditions to prune invalid path conditions based on the transformation's output meta-model, and d) performing dependency analysis to warn the user of errors with the contract or transformation and assist in the comprehension of contract proof results.
... We detail in [14] the whole set consisting of 32 rules, of which the largest one has 16 nodes. According to [12] practical TGGs have in average 15-20 rules, with 10-40 nodes each. The larger number of rules in our case is explained by the number of types and syntactic categories in the Erlang language. ...
In this paper, we present a method that transforms event-driven Erlang state machines into high-level state machine models represented in UML. We formalized the transformation system as a triple graph grammar, a special case of graph rewriting. We argue in this paper that using this well-defined formal procedure opens up the way for verifying the transformation system, synchronizing code and formal documentation, and executing state machine models among many other possible use cases. We also provide an example transformation system and demonstrate its application in action on a small Erlang state machine. We also present our evaluation of our full system implementation tested on real world Erlangstate machines.
... The triple graph rules correlate two graphs through a third graph. These rules can serve to (formally) relate two types of models, to transform a model of one type into another, to compute the correspondence between two existing models, or to maintain the consistency between the two types of models (Kindler and Wagner, 2007). In our research, we adopt triple graph grammars to formally relate IFC and CityGML, both semantically and geometrically, and to transform a BIM model, expressed as an IFC graph, into a CityGML model expressed as a GML graph. ...
A triple graph grammar approach is adopted as a formal framework for semantic and geometric conversion of IFC models into CityGML Level of Detail 3/4 building models. The triple graph grammar approach supports a semantic mapping from IFC to CityGML, the generation of conversion routines from this mapping, and an incremental approach to achieving a "complete and near-lossless" mapping. The objective of this approach is the development of a methodology and algorithms to automate the conversion of Building Information Models into CityGML building models, capturing both geometric and semantic information as available in the BIM models, in order to create semantically enriched 3D city models that include both exterior and interior structures.
... Chaque pattern trouvé est remplacé dans le modèle cible par une autre structure d'élément. Techniques : Triple Graph Grammars [114], EMF-IncQuery [115], [116], Acceleo 3 37 , QVT-Relation [117]. -Approche impérative [118] : Elle parcourt le modèle source dans un certain ordre et lors de ce parcours le modèle cible est généré. ...
L'organisation classique en silos disciplinaires des industries atteint ses limites pour maîtriser la complexité. Les problèmes sont découverts trop tard et le manque de communication entre les experts empêche l'émergence précoce de solutions. C'est pourquoi, il est urgent de fournir de nouvelles approches collaboratives et des moyens d' interactions entre les disciplines d'ingénierie, au début et tout au long du cycle de développement. Dans ce contexte, nous avons étudié l'approche synchronisation de modèles entre deux domaines d'ingénierie : la conception d'architecture de systèmes et la sûreté de fonctionnement. Elle a pour but de construire et maintenir la cohérence entre les modèles.Ces travaux proposent, étudient et analysent une démarche collaborative de synchronisation de modèles. Ils tiennent compte des contextes d’études, des processus, des méthodes appliqués et des points de vue produits par les ingénieurs. Les contributions répondent à des problématiques au niveau des pratiques, des concepts, de la mise en œuvre, des applications et l’implémentation de la synchronisation de modèles.
... While some model transformation techniques were mentioned earlier, there are several interesting works which appear to be pushing the boundaries of what is currently implemented in MBSE tools. For example, there is an mathematical connection as can be seen by noting in Ref. 35 that triple graph grammars are formalized through category theory; from category theory to relational databases as mentioned in Ref. 58; and finally to the relational orientation methodology of Ref. 4. The interconnectedness of these mathematical techniques of these subjects may be good news for MBSE languages. For example, UML is known to be formalizable in terms of category theory. ...
... Program refactoring advocates an idea of transforming one program into another which holds the same external behaviors as the original program [8], [18], [21], meanwhile few refactorings support bi-directional transformations. Schürr has proposed triple graph grammars [26] which extend the original pair graph grammar approach [25] to specify the interdependencies between graph-like data structure, and applied it to define fine-grained m-to-n inter-graph relationships between program representations (e.g., abstract syntax tree and control flow graph) [14]. However, there still remains a difficulty about how to transform two programs bidirectionally. ...
Due to various considerations, programmers often need to backtrack their code. Furthermore, as the most recent edit may not be the wrong edit, programmers sometimes have to backtrack their code for arbitrary edits, which is referred as selective undo in this paper. To meet the needs, researchers have proposed various approaches to support selective undo. However, to the best of our knowledge, these approaches can support only simple edits, and cannot handle refactoring, although most code editors already provide various refactoring actions. Indeed, it is challenging to support selective undo for refactoring, since multiple code elements and complicated actions can be involved. In this paper, we present a novel approach that leverages Bidirectional Transformation (BX) to support selective undo for refactoring. We evaluate our approach on a recent refactoring tool that transfers enhanced for loops to lambda expressions. Our results show that our approach achieves an accuracy of up to 89%.
