IEEE TRANSACTIONS ON SOFTWARE ENGINEERING (CONFERENCE) ,VOL. 14, NO.
2, APRIL 2011
Analysis of Quality of Object Oriented Systems using Object Oriented Metrics
N. Kayarvizhy
Assistant, Professor, Department of Computer Science
AMC Engineering College
Bangalore, India
e-mail: kayarvizhy@gmail.com
Abstract—Measurement is fundamental to any engineering
discipline. There is considerable evidence that object-oriented
design metrics can be used to make quality management
decisions. This leads to substantial cost savings in allocation of
resources for testing or estimation of maintenance effort for a
project. C++ has always been the most preferred language of
choice for many object oriented systems and many object
oriented metrics have been proposed for it. This paper focuses on
an empirical evaluation of object oriented metrics in C++. Two
projects have been considered as inputs for the study - the first
project is a Library management system for a college and the
second is a graphical editor which can be used to describe and
create a scene. The metric values have been calculated using a
semi automated tool. The resulting values have been analyzed to
provide significant insight about the object oriented
characteristics of the projects.
Keywords- Object Oriented Metrics, C++, Cohesion,
Coupling, Inheritance
I. INTRODUCTION
Object oriented systems continue to share a major portion
of software development and customer base for these
systems is on the rise. This is because there are huge
incentives in taking the object oriented approach. The
drawback though is that most object oriented systems tend to
be quite complex. Hence, the quality of such systems takes
precedence and lots of time, money and effort is spent in
ensuring it. One such method that predicts quality of a
software system is by evaluating key attributes of the
software through the use of metrics. Software quality is
especially a favored area when it comes to prediction based
on metrics. The introduction and subsequent use of metrics as
a means to evaluate the software quality has had deep and
useful impact on the overall system. But the success of
software quality assessment through metrics is hampered by
the need for constant validation to ensure the accuracy of such
predictions.
In this paper, an attempt is made to use software metrics as
a predictor for software characteristics of the underlying
system. The study consists of calculating and analyzing
object oriented metrics on two object oriented systems
developed using C++. The following section represents a
review of related work. Section III discusses the description of
the study and provides more details on the projects
considered. Following that Section IV describes the analysis of
the results and the findings. Section V, summarizes the
___________________________________
978-1-4244 -8679-3/11/$26.00 ©2011 IEEE
203
S. Kanmani
Professor and Head, Department of Information
Technology, Pondicherry Engineering College,
Pondichery, India
e-mail: kanmani@pec.edu
study undertaken and presents conclusions. Following that
are appendix and references.
II. RELATED WORK
A lot of object oriented metrics have been proposed in
the literature [1]. Chidamber and Kemerer (1991) proposed
six measures which are the most widely used design
measures for object oriented systems focusing on class and
class hierarchy. After the inception of the CK metric suite,
many have introduced new class level design metrics. Li and
Henry (1993) introduced a set of measure for the
maintenance of OO system and are validated by regression
analysis. Lorenz and Kidd (1994) categorized class measures
into four broad categories as size, inheritance, internals and
externals. Abreau et al. (1996) proposed a set of metrics,
which can be applied at system level. Briand et al. (1997)
introduced set of coupling measure for C++. Xenos et al.
(2000) surveyed the existing OO measures and evaluated
them. Thus there are so many sets of metrics proposed in the
literature. Each metric captures a particular dimension of the
project and some might end up capturing the same dimension.
There is no definite set of metrics that has been proposed.
Several empirical validation studies have been attempted
for various object oriented metric sets [3], [5], [6], [7], [8],
[9], [10]. The general conclusion is that these metrics are
important indicators of external quality factors. Few other
works like [2], [11], [12], [13] give preliminary statistical
analysis of CK and MOOD metrics for Eiffel and C++ based
projects. Li and Henry [14] explored the link between OO
design metrics (including metrics from the CK suite) and the
extent of code change, which they used as a surrogate
measure for maintenance effort. Similarly, based on an
investigation of coupling measures (including CBO) and the
NOC metric of the CK suite in two university software
applications, Binkley and Schach [15] found that the
coupling measure was associated with maintenance changes
made in classes due to field failures. Based on a study of eight
medium-sized systems developed by students, Basili et al. [16]
found that CK metrics were associated with fault proneness
of classes. On similar lines, initial validation studies on CK
metrics by Briand et al. [18] and Tang et al. [19] indicated
that design metrics from the CK suite were positively
associated with fault proneness of classes' description of the
empirical study.
Though many validation efforts have been done on C++
projects, a replicated study is still required to establish the
significance of the object oriented metrics in predicting the RFC 2 17 4.56 4.77 2 16 7.63 4.17
characteristics of object oriented systems. RFC1 1 17 4.11 5.01 2 14 6.38 4.17
MPC 0 12 2.00 3.84 0 10 2.38 3.89
III. DESCRIPTION OF EMPIRICAL STUDY DAC 0 2 0.22 0.67 0 4 .63 1.41
DAC' 0 2 0.22 0.67 0 1 .25 .46
A. Data Set ICP 0 5 0.98 1.58 0 0.48 .17 .19

