SWE 439

Object-oriented design metrics

S. R. Chidamber and C. F. Kemerer, "A Metrics Suite for Object Oriented Design," IEEE Transactions on Software Engineering vol. 20, pp. 476-493, 1994.
W. Li, "Another metric suite for object-oriented programming," The Journal of Systems and Software, vol. 44, pp. 155-162, 1998.
 Objectives

 To introduce suites of object-oriented design metrics

 C&K
 Li

2
SWE 439

Object-oriented Design Metrics

S. R. Chidamber and C. F. Kemerer, "A Metrics Suite for Object Oriented

Design," IEEE Transactions on Software Engineering vol. 20, pp. 476-493, 1994.
 Weighted Methods per Class (WMC)

 If all method complexities are considered to be unity, then

 WMC = n, the number of methods.

4
 WMC: viewpoints

 The number of methods and the complexity of methods involved is a

predictor of how much time and effort is required to develop and maintain
the class.

 The larger the number of methods in a class the greater the potential
impact on children, since children will inherit all the methods defined in the
class.

 Classes with large numbers of methods are likely to be more application-

specific, limiting the possibility of reuse.

5
 Depth of Inheritance Tree (DIT)

 Definition: Depth of inheritance of the class is the DIT metric for the class.

 In cases involving multiple inheritance, the DIT will be the maximum length
from the node to the root of the tree.

A
DIT(A) = 0
B C DIT(B) = 1
DIT(C) = 0
D
DIT(D) = 2
E DIT(E) = 3
DIT(F) = 4
DIT (C211) = 3 F
Starting the root as 0 6
 DIT: viewpoints

 The deeper a class is in the hierarchy, the greater the number of methods
it is likely to inherit, making it more complex to predict its behavior.

 Deeper trees constitute greater design complexity, since more methods

and classes are involved.

 The deeper a particular class is in the hierarchy, the greater the potential
reuse of inherited methods.

7
 Number of Children (NOC)

 Definition: NOC is the number of immediate subclasses subordinated to a

class in the class hierarchy.

A
NOC(A) = 1
B C NOC(B) = 1
NOC(C) = 1
D NOC(D) = 2
NOC(E) = 1
E
NOC(F) = 0
DIT (C2) = 3
F
Class C2 has three children—
subclasses C21, C22, and C23 8
 NOC: viewpoints

 Greater the number of children, the greater the likelihood of improper

abstraction of the parent class. If a class has a large number of children, it
may be a case of misuse of subclassing.

 The number of children gives an idea of the potential influence a class has on
the design. If a class has a large number of children, it may require more
testing of the methods in that class.

 If the base contains errors/bugs, these will propagate to a larger number of

subclasses.

9
 Coupling Between Object classes (CBO)

 Definition: CBO for a class is a count of the number of classes that are
coupled to a particular class
 Where the methods of one class call the methods or access the variables of the other.
 These calls need to be counted in both directions, so the CBO of class A is the size of the
set of classes that class A references and those classes that reference class A.
 Since this is a set - each class is counted only once even if the reference operates in
both directions i.e., if A references B and B references A, B is only counted once.

 Coupling can occur through method calls, field accesses, inheritance,

arguments, and return types.

10
 CBO Example 1

CBO (A) = 2

B C D

CBO (B) = 2 CBO (C) = 3 CBO (D) = 1

11
 CBO Example 2
Book
Customer -orders Order -books
-title : String
-name : String -id : String -author : String
+computeCost() : double * +computeCost() : double * #price : double
+computeCost() : double

1 -creditCard
for (Order o: orders)
RegularBook EBook
o.computeCost(); CreditCardInfo
-shippingCost : double -discount : double
-number : long -sizeMB : int
+computeCost() : double
-expiration : Date +computeCost() : double

for (Book b: books)

CBO(Customer) = 2 b.computeCost();
CBO(Order) = 2 access #price
CBO(CreditCardInfo) = 1
CBO(Book) = 3
CBO(RegularBook) = 1
CBO(Ebook) = 1 12
 CBO: viewpoints

 Excessive coupling between object classes is harmful to modular design and prevents
