1 The CKJM Plugin

1.0.1 Description

The program ckjm calculates Chidamber and Kemerer object-oriented metrics by processing the bytecode of compiled Java files. The program calculates for each class the following six metrics proposed by Chidamber and Kemerer.

  • WMC: Weighted Methods per Class
  • DIT: Depth of Inheritance Tree
  • NOC: Number Of Children
  • CBO: Coupling Between Object classes
  • RFC: Response For a Class
  • LCOM: Lack of COhesion in Methods

In addition it also calculates for each class

  • Ca: Afferent Couplings
  • NPM: Number of Public Methods

1.0.2 Metrics

The metrics ckjm will calculate and display for each class are the following.

WMC - Weighted methods per class A class's weighted methods per class WMC metric is simply the sum of the complexities of its methods. As a measure of complexity we can use the cyclomatic complexity, or we can abritrarily assign a complexity value of 1 to each method. The ckjm program assigns a complexity value of 1 to each method, and therefore the value of the WMC is equal to the number of methods in the class.

DIT - Depth of Inheritance Tree The depth of inheritance tree (DIT) metric provides for each class a measure of the inheritance levels from the object hierarchy top. In Java where all classes inherit Object the minimum value of DIT is 1.

NOC - Number of Children A class's number of children (NOC) metric simply measures the number of immediate descendants of the class.

CBO - Coupling between object classes The coupling between object classes (CBO) metric represents the number of classes coupled to a given class (efferent couplings, Ce). This coupling can occur through method calls, field accesses, inheritance, arguments, return types, and exceptions.

RFC - Response for a Class The metric called the response for a class (RFC) measures the number of different methods that can be executed when an object of that class receives a message (when a method is invoked for that object). Ideally, we would want to find for each method of the class, the methods that class will call, and repeat this for each called method, calculating what is called the transitive closure of the method's call graph. This process can however be both expensive and quite inaccurate. In ckjm, we calculate a rough approximation to the response set by simply inspecting method calls within the class's method bodies. This simplification was also used in the 1994 Chidamber and Kemerer description of the metrics.

LCOM - Lack of cohesion in methods A class's lack of cohesion in methods (LCOM) metric counts the sets of methods in a class that are not related through the sharing of some of the class's fields. The original definition of this metric (which is the one used in ckjm) considers all pairs of a class's methods. In some of these pairs both methods access at least one common field of the class, while in other pairs the two methods to not share any common field accesses. The lack of cohesion in methods is then calculated by subtracting from the number of method pairs that don't share a field access the number of method pairs that do. Note that subsequent definitions of this metric used as a measurement basis the number of disjoint graph components of the class's methods. Others modified the definition of connectedness to include calls between the methods of the class. The program ckjm follows the original (1994) definition by Chidamber and Kemerer. Ca - Afferent couplings A class's afferent couplings is a measure of how many other classes use the specific class. Ca is calculated using the same definition as that used for calculating CBO (Ce).

NPM - Number of Public Methods The NPM metric simply counts all the methods in a class that are declared as public. It can be used to measure the size of an API provided by a package.

1.0.3 Measurement details

The original definition of the metrics, and implementation details of both the program, and the Java language provide some leeway on how the metrics are measured. The following list contains the most important decisions.

  • Interfaces are measured when considering a class's coupling. Rationale: changes to the interface may well require changes to the class.
  • Use of Java SDK classes (java.*, javax.*, and some others) does not count toward a class's coupling. Rationale: the Java SDK classes are relatively stable, in comparison to the rest of the project. A command line argument switch (-s) is available for including the Java SDK classes into the calculation.
  • Calls to JDK methods are included in the RFC calculation. Rationale: the method calls increase the class's complexity.
  • The classes used for catching exceptions contribute toward the class's coupling measurements. Rationale: at the point where an exception is caught a new object of the corresponding type is instantiated.
  • The complexity of each method is considered 1, when calculating WMC. Rationale: ease of implementation, and compatibility with Chidamber and Kemerer.
  • LCOM is calculated following the 1994 paper description, and not by looking at disjoint graph components. Rationale: ease of implementation, and compatibility with Chidamber and Kemerer.
  • RFC is calculated up to the first method call level, and not through the transitive closure of all method calls. Rationale: ease of implementation, and compatibility with Chidamber and Kemerer.
  • A class's own methods contribute to its RFC. Rationale: the original Chidamber and Kemerer article describes RFC as a union of the set of methods called by the class and the set of methods in the class.

1.0.4 Vendor

Diomidis D. Spinellis - http://www.spinellis.gr

1.0.5 Version

JCKJM Plugin 1.0.0-1

CKJM 1.8a

1.0.6 Homepage

http://www.spinellis.gr/sw/ckjm

1.0.7 Documentation

Documentation: http://www.spinellis.gr/sw/ckjm/doc/index.html

Printable Version: http://www.spinellis.gr/sw/ckjm/doc/indexw.html

JavaDoc: http://www.spinellis.gr/sw/ckjm/javadoc/index.html

1.1 Activation

1.1.1 Suitability

Suitable for any module with available compiled Java source code (class files) or binaries (JAR files).

External libraries needed to run the code must also be available.

1.1.2 Execution point

COMMAND build
TARGET pretest

1.1.3 Profiles

The profiles must be specified in the configuration in order to activate the plugin.

The plugin profile can be used to enable specific plugins.

The bundle profiles can be used to enable a set of plugins within a specific category.

PLUGIN PROFILES ckjm
BUNDLE PROFILES java

1.2 Deactivation

If this plugin has been activated for a larger set of modules (at project or subsystem level), it is possible to disable it for specific modules using special properties:
NAME nockjm
DESCRIPTION To disable the ckjm execution for the current module

NAME notest
DESCRIPTION To disable all the plugins registered at TEST target (PRETEST, TEST, POSTTEST) for the current module

1.3 Input

1.3.1 Required properties

The required properties must be available in order for the plugin to run.

Some of the requires properties may have default values which correctness must be check to ensure the correct execution of the plugin.

NAME ckjm.class.location (java.class.location)
DESCRIPTION Root of the directory structure where the compiled Java files (.class) are placed according to their package definition. Needed only if the classes are needed for the execution of the tests and not already in the CLASSPATH. java.class.location can be used instead of ckjm.class.location to have a generic property that works with all the java plugins. All the .class files in directory structure will be added in the CLASSPATH.
DEFAULT VALUE ${src.location}/classes or if not present ${src.location}/build/classes
EXAMPLE Assuming the compilation output directory is ${location}/bin having files like ${src.location}/bin/org/my/package/MyClass.class, the property must be set as: ${src.location}/bin

NAME ckjm.jar.location (java.jar.location)
DESCRIPTION Directory containing the JAR files of the application, if available. Needed only if the JARs are needed for the execution of the tests and not already in the CLASSPATH. java.jar.location can be used instead of ckjm.jar.location to have a generic property that works with all the java plugins. The available JAR files will be added in the CLASSPATH.
DEFAULT VALUE ${src.location}/jars or if not present ${src.location}/build/jars
EXAMPLE Assuming the ANT script generates a JAR file in ${src.location}/build/jar/MyJarFile.jar, the property must be set as: ${src.location}/build/jar

-- FabioCapannini - 19-Sep-2011

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2011-09-19 - FabioCapanniniExternal
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback