The Operation Recorder 

 

 Description | The Operation Definition Process | Realization | The Graphical User Interface | Evaluation | Publications

Description

The Operation Recorder allows to specify of composite operations like refactorings for Ecore-based models by example. The user simply illustrates the refactoring by applying it to an example model within his/her preferred modeling editor. Therefrom, the Operation Recorder automatically derives a generic operation specification, which may then be manually fine-tuned.

There is also a screencast of the operation recorder in action available.

Core Features:

  • language independence
  • editor indpendence
  • no textual programming

 

The Operation Specification Process

Phase 1: Modeling

The user starts the specification process by providing the initial model. This model contains all model elements which are necessary to successfully apply the composite operation. Each model element of the initial model is annotated with a unique ID. In the next step, a so-called working copy is created automatically, which is a copy of the initial model. The user applies all necessary changes of the refactoring to the working copy. The result is the so-called revised model. The IDs preserve the relationship between the model elements in the initial model and the changed elements in the revised model. Both models are the input for the second phase of the operation specification process.
 

Phase 2: Configuration

When the revised model is completed, the Operation Recorder detects all performed atomic changes by conducting a state-based comparison relying on a sound ID-based match. Furthermore, the Operation Recorder derives pre- and postconditions necessary for the application of the composite operation. Then, the user may edit those automatically derived conditions. In particular, the conditions may be activated, deactivated, or modified. Furthermore, additional conditions, iterations, and user input variables may be introduced by the user. In the last step, the operation specification is automatically generated created. Such operation specifications may now be automatically applied to arbitrary models, which fulfil the preconditions.

Realization

  • Eclipse Plug-In
  • Eclipse Modeling Framwork
  • Applicable on any Ecore model
  • Adaption of EMFCompare
  • SWT/JFace for the Graphical User Interface
  • currently integrated editors: Graphical Ecore Editor, GMF class diagram editor, GMF statechart editor

The Graphical User Interface

 The graphical user interface consists of the following components: 

1.) The Starting Page where general settings are entered:

 General Page

 

2.) Any editors may now be used for changing the initial and the revised model.

 Editors

 

3.) Lists containing the automatically derived pre- and postconditions. In this view, the conditions may also be edited.

Conditions

 

4.) The final page showing the differences and allowing to introduce iterations and user input variables. 

 Final Page

Evaluation

So far, we successfully designed the following refactorings using the Operation Recorder.

For each operation specification the initial and the revised model is depicted. The detailed specifications consist of the executed operations as well as the generated and subsequently adapted templates and conditions. For each operation there is a text file summarizing the specification linked in the following subsections. The adapted conditions in the text file are represented using the following syntax:


===== Preconditions / Postconditions ======
===== Template name =====
// deactivated feature condition which was automatically deactivated
  * ( )...
// activated feature condition which was automatically activated
  * (X)...
// activated feature condition which was automatically deactivated and activated manually
  * (+)...
// deactivated feature condition which was automatically activated and deactivated manually
  * (-)...
// edited feature condition
  * (e)...

Move Attribute (mvAtt)

Diagram: Class Diagram

Description: Move an attribute of one class to an other class.

Operation Specification Model (TBD)

Initial model

 Move Attribute: Initial Model

Revised model

Move Attribute: Revised Model

Convert to Singleton (convSing)

Diagram: Class Diagram

Description: Introduces a static method which creates one instance of a class if the instance does not exist or which otherwise returns one instance. Constructors are set to private.

Operation Specification Model

Initial model

Convert to Singleton: Initial Model

Revised model

Convert to Singleton: Revised Model

Encapsulate Variable (encVar)

Diagram: Class Diagram

Description: Sets a public variable to private and adds a getter and a setter method.

Operation Specification Model

Initial model

 Encapsulate Variable: Initial Model

Revised model

Encapsulate Variable: Revised Model

 

Replace Data Value with Object (repDV)

Diagram: Class Diagram

Description: Removes one attribute from a class. For this attribute a new class is introduced and related the new class is related to the other class.

Operation Specification Model

Initial model

 Replace Date Value with Object: Initial Model

Revised model

Replace Date Value with Object: Revised Model

 

Extract Superclass (extSC)

Diagram: Class Diagram

Description: Attributes and Methods which are shared by multiple classes are extracted in one common superclass.

Operation Specification Model

Initial model

 Extract Super Class: Initial Model

Revised model

 Extract Super Class: Revised Model

Introduce Composite State (intCS)

Diagram: Statechart

Description: States with the same transitions are grouped in one composite state.

Operation Specification Model

Initial model

 Introduce Composite State: Initial Model

Revised model

 Introduce Composite State: Revised Model

Merge States (merge)

Diagram: Statechart

Description: Adjacent states are merged to one state. 

Operation Specification Model

Initial model

 Merge States: Initial Model

Revised model

 Merge States: Revised Model

 

Publications