328  Object-Oriented Software Engineering

On the basis of the above direct measures, we may design the following additional metrics so
that more useful information can be gained from the basic metrics:
1. Percentage of test cases executed
2. Percentage of test cases passed
3. Percentage of test cases failed
4. Total actual execution time/total estimated execution time
5. Average execution time of a test case

8.7 Object-Oriented Metrics

Object-oriented systems are rapidly increasing in the market. Object-oriented software
engineering leads to better design, higher quality and maintainable software. As the object-
oriented development is growing, the need for object-oriented metrics that can be used across the
software industry is also increasing. The traditional metrics, although applicable to object-oriented
systems, do not measure object-oriented constructs such as inheritance and polymorphism. This
need has led to the development of object-oriented metrics. In the following subsections, we
define coupling, cohesion, inheritance, reuse and size metrics for object-oriented systems.

8.7.1 Coupling Metrics

The degree of interdependence between classes is defined by coupling. During object-oriented
analysis and design phases, coupling is measured by counting the relationship a class has
with other classes or systems. Coupling increases complexity and decreases maintainability,
reusability and understandability. Hence, coupling should be reduced amongst classes and the
classes should be designed with the aim of weak coupling. The developer’s goal should be
to eliminate extraneous coupling (Henderson-Sellers, 1996). Chidamber and Kemerer (1994)
defined coupling as:
Two classes are coupled when methods declared in one class use methods or instance variables
of the other classes.

This definition also includes coupling based on inheritance. In 1994, Chidamber and Kemerer
defined coupling between objects (CBO). In their paper, they defined CBO as the count of the
number of other classes to which a class is coupled. The CBO definition given in 1994 includes
inheritance-based coupling. For example, consider Figure 8.25. Two variables of other classes
(class B and class C) are used in class A; hence, the value of CBO for class A is 2. Similarly, for
class B and class C, the value of CBO is zero.

Figure 8.25 Values of CBO metric for a small program.

 Software Quality and Metrics  329
Li and Henry (1993) used the data abstraction technique for defining coupling. Data
abstraction provides the ability to create user-defined data types called abstract data types
(ADTs). Li and Henry defined data abstraction coupling (DAC) as:
DAC = Number of ADTs defined in a class
In Figure 8.25, class A has two ADTs (i.e. two non-simple attributes) objB and objC. Li and
Henry defined another coupling metric known as message passing coupling (MPC) as “the
number of unique sent statements in a class”. Hence, if four different methods in class A access
the same method in class B, then MPC is 4 as shown in Figure 8.26.

Figure 8.26 Example of MPC metric.

Chidamber and Kemerer (1994) defined response for a class (RFC) metric as a set of methods
defined in a class and called by a class. It is given by RFC = | RS |, where RS, the response set
of the class, is given by:
RS = Mi  all j{Rij}
where Mi = set of all methods in a class (total n) and Ri = {Rij} = set of methods called by Mi.
For example, in Figure 8.27, the RFC value for class A is 9 and the method for calculating it is
explained in the given example.

Class consists of four functions: A1, A2, A3, A4

A1 calls B1 and B2 of class B
A2 calls C1 of class C
A3 calls D1 and D2 of class D
Thus, RFC = | RS |
Mi = {A1, A2, A3, A4}
Rij = {B1, B2, C1, D1, D2}
RS = {A1, A2, A3, A4, B1, B2, C1, D1, D2}
RFC = 9

Figure 8.27 Example for RFC metric.

A system level metric, coupling factor, is also defined by Harrison et al. (1998). In 1997,
Briand et al. (1997) gave a suite of 18 metrics that measured different types of interaction
between classes. These metrics may be used to guide software developers about which type of
coupling affects maintenance cost and reduces reusability. Briand et al. (1997) observed that the
coupling between classes can be divided into different facets:
330  Object-Oriented Software Engineering

1. Relationship: It refers to the type of relationship between classes—friendship,

