Skip to main content

EMF Refactor - Component Proposal

Introduction

EMF Refactor is a proposed new open source component under Eclipse EMFT to provide tool support for generating and applying refactorings for models based on EMF Ecore, e.g. UML EMF models.

This component is in the Pre-Proposal Phase (as defined in the Eclipse Development Process) and this document is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join in the development of the component. Please send all feedback to the emft newsgroup.

Background

Model driven development has become a promising trend in software development which makes models to the primary artifacts. However, code generators can produce high quality code only for input models being of high quality. On the other side, code refactoring is a well-known and investigated technique to improve software structures without changing the observable behaviour. So an essential technique for model quality assurance is the refactoring of models which is in focus of the current research.

Although several refactorings for models have been suggested, there is not yet a corresponding tool support in Eclipse for creating custom refactorings and applying them. Moreover, some model refactorings were adopted from code refactorings, especially for models that describe structural features like UML class diagrams. In addition, completely new approaches have been developed, especially for further diagram types such as state machines and activity diagrams or just other kinds of EMF models.

Scope

Providing similarly comfortable refactoring support for models as for code refactoring in Eclipse would be worthwhile. Since EMF has become a key reference in model driven software development and a basic technology in Eclipse modeling, the intention is to provide an extensible tool support for handling EMF model refactorings.

A basic intention of the proposed component is to provide a framework for developing refactorings for models that are based on EMF. Model refactorings can be seen as endogenous model transformations preserving the semantics of a model yet improving the internal structure. The idea is to provide an easy to use generator which relies on model transformations to build model refactorings. So in the proposed framework the development of individual model refactorings will be based on model transformations, whereas the specifications of these model refactorings should be done by means of several different model transformation approaches. This will lead to a framework which will be extensible in two ways: on the one hand it should be possible to develop new EMF model refactorings which will, on the other hand, be specified and executed by exchangeable model transformation engines.

Like in tool support for code refactoring all generated model refactorings shall be applied in an intuitive and convenient way. Users should be able to select one or more model elements of interest - either in the standard EMF instance editor or in a generated graphical editor - and choose the appropriate model refactoring out of the context menu of the selection. Needed parameters should be entered like in Eclipse code refactoring wizards. If the selected refactoring can not be executed the user should be informed by appropriate error messages. Furthermore, tool support for EMF model refactoring should provide a preview of the performed changes as well as undo and redo functionality. Here, the proposed framework should aspire to an integration or adjustment of the Language Toolkit API (LTK).

An advanced tool support for EMF model refactoring could additionally combine refactorings of different models or, what is especially of interest in the field of MDD, combine model refactorings and code refactorings to synchronize the approriate artifacts of the software development process. A further improvement would be to provide supplementary tool support for specifying and detecting model smells which could be hints for possible model refactorings. Here, model refactorings could be executed in a quick-fix manner.

Because of the increasing usage of UML2 models refactoring support especially for UML2 models edited in UML2 Tools is desirable.

Initial Contribution

An initial contribution will provide the primary functionality for model refactoring.

As described above EMF Refactor consists of two main modules with basic functionalities. The Refactoring Generation Module integrates the functionality of each model refactoring, that has been defined by an EMF model transformation, into a special Eclipse plugin. Here, the actual distribution supports the model transformation tool EMF Tiger that allows defining model transformations graphically. The advanced plugin will extend EMF Refactor and provide a new item in the context menu of the standard tree-based EMF instance model editor by which the refactoring can be applied. Moreover, the Refactoring Application Module allows to select a model refactoring, to set all parameters needed, to preview the result of a refactoring, and to actually perform a refactoring.

The actual distribution of EMF Refactor provides implementations of a number of basic UML2 model refactorings:

