Introduction

Object-Oriented programming design and development methods have been widely adopted in the software industry. This has created a strong need for assessing the quality of OO software systems. In deed, just as Object-Oriented programming requires a different approach compared to traditional imperative programming, software metrics must differ from traditional software metrics. 
The most widely known and used set of Object Oriented metrics is the Chidamber and Kemerer Metrics Suite (also called CK Metrics Suite). 
The Chidamber and Kemerer Object-Oriented metrics aim to measure design and code quality by investigating the coupling among classes, the cohesion within classes, complexity of classes and the complexity of the inheritance hierarchy. 
The CK Metrics Suite is composed of 6 metrics, which are described in details in this document:

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

High values of the CK metrics have been shown to be correlated with:

• Low productivity
• High effort to reuse classes
• High effort to design and implement classes
• Number of maintenance changes
• Number of faults
• User reported problems.

These metrics are typically being used to:

• Detect Design Anomalies,
• Support Iterative Development and Refactoring (Agile Development Methods),
• Measure Quality as part of a Quality Program.

To support these uses, this document provides the definition of each metric along with viewpoints to help interpret results and potential refactorings (metrics are then used as code smells to detect potential refactoring candidate classes).

Table of content

The CK Metrics Suite

The CK Metrics Suite is composed of 6 metrics described in this chapter:

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

WMC is a complexity metric.
DIT and NOC are inheritance metrics.
CBO and RFC are communication / coupling metrics.
LCOM is a cohesion metric.

 Weighted Methods per Class (WMC)

 Definition

This metric investigates the complexity of the class.
The Weighted Methods per Class metric is defined as the sum of all the class method's cyclomatic complexity.

 Viewpoints

The number of methods and complexity of methods is an indicator of how much time and effort is required to develop and maintain the object.
Objects with large number of methods are likely to be more application specific, limiting the possible reuse.
It is also important to note that the larger the number of methods in a class, the greater the potential impact on the children (classes that inherit from it).
High Weighted Methods per Class can denote that the class concentrates complex or important business logic.

 Refactoring

Classes with very high number of methods can be good candidates for the following refactorings:

• "Move method" to a component class (with a delegation from the existing class to the component class)
• "Extract Class" (the original class is split into two or more classes),In this case, it can be interesting to check the LCOM metric to detect if there is low cohesion for this class. A correlation between LCOM and WMC (low cohesion and high number of methods) would favor a split to improve design.

A good practice is also to use ReportCenter or CAST AppMiner to check if High Weighted Methods per Class is due to a single very complex method. To improve maintainability and reusability, one can decide to refactor that method (Delegate, new methods). 
Another good practice is called Trend Analysis. Trend Analysis consists of monitoring WMC to check if the numbers are growing or not. Growing complexity numbers then help decide for a refactoring.

Depth of Inheritance Tree (DIT)

 Definition

This metric investigates complexity of the inheritance hierarchy.
The depth of inheritance of a class is defined as the number of ancestor levels in the inheritance tree.

 Viewpoints

The deeper a class is in the hierarchy, the more methods it is likely to inherit, making it more complex. Deeper inheritance trees indicate greater design complexity.
On the other hand, very low numbers of DIT across an entire application indicates a lack of use of inheritance. The consequence of this a low level of code reuse and low maintainability of the application.

 Refactoring

Deep inheritance trees (usually DIT higher than 5) should be redesigned for the sake of simplicity using one of these refactoring (when applicable):

• Collapse Hierarchy
• Replace Inheritance with Delegation

However, studies as well as CAST experience have shown that usually there is generally a lack of use of inheritance (mainly first generation OO applications?). If low DIT numbers for an entire application correlates with several classes having high complexity or coupling number, this is an indicator that the application can benefit from the use of inheritance to improve code comprehension, reuse and ease of change.

Number Of Children (NOC)

 Definition

This metric investigates complexity of the inheritance hierarchy.
The Number Of Children (NOC) is the number of immediate sub-classes of the class.

 Viewpoints

Depth is generally better than breadth in class hierarchy, since it promotes reuse of methods through inheritance. 
Not all classes should have the same number of sub classes. Classes higher up in the hierarchy should have more sub-classes then those lower down. 
NOC gives an idea of the potential influence a class has on the design. Classes with large number of children may require more testing.

Coupling Between Object classes (CBO)

 Definition

This metric investigates the coupling among classes.
The Fan-out of a class, C, is the number of other classes that are referenced in C
A reference to another class, A, is a reference to a method or a data member of class A.
In the fan-out of a class multiple accesses are counted as one access. 
The Coupling Between Object classes (CBO) is equal to the fan-out of a class.

 Viewpoints

Excessive coupling between objects is detrimental to modular design and prevents reuse. The more independent an object is, the easier it is to reuse it in another application.
In order to improve modularity and promote encapsulation, inter-object couples should be kept to a minimum.
The larger the number of couples, the higher the sensitivity to changes in other parts of the design and therefore maintenance is more difficult.

 Refactoring