inheritance, or other.
2. Export or import coupling: This identifies whether class A uses methods/variables of
other class B (import).
3. Type of interaction: Briand et al. identified three types of interaction between classes—
class-attribute, class-method and method-method.
(i) Class-attribute (CA) interaction: For example, consider Figure 8.28, class A
consists of two non-simple attributes objA and objB of type class B and class C,
respectively. Thus, if there is any change in class B and/or class C, class A will be
affected.
(ii) Class-method (CM) interaction: If the parameter of class B is passed as argument
to method of class A, the type of interaction is said to be class-method. For example,
consider class A given in Figure 8.28. There is a CM interaction between method
A1 and class B as method A1 uses the object of class B as parameter.
(iii) Method-method (MM) interaction: If a method Mi of class Ci calls method Mj of
class Cj or method Mi of class Ci consists of reference of method Mj of class Cj as
arguments, then there is MM type of interaction between class Ci and class Cj. For
example, as shown in Figure 8.28, the method of class B calls method A1 of class
A; hence, there is an MM interaction between class B and class A.

class A
{
B objB;
C objC;
public:
void A1(B obj1)
{
}
};
class B
{
public:
void B1()
{
A objA
A1();
}
};
class C
{
void A2(B::B1)
{
}
};

Figure 8.28 Example for computing type of interaction.

 Software Quality and Metrics  331
The metrics for CA are FCAIC, ACSIC, OCAIC, FCAEC, DCAEC and OCEEC. In these
metrics, the first one/two letters signify the type of relationship (IF signifies inverse friendship,
A signifies ancestors, D signifies descendant, F signifies friendship, and O signifies others).
The next two letters signify the type of interaction (CA, CM, MM). Finally, the last two letters
signify import coupling (IC) or export coupling (EC).
Lee et al. (1995) differentiate between inheritance-based and non-inheritance-based coupling
by the corresponding measures: Non-inheritance information flow-based coupling (NIH-ICP),
and information flow-based inheritance coupling (IH-ICP). Information flow-based coupling
(ICP) metric was the sum of NIH-ICP and IH-ICP metrics. Lee et al. emphasized that their ICP
metric, based on method invocation, take polymorphism into account.

8.7.2 Cohesion Metrics

Cohesion is a desirable property of a class and should be maximized as it supports the concept of
data hiding. Low cohesive class is more complex and is more prone to faults in the development
life cycle. Chidamber and Kemerer (1994) proposed lack of cohesion in methods (LCOM) metric
in 1994. The LCOM metric measures the dissimilarity of methods in a class by finding the
attributes used by the methods.
It calculates the difference between the number of methods that have similarity zero and
the number of methods that have similarity greater than zero. If the difference is negative, then
the value of LCOM is zero. The larger the similarity between methods, the more cohesive is the
class. For example, a class consists of four attributes (a1, a2, a3 and a4). The method usage of the
class is given is Figure 8.29.

M1 = {a1, a2, a3, a4}

M2 = {a1, a2}
M3 = {a3}
M4 = {a3, a4}
M1  M2 = 1
M1  M3 = 1
M1  M4 = 1
M 2  M3 = 0
M2  M4 = 0
M3  M4 = 1
LCOM = 2 – 4, hence, LCOM = 0

Figure 8.29 Example of LCOM metric.

Henderson-Sellers (1996) observed some problems in the definition of LCOM metric

proposed by Chidamber and Kemerer in 1994. The problems were as follows:
1. A number of real examples showed the value of LCOM as zero due to the presence
of dissimilarity amongst methods. Hence, while a large value of LCOM suggests low
cohesion, the zero value does not necessarily suggest high cohesion.
2. No guideline for interpretation of the value of LCOM was given by Chidamber and
Kemerer. Thus, Henderson-Sellers revised the LCOM value. Consider m methods
332  Object-Oriented Software Engineering

accessing a set of attributes Di (i = 1, ..., n). Let the number of methods that access each
datum be m(Di). The revised LCOM1 metric is given as:
n
1
N
 m (Di ) - m
i =1
LCOM1 =
1- m
Beiman and Kang (1995) defined two cohesion metrics: tight class cohesion (TCC) and loose
class cohesion (LCC). The TCC metric is defined as the percentage of pairs of directly connected
public methods of the class with common attribute usage. The LCC metric is the same as TCC,
except that it also considers indirectly connected methods. A method M1 is said to be indirectly
connected with method M3, if M1 is connected to method M2 and method M2 is connected
to method M3. Hence, indirectly connected methods represent transitive closure of directly
connected methods. Consider the source code of a queue class given in Figure 8.30 (Beiman
and Kang, 1995).

