Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Refactor"

(References)
(References)
Line 60: Line 60:
 
[2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. ''Design patterns: Elements of Reusable Object-Oriented software.'' Addison-Wesley Longman Publishing Co., Inc., 1995.
 
[2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. ''Design patterns: Elements of Reusable Object-Oriented software.'' Addison-Wesley Longman Publishing Co., Inc., 1995.
  
[3] The Eclipse Foundation. ''Papyrus'', 2014. URL <a href="http://www.eclipse.org/papyrus/" target="_blank">http://www.eclipse.org/papyrus/</a>.
+
[3] The Eclipse Foundation. ''Papyrus'', 2014. URL http://www.eclipse.org/papyrus/.

Revision as of 07:42, 23 April 2014

EMF Refactor

EMF Refactor is an Eclipse open source tool environment conveniently supporting a structured model quality assurance process. In particular, EMF Refactor supports metrics reporting, smell detection, and refactoring for models being based on the Eclipse Modeling Framework, a widely used open source technology in model-based software development.


The following major functionalities are provided:

  • User-friendly support for project-specific configurations of model metrics, smells, and refactorings.
  • Calculation of model metrics, detection of model smells, and application of model refactorings.
  • Generation of model metrics and smell detection reports.
  • Suggestion of suitable refactorings in case of specific smell occurrences.
  • Provision of suitable information in cases where new model smells come in by applying a certain refactoring.
  • Support for the implementation of new model metrics, smells, and refactorings.


The tool environment mainly consists of two kinds of modules: For calculating model metrics, detecting smells, and executing refactorings there is an application module 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.

Example Applications

In the following, the application of several model quality assurance techniques supported by EMF Refactor is presented. We demonstrate this application on a UML class model representing the domain of a vehicle rental company.

Example UML class model (to do)

Figure 12.1 shows a first UML example model that has been developed in an early stage during the development of an accounting and customer management system for a vehicle rental company. This first version of the domain model of the company is shown as UML class diagram modeled using the EMF-based UML CASE tool Papyrus [3].

How to calculate model metrics (to do)

How to detect model smells (to do)

How to apply model refactorings (to do)

Example Specifications

EMF Refactor provides a wizard-based specification process for each supported quality assurance technique. In the following, several concrete specification mechanisms for model quality assurance techniques are presented. The techniques and mechanisms are discussed along a domain-specific modeling language for defining web applications.

Example DSML

To demonstrate the specification facilities provided by EMF Refactor, we use a domain-specific modeling language (DSML) called Simple Web Model (SWM) for defining a specific kind of web applications. In this example case, we assume the following scenario (taken from [1]):

A software development company is repeatedly building simple web applications being mostly used to populate and manage persistent data in a database. Here, a typical three-layered architecture following the Model-View-Controller (MVC) pattern [2] is used. As implementation technologies, a relational database for persisting the data as well as plain Java classes for retrieving and modifying the data are employed for building the model layer. Apache Tomcat is used as the Web Server, and the view layer, i.e., the user interface, is implemented as Java Server Pages and the controller layer is realized as Java Servlets. The company decides to develop its own DSML called Simple Web Modeling Language (SWM) for defining their specific kind of web applications in a platform-independent way. Furthermore, platform-specific models following the MVC pattern should be derived with model transformations from which the Java-based implementations are finally generated.

The following figure shows the language description of SWM as meta model modeled in EMF Ecore.

SimpleWebModel.png

A WebModel consists of two parts: a DataLayer for modeling entities which should be persisted in the database (see left-hand-side of the meta model), and a HypertextLayer presenting the web pages of the application (see right-hand-side of the meta model). An Entity owns several Attributes (each having a SimpleType) and can be related to several other entities (see meta class Reference). A Page is either a StaticPage having a static content or a DynamicPage having a dynamic content depending on the referenced entity. An IndexPage lists objects of this entity whereas a DataPage shows concrete information on a specific entity like its name, attributes, and references. Pages are connected by Links.

How to specify new model metrics (to do)

How to specify new model smells (to do)

How to specify new model refactorings (to do)

How to specify new smell-refactoring relations (to do)

References

[1] Marco Brambilla, Jordi Cabot, and Manuel Wimmer. Model-Driven Software Engineering in Practice. Morgan & Claypool, 2012.

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

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

Back to the top