EMF Refactor Architecture

Design and Architecture

This Wiki presents the architecture of EMF Refactor and summarizes the components used by it. Each tool in EMF Refactor is based on the Eclipse Modeling Framework [1,2], i.e., each tool can be used for arbitrary models whose meta models are instances of EMF Ecore, for example domain-specific languages, common languages like UML2 (we refer to UML2 being the standard EMF-based representation of UML2, i.e., org.eclipse.emf.uml2.uml) used by Eclipse Papyrus [3] and the Java EMF model used by JaMoPP [4] and MoDisco [5, 6], or even Ecore instance models themselves.

EMF Refactor mainly consists of six components out of two dimensions: With respect to the main functionalities (calculating model metrics, detecting smells, and executing refactorings) there is an application module for each. Similarly there are three specification modules for generating metrics, smell, and refactoring plugins containing Java code that can be used by the corresponding application module. For simplicity reasons, we refer to these plugins as custom QA plugins in the following. We start with a description of the specification dimension.

The specification modules

The following figure shows the architecture of a specification module using a UML component model.

The specification module provides the generation of custom QA plugins containing the metric-, smell-, or refactoring-specific Java code. Using the Eclipse plugin technology, libraries consisting of model quality assurance techniques can be provided. So, already implemented techniques can be reused.

Actually, the following specification technologies are supported:

• Java [7]; version 6.
• OCL [8] provided by the Eclipse Modeling Project [9].
• Henshin [10, 11], a model transformation engine for the Eclipse Modeling Framework based on graph transformation concepts. Henshin uses pattern-based rules that can be structured into nested transformation units with well-defined operational semantics.
• CoMReL, a model-based language for the combination of EMF model refactorings.

More concretely, the following techniques can be used in a concrete specification of a new EMF model metric, smell, or refactoring:

1. Model metrics can be concretely specified in Java, as OCL expressions, by Henshin pattern rules, or as a combination of existing metrics using a binary operator.
2. Model smells can be concretely specified in Java, by Henshin pattern rules, or as a combination of an existing metric and a comparator like greater than (>).
3. The three parts of a model refactoring can be concretely specified in Java, in Henshin (pattern rules for precondition checks; transformations for the proper model change), or as a combination of existing refactorings using the CoMReL language.

The specification module provides wizard-based specification processes (component Specification Wizard in the figure above). After inserting specific information (like the name of the metric, smell, or refactoring, and the corresponding meta model) the Code Generator component uses the Java Emitter Templates framework [12] to generate the specific Java code required by the corresponding extension point (see arrow in the figure above). The following table shows the extension point descriptions for EMF model metrics, smells, and refactorings.

Besides basic information like the name, id, or the corresponding meta model of a concrete model quality assurance technique the following interfaces have to be implemented:

• IMetricCalculateClass: This interface provides the calculation of the corresponding EMF model metric on a given model element. Here, two methods have to be implemented: method void setContext(List<EObject> context) for maintaining the model element on which the metric should be calculated on, and method double calculate() for the proper calculation of the metric value on this element.
• IModelSmellFinderClass: This interface provides the detection of the corresponding model smell in a given EMF model. It has one method which must be implemented by the corresponding Java class: findSmell(EObject root). Here, the model is specified by parameter root. The method returns a list of detected smell occurrences where such an occurrence is given by a list of model elements which are involved in the detected smell.
• IController: This interface is responsible for executing the corresponding model refactoring. Here, the main method which has to be implemented is getLtkRefactoringProcessor() that returns an instance of class RefactoringProcessor from the Language Toolkit (LTK) API [13]. Within this class, the refactoring specific preconditions are checked by the two boolean methods checkInitialConditions () and checkFinalConditions() whereas the refactoring is executed by method createChange().
• IGuiHandler: This interface checks whether the refactoring can be executed on the given context elements (method showInMenu (List<EObject> selection)); the process is started by method RefactoringWizard show(). As above, RefactoringWizard is a class of the LTK API.

The application modules

The following figure shows the architecture of an application module.

