| <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop' | |
| $pageTitle = "Edapt -- Project Proposal"; | |
| $pageKeywords = "emf, emft, ecore, refactoring, evolution, meta model evolution, compare, diff, patch, history, model"; | |
| $pageAuthor = "Moritz Eysholdt, Markus Herrmannsdoerfer"; | |
| ob_start(); | |
| ?> | |
| <div id="maincontent"> | |
| <div id="midcolumn"> | |
| <h1>Edapt -- Project Proposal</h1> | |
| </p> | |
| <?php | |
| include_once($_SERVER['DOCUMENT_ROOT'] . "/projects/fragments/proposal-page-header.php"); | |
| generate_header("Edapt"); | |
| ?> | |
| <!-- ----- BEGIN inserted from Edapt-v*.html ----- --> | |
| <b>Framework for Ecore model adaptation and instance migration</b> | |
| <h2>Introduction</h2> | |
| <p> | |
| Edapt is an open source project proposed under the <a | |
| href="http://www.eclipse.org/modeling/emft">Eclipse Modeling Framework | |
| Technology</a> (EMFT). | |
| </p> | |
| <p> | |
| The project is in the Project Proposal Phase (as defined by the <a | |
| href="http://www.eclipse.org/projects/dev_process/">Eclipse Development | |
| Process</a>) 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 <a | |
| href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.emft">EMFT | |
| newsgroup</a>. | |
| </p> | |
| <h2>Background</h2> | |
| <p> | |
| 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. | |
| </p> | |
| <p> | |
| 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. | |
| </p> | |
| <h2>Scope</h2> | |
| <p> | |
| 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. | |
| </p> | |
| <p> | |
| 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. | |
| </p> | |
| <p> | |
| 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. | |
| </p> | |
| <p> | |
| 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. | |
| </p> | |
| <h2>Description</h2> | |
| <p> | |
| More specifically, Edapt will have to define APIs and provide implementations for | |
| the following functionality which is common to both approaches: | |
| </p> | |
| <ul> | |
| <li>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.</li> | |
| <li>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.</li> | |
| </ul> | |
| <p> | |
| In addition, the operation-based approach requires the following functionality. | |
| </p> | |
| <ul> | |
| <li>A way to define new operations and to extend existing ones with instructions on how to migrate other artifacts.</li> | |
| <li>A generic user interface to offer operations to the developer and to inspect the impact of their executions.</li> | |
| <li>A mechanism to record the operations that are executed on an Ecore model in the editor.</li> | |
| <li>A way to re-apply the recorded operations to migrate existing artifacts which are not accessible during development.</li> | |
| </ul> | |
| <p> | |
| In addition, the difference-based approach requires the following functionality: | |
| </p> | |
| <ul> | |
| <li>A way to obtain the changes between two versions of an EMF model.</li> | |
| </ul> | |
| <h2>Relationship with other Eclipse Projects</h2> | |
| <ul> | |
| <li>Edapt will be built on top of EMF.</li> | |
| <li>Edapt will allow to integrate languages for model transformation (e.g. ATL, QVT, Xtend) to specify the migration of instances.</li> | |
| <li>Edapt will make use of the Language Toolkit (LTK) as far as possible or make contributions to it.</li> | |
| <li>Edapt will need functionality that can be applied to refactoring of models in general.</li> | |
| <li>Edapt will integrate with the Ecore Tools project.</li> | |
| <li>Edapt will need EMF Compare to obtain differences between models.</li> | |
| <li>Edapt's difference-based approach will be based on the Epatch format which is currently being contributed to EMF Compare.</li> | |
| <li>Edapt can utilize TMF Xtext for providing textual representations of the patch format.</li> | |
| </ul> | |
| <h2>Organization</h2> | |
| <h3>Mentors</h3> | |
| <ul> | |
| <li>Ed Merks (Macro Modeling, Canada)</li> | |
| <li>Sven Efftinge (itemis AG, Germany)</li> | |
| </ul> | |
| <h3>Proposed initial committers</h3> | |
| <ul> | |
| <li>Markus Herrmannsdörfer (Technische Universität München, Germany)</li> | |
| <li>Moritz Eysholdt (itemis AG, Germany)</li> | |
| </ul> | |
| <h3>Interested parties</h3> | |
| <ul> | |
| <li>The need for a tool supporting the evolution of EMF models has been discussed within the Modeling Symposium at the Eclipse Summit Europe 2008.</li> | |
| <li>Ed Merks (Macro Modeling, Canada)</li> | |
| <li>Laurent Goubet, Stéphane Lacrampe, Cédric Brun (Obeo, France)</li> | |
| <li>Enrico Schnepel (b+m Informatik AG, Germany)</li> | |
| <li>Michael Rudorfer (BMW Car IT, Germany)</li> | |
| <li>itemis AG, Germany</li> | |
| <li>Eike Stepper (Eclipse CDO Team, Germany)</li> | |
| <li>Bernd Kolb (SAP, Germany)</li> | |
| <li>Ersin Er (Hacettepe University)</li> | |
| <li>Cédric Vidal (ProxiAD, France)</li> | |
| </ul> | |
| <h3>Code contributions</h3> | |
| <p> | |
| The initial code contribution will be a set of plug-ins from the COPE project | |
| (Coupled Evolution of Metamodels and Models). Visit the <a | |
| href="http://cope.in.tum.de/">project's website</a> for further information and | |
| documentation. | |
| </p> | |
| <!-- ----- END inserted from Edapt-v*.html ----- --> | |
| </div> | |
| </div> | |
| <?php | |
| $html = ob_get_contents(); | |
| ob_end_clean(); | |
| # Generate the web page | |
| $App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html); | |
| ?> |