reuse. The more independent a class is, the easier it is to reuse it in another application.

 In order to improve modularity and promote encapsulation, inter-object class 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.

 A measure of coupling is useful to determine how complex the testing of various parts of
a design is likely to be. The higher the inter-object class coupling, the more rigorous the
testing needs to be.

 High coupling has been found to indicate fault-proneness.

13
 Response For a Class (RFC)

 Definition: The response set of a class is a set of methods that can

potentially be executed in response to a message received by an object of
that class.

 That means all the methods in the class and all the methods that are called
by methods in that class. As it is a set each called method is only
counted once no matter how many times it is called.

 It is calculated by adding the number of methods in the class (not including

inherited methods) plus the number of distinct method calls made by the
methods in the class (each method call is counted only once even if it is
called from different methods).
14
 RFC Example 1

RFC (for Class A )= 6

methods in class A (3) + the methods that can be executed from the methods in class A (3)
15
RFC example 2

Suppose that class A has four methods:

A.m1 calls B.m2
A.m2 calls C.m1
A.m3 calls A.m4
A.m4 calls no method
M = {A.m1, A.m2, A.m3, A.m4}
R = {B.m2}  {C.m1}  {A.m4}  
RS = M  R = {A.m1, A.m2, A.m3, A.m4,
B.m2, C.m1}
RFC = |RS| = 6

16
 RFC: viewpoints

 If a large number of methods can be invoked in response to a message,

the testing and debugging of the class becomes more complicated since it
requires a greater level of understanding required on the part of the tester.

 The larger the number of methods that can be invoked from a class, the
greater the complexity of the class.

 A worst-case value for possible responses will assist in appropriate allocation

of testing time.

17
 Lack of Cohesion in Methods (LCOM)

 Cohesion metrics measure how well the methods of a class are related to
each other.

 LCOM:

18
 LCOM: Example 1

 Consider a class C with three methods M1,M2 and M3. Let {I1} = { a , b , c , d ,
e } and {I2} = { a , b , e } and {I3} = {x, y, z}. {I1} ∩ {I2} is nonempty, but {I1} ∩
{I3} and {I2} ∩ {I3} are null sets.

 LCOM is the (number of null intersections - number of nonempty

intersections), which in this case is 1.

number of null intersections = {M1,M3}, {M2,M3} = 2

number of nonempty intersections = {M1,M2} = 1

LCOM = max(2-1,0) = 1

19
 LCOM: Example 2

a1 a4

m1 m2 m3 m4

20
 LCOM: More examples

 LCOM =
number of null intersections = {M1,M3}, {M2,M3} = 2
number of nonempty intersections = {M1,M2} = 1
LCOM = max(2-1,0) = 1

 LCOM =
number of null intersections = {M1,M3} = 1
number of nonempty intersections = {M1,M2}, {M2,M3} = 2
LCOM = max(1-2,0) = 0

 What about when m1 accesses c?

number of null intersections = {}
number of nonempty intersections = {M1,M2}, {M1,M3}, {M2,M3} =
3
LCOM = max(0-3,0) = 0
Do you see any problem? 21
 LCOM: 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
subclasses.

 Low cohesion increases complexity, thereby increasing the likelihood of

errors during the development process.

22
SWE 439

Object-oriented Design Metrics

W. Li, "Another metric suite for object-oriented programming," The Journal of

Systems and Software, vol. 44, pp. 155-162, 1998.
 Evaluation of DIT metric

 The Depth of Inheritance Tree (DIT) metric is defined as “Depth of

inheritance of the class is the DIT metric for the class. In cases involving
multiple inheritance, the DIT will be the maximum length from the node to the
root of the tree”

 There are two ambiguous points in this definition.

 First, this definition is ambiguous when there are multiple inheritance and multiple
roots.
 Second, the viewpoints also stated that the DIT metric measures the number of classes
that can potentially affect a class.

24
 Evaluation of DIT metric (Cont’d)

 In Fig(b), is DIT(B) = 1 or DIT(B) = 2?

 In Fig(a), DIT(A) = DIT(B) = 2. However, class B inherits

