We present a solution to the Round-Trip Migration case of the Transformation Tool Contest 2020, based on the Henshin model transformation language. The task is to support four scenarios of transformations between two versions of the same data metamodel, a problem inspired by the application scenario of Web API migration, where such a round-trip migration methodology might mitigate drawbacks of the conventional “instant” migration style. Our solution relies on Henshin's visual syntax, which seems well-suited to capture the problem on an intuitive level, since the syntax is already similar to the scenario illustrations in the case description. We discuss the five evaluation criteria expressiveness, comprehensibility, bidirectionality, performance, and reusability.
APIs may change over time. Implementing API changes in an instant usually leads to severe complications, as developers of client software need to rapidly respond to such changes. A desirable alternative is a round-trip migration system that provides support for several API versions in parallel, while internally managing the data in such way that consistency is ensured.
To study how transformation tools may be an enabling
technology for such a system, this problem is the subject
of a case in the 2020 edition of TTC, called Round-Trip
Migration of Object-Oriented Data Model Instances [
In this paper, we present a solution to the case based on
the Henshin model transformation language [
Henshin provides an expressive visual syntax that aims
to support usability during transformation development
[
The solution comprises a set of Henshin rules and units, as well some Java-based glue code. The reason for having the glue code is to establish the connection to the benchmark framework by implementing the provided task interface (constant over the diferent scenarios). The solution contains 8 modules (one per scenario and case), encapsulating rules and units. For scenarios 1–3, each module contains 2 rules, one for forward and one for background migration. For scenarios 4, each module contains 2 units, each orchestrating 4 rules (one of them reused). The full solution and setup instructions are available at https://github.com/dstrueber/ttc2020. (a) Scenario 1, 1-2-1 case. (b) Scenario 1, 2-1-2 case.
The solution for scenario 1 comprises four rules, shown in Figure 2 shows two out of the four rules for scenario 2, Fig. 1: two for both directions, one for migration and one capturing the 1-2-1 case (for symmetry reasons, for back-migration. Each rule has a name and a parame- the other two rules are identical). In attribute calculater list; parameters have a name and one of the directions tions, Henshin supports the use of JavaScript expressions, in, out, var. In and out parameters are passed into and including standard library objects such as Date, as we use out of the the rule from the usage context (in our case, to specify the conversion between birth dates and age. the Java-based glue code), var parameters (variables) are During execution, JavaScript expressions are evaluated used internally to propagate information between difer- using the Nashorn JavaScript engine. ent parts of the rule. Each rule comprises a number of preserve elements (shown in gray), specifying the con- 2.3. Scenario 3: declare field text for creations, and create elements (shown in green), specifying newly created elements. For example, the optional/mandatory. top migrate rule specifies a person from metamodel 1 as Figure 3 shows two out of four rules for scenario 3, capcontext for the creation of a new person based on meta- turing the 1-2-1 case. Again, we rely on Henshin’s model 2, obtaining the same name and the age value of -1. capability of using JavaScript calculations in attribute valThe migrateBack rule for the 2-1-2 case requires a ues. In the migrateBack rule, we use the ternary operator trace person as a source for the age value. The glue code to check if the name of the provided person object is null, for the previously applied migrate rule ensures that this and specify diferent calculation outcomes for both cases. object is available and can be passed into migrateBack. The 2-1-2 case (not shown) is largely similar; the
A usability limitation in this particular scenario (in- main diference is that the migrate rule includes a hanvolving two metamodels that, from the user’s perspective, dling of empty strings, in the same way that the shown are actually versions of the same metamodel) is that there migraterules handles the null case. is no visual distinction between elements from diferent metamodels. This issue is mitigated by the use of names 2.4. Scenario 4: multiple edits. (e.g., instance1 and instance2, referring to instances from 1 and 2) as well as the coloring of separate actions (preserve, create).
a design space of possible solutions. The rationale of our solution is to illustrate the reuse capabilities of Henshin, as requested in the case description. Still, we notice an inherent trade-of between reuse, simplicity and performance. The granularity of reuse in this case is so fine
that the price of reuse appears high: Compared to a
solution without reuse (capturing the edits in a single rule),
the specification is much larger and therefore harder to We discuss our solution in the light of the five evaluation
understand and less eficient to execute. criteria from the case description [
Figure 4 shows the implementation of the migrate step Expressiveness. The assessment of expressiveness is
in the 1-2-1 direction, comprising a sequential based on the number of passing test cases: the more test
unit that invokes four rules – three of them presented cases a solution covers, the more expressive it is.
Accordwith the unit, one of them reused from Scenario 2. (For ing to this criterion, the present solution is maximally
reading convenience, the rule from Scenario 2 was actu- expressive, since it passes all test cases.
ally copied and included into the Scenario 4
transformation file, but it would be possible to maintain an actual Comprehensibility. With our solution, we aimed at
reference as well—using EMF’s concept of remote refer- providing a primarily declarative solution. We achieved
ences.) The unit produces an instance of a 2 container this goal by specifying all parts of the change logic using
object from an instance of a 1 container object, and Henshin’s declarative rule and control flow concepts. In
also has four internal var parameters. The order of the addition, our solution includes some glue code, written
rule invocations is specified in an activity-diagram-like in Java, to implement the provided Task interface.
notation. Data flow is specified by passing parameters
Bidirectionality. Our solution (like any solution
passbetween rule invocations (questions marks refer to vari- ing all test cases) is inherently bidirectional, since it
supables, which do not have to be set from the context). Rule ports transformations in both directions. Still, Henshin
getObject1 fetches the person and dog objects from the does not provide dedicated support for automatically
gencontainer. Rules task2_migrate and dog_migrate produce erating the transformation in either direction, and hence,
the migrated objects. Rule connectMigrated2 connects leaves the efort for bidirectionality implementation to
the migrated objects with a reference and encapsulates the user. An extension of Henshin with dedicated support
them in a container, which is yielded as output. for bidirectionality exists in an early stage [
The solution for migrateBack and both steps in the 2-1-2 direction look largely similar. A small addi- Performance. Figure 5 shows the execution time data tional sophistication is that migrateBack for 1-2-1 from running the performance test on a dual-core i7requires a copy (a.k.a. trace) of the previously migrated 6600U CPU Ubuntu Linux system with 16 GB RAM. We dog instance, which we implement in a similar manner observe a large slowdown, by two orders of magnitude, as in the 2-1-2 case of scenario 1. compared to the Java reference implementation. This
Total Transformation Runtime
Furthermore, it can be emphasized that the Java-based glue code for implementing the task interface is constant over the diferent scenarios. Even though scenario 4 is the most complex scenario by far, we were able to fully reuse the glue code developed for scenarios 1–3 without further modifications. 0
No. of Repetitions 250000 500000 750000 1000000 1250000 1500000 1750000 2000000
slowdown is to be expected due to the overhead of
Henshin’s generic matching engine, and the decision to use a
deliberately ineficient implementation (in favor of reuse)
in the most complicated scenario (scenario 4).
Re-usability. Henshin’s composite units support the
specification of a control flow. In scenario 4, we use this
feature to reuse rules originally specified for the
implementation of scenario 2. Doing so, we enable reuse by
following a suggestion from the case description:
"delegating the migration of the referenced Person instances to
migration functions which have been already defined." [
The trade-of related to reusability vs.
simplicity/performance motivates further work on composition
of transformation systems: The complicated specification
of units and rules in scenario 4 could be translated into
a single rule, which might both increase readability and
execution performance. While there are various works
on composition of rules from smaller parts [
Dominguez for providing an initial version of the performance comparison figure.