class queue
{
private:
int *a;
int rear;
int front;
int n;
public:
queue(int s)
{
n=s;
rear=0;
front=0;
a=new int[n];
}
int empty()
{
if(rear==0)
{
return 1;
}
else
{
return 0;
}
}
void insert(int);
int remove();
int getsize()

Figure 8.30 (Contd.)

 Software Quality and Metrics  333

{
return n;
}
void display();
};
void queue::insert(int data)
{
if(rear==n)
{
cout<<“Queue overflow”;
}
else
{
a[rear++]=data;
}
}
int queue::remove()
{
int element,i;
if(empty())
{
cout<<“Queue underflow”;
getch();
}
else
{
element=a[front];
for(i=0;i<rear-1;i++)
{
a[i]=a[i+1];
}
rear--;
}
return element;
}
void queue::display()
{
int i;
for(i=0;i<rear;i++)
{
cout<<a[i]<<“ “;
}
getch();
}

Figure 8.30 Source code for implementing queue class.

Figure 8.31 shows the attribute usage of methods. The pair of public functions with common
attribute usage is given below:
{(empty, insert), (empty, remove), (empty, display), (getsize, insert), (insert, remove),
   (insert, display), (remove, display)}
334  Object-Oriented Software Engineering

Thus,
7
TCC(Queue) = ¥ 100 = 70%
10
The methods empty and getsize are indirectly connected, since empty is connected to insert and
getsize is also connected to insert. Thus, by transitivity, empty is connected to getsize.
Thus,
10
LCC(Queue) = ¥ 100 = 100%
10

Figure 8.31 Attribute usage of methods of class queue.

Lee et al. (1995) proposed information flow-based cohesion (ICH) metric. ICH for a class is
defined as the weighted sum of the number of invocations of other methods of the same class,
weighted by the number of parameters of the invoked method. In Figure 8.31, the method remove
invokes the method empty which does not consist of any arguments. Thus, ICH (Queue) = 1.

8.7.3 Inheritance Metrics

The inheritance is measured in terms of depth of inheritance hierarchy by many authors in
the literature. The depth of a class within an inheritance hierarchy is measured by depth of
inheritance tree (DIT) metric given by Chidamber and Kemerer (1994). It is measured as the
number of steps from the class node to the root node of the tree. In the case of involving multiple
inheritances, the DIT will be the maximum length from the node to the root of the tree. Consider
Figure 8.32. The value of the DIT metric for class D is 2.

Figure 8.32 Inheritance hierarchy.

 Software Quality and Metrics  335
The average inheritance depth (AID) is calculated as (Yap and Henderson-Sellers, 1993):

AID =
 Depth of each class
Total number of classes
In Figure 8.32, the depth of subclass D is 1.5 [(2 + 1)/2].
The AID of overall inheritance structure is: 0(A) + 1(B) + 0(C) + D(1.5) + E(1) + 0(F) = 3.5.
Finally, dividing by the total number of classes, we get 3.5/6 = 0.58.
Number of children (NOC) metric counts the number of immediate subclasses of a class
in a hierarchy. In Figure 8.32, the NOC value for class A is 1 and for class E it is 2. Lorenz
and Kidd developed number of parents (NOP) metric which counts the number of classes
that a class directly inherits (i.e. multiple inheritance) and number of descendants (NOD) as
the number of subclasses of a class (both directly and indirectly). Number of ancestors (NOA)
given by Tegarden and Sheetz (1992) counts the number of base classes of a class (both directly
and indirectly). Hence, in Figure 8.32, NOA(D) = 3 (A, B, C), NOP(D) = 2 (B, C) and NOD(A)
= 2 (B, D).
Lorenz and Kidd (1994) gave three measures: number of methods overridden (NMO),
number of methods added (NMA) and number of methods inherited (NMI). When a method
in a subclass has the same name and type (signature) as in the superclass, then the method in
the superclass is said to be overridden by the method in the subclass. NMA counts the number
of new methods (neither overridden nor inherited) added in a class. NMI counts the number of
methods a class inherits from its superclasses. Finally, Lorenz and Kidd use NMO, NMA and
NMI metrics to calculate specialization index (SIX) as given below:
NMO ¥ DIT
SIX =
NMO + NMA + NMI