from more classes than class A does.
25
 Number of Ancestor Classes (NAC)

 NAC measures the total number of ancestor classes from which a class
inherits in the class inheritance hierarchy.

 The unit for the NAC is “class”

26
 Evaluation of NOC metric

 The Number of Children (NOC) metric is defined as the “number of

immediate subclasses subordinated to a class in the class hierarchy”

 It is not clear why only the immediate subclasses of a class are counted
because a class has influence over all its subclasses, immediate or
nonimmediate.

27
 Number of Descendent Classes (NDC)

 The NDC metric is the total number of descendent classes (subclasses) of a

class.

 The unit for the NDC is “class”

28
 Evaluation of WMC metric

 The Weighted Method per Class (WMC) metric is defined as the sum of the complexity of a class’ local
methods.

 WMC is used with two intentions: (1) the count of local methods, and (2) the sum of the internal
complexity of all local methods.
 But these are two independent attributes of a class.

 If the WMC metric is used to measure the number of local methods of a class, the unit for WMC should
be “method”.

 If WMC is used to measure the total complexity of all local methods, the WMC metric should have the
same unit as the method‘s internal complexity
 E.g., Lines of Code (LOC) or number of independent paths in a method, if McCabe‘s Cyclomatic Complexity is
used to measure a method's complexity.

29
 Number of Local Methods (NLM)

 The NLM metric is the number of the local methods defined in a class.

 The unit for the NLM metric is “method”.

30
 Class Method Complexity (CMC)

 The CMC metric is the summation of the internal structural complexity of all
local methods.

 The unit for the CMC metric depends on the unit used to measure the
structural complexity of a method.

31
 Evaluation of CBO metric

 The Coupling Between Object Classes (CBO) metric is defined as “a count of

the number of other classes to which it is coupled”

 The unit for the CBO metric is “class”.

 A class can be coupled with other classes in three different forms

 Inheritance
 Abstract data type
 Message passing

32
 Coupling Through Abstract Data Type (CTA)

 The CTA metric is the total number of classes that are used as abstract data types in the
data-attribute declaration of a class.

 Two classes are coupled when one class uses the other class as an abstract data type.

 Consider the example in the figure below. Class B is coupled with class A through the use of
abstract data type because class B uses class A in its data-attribute declaration.

CTA (A) = 0
CTA (B) = 1

33
 Coupling Through Message Passing (CTM)

 The CTM metric measures the number of different messages sent out from a class to
other classes excluding the messages sent to the objects created as local objects in the
local methods of the class.
 Two classes can be coupled because one class sends a message to an object of another
class, without involving the two classes through inheritance or abstract data types.
 Consider the example in the figure below. Both classes A and B are in the same OO design,
class A is coupled with class B because one of A's methods sends a message to B's object.

CTM (A) = 1
CTM (B) = 0

34
SWE 439

Coupling and Cohesion Metrics

 LCOM (Li & Henry, 1993)

 The number of disjoint components in the graph that represents:

 Each method as a node
 The sharing of at least one attribute between two methods as an edge

a1 a4

m1 m2 m3 m4

m1 m2 m3 m4
𝑳𝑪𝑶𝑴 =𝟑

W. Li, and S. Henry, "Object-Oriented Metrics that Predict Maintainability," Journal of Systems
and Software, vol. 23, no. 2, pp. 111-122, 1993. 36
 LCOM (Hitz & Montazeri, 1995)

 The number of disjoint components in the graph that represents:

 Each method as a node
 The sharing of at least one attribute between two methods as an edge
 The presence of a method call between two methods as an edge

a1 a4

m1 m2 m3 m4

m1 m2 m3 m4
𝑳𝑪𝑶𝑴 =𝟏
M. Hitz, B. Montazeri, "Measuring Coupling and Cohesion In Object-Oriented Systems," Proc.
37
Int. Symposium on Applied Corporate Computing, Monterrey, Mexico, Oct. 1995.
 LCOM (Henderson-Sellers, 1996)

 Let m be the number of methods in a class.

 Let a be the number of instance variables in the class.
 Let p(Ai) be the number of methods that access instance variable Ai.

