|
As at 13 December 2011 : isotrol.org is not available. |
Name |
Isotrol MetricsAnalytics |
Authors |
Nicolas Bertet (Project Manager & Functional Responsable) and Emilio Escobar Reyero (Technical Manager) from Isotrol http://www.isotrol.com |
Homepage |
|
Jira |
|
Most Recent Version |
0.6.1 |
Availability |
Sonar 1.11 |
State |
Under development |
License |
LGPL v3 |
Download sources |
|
Download jar |
Compatibility with Sonar
Plugin versions |
1.8 |
1.9 |
1.10 |
1.11 |
1.12 |
|---|---|---|---|---|---|
0.6.1 |
|
|
|
|
|
0.6 |
|
|
|
|
|
0.5 |
|
|
|
|
|
0.4 |
|
|
|
|
|
Description / Features
Sonar[1] is a system for Code Quality Management of development projects. The founder members of SonarSource[2] like to say that the Sonar purpose is to hunt the seven capitals sins of source code. But, up until now, the sin of the bad design and architecture escaped us.
Now, thanks to the Sonar MetricsAnalytics Plugin[3], JDepend[4] and Ckjm[5], we are near to resolve this ultimate barrier.
This plugin try to unify the concepts of XRadar[6] in the Sonar World with some adaptations to get the Total Quality Indicator.
Sonar MetricsAnalytics plugin add new domains and metrics in Sonar and an extention point in the dashboard:
- The "Architecture" domain with Package metrics of JDepend.
- The "Design" domain with Class metrics of Ckjm.

Package primitive metrics of JDepend
- tc, Total Number of concrete and abstract Classes and Interfaces in a package. It is an extensibility indicator of the package: It belongs to the "Size" domain of Sonar.
- cc, Concrete Class Count (instantiable) in a package.
- ac, Abstract Class (and Interface) Count in a pakage: It belongs to the "Size" domain of Sonar.
- ca, Afferent Couplings. The number of other Packages which depends on Classes of the package (indicator of his responsability): It belongs to the "Architecture" domain of Sonar.
- ce, Efferent Couplings. The number of Classe of the package which depends on other Packages (indicator of his independence): It belongs to the "Architecture" domain of Sonar.
- a, Abstractness a = ac/(ac + cc). 0% indicates a Concrete Package and 100% an Abstract Package: The "Architecture" domain of Sonar.
- i, Instability. i = ce/(ce + ca). It's an indicator which shows the package probability of change if a package close to it is modificated. 0% indicates a stable package and 100% indicates a total instability: It belongs to the "Architecture" domain of Sonar.
- d, Distance from the Main Sequence. It's the distance from the line a+i=1. d=|(a+i-1)/2|. A package must keep the balance between his Abstractness and his Instability (a+i=1). A perfect package is either abstract and stable or concrete and inestable: It belongs to the "Architecture" domain of Sonar.
- dc, The Package Dependency Cycles Number. 0 is the best value: It belongs to the "Architecture" domain of Sonar.

Class primitive metrics of Ckjm
- dit, Depth of Inheritance Tree. The root has a dit=1. More the dit is high and more the design is bad. It belongs to the "Design" domain of Sonar.
- cbo, Coupling between object classes. This Coupling Number is due to a call of a method, getter o setter, inheritance, response type, arguments and exceptions. More the cbo is high and more the design is bad.It belongs to the "Design" domain of Sonar.
- rfc, Response for a Class. It counts the number of methods called when a method is executed. More the dit is high and more the design is bad. It belongs to the "Design" domain of Sonar.
- lcom, Lack of cohesion in methods indicates the quality of the rol and responsabilities definition of the class. It counts the method number which doesn t use any atribute. If lcom is close to O, we must refactorize by moving some methods out of its class: It belongs to the "Design" domain of Sonar.
The architecture primitive metrics permit the architecture indicator calculation of the project totality
- COH, Cohesion. Package Number wih cycles / Total Number of Package : It belongs to the "Architecture" domain of Sonar at the project level. At the Package level, we calculate this indicator with only 2 values: 0 (with some cycles) or 100 (without any cycles).
- ADI, Distance. Package Number with a distance higher than 20% (you can change this value) / divided between the package Total at the project level: It belongs to the "Architecture" domain of Sonar at the project level. At the Package level, we calculate this indicator with only 2 values: 0 (d > 20) or 100 (d < 20).
- ARCH, Architecture. ARCH = 0.5*COH + 0.5*ADI: It belongs to the "Architecture" domain of Sonar at the project level.
The design primitive metrics permit the design indicator calculation of the project totality
- NOM, Number of Methods. Class Number with a complexity higher than 20 (you can change this value) divided by the Total Class Number of a package. At the project level, we calculate the NOM mean of packages. It belongs to the "Design" domain of Sonar.
- RFC, Response for Class. Class Number with a rfc less high than 50 (you can change this value) divided by the Total Class Number of a package. At the project level, we calculate the RFC mean of packages. It belongs to the "Design" domain of Sonar.
- CBO, Coupling Between Objects. The class number with cbo less high than 5 (you can change this value) divided by the Total Class Number of a package. At the project level, we calculate the CBO mean of packages. It belongs to the "Design" domain of Sonar.
- DIT, Depth of Inheritance Tree. The class number with dit less high than 5 (you can change this value) divided by the Total Class Number of a package. At the project level, we calculate the DIT mean of packages. It belongs to the "Design" domain of Sonar.
- DESIGN, Design. DES = 0.2*NOM + 0.3*RFC + 0,3*CBO + 0,2*DIT It belongs to the "Design" domain of Sonar.
Test Metric and indicator
- COVERAGE, Code coverage by unit tests. It is a Sonar metric.
Code Metric and Indicator