Consider the source code given in Figure 8.33. The class student overrides two methods of class
person—readperson() and displayperson(). Thus, the value of the NMO metric for class student
is two. One new method is added in this class (getaverage). Hence, the value of NMA metric is 1.
Similarly, for class GradStudent, the value of NMO is 2, NMA is 1 and NMI is 1
(getaverage( )). The value of SIX for class GradStudent is given by
2¥2 4
SIX = = =1
2 +1+1 4

The maximum number of levels in the inheritance hierarchy which is below the class is measured
through class to leaf depth (CLD). The value of CLD for class person is 2.

8.7.4 Reuse Metrics

An object-oriented development environment supports design and code reuse, the most
straightforward type of reuse being the use of a library class (of code), which perfectly suits the
requirements. Yap and Henderson-Sellers (1993) discuss two measures designed to evaluate the
level of reuse possible within classes.
336  Object-Oriented Software Engineering

class Person {
protected:
char name[25];
int age;
public:
void readperson();
void displayperson();
};
class Student extends Person{
protected:
roll _ no[10];
float average;
public:
void readstudent();
void displaystudent();
float getaverage();
};
class GradStudent extends Student{
private:
char subject[25];
char working[25];
public:
void readit();
void displaysubject();
void workstatus();
};

Figure 8.33 Source code to demonstrate use of inheritance.

The reuse ratio (U) is given by

Number of superclasses
U =
Total number of classes

Consider Figure 8.33, the value of U is 2/3. Another metric is specialization ratio (S), which is
given by
Number of subclasses
S=
Number of superclasses

In Figure 8.33, number of subclasses = {Student, GradStudent} and number of superclasses =

{Person, Student}. Thus, S = 1.
Aggarwal et al. (2009) proposed another set of metrics for measuring reuse by using generic
programming in the form of templates. The metric function template factor (FTF) is defined as
the ratio of the number of functions using function templates to the total number of functions as
shown below:
Number of functions using function templates
FTF =
Total number of functions
 Software Quality and Metrics  337
Consider a system, with methods F1, ..., Fn. Then,
n
 uses_FT(Fi )
i =1
FTF = n
 Fi
     i =1

Ï1, iff function uses function template ¸

where, uses_FT(Fi ) = Ì ˝
ÓÔ 0, otherwise ˛Ô

void function1(){
.........}
template<class T>
void function2(T &x, T &y){
.........}
void function3(){
........}
Figure 8.34 Source code for calculating metric FTF.

In Figure 8.34, the value of metric FTF = 1/3.

The metric class template factor (CTF) is defined as the ratio of the number of classes using
class templates to the total number of classes as shown below:
Number of classes using class templates
CTF =
Total number of classes

Consider a system, with classes C1, ..., Cn. Then,

n
 uses_CT(Ci )
i =1
CTF = n
 Ci
  i =1

Ï1, iff class uses class template ¸

where, uses_CT(Ci ) = Ì ˝
ÔÓ 0, otherwise Ô˛

class A{
.....};
template<class T, int size>
class B{
T arr[size];
....};
Figure 8.35 Source code for calculating metric CTF.

In Figure 8.35, the value of metric CTF = 1/2.

338  Object-Oriented Software Engineering

8.7.5 Size Metrics

Several traditional metrics are applicable to object-oriented systems. The traditional LOC metric
is a measure of the size of a class (refer to Section 8.3.1). Halstead’s software science and McCabe’s
measures for measuring size are also applicable to object-oriented systems; however, the object-
oriented paradigm defines a different way of doing things. This has led to the development of
size metrics applicable to object-oriented constructs. Chidamber and Kemerer defined weighted
methods per class (WMC) metric given by:
n
WMC = Â Ci
i=1

where M1, ..., Mn are methods defined in class K1 and C1, ..., Cn are the complexity of the methods.
The number of attributes (NOA), given by Lorenz and Kidd, is defined as the sum of the
number of instance variables and number of class variables. Number of methods (NOM) given
by Li and Henry (1993) is defined as the number of local methods defined in a class. They also
gave two additional size metrics SIZE1 and SIZE2 besides the LOC metric given as:
SIZE1 = number of semicolons in a class
SIZE2 = NOA + NOM

8.7.6 Popular Metric Suites

The number of recognized metric suites is limited in the literature. The object-oriented metrics
that have widely gained attention are summarized as follows:
1. Metric suite consisting of six metrics is proposed by Chidamber and Kemerer (1994).
This metric suite has received widest attention in the literature. The metric suite along
with the constructs it measures is summarized in Table 8.12.

