http://xradar.sourceforge.net


Statics Report - System: 4.0, Version: 730, Date: 2004.01.01Designed for use with , Checkstyle, CKJM, CLOC, EMMA, FindBugs, JavaNCSS, JDepend, JUnit, Macaron, PMD, PMD-CPD, Java2HTML and Ant.

[Statics] code

[scorecard] [analysis] [explanations]
{overview} {architecture} {design} {code} {test} {source control} {system specific}

Code Metrics

For each histogram column, you can roll over the diagrams to get details on the contents on which subsystem the column relates to. Click on it to go to a detailed view. On the bottom of the screen the data is presented in tabular form.
Code MetricsTotal PackagesTotal ClassesBC ClassesSource StatementsCyclomatic ComplexityCmplx. per Stmnt.Cmplx. per Meth.Violations/ Source Stmts.Style errors/ Source Stmts.Duplicated Tokens / Source Stmts.
Total799486990.22.30.760.381.72
A module11164170.274.250.50.520
B module2221730.1810.181.530
C and D module11196510.531.760.590.750
E module111710.1410.430.570
F module122251150.063.750.980.123.34
G module00000 0 0 NaNNaNNaN
Not Classified00000 0 0 NaNNaNNaN

Duplications

The matrix below presents in what way and to what degree code duplications are found in the modules in the analysed system. Each dot represents a duplication between two classes. The size of the dots represents the number of duplications the two classes are involved in between each other. Dots on the diagonal represent duplications within a class. Notice that each side of the diagonal is equal. This is no coincidence since they are each others mirror image.

By pointing your mouse over the dots you will see the details of that duplication. Click to go to the class.


Pareto Principle

Theory
The Pareto Principle states that a minority of input produces the majority of results. This principle is often called the 80%:20% rule. The principle originates from economics, but is often just as applicable to other types of systems such as software. In the following graphs Aggregated Source Statements and Aggregated Cyclomatic Complexity per package is plotted.
Needed Actions
According to the theroy the aggregated results will in most cases go though the 80:20 / 70:30 box. That is not necessarily assert a bad design. Still, it proves the point that most of the logics and development effort in the system is focused on a limited number of packages. You may in such cases consider to split up the main packages or pull together the smallest packages to get the curve to go below the 80:20 / 70:30 box. That will probably make the package structure more balanced. Note that if all the packages are of equal size, the curve will be linear (y=x).

See the explanations for Source Statements and Cyclomatic Complexity for more on their definitions.

#PackageSource Statements
1org.xradar.test.f251
2org.xradar.test.c96
3org.xradar.test.a64
4org.xradar.test.d51
5org.xradar.test.b12
6org.xradar.test.e7
7org.xradar.test.b.b25
8java.io
9java.lang
10java.util
11org.xradar.test.a.suba
12sun.io

#PackageCyclomatic Complexity
1org.xradar.test.c51
2org.xradar.test.a17
3org.xradar.test.f15
4org.xradar.test.d12
5org.xradar.test.b2
6org.xradar.test.b.b21
7org.xradar.test.e1
8java.io
9java.lang
10java.util
11org.xradar.test.a.suba
12sun.io