How to apply EMF model refactorings

This manual presents the application of an EMF model refactoring using EMF Refactor. More precisely, we demonstrate the model refactoring Move EAttribute for Ecore models. Please note, that EMF Refactor can be used for refactorings of any models whose meta model is based on EMF Ecore.

Let's take a look to the following Ecore diagram presenting a first model concerning EMF model refactorings in an early stage of the EMF Refactor development process. A ModelRefactoring has a name and conforms to a MetaModel that is specified by name, namespace prefix, and namespace URI. Furthermore, it has a label that should be shown as an Entry in the ContextMenu of an arbitrary ModelElement. A ModelElement belongs to a Model that is specified by a name and stored in a file with a specific name. Furthermore, a Model conforms to a MetaModel and each ModelElement is typed over a specific MetaModelType belonging to the corresponding MetaModel. Besides the afore mentioned attributes, each ModelRefactoring is related to a MetaModelType representing the type of the contextual element the refactoring can be applied on.

Fig. a_1

During software design it became questionable whether attribute label of class ModelRefactoring could be better placed in class Entry. So, model refactoring Move EAttribute is the next task to be performed. Since EMF Refactor can be used on arbitrary EMF based models the application of a specific refactoring is mainly triggered from within the EMF instance editor. The next figure shows the example model from above using this tree-based editor.

Fig. a_2

EMF model refactoring Move EAttribute can be specified in the following way: First, it has to be checked whether the contextual EAttribute is not marked as ID of the containing class, and whether this class has at least one referenced class. If these (initial) checks pass the user has to put in the name of the class the attribute has to be moved to. Then, it has to be checked whether the containing class has a referenced class with the specified name, and whether this class does not already owns an attribute with the same name as the contextual attribute. If these (final) checks pass the contextual attribute can finally be moved to the specified class.

Before applying the refactoring let us first present some erroneous situations. The following figure shows that attribute name of class ModelRefactoring represents the ID of this class. So, the application of refactoring Move EAttribute on attribute name is not possible.

Fig. a_3

Each refactoring can be triggered from within the context menu of a specific contextual model element. The next figure shows the context menu of attribute name.

Fig. a_4

As expected, EMF Refactor does not apply refactoring Move EAttribute because of the violated precondition. The following figure shows the corresponding error message.

Fig. a_5

The second erroneous situation occurs if we try to apply refactoring Move EAttribute on attribute name of class MetaModelElement. As you see in the following figure, this class does not have any (outgoing) references to other classes in our example model.

Fig. a_1

Again, we trigger refactoring Move EAttribute from within the context menu of attribute name of class MetaModelElement as shown in the following figure.

Fig. a_6

Again, EMF Refactor does not apply refactoring Move EAttribute because of the violated precondition. The following figure shows the corresponding error message.

Fig. a_7

Now, let's try to apply refactoring Move EAttribute on attribute name of class MetaModel. The initial checks pass, i.e. the attribute is not the ID of its containing class and this class is referenced to class MetaModelType (see following figure).

Fig. a_1

Again, we trigger refactoring Move EAttribute from within the context menu of attribute name of class MetaModel as shown in the following figure.

Fig. a_8

The initial precondition checks pass, i.e. EMF Refactor does not display any error messages, and a user input form appears specific to the triggered EMF model refactoring. For refactoring Move EAttribute we now have to input the name of the class the contextual attribute should be moved to. The following figure shows the input dialog. Here, another erroneous situation arises if we type in a name of a class that is not referenced by the containing class of the contextual attribute (or even a complete invalid name), for example ModelElement.

Fig. a_9

Again, EMF Refactor does not apply refactoring Move EAttribute because of the violated precondition. The following figure shows the corresponding error message.

Fig. a_10

The last erroneous situation occurs if we try to move attribute name of class MetaModel to the referenced class MetaModelType. Here, class MetaModelType already owns an attribute name (see following figure).

Fig. a_1

Again, we trigger refactoring Move EAttribute from within the context menu of attribute name of class MetaModel as shown in the following figure.

Fig. a_8

In the refactoring parameter dialog we type in name MetaModelType as shown in the following figure.

Fig. a_11

Again, EMF Refactor does not apply refactoring Move EAttribute because of the violated precondition. The following figure shows the corresponding error message.

Fig. a_10

Now, all possible erroneous situations of EMf refactoring Move EAttribute are presented and we can continue with a successful refactoring application. As already mentioned above, attribute label of class ModelRefactoring could be better placed in class Entry and should be moved.

Fig. a_1

Now, we trigger refactoring Move EAttribute from within the context menu of attribute label of class ModelRefactoring as shown in the following figure.

Fig. a_13

Since the initial precondition checks pass the parameter dialog appears and we type in class name Entry (see following figure).

Fig. a_14

It is possible to obtain a preview of the refactoring action. Here, EMF Refactor uses EMF Compare. The left hand side of the following figure shows the original model whereas the right hand side presents the refactored model. Model changes are highlighted by colored connections. Here, the dialog shows that attribute label was removed from class ModelRefactoring and inserted into class Entry, i.e. the attribute was moved.

Fig. a_15

Now, these changes can be committed and refactoring Move EAttribute can take place. The following figure shows the refactored model using the tree-based EMF instance editor.

Fig. a_16

Of course, EMF Refactor provides undo ...

Fig. a_17

... and redo functionality.

Fig. a_18

The last figure of this manual shows the refactored Ecore model using the graphical diagram view of Ecore Tools.

Fig. a_19

top

Incubation

This component is currently in its Validation (Incubation) Phase.

Incubation