GMF: A Model Migration Case for the Transformation Tool Contest

Using a real-life evolution taken from the Graphical Modeling Framework, we invite submissions to explore ways in which model transformation and migration tools can be used to migrate models in response to metamodel adaptation.

💡 Research Summary

The paper presents a concrete model migration case for the Transformation Tool Contest (TTC) 2011, built around the evolution of the Eclipse Graphical Modeling Framework (GMF). GMF is a widely used open‑source framework that supports model‑driven development of diagram editors on top of EMF (Eclipse Modeling Framework) and GEF (Graphical Editing Framework). It follows a classic Model‑Driven Architecture (MDA) approach: a domain model expressed in Ecore is used to generate a set of auxiliary models – a graphical definition model, a tooling definition model, and a mapping model – which together drive the generation of a fully functional diagram editor.

During the evolution from GMF version 1.0 to 2.1 the “GMF Graph” metamodel, which describes the visual appearance of the generated editor, was changed. The original metamodel contained a reference called referencingElements that linked Figure instances to the DiagramElements that used them. This reference made figure reuse cumbersome and was only needed by the code generator to decide whether to create accessors for nested figures. In version 2.1 the reference was removed and two new concepts were introduced: FigureDescriptor and ChildAccess. FigureDescriptor abstracts a reusable figure, while ChildAccess makes the relationship between a parent figure and its nested child explicit. This redesign simplifies figure reuse, clarifies the model structure, and reduces the amount of boilerplate code required in generated editors.

The authors provide a reference migrator implemented in Java that reads a model conforming to the old metamodel and produces a model conforming to the new one. The migration logic is publicly available, and the version‑control repository also contains a set of test models for both versions, enabling participants to verify the correctness of their solutions against a trusted baseline.

The core task of the contest is to implement the migration using any model transformation or migration tool of the participant’s choice. Submissions are judged according to four criteria:

1. Expressiveness – Does the language allow the migration to be described declaratively, or does it force the author to write imperative Java‑style code? Tools that automatically copy unchanged elements (e.g., Epsilon Flock, Sprinkle) score higher.
2. Correctness – Does the transformation produce exactly the same result as the reference Java migrator for all supplied test models? The output must be semantically equivalent, not merely syntactically similar.
3. Conciseness – How many lines of transformation code are required? Ideally the size of the transformation should be proportional to the number of metamodel differences, not to the total size of the metamodels.
4. Maintainability – Is the transformation easy to read, understand, and modify? This includes clear naming, modular structure, and the ability to extend the migration when future metamodel versions appear.

Two extensions increase the difficulty and broaden the evaluation scope.

• Multi‑File Models – GMF permits models to be split across several files to improve modularity. A migration must preserve this modularization, keeping the same file boundaries and import relationships after transformation. Test models that are distributed over multiple files are provided for this purpose.

• GMF Map Metamodel – The “GMF Map” metamodel defines the structure of mapping models that connect graphical definitions and tooling definitions to the domain model. It has also evolved from version 1.0 to 2.1, but its migration is conceptually simpler than that of GMF Graph. However, it introduces two additional challenges: (a) the Map metamodel references other metamodels, so a migration must preserve cross‑model references; (b) the Map metamodel has undergone three releases, requiring the transformation to detect the source version and apply a chain of migrations to reach the latest version. This tests a tool’s ability to compose transformation pipelines (as discussed in von Pilgrim et al.).

The paper situates this case within the broader landscape of model migration research. It reviews manual specification approaches (Sprinkle, MCL, Epsilon Flock), operator‑based approaches (Ecoral, COPE), and metamodel‑matching approaches (Cicchetti et al., AML). By using a real‑world, well‑documented evolution from an established open‑source project, the authors provide a realistic benchmark that goes beyond synthetic examples. The case also builds on previous TTC migration cases (e.g., the 2010 case) but introduces a scenario where most of the metamodel stays unchanged, thereby reflecting the typical situation in practice where migrations are incremental rather than wholesale rewrites.

In summary, the paper delivers:

• A detailed description of the GMF Graph metamodel change (removal of referencingElements, addition of FigureDescriptor and ChildAccess).
• Access to the original and evolved metamodels, a Java reference migrator, and a suite of test models (including multi‑file variants).
• A clear set of evaluation criteria that address both technical adequacy (expressiveness, correctness) and software‑engineering qualities (conciseness, maintainability).
• Two extension tasks that probe a tool’s handling of modular model files and of chained migrations across multiple metamodel versions.

The case thus serves as a comprehensive, reproducible benchmark for the model transformation community, encouraging the development of tools that can express complex migrations declaratively, handle modularization, and support transformation chaining—all essential capabilities for maintaining large‑scale model‑driven engineering projects in the face of continual metamodel evolution.