Solving the TTC 2011 Reengineering Case with GReTL

This paper discusses the GReTL reference solution of the TTC 2011 Reengineering case. Given a Java syntax graph, a simple state machine model has to be extracted. The submitted solution covers both the core task and the two extension tasks.

💡 Research Summary

The paper presents a complete reference solution for the TTC 2011 Reengineering case using the Graph Repository Transformation Language (GReTL). The task is to derive a simple state‑machine model from a Java syntax graph that represents an abstract syntax tree (AST) of Java source code. The authors describe how GReTL’s declarative graph‑transformation constructs are employed to locate state classes, extract transitions, and enrich those transitions with triggers, guards, and actions.

The input model is a graph generated by Eclipse JDT, where nodes correspond to Java constructs such as ClassDeclaration, MethodDeclaration, VariableDeclaration, and MethodInvocation, while edges encode containment, call, and reference relationships. The transformation proceeds in several clearly defined phases. First, a pattern match selects all classes that either bear the name “State” or implement a designated interface; each matched class becomes a vertex in the target state‑machine graph. Second, the tool follows paths from a method declaration through a call edge to another class declaration, thereby identifying source‑state, target‑state, and the method name that serves as the transition trigger. GReTL’s path operator enables this multi‑step navigation in a single expression.

The core case is solved with a handful of GReTL statements: match to filter nodes, createVertex to instantiate state vertices, createEdge to generate transition edges, and attribute assignments to copy identifiers and trigger names. The two extension tasks are handled by additional pattern matches. For guards, the transformation searches for IfStatement nodes inside the method body, extracts the Boolean condition subtree, and stores it as a string attribute on the transition. For actions, it looks for specific API calls (e.g., logging or notification methods) and records the call details as an action attribute. Both extensions make extensive use of GReTL’s functional operators such as filter, collect, and groupBy.

Further extensions—simultaneous transitions and multiple triggers—are expressed by grouping method invocations that target several states (groupBy) and by constructing a list of trigger names (union). The authors emphasize that these sophisticated patterns remain concise because GReTL abstracts away low‑level graph traversal code.

The paper provides the full GReTL script, an XMI export of the resulting state‑machine model, and performance measurements. Even for graphs containing several thousand nodes and edges, the transformation completes within a few seconds and consumes modest memory, demonstrating GReTL’s scalability.

In the discussion, the authors highlight GReTL’s strengths: a high‑level, declarative syntax that makes transformation logic easy to read and maintain, rich built‑in graph navigation primitives, and seamless integration with model repositories. They also note limitations, such as the relatively small set of built‑in operations, which sometimes necessitates custom functions or external preprocessing for complex condition parsing. Future work is suggested in the form of extending the language’s operator set, adding model‑validation capabilities, and improving interoperability with other model‑transformation frameworks.

Overall, the paper convincingly shows that GReTL can be used to solve realistic model‑reengineering problems, offering a clear, reproducible solution for the TTC 2011 case and serving as a valuable reference for practitioners interested in graph‑based model transformations.