a1 a2 a3 a4

m1 m2 m3 m4
B. Henderson-Sellers, L. Constantine, and I. Graham, "Coupling and Cohesion (Towards a Valid Metrics Suite for
Object-Oriented Analysis and Design)," Object-Oriented Systems, vol. 3, no. 3, pp. 143-158, 1996. 38
 Coh (Briand et al., 1998)

 Let m be the number of methods in a class.

 Let a be the number of instance variables in the class.
 Let p(Ai) be the number of methods that access instance variable Ai.

a1 a2 a3 a4

m1 m2 m3 m4
Briand, L. C., Daly, J. W., & Wüst, J. (1998). A unified framework for cohesion measurement in object-
oriented systems. Empirical Software Engineering, 3(1), 65–117. 39
 Tight Class Cohesion (Bieman & Kang, 1995)

 The relative number of directly connected pairs of methods. Two methods are
directly connected if they are directly connected to an attribute.
 A method m is directly connected to an attribute, when the attribute appears
 within m's body or
 within the body of a method that is directly or transitively invoked by method m.

Access a1 Access a3 Access a3

a1 a2 a3 a4
𝟒
𝑻𝑪𝑪 =
𝟔
m1 m2 m3 m4

m1 m2 m3 m4 Access a3
J. M. Bieman, and B.-K. Kang, "Cohesion and reuse in an object-oriented system," Proc.
40
Symposium on Software reusability (SSR '95), pp. 259-262, 1995.
 Loose Class Cohesion (Bieman & Kang, 1995)

The relative number of directly or transitively connected pairs of

methods. Two methods are transitively connected if they are indirectly
connected to an attribute.
 A method m, which is directly connected to an attribute j, is
indirectly connected to an attribute i when there is a method X that
is directly or transitively connected to both attributes i and j.

j i

m X

J. M. Bieman, and B.-K. Kang, "Cohesion and reuse in an object-oriented system," Proc.
41
Symposium on Software reusability (SSR '95), pp. 259-262, 1995.
 TCC vs. LCC example

Access a1 Access a3 𝟐
𝑻𝑪𝑪 =
𝟔
a1 a2 a3 a4
m1 m2 m3 m4

m1 m2 m3 m4
m1 m2 m3 m4

𝟑
𝑳𝑪𝑪=
𝟔
m2 accesses both a1 and a3
m3 is indirectly connected to a1
m1 is indirectly connected to a3 42
 Class Cohesion (Bonja & Kidanmariam, 2006)

 Ratio of the sum of the

similarities between all pairs of
methods to the total number of a1 a2 a3 a4
pairs of methods.
 The similarity between methods
mi and mj is defined as
 Where Ii and Ij are the sets of
m1 m2 m3 m4
attributes referenced by methods
mi and mj, respectively

𝟏
𝟐 𝟏
𝑪𝑪 = =
C. Bonja, and E. Kidanmariam, "Metrics for class cohesion and similarity between methods," 𝟔 𝟏𝟐
ACM Southeast Regional Conference, pp. 91-95, 2006.
43
 Cohesion Metrics

J. Al Dallal, "Measuring the Discriminative Power of Object-Oriented Class Cohesion Metrics," in IEEE Transactions on Software Engineering, vol. 37, no. 6, pp. 788-804,
Nov.-Dec. 2011 44
 Coupling Metrics

Jehad Al Dallal, “Empirical Exploration for the Correlation between Class Object-Oriented Connectivity-Based Cohesion and Coupling”, International Journal of Computer
and Information Engineering, Vol:9, No:4, 2015 45
 Coupling relation taxonomy

Enrico Fregnan, Tobias Baum, Fabio Palomba, Alberto Bacchelli, “A survey on software coupling relations and tools”, Information and Software
Technology, Volume 107, 2019, Pages 159-178, 46
 Summary

 Several OO Design metrics exist

 C&K metrics suite is the most popular OO metrics suite
 Li metrics suites tends to address some limitation of C&K suite

47