It uses the Java code of the custom QA plugins generated by the corresponding specification module and consists of two components. The Configuration Component maintains project-specific configurations of metrics, smells, and refactorings. The Runtime Component is responsible for metrics calculation, smell detection, and refactoring execution. Depending on the concrete specification approach, the runtime component uses the appropriate components Java, OCL, Henshin, or the internal CoMReL interpreter. Further languages, especially model transformation languages like EWL [14,15], may be integrated by suitable adapters [16]. For exporting calculated model metrics, the reporting engine BIRT [17] is used. Finally, the Language Toolkit (LTK) [13] is used for homogeneous refactoring execution and EMF Compare [18], a tool that provides comparison and merge facility for any kind of EMF models, for refactoring preview.

For manually defining the relationships between model smells and model refactorings, our tool environment uses the Eclipse extension point technology again to provide information about these relationships globally. Therefore, two extension points for the manual definition of relations between model smells and model refactorings are provided. Since our tools identify smells and refactorings by distinct identifiers (see table above), these extension points require relations from smell IDs to a list of refactoring IDs (in case of providing suitable refactorings for a given smell) and relations from refactoring IDs to a list of smell IDs (in case of possible new smells when applying a given refactoring). To serve these extension points in a user-friendly way, we extend the property page of a certain Eclipse plugin project in the workspace by providing graphical user interfaces for (de-)activating appropriate relations.

References

[1] Dave Steinberg, Frank Budinsky, Marcelo Patenostro, and Ed Merks. EMF: Eclipse Modeling Framework, 2nd Edition. Addison Wesley, 2008.

[2] The Eclipse Foundation. Eclipse Modeling Framework Project (EMF), 2014. URL http://www.eclipse.org/modeling/emf/.

[3] The Eclipse Foundation. Papyrus, 2014. URL http://www.eclipse.org/papyrus/.

[4] Technische Universität Dresden. JaMoPP, 2014. URL http://www.jamopp.org.

[5] Gabriel Barbier, Hugo Brunelière, Frédéric Jouault, Yves Lennon, and Frédéric Madiot. MoDisco, a Model-Driven Platform to Support Real Legacy Modernization Use Cases. In Information Systems Transformation: Architecture-Driven Modernization Case Studies, pages 365–400. The Morgan Kaufmann/OMG Press, 2010.

[6] The Eclipse Foundation. MoDisco, 2014. URL http://www.eclipse.org/MoDisco/.

[7] Oracle. Java, 2014. URL http://www.java.com/.

[8] OMG. Object Constraint Language (OCL), 2014. URL http://www.omg.org/spec/OCL/.

[9] The Eclipse Foundation. Eclipse Modeling Project, 2014. URLhttp://www.eclipse.org/modeling/.

[10] Thorsten Arendt, Enrico Biermann, Stefan Jurack, Christian Krause, and Gabriele Taentzer. Henshin: Advanced Concepts and Tools for In-Place EMF Model Transformations. In Model Driven Engineering Languages and Systems (MoDELS), volume 6394 of LNCS, pages 121–135, 2010.

[11] The Eclipse Foundation. Henshin, 2014. URL http://www.eclipse.org/henshin/.

[12] The Eclipse Foundation. Java Emitter Templates (JET), 2014. URL http://www.eclipse.org/modeling/m2t/?project=jet.

[13] Leif Frenzel. The Language Toolkit: An API for Automated Refactorings in Eclipse-based IDEs. Eclipse Magazin, 5, 2006. URL http://www.eclipse.org/articles/Article-LTK/ltk.html.

[14] Dimitrios S. Kolovos, Richard F. Paige, Fiona Polack, and Louis M. Rose. Update Transformations in the Small with the Epsilon Wizard Language. Journal of Object Technology, 6(9):53–69, 2007.

[15] The Eclipse Foundation. Epsilon, 2014. URL http://www.eclipse.org/epsilon/.

[16] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: Elements of Reusable Object-Oriented software. Addison-Wesley Longman Publishing Co., Inc., 1995.

[17] The Eclipse Foundation. Business Intelligence and Reporting Tools (BIRT), 2014. URL http://www.eclipse.org/birt/.

[18] The Eclipse Foundation. EMF Compare, 2014. URL http://eclipse.org/emf/compare/.