Table 8.12 Chidamber and Kemerer metrics

Metric Definition Construct being measured
CBO Coupling between objects Coupling
WMC Weighted methods per class Size
RFC Response for a class Coupling
LCOM Lack of cohesion in methods Cohesion
NOC Number of children Inheritance
DIT Depth of inheritance Inheritance

2. Li and Henry (1993) investigated Chidamber and Kemerer metrics and proposed a suite
of five metrics. These metrics are summarized in Table 8.13.
 Software Quality and Metrics  339
Table 8.13 Li and Henry metric suite
Metric Definition Construct being measured
DAC Data abstraction coupling Coupling
MPC Message passing coupling
NOM Number of methods Size
SIZE1 Number of semicolons
SIZE2 Number of attributes + NOM

3. Beiman and Kang (1995) proposed two cohesion metrics LCC and TCC.
4. Lorenz and Kidd (1994) proposed a suite of 11 metrics. These metrics address size,
coupling, inheritance, etc. and are summarized in Table 8.14.

Table 8.14 Lorenz and Kidd metric suite

Metric Definition Construct being measured
NOP Number of parents Inheritance
NOD Number of descendants
NMO Number of methods overridden
NMI Number of methods inherited
NMA Number of methods added
SIX Specialization index

5. Briand et al. (1997) proposed a suite of 18 coupling metrics. These metrics are
summarized in Table 8.15.

Table 8.15 Briand et al. metric suite

IFCAIC These coupling metrics count the number of interactions between classes.
ACAIC The metrics distinguish the relationship between the classes (friendship, inheritance,
OCAIC none), different types of interactions, and the locus of impact of the interaction.
FCAEC The acronyms for the metrics indicate what interactions are counted:
DCAEC  The first or first two characters indicate the type of coupling relationship between
OCAEC classes [A: Ancestor, D: Descendants, F: Friend classes, IF: Inverse Friends
IFCMIC (classes that declare a given class a as their friend), O: Others, i.e. none of the
ACMIC other relationships].
DCMIC  The next two characters indicate the type of interaction:
FCMEC CA: There is a Class-Attribute interaction if class x has an attribute of type class y.
DCMEC CM: There is a Class-Method interaction if class x consists of a method that has
OCMEC parameter of type class y.
IFMMIC MM: There is a Method-Method interaction if class x calls method of another class
AMMIC y, or class x has a method of class y as a parameter.
OMMIC  The last two characters indicate the locus of impact:
FMMEC IC: Import coupling, counts the number of other classes called by class x.
DMMEC EC: Export coupling, counts the number of other classes using class y.
OMMEC
340  Object-Oriented Software Engineering

6. Teagarden and Sheetz have proposed a large suite of metrics.

7. Lee et al. (1995) have given four metrics: one for measuring cohesion and three metrics
for measuring coupling (see Table 8.16).

Table 8.16 Lee et al. metric suite

Metric Definition Construct being measured
ICP Information flow-based coupling Coupling
IHICP Information flow-based inheritance coupling
NIHICP Information flow-based non-inheritance coupling
ICH Information based cohesion Cohesion

8. The system level polymorphism metrics are measured by Benlarbi and Melo (1999). These
metrics are used to measure static and dynamic polymorphism and are summarized in
Table 8.17.

Table 8.17 Polymorphism metrics

Metric Definition
SPA Static polymorphism in ancestors
DPA Dynamic polymorphism in ancestors
SP Static polymorphism in inheritance relations; SP = SPA + SPD
DP Dynamic polymorphism in inheritance relations; DP = DPA + DPD
NIP Polymorphism in non-inheritance relations
OVO Overloading in stand-alone classes
SPD Static polymorphism in descendants
DPD Dynamic polymorphism in descendants

9. Yap and Henderson-Sellers (1993) have proposed a suite of metrics to measure cohesion
and reuse in object-oriented systems.
10. Aggarwal et al. (2006) have proposed a set of two metrics (FTF and CTF) to measure
reuse in object-oriented systems.

Review Questions
1. What is software quality? Explain the various software quality attributes.
2. Define the following software quality attributes:
(a) Functionality
(b) Reliability
(c) Maintainability
(d) Adaptability
3. Establish the relationship between reliability and maintainability. How does one affect
the effectiveness of the other?