DevBooststLogoQualiTunetudLogorewerseLogo modelplexLogo
Refactory Logo
EMFText Refactoring SDK
Enabling Refactorings for your DSL just became a piece of cake

Contents

Documentation

Installation

Refactory is available from the update site http://www.modelrefactoring.org/update. A trunk update site is deployed after each successful run of the build server and can be reached via http://www.modelrefactoring.org/update_trunk/. Another possibility is to install it via the Eclipse Marketplace. Just search for Refactory and install. A third possibility to install Refactory is to check it out from trunk. This is described here. Or you can just drag and drop this install button into your Eclipse onto the main menu bar.

installbutton.png

Specifying and enabling model refactorings

Enabling a refactoring in your DSL (or metamodel) consists of two main parts. At first, the refactoring itself has to be defined. Since Refactory is a framework enabling the reuse of refactorings for arbitrary metamodels, refactorings must be defined generically. That means they will be specified independently from the target metamodel. In detail the following steps must be run through in detail from the refactoring designer:

  1. Define the participating elements
  2. Define the transformation steps

At second, the previously defined generic model refactoring must be mapped to a target metamodel in which the DSL designer wants to enable the refactorings. The mapping will be described in detail in the following link:

Customising refactorings for your DSL

In some cases the generic definition of a refactoring is not sufficient in the context of a target metamodel. It can happen that in such cases additional modifications have to be invoked because the semantics of a metamodel is more specific than the generically defined model refactoring. For this purpose we developed the mechanism of post processors in Refactory which can be used to implement further model transformations after the generic refactoring has been executed:

Besides the above mentioned technique for specializing a generic model refactoring, we developed extension points for beautifying the context menu entries to invoke refactorings and to structure refactorings in submenus:

Enable model refactorings in arbitrary editors

Since Refactory works with the abstract syntax, i.e. with the metamodel and its reflective API, of a model to be refactored, the invocation of refactorings should be independent from which editor is used. This means that the model representation doesn't play a role. For this purpose we introduced a new extension point which is used for registering editor connectors to provide the underlying model of a concrete model representation.

Videos

The list below will contain some videos or screencasts