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.
Difference between revisions of "Refactor"
(→How to calculate model metrics (to do)) |
(→How to calculate model metrics (to do)) |
||
| Line 35: | Line 35: | ||
</ul> | </ul> | ||
| − | === How to calculate model metrics | + | === How to calculate model metrics === |
---- | ---- | ||
Revision as of 09:29, 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
The following figure 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].
The model consists of altogether four packages:
- Package Commonalities contains general concepts (enumerations, interfaces, and common classes like Person and Date).
- Package RentalCompany contains the main entities of the company (represented by class VehicleRental). The company has a number of employees and customers. Each customer is associated with a concrete employee (see association end consultant). Special persons are subcontractors of the company which represent both, a customer and an employee. The right-hand-side of this package shows that the company owns several cars, trucks, and motorbikes which can be rented by some customer.
- Packages Services and Invoicing contain classes for renting a vehicle by some customer as well as for billing purposes.
How to calculate model metrics
For the first overview on a model, a report on project-specific model metrics might be helpful. In the following, we calculate common metrics to get an overview on interesting model properties.
To calculate relevant metrics only, our tool environment supports a project-specific configuration for the metrics suite. The configuration is managed by means of a dedicated project properties page (select project -> menu Project -> Properties -> category EMF Quality Assurance -> subcategory Metrics Configuration). On this page, all existing model metrics for EMF-based models are listed. They are structured with respect to the corresponding meta-model (e.g., UML and Ecore) and to the corresponding element type the metrics are calculated on (the context).The following figure shows the project-specific configuration page for our example project.
On this page, all existing model metrics for EMF-based models are listed. They are structured with respect to the corresponding meta model (e.g., UML and Ecore) and to the corresponding element type the metrics are calculated on (the context). In the figure above, we activate model metrics for UML packages concerning abstractness (A, NACP, NCCP, and TNCP) and coupling issues (Ca, Ce, I, and TC).
The calculation of metrics on a specific model element is started from its context menu (menu EMF Quality Assurance (use existing techniques) -> Calculate Configured Metrics (on element)). In our UML show case, this element is selected from within the graphical GMF-based Papyrus editor. However, EMF Refactor also supports further editors like the tree-based EMF instance editor and textual editors generated by Xtext [4]. The following figure shows the calculated results of the configured UML metrics on packages Commonalities and RentalCompany from the example UML class model above.
The results view shows that package Commonalities contains altogether four classes (metric TNCP): two concrete and two abstract classes (metrics NCCP and NACP). Furthermore, metric Ca (afferent coupling: number of classes in other packages depending on classes of the package) of package RentalCompany is evaluated to 3 whereas its efferent coupling metric (number of classes within the package depending on classes in other packages - Ce) is evaluated to 7. Metrics A, TC, and I are calculated using these ’basic’ metrics. The abstractness (A) of package Commonalities is 0.5 (ratio between the number of abstract classes in the package and the total number of classes in the package). The total coupling (TC: afferent + efferent coupling) of package RentalCompany is 10 and its instability (I) is 0.7 (ratio between efferent coupling and total coupling).
EMF Refactor’s metrics tool provides the export of calculated results for reporting purposes (select top down menu of the results view -> Export Results). The following output formats are supported: XML (default), HTML, PDF, Postscript, MS DOC, MS PPT, MS XLS, ODP, ODS, and ODT. Furthermore, several output designs are provided but also custom designs can be imported. The following figure shows two PDF exports of our example metrics calculation.
On the left-hand side, metric values for Ca (Afferent Coupling) and Ce (Efferent Coupling) of package RentalCompany are compared using a pie diagram. The right-hand side shows an exported tube diagram containing the metric values for Ca, Ce, and TC (Total Coupling).
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.
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/.
[4] The Eclipse Foundation. Xtext, 2014. URL http://www.eclipse.org/Xtext/.