Two projects developed in C++ have been considered for
this study. Both of them were developed by students doing
their graduation degree. The requirements were clearly
specified to them. The students considered for this project
were beginners in object oriented systems development and
did not have prior experience in developing object oriented
systems. The first project is "Library Management System" for
a college. The requirement specification was obtained from
the existing Library management software and was used for
this project. The next project is a "Graphical Scene Creator"
which can be used to define and draw a scene comprised of
basic shapes. Both the projects were monitored
for their use of object oriented features in the design phase to
avoid a procedural oriented approach.
From the Table I above, the CBO values are low for both
the projects, which indicate that the classes in the projects are
not too much dependent on each other. The RFC metric also
has reasonable values depicting that the system does not
spawn many messages in response to a message posted to it.
This directly implies that testing and debugging these
projects are not too difficult. From the graph below it can be
noted that Project 2 is slightly on the higher side with the
coupling values especially when inheritance is also
considered like CBO'. This implies that Project 2 is slightly
more complex compared to Project 1.
9
8
7

The 'Library Management Project' had 9 classes and the 6

Metric Values

'Graphics Scene Creator' had 8 classes. The lines of code were 5 Project 1
4 Project 2
also comparable between the two projects. 3
2
1
B. Object Oriented Metrics Considered 0
CBO CBO' RFC RFC1 MPC DAC DAC' ICP

The metrics considered for this study have been listed in Coupling Metrics

Appendix. Only class level metrics have been considered.

The metrics chosen are a subset from the author1's previous Figure 1. Coupling Metrics Graph.
study [4].
B. Evaluation Results for Cohesion Metrics
C. Data Collection Procedure The cohesion metrics are actually inverse in nature -
The metrics were calculated using a semi automated meaning they measure the lack of cohesion. High cohesion
approach. A tool was specifically developed for this purpose. indicates good class subdivision. The following table
The details of the classes, attributes, methods and their usage provides the values for the various cohesion metrics for the
were provided to the tool which then calculated the various two projects.
metrics based on this input
TABLE II. COHESION METRICS
IV. ANALYSIS RESULTS Project 1 Project 2

A. Evaluation Results for Coupling Metrics Metric Min Ma Avg SD Min Ma Mea SD
x x n
The coupling metrics provides insight on how the classes LCOM1 0 3 .33 1 0 5 1.25 2.31
are dependent on each other. Strong coupling complicates a LCOM2 0 0 0 0 0 0 0 0
system, since a module is harder to understand, change, or
LCOM3 1 1 1 0 1 2 1.25 .46 .
correct by itself if it is interrelated with other modules. The
more independent a class is, the easier it is to reuse it in LCOM4 1 1 1 0 1 2 1.25 46 .
another application. The larger the number of couples is, the TCC 1 1 1 0 . 1 . 15 .
higher the sensitivity to changes in other parts of the design LCC 1 1 1 0 66 . 1 92 . 15
will be leading to difficulty in maintainability. The following 66 92
table provides the values for the various coupling metrics for
the two projects considered for the study. In the table above we see that the values tend to be
generally lower for both the projects which mean that
TABLE I. COUPLING METRICS cohesion is actually higher. High cohesion is associated with
several desirable traits of software engineering like
Project 1 Project 2
Metric Min Ma Avg SD Min Ma Mea SD robustness, reliability, reusability and understand-ability. As
x x n in the case of coupling here too cohesion is slightly lesser for
CBO 2 7 3.11 1.76 2 7 3.75 1.83
Project 2 in most cases with LCOM1 being quite high
CBO' 0 2 0.44 0.73 1 16 1.75 1.75

204
 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING (CONFERENCE) ,VOL. 14, NO. 2, APRIL 2011

1.4 2.5

1.2
2
1