High CBO numbers might indicate that a class has to many responsibilities. Such a class is potential candidate for a refactoring where the class would delegate some the responsibilities to other classes or new classes ("Extract Class", "Extract Method"). This will increase modularity and reusability. 
When refactoring with architecture in mind, the CBO metric can be used to check classes running on the application client that have high coupling. These classes are then good candidate for a refactoring towards the Session Façade pattern:
http://java.sun.com/blueprints/patterns/SessionFacade.html

Response for a Class (RFC)

 Definition

This metric investigates the coupling among classes.
Response For a Class is complementary to Coupling Between Objects metrics. It counts all methods that can be invoked in response to a message to an object of the class. 
The definition of the metrics is the following: 
RFC = NLM + NRM where 
NLM = number of local methods in the class
NRM = number of remote methods called by methods in the class. 
A given remote method is counted only once.

 Viewpoints

The larger RFC implies longer and more complicated testing and debugging. The RFC metric

 Refactoring

Refactorings proposed for High CBO can also be proposed for high RFC classes.

Lack of Cohesion in Methods (LCOM)

 Definition

This metric investigates cohesion within a class.Intuitively, Cohesion refers to the internal consistency within parts of the design (i.e. class). 
LCOM is measure of the interrelatedness of a class's interface. Low cohesion indicates that the class does many different things. High cohesion suggests a class is a good conceptual "chunk", a good abstraction. 
LCOM is implemented using Henderson-Sellers (1995) definition as original CK definition was ill formed and Henderson-Sellers one is easier to compute. 
Henderson-Sellers LCOM definition:
Consider a set of m methods, M₁ , M₂ ,... , M_m The methods access a data attributes, A₁ , A₂ ,... , A_aLet m(A_k) = number of methods that access data A_k
Then 
 
High Cohesion Example - LCOM = 0
At maximum cohesion LCOM* = 0.
As an example, if each method accesses all attributes then m(A_k) = m so 
 

Low Cohesion Example - LCOM = 1
At minimum cohesion LCOM* = 1.
As an example, if each method accesses only one attribute and a different attribute then we have:

 Lack of Cohesion in Methods 2 (LCOM 2)

Addition to LCOM, LCOM2 does not take into account methods that do not access any field. The threshold is a parameter and can be changed at will.

Henderson-Sellers LCOM definition:
Consider a set of m methods, M₁ , M₂ ,... , M_m The methods access a data attributes, A₁ , A₂ ,... , A_aLet m(A_k) = number of methods that access data A_k
Then 

where, a= number of attribute , m = Number of method(s) which access at-least one attribute.

           sum(ma): it is summation of methods over attributes  i.e. SUM of [ attribute a(1) access no. of method(s) + a(2) access no. of method(s)+ ... so on].

Possible Scenario:

                         When a (Number of attribute)=3,

                         Number of method(s)=3,

                         But only one methods access all three attributes, Thus m=1

                          summation(m(a))= SUM OF [ 1+1+1] i.e. = 3

                         Then, LCOM2=((1/3*3)-1)/1-1=0/0 --> impossible to process, therefore by default the value is set to 100% to mean there is no cohesion

 Viewpoints

Cohesiveness of methods within a class is desirable, since it promotes encapsulation.
Lack of cohesion implies classes should probably be split into two or more sub/classes.
This measure of disparateness of methods helps identify flaws in the design of classes. 
Low cohesion increases complexity, thereby increasing the likelihood of errors during the development process.

 Refactoring

LCOM is the most interesting metric from the point of view of refactoring. 
Classes that have LCOM close to 1 (very low cohesion) are usually either:

• Proxy classes that have no or few class attributes and only redirect methods calls to other classes in order for example to control access (also called Delegate),
• Function Libraries (old functional programming practice),
• Classes having unused attributes,
• Classes implementing too many concepts.

Refactoring will mainly target classes implementing too many concepts. This can be due either to an original design flaw or to a deteriorated design (methods and attributes addition during maintenance, base class doing to much for its sub-classes). 
When a class is implementing too many concepts, it should be redesigned using one of the following refactorings:

• Extract Class,
• Extract Method,
• Add Super Class,
• Add Sub Class.

To help decide for the best refactoring as well as to help implement these complex refactorings, we recommend using CAST AppMiner to visualize graphically the inner workings of the class (the relation between methods and attributes).
For more details about using CAST products for Refactoring using refer to:
Refactor Java applications using CAST Application Mining Suite

References

A Metrics Suite for Object Oriented Design
Chidamber, S.R. and C.F. Kemerer
IEEE Transactions on Software Engineering, 1994. 20(6): p. 476-493. 
Object-Oriented Metrics: Measures of Complexity
Brian Henderson-Sellers
Prentice Hall; ISBN: 0132398729 
Refactoring: Improving the Design of Existing Code
Martin Fowler
Addison-Wesley Pub Co; ISBN: 0201485672 
The Refactoring Home Page
http://www.refactoring.com/ 
CAST Solutions - Refactor Java applications using CAST Application Mining Suite
Mark Brooks, CAST