Metrics for JDBV project

Uday Kayle

I2CS Student

We used the Netbeans tool to take the metrics. Steps for using it –

  1. Download and install the Netbeans IDE from
  2. Download the metrics module from Just save this .nbm file for now.
  3. Now start up the IDE and open Tools->UpdateCenter to install this metrics module.
  4. Restart IDE after installation completes and to collect the metrics, just select the path to source code in Explorer window and run Tools->Metrics on it. Information on how to use it is available at

General information about the metrics module is at

Following is a snapshot of the metrics reported by the Netbeans tool for our source code -

Weighted Methods per Class (WMC) –

WMC for a class is defined as the sum of complexities of methods in the class. The possible method complexities include 1 (number of methods), Lines of code, Number of method calls and Cyclomatic complexity. This is a per class metric that is an indicative of the overall complexity of that class.

The Netbeans tool uses Cyclomatic complexity. Cyclomatic complexity is the number of branches or control statements in a method + 1. It is a good estimate for the number of tests required for that method. If this number is too high, it means that the method is very sensitive to change and we should probably have the tasks of that method distributed, or ‘refactor’ the method. Using cyclomatic complexity to calculate WMC helps deciding whether the class needs refactoring as a whole.

Classes with large number of methods are more likely to be application specific and less reusable. So we plan to run the metrics after each iteration of the project. The numbers thrown by the metric give us a good indication of the complexity of each class and if we do not want to have that much complexity for a class, then we can review some of the classes. For example, the class ‘edu.uiuc.jdbv.JDBV’ has a WMC of 20, but that is justified as it is the main control class – the starting point of the application – so it is bound to be much complex cyclomatically. This is not true for all classes though, and we will have to evaluate the numbers for all the classes to identify those which are complex, but need not be and correct them, if required.

Coupling Between Objects (CBO) –

CBO is the number of classes to which a class is coupled. A class A is said to be coupled to another class B, if there is a method in class A that calls some method in class B. More coupling means that there is a lot of binding between the classes. This makes the overall design hard to change and the classes hard to reuse as the tight bonding between them makes the classes less flexible to change.

We plan to run this metric after each iteration of the project and have the results analyzed.

The class ‘edu.uiuc.jdbv.diagram.Diagram’ has a CBO value of 31, which is pretty high relative to the other classes, but that is justified by the very nature of the class as it holds a lot of control objects and a lot of ‘util’ classes to manage the GUI, so this high number is also justified. We will have to evaluate the numbers for all the classes this way on a regular basis to find out the trouble spots in the source code.

Other metrics that are measured by this tool are – Response for Class (RFC), Methods per Class (MPC), Depth in Tree (DIT), Number of Children (NOC).