Metric Values
Metric Values

1.5
0.8 Project 1 Project 1

0.6 Project 2 Project 2

1
0.4
0.5
0.2

0 0
LCOM1 LCOM2 LCOM3 LCOM4 TCC LCC DIT AID CLD NOC NOP NOD NOA NMO NMI NMA
Cohesion Metrics Inheritance Metrics

Figure 2. Cohesion Metrics Graph. Figure 3. Inheritance Metrics Graph.

C. Evaluation Results for Inheritance Metrics V. CONCLUSION AND FUTURE WORK

The Inheritance metrics provide details on the various In this study, object oriented metrics have been measured
inheritance attributes. High degree of inheritance is for two C++ projects under the three categories of coupling,
detrimental to the health of the system while too less cohesion and inheritance. The metrics were then analyzed and
inheritance might miss out on the advantages of object used to understand the various characteristics of the systems.
oriented concepts. While there is no hard rule on the amount of The conclusion that could be drawn from this study was that
inheritance, logical conclusion can be derived by measuring both the projects showed good use of object oriented
them. The following table provides the values for the various features and resulted in highly cohesive, loosely coupled
inheritance metrics. classes. It was also found that of the two projects, the second
project taken for the study, Graphical Scene
TABLE III. INHERITANCE METRICS Creator showed metrics which implied that it was slightly
Project 1 Project 2 more complex. This was the case since it had virtual
Metri polymorphism and had more interactions between the classes
c Mi Ma Av SD Mi Ma Mea SD than the Library Management System.
n x g n x n This study hence not only helped to get some
DIT 0 2 .89 .78 0 2 1 .76
AID
understanding of the systems but also proved that the
0 2 . . 0 2 1 .
metrics were good at evaluating the system.
CLD 0 2 89 . 78 . 0 2 . 76 . This study can be followed up with another which
NO 0 2 56 . 73 . 0 4 38 . 74 includes the model necessary to map the metrics to software
C 67 87 75 1.4 quality. Another future study prospect would be to have the
0 1 0 1 9 data set as projects with identical requirements done in
NOP 0 4 .67 .50 0 6 .75 .46 different object oriented languages. This would help us to
NOD .89 1.3 1 2.1 ascertain that the metrics are capable of predicting the quality of
0 2 0 2
6 4 software across the object oriented language.
NOA 0 1 .89 .78 0 4 1 .76
NMO .22 .44 2.13 1.8
1
NMI 0 3 1.7 1.3 0 4 1.63 1.6 VI. APPENDIX
8 9 0
NMA 0 6 1.3 2.2 0 3 .50 1.0
3 4 7 A. Coupling Metrics
CBO: A class is coupled with another if the methods of one
The inheritance values listed above for both the projects class use attribute or methods of another class (or vice versa).
indicate that inheritance has been used moderately in both the CBO is the number of classes coupled to this class
projects. The graph below indicates that between the projects
the values are similar except NMO which is high for Project 2. CBO': Same as CBO, but inheritance based coupling is not
Since Project 2 is a graphical scene creator, most of the base counted
class methods were pure virtual functions which
had to be implemented and thus overridden in child classes. RFC: Response set of a class consists of set of methods of
the class and the methods directly or indirectly invoked by
methods. It is the set of methods that can be potentially
executed in response to message received by the class

RFC1: Same as RFC except that methods indirectly invoked

are not counted

