The project has been created.
Framework for Ecore model adaptation and instance migrationEdapt 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.
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.
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.
More specifically, Edapt will have to define APIs and provide implementations for the following functionality which is common to both approaches:
In addition, the operation-based approach requires the following functionality.
In addition, the difference-based approach requires the following functionality:
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.