In this paper, we describe the language and features of our graph transformation tool, GReAT.We begin with a brief introduction and motivation, followed by an overview of the actual language, the modeling framework, and the tools that were written to support transformations. Finally, we compare GReAT to other similar tools, discuss additional functionality we are currently implementing, and describe some of our experiences with the tool thus far

Balasubramanian, Daniel

Karsai, Gabor

Narayanan, Anantha

van Buskirk, Christopher

English

Electronic Communications of the EASST (European Association of Software Science and Technology)

Electronic Communications of the EASSTVolume 1 (2006)Proceedings of theThird International Workshop on Graph Based Tools(GraBaTs 2006)The Graph Rewriting and Transformation Language: GReATDaniel Balasubramanian, Anantha Narayanan, Chris vanBuskirk, and Gabor Karsai8 pagesGuest Editors: Albert Zu¨ndorf, Daniel Varro´Managing Editors: Tiziana Margaria, Julia Padberg, Gabriele TaentzerECEASST Home Page: http://www.easst.org/eceasst/ ISSN 1863-2122ECEASSTThe Graph Rewriting and Transformation Language: GReATDaniel Balasubramanian1, Anantha Narayanan1, Chris vanBuskirk1, and GaborKarsai11Institute for Software-Integrated Systems, Vanderbilt University, Nashville, TN 37235, USAAbstract: In this paper, we describe the language and features of our graph transfor-mation tool, GReAT. We begin with a brief introduction and motivation, followed byan overview of the actual language, the modeling framework, and the tools that werewritten to support transformations. Finally, we compare GReAT to other similartools, discuss additional functionality we are currently implementing, and describesome of our experiences with the tool thus far.Keywords: Model Transformation, Modeling Tools1 IntroductionModel transformations are a central part of the model based approach to software engineer-ing. The construction of model transformations using textual languages is time consuming,costly, and rarely has a formal foundation. Models can be considered as labeled multigraphs.Thus, model transformations can be accomplished using the techniques of graph transforma-tions [EER96]. Since graph transformations are grounded in mathematical concepts, we can usethem to formally specify the intended behavior of model transformations. The Graph Rewrit-ing and Transformation (GReAT) language is a graphical language for the specification of graphtransformations between domain-specific modeling languages (DSMLs). The rest of this paperdescribes the GReAT language and toolset, a comprehensive set of tools which can be used tospecify, debug and execute efficient graph transformations between DSMLs.2 The GReAT LanguageThe GReAT language consists of three sub-languages: the pattern specification language, thetransformation rule language, and the sequencing or control flow language. Additionally, theinput and the output languages of a transformation are defined in terms of meta-models.The meta-information of the DSMLs on either side (i.e. input or output) of the transformationis specified using UML class diagrams. Transformations also often require the ability to maintaintemporary information that may correspond to both paradigms; for instance, a transformationfrom a hierarchal state-machine language to one without hierarchy benefits from the ability tocreate temporary links between hierarchal states in the first DSML and flat states in the secondDSML. GReAT allows the users to create additional, heterogeneous class diagrams that describethe cross-domain and temporary associations. Transformations in GReAT are specified over theset of meta-models and the heterogeneous class diagrams.1 / 8 Volume 1 (2006)The Graph Rewriting and Transformation Language: GReATFigure 1: An example GReAT rule2.1 Pattern SpecificationGReAT uses the UML classes defined in the input meta-models to specify patterns that will bematched in the host graph. A pattern graph consists of nodes and edges, and each node andedge must have a corresponding class and association element in the class diagram of the inputmeta-model. For instance, the user might draw a simple pattern that selects all elements of type‘A’ in a container class that are associated with elements of type ‘B’ in the same container, asthree classes (container, A, B), two containment relations, and one association. In the event that apattern requires that a given element not be present in the matching subgraph, the user can set thepattern cardinality on the containment association of this element to zero, effectively providinga negative application condition.2.2 Transformation RuleThe basic transformation entity in GReAT is a production rule. A rule in GReAT has the follow-ing elements:• Pattern: a graph with pattern vertices and edges,• Actions: a mapping of pattern vertices and edges to the set of actions {Bind, CreateNew,Delete},• Input interface: a set of distinct input ports that can receive graph objects from previousrules,• Output interface: a set of distinct output ports that will transfer graph objects to the nextrule,• Guard: an expression that evaluates true or false and determines whether a rule actionsshould be executed for the matched subgraph,• Attribute mapping: code that is executed for each valid match to generate the values ofedge and vertex attributes,Proc. GraBaTs 2006 2 / 8ECEASSTFigure 2: Rule execution in GReAT• Match condition: a flag determining whether all matches are executed, or any one, non-deterministically chosen match is executed.Figure 1 shows a simple transformation rule in GReAT, with a simple pattern. The objects,“House” and “PurchaseOrder” are bound to the input ports, which means that they are received asinput from a rule that has already been executed. These bound objects form the initial context forthe rule for subsequent pattern searches, which means that we search for the objects, “Room1”,“Room2”, and “AdjacentTo” inside this “House” object. Once these elements are found, wecheck the guard condition, “HasDoor”, which contains procedural (C++) code that can accessthe attributes of objects. If the guard condition is true, then we create a new “OrderItem” objectinside the bound object “PurchaseOrder”, and finally we execute the procedural code containedin the “AttributeMapping” block.It is important to note that in GReAT both the LHS and RHS of a transformation rule arespecified together in a composite pattern. The objects marked as “Bound” can be considered asthe LHS of the rule, and the objects marked “CreateNew” or “Delete” are the RHS. This is incontrast to some other popular approaches in the field, in which the LHS and RHS are specifiedseparately.The execution of a production rule assumes that the input interface is bound to some nodes inthe graph. In the case of the first, top-level rule, the user selects which elements from the inputand output graphs are passed in. These bindings for the input (and later for the output) ports forma packet. When a rule fires, the binding is established, and then a pattern matching algorithmfinds a matching subgraph within the connected neighborhood of the bound nodes. Frequentlymany such matches are generated, each match forming a consistent binding for all edges andnodes in the pattern graph of the rule. These matches will generate packets via the output portsfor downstream rules as described below.Figure 2 gives an overview of the steps of a single rule execution. Two input packets arrive in(a). The rule execution begins with the first packet. The rule first binds all incoming objects from3 / 8 Volume 1 (2006)The Graph Rewriting and Transformation Language: GReATFigure 3: Sequence of rulesthe first packet (containing Root R and Parent P1). Suppose that in the input model, P1 containstwo children, C11 and C12. The intermediate packets produced for these two matches are shownin (b). At this point, a new Actor is created for each match. If a guard had been present, onlythose matches for which the guard condition evaluated to true would have been retained. Therule binds the Root and the Child objects to the output ports. Part (c) shows the output packetsgenerated by this binding of graph objects to output ports. These packets will be sent to the nextrule after all the input packets to this rule have been processed. Parts (d) and (e) show the rest ofthe execution of this rule for the remaining input packet, with part (e) showing the output packetscreated by this rule.2.3 Control FlowWe have seen how a single rule executes in GReAT. GReAT allows the construction of largertransformations using the following control flow concepts:1. Sequencing - Rules can be coupled with other rules to execute sequentially. Figure 3 showstwo rules in sequence. Rule 1 executes first, consuming all its input packets. Rule 2 firesafter Rule 1 has completed producing all its output packets.2. Non-determinism - When rules are not connected sequentially, they can be connected inparallel, and the order of rule execution will be non-deterministic.3. Hierarchy - Rules can be composed hierarchically using Blocks. Blocks can contain prim-itive rules or other blocks. There are two types of blocks in GReAT: Block and ForBlock.The only difference in their semantics is that in the ForBlock, each input packet passesthrough all the contained rules before the next input packet is passed, while in a Block allpackets are consumed by the first rule, then the generated packets are passed to the nextrule, and so on.4. Recursion - The output of rules can be connected to inputs of blocks higher in the contain-ment hierarchy, which results in the output packets being sent back as input packets to thepreceding rules (in effect, recursively activating the rules for a subgraph).5. Conditional execution - GReAT offers special blocks called Test/Case blocks for condi-tional execution. Test blocks can have multiple Case blocks, and multiple outputs. Theoutput packets are placed on the output ports determined by the Case that matches suc-cessfully.Proc. GraBaTs 2006 4 / 8ECEASST3 Tools3.1 Modeling FrameworkGReAT is not a standalone tool; rather, it is used in conjunction with the Generic ModelingEnvironment (GME) [Led01]. However, once a transformation has been developed, a standaloneexecutable can be executed outside of GME. The typical modeling and transformation processproceeds as follows.1. A GReAT transformation project is created in GME, the UML meta-models for the inputand the target of the transformation are attached, and the heterogeneous class diagramscreated.2. The transformation rules are specified by drawing patterns of UML classes from elementsof the meta-models, and the rules are sequenced to form a transformation program.3. The transformation is executed. Depending on the required level of performance and ma-turity of the transformation, this can be done using one of three supplied tools: the GR-Engine, the GR-Debugger, or the code produced by the GR-Code Generator.3.2 Execution EnginesThe GR-Engine provides the fastest way of testing transformation prototypes. The transforma-tion rules are interpreted by the GR-Engine, and thus the level of performance is not as high aswith compiled code. The GR-Engine is often used early in the development of a transformationso that results can be tested quickly.Just as the need for debuggers arises with complex programs written in traditional proceduralprogramming languages, it often becomes very helpful to have the ability to debug graph trans-formations as well. The GR-Debugger is built on top of the GR-Engine, and offers the typicalfeatures found in traditional debuggers, e.g., breakpoints, stepping in/over rules, etc. A graphicalwindow displays a list of the transformation rules, and the user can set breakpoints at any ruleand step through the transformation rule by rule, allowing them to see the results of a particularrule or see what elements are being matched at any given time. Figure 4 shows the GR-Debugger.While both the GR-Engine and GR-Debugger rely on an interpreter to execute the transforma-tion rules, the Code Generator produces the corresponding transformation code in C++ using amodel data structure library called UDM [MBL+03]. Our empirical studies have shown that inmost cases, this results in a 10x-100x improvement in transformation execution time [VAS04].4 ComparisonOther graph transformation tools include VIATRA, AGG, Fujaba, and PROGRES. [MGVKar]provides a good comparison and feature summary of the first three, along with GReAT, in theframework of the taxonomy developed in [MCG05].Fujaba (From UML to Java And Back Again) is geared toward the creation of Java code fromUML models in such a way that the UML models can be reverse engineered from the generatedJava code by reversing the transformation. Fujaba uses a technique known as story-driven mod-eling, in which an activity diagram specifies the order in which the graph transformation rules5 / 8 Volume 1 (2006)The Graph Rewriting and Transformation Language: GReATFigure 4: GReAT Debuggershould be applied. GReAT can also be used to generate non-trivial code from models [NKS+05].However, transformations in GReAT are unidirectional, and a reverse transformation must bemanually written.AGG (Attributed Graph Grammar System) is a general purpose graph transformation tool usedin high level Java applications. It uses an algebraic approach to graph transformations. In AGGa transformation can be performed only within a single domain, while GReAT allows heteroge-neous transformations. AGG also relies on a graph grammar approach rather than programmedgraph transformations. Using this method, AGG starts with an initial input graph, and then ap-plies all applicable graph productions in parallel. Thus, this approach may not be viable if theuser requires explicit control over the rule sequencing.PROGRES (PROgrammed Graph REwriting Systems) is a another general purpose transfor-mation tool. It is generally used for prototyping process modeling and reengineering tools. PRO-GRES combines UML-like class diagrams and graph re-write rules which operate on these dia-grams. Once a transformation is specified, it can be translated into C and Tcl/Tk code for rapidprototyping. GReAT transformations can be translated into C++ code, but this is mainly done toincrease the performance of the transformation.VIATRA (VIsual Automated model TRAnsformation) is primarily considered a model verifi-cation tool that relies on graph transformation techniques, especially in the area of dependabilityanalysis, although it can also be used areas of model-driven development, such as code gen-eration. Transformations in VIATRA are specified in a way similar to GReAT. Graph patternsare defined from a collection of model elements, and then assembled into complex transforma-tions by using abstract state machine rules. Novel features of VIATRA include generic graphProc. GraBaTs 2006 6 / 8ECEASSTtransformation rules, in which type parameters can be passed into a rule, making a transfor-mations easy to reuse between domains. Currently, GReAT supports only a limited form oftype-parameterization of rules through the use of UML inheritance. For instance, instead ofspecifying a specific child class in a transformation, one could match the base class, and thenfilter the specific results using guard conditions, which are written in C++.Recent additions to GReAT, such as the ability to sort the results of pattern matches, and thedistinguished merging of matches (both described in [VNS+05]), are not directly supported inany of the aforementioned tools, although one could possibly implement them with a sequence ofrules. We believe that adding these features gives support for quickly executing common tasks,and greatly improves the usability of our tool.5 Conclusions and Future WorkWe have tested the usability and scalability of GReAT with several non-trivial transformations,including a transformation that generates C code from Simulink models [NKS+05], and a trans-formation that generates real-time E-Code from a Giotto model [Sze05]. In both cases, we wereable to express the transformation using the existing features of GReAT, although we also foundthat additional features would make both transformations easier to define. Thus, we implementedsome of these additional features, such as support for sorting the results of pattern matches andsupport for global objects [VNS+05].Currently, we are working on implementing novel capabilities, such as the ability to move a(containment) hierarchy of objects contained by one element to be contained by another element.However, this feature requires a precise definition of the semantics of moving an object’s con-nections and children objects, and thus does not have a straightforward solution. The challengeis to decide on an implementation that will make the feature as powerful as possible while stillgiving the user a high degree of freedom.In general, we have found that GReAT is a highly usable tool for quickly specifying modeltransformations. In particular, we believe that our explicit rule sequencing saves the user fromdealing with confluence considerations, and our ability to operate on any number of input/outputmodels during a transformation can save the user from having to define multiple transformations[AKL03]. We are continuing our research to determine what constructs and operations shouldbe directly supported by the language so that it is sufficiently expressive, yet still simple enoughto be learned and used efficiently.Bibliography[AKL03] A. Agrawal, G. Karsai, A. Ledeczi. An end-to-end domain-driven software develop-ment framework. In OOPSLA ’03: Companion of the 18th annual ACM SIGPLANconference on Object-oriented programming, systems, languages, and applications.Pp. 8–15. ACM Press, New York, NY, USA, 2003.doi:http://doi.acm.org/10.1145/949344.9493477 / 8 Volume 1 (2006)The Graph Rewriting and Transformation Language: GReAT[EER96] G. Engels, H. Ehrig, G. Rozenberg(eds.). Special Issue on Graph TransformationSystems. In Fundamenta Informaticae, Vol. 26, No. 3/4, No. 1/2. 1996.[Led01] A. Ledeczi. Composing Domain-Specific Design Environments. In Computer. 2001.[MBL+03] E. Magyari, A. Bakay, A. Lang, T. Paka, A. Vizhanyo, A. Agrawal, G. Karsai. UDM:An Infrastructure for Implementing Domain-Specific Modeling Languages. In The3rd OOPSLA Workshop on Domain-Specific Modeling, OOPSLA 2003. 2003.[MCG05] T. Mens, K. Czarnecki, P. V. Gorp. A Taxonomy of Model Transformations.In Bezivin and Heckel (eds.), Language Engineering for Model-Driven SoftwareDevelopment. Dagstuhl Seminar Proceedings 04101. Internationales Begegnungs-und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany, 2005.<http://drops.dagstuhl.de/opus/volltexte/2005/11> [date of citation: 2005-01-01].[MGVKar] T. Mens, P. V. Gorp, D. Varro, G. Karsai. Applying a Model Transformation Taxon-omy to Graph Transformation Technology. (To Appear).[NKS+05] S. Neema, Z. Kalmar, F. Shi, A. Vizhanyo, G. Karsai. A visually-specified codegenerator for Simulink/Stateflow. In IEEE Symposium on Visual Languages andHuman-Centric Computing. 2005.[Sze05] T. Szemethy. Case Study: Model Transformations for Time-Triggered Systems. InInternational Workshop on Graph and Model Transformations (GRaMoT). 2005.[VAS04] A. Vizhanyo, A. Agrawal, F. Shi. Towards Generation of High-performance Trans-formations. In Generative Programming and Component Engineering, Vancouver,Canada. 2004.[VNS+05] A. Vizhanyo, S. Neema, F. Shi, D. Balasubramanian, G. Karsai. Improving the Us-ability of a Graph Transformation Language. In International Workshop on Graphand Model Transformations (GRaMoT). 2005.Proc. GraBaTs 2006 8 / 8

The Graph Rewriting and Transformation Language: GReAT

https://journal.ub.tu-berlin.de/eceasst/article/download/89/82

The Graph Rewriting and Transformation Language: GReAT

Abstract

Similar works

Full text

Available Versions

Electronic Communications of the EASST (European Association of Software Science and Technology)