Skip to content

QualityOfSoftware

stockiNail edited this page Oct 26, 2015 · 3 revisions

Introduction

To improve the software quality of JEM, we decided to use SonarQube and FindBugs to check which part of JEM had to be improved.

In this page we've published the results of this analysis (for JEM last version) and explain the reason of presence of specific issues.

FindBugs analysis

JEM-gwt (web user interface), JEM plugin (Eclipse plugin) and JEM JBPM (JBoss JBPM addon) projects don't have any issue.

JEM (core project) has got the following FindBugs issues situation:

http://www.pepstock.org/wiki/webui/FindBugs-JEM.png

Method invokes System.exit(...)

There is this issue because we call System.exit() static method to close the JVM and then ShutDownHandler, necesary to close quietly all internal connections and pools. We are aware about that's not really a bug.

May expose internal representation by returning reference to mutable object

There is this issue because in JEM beans we are using the java.util.Date and its get method return the object itself. One of the suggestion is to clone the object in get method. But this way, we are creating a lot of objects and this is not good for the performance perspective.

Creating a immutable date object, there is the problem that a custom serialization is mandatory and Hazelcast (in the version 2.6.6 that we are using) doesn't support custom serialization for java.util.Date. In the Hazelcast version 3, there is this feature.

May expose internal representation by incorporating reference to mutable object

There is this issue because in JEM beans we are using the java.util.Date and its get method return the object itself. One of the suggestion is to clone the object in get method. But this way, we are creating a lot of objects and this is not good for the performance perspective.

Creating a immutable date object, there is the problem that a custom serialization is mandatory and Hazelcast (in the version 2.6.6 that we are using) doesn't support custom serialization for java.util.Date. In the Hazelcast version 3, there is this feature.

SonarQube analysis

Using SonarQube, we have improved a lot the software quality, mainly its reading. The following tree graph will show the rules compliance of JEM projects (see below about the percentage of compliance).

http://www.pepstock.org/wiki/webui/Sonar-TreeGraph.png

Here you could find the details about metrics collected by SonarQube and showed below, applied on JEM.

SQALE

(quoted from SQALE models in SonarQube)

The most important thing about SQALE is that it changes the paradigm for analysis and quality management of source code. Traditional approaches use complex formulas that make indicators difficult to understand and utilize. This is slowing down adoption.

SQALE has a different approach which is much simpler to understand: it is built around the technical debt concept.

Here are the SQALE for all JEM projects:

JEM core

http://www.pepstock.org/wiki/webui/SQALE-core.png

JEM UI gwt

http://www.pepstock.org/wiki/webui/SQALE-gwt.png

JEM Eclipse plugin

http://www.pepstock.org/wiki/webui/SQALE-plugin.png

JEM JBPM extension

http://www.pepstock.org/wiki/webui/SQALE-jbpm.png

Source code statistics

These are the source code statistics and the percentage of documentation, produced in sources.

Project LOCs Classes Pub. doc. API (%) Comments (%)
JEM 43,668 794 99.6% 35.4%
JEM-gwt 32,411 664 90,7% 23.2%
JEM-plugin 4,843 106 96.6% 30.9%
JEM-JBPM 3,177 45 98.8% 33.7%

Issues

These are the rules compliance and the amount of open issues on different severity. The rule compliance index (RCI) is calculated by the following formula:

100 - (Weighted issues / Lines of code * 100), where Weighted issues is sum of the issues weighted by the coefficient associated to each severity ((Blocker_violatons * 10) + (Critical_violations * 5) + (Major_violations * 3) + Minor_violations).

Project Rules Compliance Blocker issues Critical issues Major issues Minor issues Info issues
JEM 97.8% 0 0 255 197 0
JEM-gwt 97.2% 0 0 195 311 * 0
JEM-plugin 98.3% 0 0 24 9 0
JEM-JBPM 97.5% 0 0 18 26 0

* 213 of 311 issues are "Magic numbers should not be used"

Duplications & Complexity

These are the percentage of duplicated lines and the complexity rates. SonarQube calculates the cyclomatic complexity, also known as McCabe metric. Whenever the control flow of a function splits, the complexity counter gets incremented by one. Each function has a minimum complexity of 1.

Project Dup. lines(%) Complexity/function Complexity/class Complexity/file
JEM 3.2% 3.0 10.6 11.0
JEM-gwt 7.8% 2.4 8.6 11.5
JEM-plugin 2.8% 2.6 8.3 11.1
JEM-JBPM 0.0% 4.3 16.4 17.6
Clone this wiki locally