Purpose

Background

Introduction

Applicable Scenarios 

Case Study Candidate

Scope

Analysis

• Preparing the workspace.
• Analyzing versions of JFreechart source code one by one.
• Answering the questions.

• 1. Download the source code of Jfreechart versions. 
• 2. Install Analyst4j - Plugin of Eclipse 3.1 [or above] or Analyst4j Standalone. 
• 3. Open Eclipse and enter a new workspace path (for e.g., C:\MetricsCaseStudy).
• 4. Create a Java Project using ant build scripts or manually for each version of JFreechart. The workspace should resemble as follows.
  
• 

Analyzing versions of JFreechart source code one by one

• 1. Right click on a project node (for e.g., jfreechart-0.9.15) in the "Package Explorer" and choose "Analyst4j->Analyze" in the context menu.
• 
• 2. In the dialog box that follows the above action, Select/Un Select packages/files which are not to be included in the analysis. In our case, we have excluded all "*.junit" packages from the analysis.
• 
• 3. Click "Finish" to kick start the source code analysis.
• 
• 4. When the analysis complete, the following analysis report is displayed.
• 

• 5. Perform the steps 1 - 3 for all the versions in our case study one by one.

Quality Analysis Results

The following analysis reports are possible once we complete analyzing all the four version of our case study.

General  Project Analysis Report Comparison

Comparing some of the metrics in the analysis reports of the case study gives us a higher level view of the changes that has gone through the versions. The following table (Table1) represent the changes in our case study.

Download Complete Report(rtf)  

It can observed that effort (HE) increases with new versions and maintainability(MI) is slightly reducing. However maintainability is way ahead of the guideline threshold of 65, and that maintainability is tolerant considering the change in effort(HE) and NLOC across versions.

Measuring Design Changes / Regression

We shall attempt to use one ore more automated software metric to evaluate and understand the design changes at different level of code. The levels being Project , Package , Class & Method . 

Project Level: Amongst other measurements, higher level design changes can be measured by measuring increase / decrease in number of Packages, Interfaces and Max Depth of Inheritance. The following table (Table2) represents these measurements.

It can be observed that

1. DIT i.e maximum depth of inheritance tree of the project has remained same across all the versions and this is a good indicator that since inception of the project there has been no major changes in the design.
2. There has been no change in design in pre-release (jfreechart-1.0.1-pre1) and the release (jfreechart-1.0.1) for the fact that No.Of Package, No.Of Interfaces and DIT have remained constant between these versions.
3. In general it can be said that though there are design changes to meet various functional/feature additions, the original design concept has remained intact throughout these versions.

Package Level: To understand package level design changes, a quality analysis graph of number of interface vs number of classes gives instant visibility of changes that has happened across the version.

It can be observed that

1. There is a visible difference in the  package org.jfree.data (the distinct red square on the top right of the above graph), had around 34 interfaces in jfreechart-0.9.15 and that in subsequent versions it has been distributed into one or more sub packages. We can understand from the Tabel2 , that the total number of interfaces had always been increasing with each newer version.
2. The package org.jfree.chart.renderer (red square on the left top of the above graph) which had 55 classes(concentrated implementation) has been distributed into more sub-packages in the subsequent versions(dilution).

Class Level: If design patterns are best practices to be followed during design, antipatterns on the other hand find faulty design patterns.  Analyst4j introduced the idea of identifying antipatterns in Java using software metrics, the following graph is an application of the idea to the case study.

It can be observed that

1. Referring to the total number of classes of each version in Table1, it can be understood that though there was a decline in number of classes in jfreechart-1.0.1-pre1(388) compared to jfreechart-0.9.15(480) the number of antipatterns classes have increased. This indicates that there has been high consolidation effort amongst these versions and a similar pattern can be seen when the system moved from jfreechart-1.0.1-pre to jfreechart-1.0.1.
2. Swiss Knife Classes have remained same 2nd and 3rd version and we could see an addition(SpiderWebPlot Class) in the latest version. This means that SpiderWebPlot has undergone rapid functionality addition or it is totally new in the latest version.

Method Level: One way to understand design changes / regression in methods is to measure its structuredness(Essential Complexity) and complexity (Cyclomatic Complexity). The following graph represents the number of methods whose CC(Cyclomatic Complexity) is greater than 40 and EC(Essential Complexity) > 1. The fundamental in the thresholds being that we want to find structural changes in highly complex methods across versions.

Search using metrics

Search results across projects graph, shows increase in unstructured code across versions.

It can be observed that:

1. Spaghetti code or unstructuredness is slowly increasing with each newer version.
2. Although unstructured code is not a good sign for good maintainability, under inevitable circumstances such code could be known exceptions. Also, the graph reveals that there is no sudden increase of spaghetti code which is a good sign maintainable code.

Measuring Effort Change
We shall attempt to use one or more automated software metric to evaluate and understand the effort changes at different level of code. The levels being Project , File , Class & Method.

Project Level: The following table (Table 3) represents list of effort change (using Halstead Effort) across the four versions of our case study.

It can be observed that:

1. Effort Increase indicates that there has considerable additions/improvement of functionality in the system.
2. The surge in effort in the latest version (jfreechart-1.0.1 to jfreechart-1.0.5) compared to previous effort increase (jfreechart-1.0.1-pre to jfreechart-1.0.1) indicates that there has been more additions / improvement lately.
3. Though the variation in Number of Analyzed Files suggests that some files were removed, the constant increase in Average Halstead Effort per file and Total Effort indicate that there has been some restructuring and that the functionality of the files where not actually removed.

File Level: To understand the change in effort at file level we plot a graph using NLOC Vs Halstead Effort in File, which should reveal file level difference in effort. The following QA graph is generated using Analyst4j represents the change in NLOC and HE for our case study.

We can track the changes in effort in two prominent cases

1. CategoryPlot.java, some amount of code had been removed/commented out in version jfreechart-1.0.1-pre1. The change in HE for CategoryPlot.java can be observed in the above graph.
2. XYPlot.java, effort on this file has always been increasing and that there is noticeable increase in HE in the latest version (jfreechart-1.0.5) compared to its previous version.

Class Level: Effort change at class level can be measured using Weighted Methods Per Class, the increase/decrease in WMC would reflect the changes made in a class. The following distribution graph of WMC across the four version of our case study gives us a picture of the changes.

Method Level: The following comparison analysis  graph of NLOC Vs Cyclomatic Complexity and Decision Density represent the effort changes across two versions of our case study(jfreechart-1.0.1 and jfreechart-1.0.5).

We can track changes in some prominent cases from the above graphs.

Decision Density: "draw" method of XYPlot class has increase in decision, "executeQuery" method of JDBCXYDataSet class has remained the same and "drawItem" method of CyclicXYItemRenderer class decision density has reduced.

Cyclomatic Complexity:  The complexity of "drawSide", "draw" methods of PiePlot3D have remained the same though there has been considerable reduction in NLOC. However the complexity of "draw" method of XYPlot has increased considerably.

Conclusion

The case study demonstrates that using software metrics during development or maintenance to evaluate the quality of code is found to be very useful to quickly understand the changes in the code.