Available Refactorings for UML2 class diagrams

  • Change Attribute To Association End - transforms an attribute to an association end.
  • Change Association End To Attribute - transforms an association end to an attribute and is the opposite of refactoring [Change Association End To Attribute].
  • Create Associated Class - creates an empty class and connects it with a new association to the source class from where it is extracted.
  • Create Intermediate Superclass - creates an empty class in between a selected class and one of its superclasses.
  • Create Subclass - creates an empty subclass of a selected class.
  • Create Subinterface - creates an empty subinterface of a selected interface.
  • Create Superclass - creates a new super-class of a class.
  • Hide Property - makes a non-private attribute/property of a given class private and creates getter and setter operations for it. In the literature, this refactoring is called [Attribute/Field/Property Privatization] and [Encapsulate Attribute/Field/Property].
  • Pull Up Operation - moves an operation of a class to one of its superclasses.
  • Pull Up Operation To Interface - moves an operation of a class to one of its implemented interfaces.
  • Pull Up Operation To Superinterface - moves an operation of an interface to one of its superinterfaces.
  • Pull Up Property - removes a property from a class and inserts it into one of its super-classes.
  • Push Down Operation - pushes an operation down to all its sub-classes. Sometimes it is also called [Push Down Method] and it is the opposite of refactoring [Pull Up Operation].
  • Push Down Property - moves a property of a class to all of its sub-classes. It is the opposite of refactoring [Pull Up Property].
  • Remove Empty Intermediate Superclass - removes a completely empty class which is a superclass of a set of subclasses but also generalizes other classes or implements interfaces. It is the opposite of refactoring [Create Intermediate Superclass].
  • Remove Empty Subclass - removes a completely empty subclass of a classes and is the opposite of refactoring [Create Subclass].
  • Remove Empty Subinterface - removes a completely empty subinterface of an interface and is the opposite of refactoring [Create Subinterface].
  • Remove Empty Superclass - removes a completely empty superclass of a set of classes.
  • Rename Class - changes a class name to a new one.
  • Show Property - makes a non-visible property public and removes its getter and setter operations. It is the opposite of refactoring [Hide Property].

Available Refactorings for UML2 state machines

  • Fold Transition Incoming to Composite State - folds transitions with same event incoming to a composite state from a state outside that composite state.
  • Fold Transition Outgoing From Composite State - folds transitions with same event outgoing from a composite state to a state outside that composite state.
  • Unfold Transition Incoming to Composite State - unfolds a transition incoming to a composite state to transitions incoming to each sub-state of the composite state. It is the opposite of refactoring [Fold Transition Incoming to Composite State].
  • Unfold Transition Outgoing From Composite State - unfolds a transition outgoing from a composite state to transitions outgoing from each sub-state of the composite state. It is the opposite of refactoring [Fold Transition Outgoing From Composite State].

Relationships to other Eclipse Projects/Components

EMF Refactor builds upon the functionality provided by the EMF project itself.

Special relationships to other projects/components are:

  • JET, for Java code generation by the Refactoring Generation Module.
  • EMF model transformation tools for designing and generating individual model refactorings. Here we plan a close collaboration with EMF Tiger, also in the Pre-Proposal Phase as EMFT component. But other transformation tools should be supported by EMF Refactor, too.
  • An EMF model comparison tool for providing a preview before applying individual model refactorings. Here we plan to integrate the existing EMFT component EMF Compare.

Planned integrations:

  • An integration into the graphical editors of UML2 Tools should be involved.
  • EMF Refactor should aspire to an integration or adjustment of the Language Toolkit API (LTK).

Related Work:

  • EMF Refactor will not compete with the Epsilon Wizard Language (EWL), a language that supports update transformations in the small for diverse modeling languages. Instead, a combinated use of EMF Refactor and EWL could be possible.
  • EMF Refactor could be used in combination with Edapt, a framework for Ecore model adaptation and instance migration which is also proposed as project under Eclipse EMFT.

Organization

Mentors

Initial Committers

The initial committers for this component would be:

Interested Parties

So far, interest in this component has been expressed by:

Interested parties are welcome to add themselves to the list above as interested parties or to suggest changes to this document.

Developer Community

The team of initial committers will explore statements of interest from additional developers experienced with model refactoring or willing to gain such experience.

User Community

It is expected that the user community for EMF Refactor will consist of two kinds of users. On the one hand, there will be researchers and developers who design model refactorings. On the other hand, there will be modelers who apply the generated model refactorings to their EMF based models - which can surely belong to the first category, too.

Tentative Plan

The first community technical preview release is scheduled at the beginning of 2010 and the first release is targeted in autumn 2010.

Please visit our Homepage for further information.

Back to the top