205
MPC: Message Passing Coupling - The number of method
invocations in a class
DAC: Data Abstraction Coupling: The number of attributes
in a class that have their type as another class
DAC': The number of different classes that are used as types
of attributes
ICP: Information Flow Based Coupling - The number of
method invocation in a class weighted by number of
parameters of invoked methods.
B. Cohesion Metrics
LCOM1: Lack of cohesion in methods - The number of
pairs of methods in the class using no attribute in common
LCOM2: LCOM1 minus number of pairs of methods that use
common attribute. When difference is negative it is set
to zero
LCOM3: Make an undirected graph with methods as
vertices and edges between them if there is a common
attribute used. LCOM3 is the number of connected
components in graph
LCOM4: Same as LCOM3 but edge is also considered if
method invokes another method
TCC: Tight Class Cohesion - Percentage pairs of methods
which directly or indirectly use and attribute
LCC: Loose Class Cohesion: Same as TCC but methods
indirectly connected are also considered
C. Inheritance Metrics
AID: Average inheritance depth of a class is zero for root
and average of AID of the parents for others classes
CLD: Class to leaf depth is the maximum number of levels
in the hierarchy that are below the class
NOC: Number of children of a class
NOP: Number of parents of a class
NOD: Number of descendants of a class
NOA: Number of ancestors of a class
NMO: The number of methods in a class that override an
inherited method from ancestor class
NMI: The number of methods in a class that are inherited
from ancestors and not overridden
NMA: The number of new methods in a class added
206
REFERENCES
[1] M. Xenos and D. Stavrinoudis and K. Zikouli and D. Christodoulakis,
"Object-oriented metrics - a survey", proceedings of the FESMA 2000,
Federation of European Software Measurement Associations, Madrid,
Spain, 2000.
[2] S.R. Chidamber, C.F. Kemerer, "Towards a Metrics Suite for Object
Oriented design", in A. Paepcke, (ed.) Proc. Conference on Object-
Oriented Programming: Systems, Languages and Applications
(OOPSLA' 91), October 1991. Published in SIGPLAN Notices, 26 (11),
197-211, 1991.
[3] Chidamber, S. and Chris Kemerer, F., A Metrics Suite for Object
Oriented Design, IEEE Transaction on Software Engineering, 1994,
Vol. SE-20.no.6, 476-493. 1994
[4] S. Kanmani, V. Sankaranarayanan and P. Thambidurai, "Object-
oriented software fault prediction using neural networks,"
Information and Software Technology 2006.
[5] Saida Benlarbi, Khaled El-Emam, Nishith Goel, and Shesh Rai,
Thresholds for object-oriented measures, Proceedings of the 11th
International Symposium on Software Reliability Engineering,
Washington, DC, USA, 2000, page 24
[6] Audun Foyen, Dynamic coupling measurement for object-oriented
software. IEEE Transaction on Software Engineering, 2004, pp 491 -
506.
[7] Lutz Prechelt, Barbara Unger, Michael Philippsen, and Walter Tichy.,
A controlled experiment on inheritance depth as a cost factor for code
maintenance. System. Software, 2003, pp 115-126.
[8] Chidamber, K. R., David Darcy, P. and Chris Kemerer, F.,
Managerial use of metrics for object-oriented software: An exploratory
analysis. IEEE Transaction on Software Engineering, 1998, pp 629 - 639.
L. Lavazza, G. Denaro and M. Pezze. An empirical evaluation of
[9] object oriented metrics in industrial setting, November, 5th CaberNet
Plenary Workshop, 2003
Khaled El-Emam, Walcelio Melo, and Javam Machado, C., The
[10] prediction of faulty classes using object-oriented design metrics,
System Software., 2001, pp 3-75
Victor Basili, R., Lionel Briand, C. and Walcelio Melo, L., A
[11] validation of object-oriented design metrics as quality indicators, IEEE
Transaction on Software. Engineering., 1996, 22(10):751-761.
Abreu, F. B., Esteves, R. and Goulao, M., The Design of Eiffel
[12] Programs: Quantitative evaluation using the MOOD metrics,
Proceedings of TOOLS'96, USA, July 1996
Abreu, F. B., Miguel Coulao, and Rita Esteves, "Towards the design
[13] quality evaluation of object-oriented software systems". In
Proceedings of the 5th International Conference on Software Quality,
Austin, Texas, USA, October 1995.
Rachel Harrison, Steve Counsell, J. and Reuben Nithi, V., An
[14] evaluation of the mood set of object-oriented software metrics. IEEE
Transaction on Software. Engineering, 1998, 24(6):491-49
Li. W. and Henry, S., Object Oriented Metrics that Predict
[15] Maintainability, J. Systems and Software, Vol. 23, pp. 111-122, 1993.
Binkley, A. and Schach, S., Validation of the Coupling Dependency
[16] Metric as a Predictor of Run-Time Failure and Maintenance Measures,
Proceedings of 20th International Conference in Software
Engineering, pp.452-455, 1998
Cartwright, M. and Sheppered, M., An Empirical Investigation of an
[17] Object-Oriented Software System, IEEE Transactions of Software
Engineering, pp 259-262, 2009
J.M. Bieman, B.-K. Kang, "Cohesion and Reuse in an Object-
[18] Oriented System", in Proc. ACM Symp. Software Reusability (SSR'94),
259-262, 1995.
Briand, L. C., Wuest, J., Ikonomovski, S. and Lounis, H.,
[19] Investigation of Quality Factors in Object-Oriented Designs: An