Edapt -- Project Proposal

The project has been created.

Framework for Ecore model adaptation and instance migration

Introduction

Edapt is an open source project proposed under the Eclipse Modeling Framework Technology (EMFT).

The project is in the Project Proposal Phase (as defined by the Eclipse Development Process) and this proposal declares its intent and scope. The proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the EMFT newsgroup.

Background

Due to their high level of abstraction, modeling languages are a promising approach to decrease software development costs by increasing productivity. Significant work in both research and practice has been invested into tool support for the initial development of modeling languages. Over the last years, the Eclipse Modeling Framework (EMF) has become the de-facto standard solution for the development of modeling languages. As modeling languages are more widely used in both academia and industry, their maintenance is gaining importance.

Even though often neglected, a language is subject to change like any other software artifact. The languages behind the Graphical Modeling Framework (GMF) for instance -- although relatively young -- have already been evolved due to technological progress or changing requirements. In EMF, a modeling language is evolved by first adjusting its Ecore model to the new requirements. Other artifacts like instances, editors, interpreters and transformations (M2M, M2T) may no longer conform to the evolved Ecore model. Manually migrating these artifacts to the evolved Ecore model is tedious and error-prone, and thus heavily hampers cost-efficient maintenance of modeling languages.

Scope

Edapt will provide an extensible framework for reducing the migration effort that results from the evolution of Ecore models. Since the number of existing instances of a successful modeling language typically outnumbers the number of editors, interpreters and transformations, instance migration effort dwarfs tool reconciliation effort. Consequently, Edapt clearly focuses on the migration of instances in the first step. However, we plan to make it extensible with respect to the migration of other artifacts like editors, interpreters and transformations. The basic idea behind Edapt is to obtain the changes between two versions of an Ecore model, and to enrich them with information about how to automatically migrate existing instances. Edapt will support a pluggable mechanism to obtain the changes between two Ecore model versions along with two examples: the operation-based and the difference-based approach.

The operation-based approach is similar to code refactoring. The developer modifies the Ecore model using predefined operations which encapsulate the adaptation of the Ecore model as well as the migration of the instances. The execution of these operations is recorded in a history which can then be used to migrate existing instances. Being fully automated, these operations thus significantly reduce the effort associated with migration. Moreover, they provide a more systematic way to adapt Ecore models, e.g. they allow the developer to better assess the impact on instances. However, not all changes can be covered by existing operations. Therefore, Edapt provides a way to manually change the Ecore model and attach information on how to migrate instances.

The difference-based approach compares two versions of an Ecore model, and evaluates the differences using EMF Compare. As opposed to the operation-based approach, this neither requires the developer to modify the Ecore model in pre-planed steps nor editor integration. Furthermore, it makes the difference based approach easily applicable to Ecore models which are not the primary artifact of modification, but are derived from other artifacts.

Both approaches complement each other: The operation-based approach allows the developer to capture the migration of instances while adapting the EMF model. While this can be more systematic, it also causes some overhead. In contrast, the difference-based approach allows the developer to enrich the changes later on with instructions on how to migrate existing. While we will provide these two approaches as examples, Edapt will be extensible with respect to other mechanisms to obtain the changes.

Description

More specifically, Edapt will have to define APIs and provide implementations for the following functionality which is common to both approaches:

  • Ecore models to specify the changes between two versions of an Ecore model and to compose these as a complete history of all versions. These models should provide means to attach migration instructions to the changes.
  • A slim runtime implementation which can be integrated into existing applications and which interprets the change models to automatically migrate old instances to the version needed by the application.

In addition, the operation-based approach requires the following functionality.

  • A way to define new operations and to extend existing ones with instructions on how to migrate other artifacts.
  • A generic user interface to offer operations to the developer and to inspect the impact of their executions.
  • A mechanism to record the operations that are executed on an Ecore model in the editor.
  • A way to re-apply the recorded operations to migrate existing artifacts which are not accessible during development.

In addition, the difference-based approach requires the following functionality:

  • A way to obtain the changes between two versions of an EMF model.

Relationship with other Eclipse Projects

  • Edapt will be built on top of EMF.
  • Edapt will allow to integrate languages for model transformation (e.g. ATL, QVT, Xtend) to specify the migration of instances.
  • Edapt will make use of the Language Toolkit (LTK) as far as possible or make contributions to it.
  • Edapt will need functionality that can be applied to refactoring of models in general.
  • Edapt will integrate with the Ecore Tools project.
  • Edapt will need EMF Compare to obtain differences between models.
  • Edapt's difference-based approach will be based on the Epatch format which is currently being contributed to EMF Compare.
  • Edapt can utilize TMF Xtext for providing textual representations of the patch format.

Organization

Mentors

  • Ed Merks (Macro Modeling, Canada)
  • Sven Efftinge (itemis AG, Germany)

Proposed initial committers

  • Markus Herrmannsdörfer (Technische Universität München, Germany)
  • Moritz Eysholdt (itemis AG, Germany)

Interested parties

  • The need for a tool supporting the evolution of EMF models has been discussed within the Modeling Symposium at the Eclipse Summit Europe 2008.
  • Ed Merks (Macro Modeling, Canada)
  • Laurent Goubet, Stéphane Lacrampe, Cédric Brun (Obeo, France)
  • Enrico Schnepel (b+m Informatik AG, Germany)
  • Michael Rudorfer (BMW Car IT, Germany)
  • itemis AG, Germany
  • Eike Stepper (Eclipse CDO Team, Germany)
  • Bernd Kolb (SAP, Germany)
  • Ersin Er (Hacettepe University)
  • Cédric Vidal (ProxiAD, France)

Code contributions

The initial code contribution will be a set of plug-ins from the COPE project (Coupled Evolution of Metamodels and Models). Visit the project's website for further information and documentation.