Solving the TTC 2011 Reengineering Case with Henshin

This paper presents the Henshin solution to the Model Transformations for Program Understanding case study as part of the Transformation Tool Contest 2011.

💡 Research Summary

The paper presents a complete solution to the TTC 2011 Reengineering case using the Henshin model transformation tool, which operates directly on EMF models without creating copies. The case requires converting Java source code, represented as JaMoPP EMF models, into a simple state‑machine model. Henshin’s core concepts—left‑hand side (LHS) and right‑hand side (RHS) patterns, positive and negative application conditions (PACs and NACs), attribute calculations, and a rich set of control units (sequential, conditional, priority, counted, and amalgamation)—are leveraged to implement the transformation. The transformation starts with a top‑level sequential unit called Start, which first applies the init rule to create a StateMachine instance and to bind the Class named “State”. Three counted units are then invoked repeatedly: StatesLoop, TransitionsLoop, and ActionsLoop.

StatesLoop recursively traverses the inheritance hierarchy rooted at the “State” class. It uses a priority unit that first attempts the createState rule, which creates a State element for a non‑abstract class that has not yet been translated. A trace model (a Trace object with source and target references) records processed classes, preventing duplicate state creation. If a class cannot be translated directly, the conditional unit ProcessChildren invokes checkClassHasChild, which finds an unvisited subclass, marks it with a trace, and recurses into StatesLoop with the child class as the new context.

TransitionsLoop iterates over all translated classes and their associated ClassMethod objects. For each method, the counted unit DescendLoop (structured similarly to StatesLoop) attempts to create a transition via the createTransition rule. This rule matches an expression statement that represents a method call, extracts the source and target state names, and creates a Transition with a default action and a trigger derived from the method call context. A Trace object is also created to mark the visited expression statement, which later enables the updateActions rule to modify the action attribute of transitions that correspond to send() calls. If createTransition cannot be applied, the conditional unit TryDescending performs a single descent step (e.g., through a try‑catch block or a switch statement) and recursively invokes DescendLoop. Because Henshin lacks native list semantics, the authors simulate iteration using the trace model, effectively turning set‑based matching into a controlled traversal.

ActionsLoop contains a single rule updateActions that refines the action attribute of transitions identified as calls to send(). It matches the previously created Trace objects, updates the corresponding Transition, and removes the trace to avoid double processing.

The solution is fully visualized using Henshin’s three editors: a tree‑based editor for high‑level control flow, a complex‑rule editor for detailed LHS/RHS views, and an integrated‑rule editor that combines both. Parameter passing between units and rules is explicitly shown, enabling clear object flow throughout the transformation.

Performance measurements on a Core2Duo 2 GHz machine show execution times of less than one second for the small and medium benchmark models and approximately five seconds for the large model, demonstrating that the in‑place approach scales well for realistic code bases.

In the conclusion, the authors acknowledge two current limitations: the need for an auxiliary trace model due to the absence of list handling in Henshin, and the lack of a single, feature‑complete editor. Future work includes extending Henshin with list‑oriented control structures to eliminate trace objects and developing a unified DSL‑based editor for a smoother modeling experience. Overall, the paper illustrates how Henshin’s visual, pattern‑based language and its flexible control mechanisms can effectively address complex model‑to‑model reengineering tasks.