Metrics Definitions
Included is a brief discussion for each metric used for this project.
jMetra
LOC - Collected over time can show how each developer is doing on a relative scale. Effects of refactoring should be visible over time as we see code growing and shrinking relative to time. This can also show the complexity of the code as more developers get added.
Method Count - Shows the complexity of each class or grouping of classes (a package). This can show how the classes have grown in functionality over time or possibly become more modularized. When this data is coupled with LOC one can see the effects of refactoring verses complexity.
Class Count - Shows how the project is growing through abstractions and their implementations. Useful in understanding how many pieces within a package are required to work together. One can also analyze how the original architecture (if layed out by class up front) has morphed or mangled overtime.
JMT
Coupling between objects-Number of classes, which are coupled with this class. Classes are coupled, if one class uses methods or attributes of the other class, CBO inside of JMT.CBO is described in Chidamber/Kemerer [1]. A high degree of coupling between objects can make application maintenance more difficult, as increasing numbers of interactions between classes relate to increasing difficulty in thorough testing. Also, high degrees of coupling may suggest a pair of classes that ought to be merged into a single class to maximize cohesion. Finally, excessive coupling between classes is detrimental to modular design and is an obstacle to reusability; the more independent a class is, the easier it is to take advantage of it again it in another application.
Fields per class-Number of attributes of the considered class. Recorded as weighted attributes per class (WAC) inside of JMT. We measured the number of methods and fields per class so we could search for ways to reduce complexity in our classes individually and our application as a whole. A health balance is sought; classes that seem too large by these measures might be candidates for separation, while large collections of tiny classes might be candidates for composition.
Public interface for class-Number of public methods in each class. This metric counts the number of methods within each class that are publicly accessible. There are several benefits to gathering this metric: Classes with large public interfaces will tend to be heavily used classes, and will merit extra testing consideration. Also, classes with excessively large interfaces may be responsible for too much, and be candidates for separation. Finally, by comparing the number of public methods to the overall number of methods in a class, we can determine if methods have been properly simplified; a class in which each method is responsible for a single operation will tend to have a fair share of private helper methods which aid the public interface methods in carrying out their responsibilities.
Response set for class-Number of methods used by the class plus the methods of the class. Is the highest possible number of methods, which can be invoked by a message to this class.RFC is described in Chidamber/Kemerer [1]. Several methods produce side effects and consequences that are not immediately obvious. RFC helps to quantify the greater effect that a local change to a class could have, guiding developers towards prudence and consideration when such changes are attempted. It is our hope that by understanding the magnitude of effects a given change might have we can avoid the common pitfall of under-testing a modification we view as trivial, only to discover later on that the change had consequences in our application beyond our imaginings.
Weighted method per class-Number of methods of the considered class.
WMC
is described in Chidamber/Kemerer [1]. We
chose to use Cyclomatic Complexity as our weight, because we were measuring
methods per class elsewhere, and wanted to find classes that were overly
complex. We discovered that most
methods in our system are relatively simple.
In order to more quickly identify offending methods in the future, we
will simply measure the Cyclomatic Complexity of each method. This will avoid the step of discovering that a class has a
high WMC value before searching for a complex method within that class, and will
point us directly to our most complex methods.
JMetrics
Cyclomatic Complexity-See above, this is another view of complexity.
LOC - Collected over time can show how each developer is doing on a relative scale. Effects of refactoring should be visible over time as we see code growing and shrinking relative to time. This can also show the complexity of the code as more developers get added. This is another view of the system, used since it's easier to tabulate.
Method Count - Shows the complexity of each class or grouping of classes (a package). This can show how the classes have grown in functionality over time or possibly become more modularized. When this data is coupled with LOC one can see the effects of refactoring verses complexity.
RMS
RMS provided in some cases slightly different results due to having different methods of tabulating some metrics. RMS also provides other useful metrics not currently used such as lines of logical code and lines of commented code.
Fields per class-See above
Methods per class-See above
Parameters per method-See above
Weighted methods per class-See above