Using EMF to control Eclipse plugins development rules

This week I am in Minneapolis to attend an OMG Technical Meeting.

Today I participated to the 2nd Eclipse & OMG Symposium where I talked about MoDisco and how we support the specifications defined by ADM, the OMG task force working on Software Modernization. I presented an example where we use KDM (Knowledge Discovery Metamodel) and SMM (Structured Metrics Metamodel) to control the quality of Eclipse plugins.

We wanted to check automatically some rules which are mandatory by the yearly synchroneous release:

• Version number ends with « qualifier »
• Source code must use ICU4J classes
• The project must contain an « about.html » file
• Packages name should start with the plug-in Id
• Plug-in must not contain JARs files
• Plug-in should contain only one « message.properties » and « Message.java » files

We also wanted to check some rules that we had defined internally at Mia-Software:

• “PLUGIN_ID” variable of “Activator.java” should be initialized with the plug-in Id
• Plug-in Id and Project name should be equal
• «Bundle-Vendor» property value of « MANIFEST.MF » should be « %providerName »
• « plugin.properties » should declare a « providerName » property
• «Bundle-Name» property value of « MANIFEST.MF » should be « %pluginName »
• « plugin.properties » should declare a « pluginName » property

Of course, we could have implemented these rules by using the APIs provided by the plugins already provided by Eclipse (org.eclipse.core, org.eclipse.pde, org.eclipse.pde, etc). But all these APIs are not homogeneous, and it is not always easy to find the right API to use. That's why we decided to experiment an other approach.

Our idea is to use these APIs only to create EMF models of the plugin. Then, once the models are created, we can implement the rules by using only EMF APIs.

In our case, we have used MoDisco to create seven EMF models:

• A KDMSource model describing the organization of the plugin project (files and directories)

• A Java model describing the Java source code of the plugin
• A Manifest model to describe the content of the MANIFEST.MF file
• Two XML models to describe the content of the .project and .classpath files
• Two KDMCode models to describe the content of the plugin.properties and the build.properties files

These models contain all the information required to check the rules listed below.

Rather than directly displaying the violations found in an Eclipse plug-in into the Eclipse Problems View, we use an SMM model to represent the result of the analysis. Then, we have developped a generic tool which displays each rule violation contained in this SMM model into the Eclipse Problems View.

The benefit of this approach is that you just have to know EMF APIs to implement the rules, or use any EMF-compliant tool (such as OCL, ATL or QVT). Another benefit is that the result (the SMM model) is independent from how you want to deliver it to the user. Here we have injected the violations into the Eclipse Problem View, but we could have generated an Excel file or populated a tool such as Sonar.

I have still some little things to improve in this plugin, and I'll try to to commit it this summer as a use-case in MoDisco.

Meanwhile, the complete presentation is available on slideshare.

MoDisco Eclipse-OMG Symp 2010

EMF and SMM to export code metrics to Sonar and Squale

How to facilitate the integration between code quality measurement tools and code quality reporting tools ?


This is the problem we are faced with at Mia-Software: to address modernization projects, we have developped a lot of parsers creating models of code from which we can compute quality metrics (from COBOL, Natural or VB6 to Smalltalk, C# or Java). But as our customers are interested in getting these metrics in the quality report tool of their choice, we don't want to multiply the development of adhoc bridges (one for each couple "metrics calculator" <-> "report tool")

To reduce the cost of bridging the tools, we chose SMM (Structured Metrics Metamodel) as a pivot. SMM is the OMG/ADM standard for defining metrics related to software and for representing their measurement on existing systems. Its reference EMF implementation can be found in MoDisco, the Eclipse Modeling project focused on discovering models from software assets.

The main classes defined by SMM are quite simple :
- Measure : the definition of an indicator (nb lines of code, cyclomatic complexity, …)
- Scope : the kind of elements on which the indicator can be measured
- Measurand : an element on which an indicator has been measured
- Measurement : the measured value of an indicator
- Observation : who ? how ? when ?
Then, for each measurement tool that we need to integrate with a report tool, we just have to create a SMM model describing the kind of metrics to exchange (instances of Measure and Scope) and a connector to translate the specific export format of the measurement tool to a SMM model containing the measured values (instances of Measurement, Measurand and Scope).

In parallel, we create one generator for each report tool to integrate with. This generator takes the SMM model defining the measures and generates :

• the files declaring the metrics within the report tool
• the files configuring the report tool to integrate the new kind of metrics
• the source code of the component which will import SMM models containing the measurements
At this time we have experimented this approach to import COBOL and VB6 metrics (calculated by Mia-Insight) into the quality report tools Sonar and Squale.

Screenshots : COBOL -> Sonar







Screenshots : COBOL -> Squale







Our conclusion is that SMM fits the need of integration between these kind of tools.

The next step will be the integration of XRadar (suggestions of other report tools are welcome ;-) ).

We also have to solve the problem of metrics aggregation. There are three possibilities :
- aggregation at measurement time
- aggregation in SMM model
- aggregation in report tool
We have already identified pros and cons for each alternative. Depending on the kind of aggregation to perform, experimentation will probabely give an answer !