Title: Solving the TTC 2011 Reengineering Case with GrGen.NET
ArXiv ID: 1111.4751
Date: 2011-06-01
Authors: Sebastian Buchwald, Andreas Hielscher, Gernot Starke
📝 Abstract
The challenge of the Reengineering Case is to extract a state machine model out of the abstract syntax graph of a Java program. The extracted state machine offers a reduced view on the full program graph and thus helps to understand the program regarding the question of interest. We tackle this task employing the general purpose graph rewrite system GrGen.NET (www.grgen.net).
💡 Deep Analysis
Deep Dive into Solving the TTC 2011 Reengineering Case with GrGen.NET.
The challenge of the Reengineering Case is to extract a state machine model out of the abstract syntax graph of a Java program. The extracted state machine offers a reduced view on the full program graph and thus helps to understand the program regarding the question of interest. We tackle this task employing the general purpose graph rewrite system GrGen.NET (www.grgen.net
).
📄 Full Content
As GrGen.NET is a general purpose graph rewrite system and not a model transformation tool, we do not support importing Ecore metamodels directly. Instead, we supply an import filter generating an equivalent GrGen-specific graph model (.gm file) from a given Ecore file by mapping classes to GrGen node classes, their attributes to corresponding GrGen attributes, and their references to GrGen edge classes. Inheritance is transferred one-to-one, and enumerations are mapped to GrGen enums. Class names are prefixed by the names of the packages they are contained in to prevent name clashes; the same holds for references which are prefixed by their node class name. Afterwards the instance graph XMI adhering to the metamodel described in the Ecore file thus adhering to the just generated equivalent GrGen graph model is imported by the filter into the system to serve as the host graph for the following extractions, i.e. transformations. The entire process is shown in Figure 1 above.
The transformation is done in two steps, the first creates the states of the state machine, and the second inserts the transitions in between. Each step consists of the application of one rule (utilizing a subpattern) on all matches found, giving a direct correspondence between coding conventions and rules.
Let us start with a short introduction into the syntax of the basic constructs of the rule language: Rules in GrGen consist of a pattern part specifying the graph pattern to match and a nested rewrite part specifying the changes to be made. The pattern part is built up of node and edge declarations or references with an intuitive syntax: Nodes are declared by n:t, where n is an optional node identifier, and t its type. An edge e with source x and target y is declared by x -e:t-> y, whereas –> introduces an anonymous edge of type Edge. Nodes and edges are referenced outside their declaration by n and -e->, respectively. Attribute conditions can be given within if-clauses.
The rewrite part is specified by a replace or modify block nested within the rule. With replacemode, graph elements which are referenced within the replace-block are kept, graph elements declared in the replace-block are created, and graph elements declared in the pattern, not referenced in the replacepart are deleted. With modify-mode, all graph elements are kept, unless they are specified to be deleted within a delete()-statement. Attribute recalculations can be given within an eval-statement. These and the language elements we introduce later on are described in more detail in our solution of the Hello World case [2], and especially in the extensive GrGen.NET user manual [1]. Now let us have a look at the code to create the states (here and in the following rules the prefixes from name mangling were removed due to space constraints): We search for the abstract class of name State as starting point and create the state machine which will receive the states and transitions found. The real work is done in a subpattern CreateStates, of which an instance es is declared and thus searched from the found stateClass on; or better in the rewrite part of this subpattern, which is applied with rule call syntax passing the just created State-Machine node: The subpattern searches a class directly extending the given parent class passed as a parameter, i.e. it descends one subtyping step downwards in the type hierarchy. It matches into breadth with the iterated construct to get all such extending classes; the iterated matches all instances of its contained pattern which can be found in the host graph. Then the subpattern matches further into depth by call-ing itself recursively with the just matched extending class as parameter, this way we cover the entire type hierarchy from the parent class on. In the optional case the class is not abstract a state is created within the state machine and a link edge is created linking the state with the class (the link edges are additional helper edges introduced to store the traceability relation between source and target nodes). The optional matches the contained pattern if it is available in the host graph. The negative causes matching of the containing pattern to fail if its pattern can be found in the host graph.
The transitions are inserted with a second rule given in Figure 2 utilizing the subpattern given in Figure 3. We search for the class.Instance().activate() pattern in the graph, if found we know the target state from the class of the called method and the link between the class and the state we inserted previously. Then we search with the subpattern FindSourceState for the source state, which gets yielded1 into the def pattern element sourceState. If this was found we add a Transition in between the source state and the target state, and link it to the expressionStatement containing the method call.
The subpattern is used to recursively walk outwards from the method call to the class containing the call (recursive ascent ov