- DOC, Documentation. we multiplies the documentation percent of Sonar by 10/4. It belongs to the "Documentation" domain of Sonar.
- DRY, Dryness. Inverse of duplicated lines % at package and project scope. It belongs to the "Size" domain of Sonar.
- RULES, Rules compliance. It is a Sonar metric.
- CODE, Code Quality. CODE = 0,15*DOC + 0,4*DRY + 0,45*RULES and belongs to the "Rules" domain of Sonar.
Key Performance Indicator: Total Quality
- TQ, Total Quality: The Total quality represent the global quality of the implementation of the project.TQ = 0,25*ARCH + 0,25*DES + 0,25*CODE + 0,25*COV and belongs to the "General" domain of Sonar.

With the administration extension you can set limits for,
- ADI generation procces.
- NOM generation procces.
- RFC generation procces.
- CBO generation procces.
- DIT generation procces.

and by the way andalusians, sonar it's Madeja[7] included!
Usage & Installation[8]
- Download jar[9]
- Copy to /extensions/plugins/ and restart server. When Sonar is deployed on an application server, the WAR file must be built each time new plugins are installed.
- Launch a new code quality analysis.
Known limitations and TODO
- Extension page.
- Packages distance distribution graph.
- More architecture metrics.
- More tests metrics.
Links
[1] http://sonar.codehaus.org
[2] http://www.sonarsource.com
[3] http://forge.isotrol.org/projects/show/org00003-mtrcsnlytcs
[4] http://clarkware.com/software/JDepend.html
[5] http://www.spinellis.gr/sw/ckjm/
[6] http://xradar.sourceforge.net/
[7] http://www.juntadeandalucia.es/xwiki/bin/view/MADEJADGIAP/VerRecursoSonar
[8] http://docs.codehaus.org/display/SONAR/Install+a+new+plugin
[9] http://forge.isotrol.org/wiki/org00003-mtrcsnlytcs/Downloads
[10] http://www.isotrol.com
[11] http://www.isotrol.org

2 Comments
Hide/Show CommentsApr 17, 2010
Stephane Vaucher (sven)
Obviously, the people integrating these metrics must have only limited knowledge of metrics:
> More the dit is high and more the design is bad.
If you use inheritance, then the design is bad??? I must only assume that this is a joke
> cbo, Coupling between object classes. This Coupling Number is due to a call of a method, getter o setter, inheritance, response type, arguments and exceptions. More the cbo is high and more the design is bad.
Yet again, the best class would use no other class? Furthermore, what is described is not the CBO metric.
> rfc, Response for a Class. It counts the number of methods called when a method is executed. More the dit is high and more the design is bad.
You must mean the set of methods that can be executed. Repetition concerning dit...
> lcom, Lack of cohesion in methods indicates the quality of the rol and responsabilities definition of the class. It counts the method number which doesn t use any atribute. If lcom is close to O, we must refactorize by moving some methods out of its class.
You are basically saying that someone should refactor cohesive code. It measures *Lack* of cohesion. You obviously mean if LCOM is high, then refactor.
Obviously, there are problems with this package. It is unclear what these assessments are based on. They seem to contradict state of the art industrial research. Using means to combine metrics is also a bit weird considering it is not a measure of central tendency for most metrics mentioned.
Apr 19, 2010
Freddy Mallet
Hi Stéphane, this plugin is no more alive since Sonar 1.11 and most metrics you are talking about are now available in Sonar core : RFC, DIT, LCOM4, NOC, ... We're going to deprecate this page in order to prevent any new confusion.
Thanks for your feedback !