Software Maintenance: Role of metrics and Smells
in object oriented softwares
Junaid Ali Reshi
Center for Computer Science and Technology
Central University of Punjab
Bathinda, India
jreshi14@gmail.com
Abstract—Software maintenance has been a topic of great
interest to both the Industry and academics. There have been
various efforts in improving the software life through various tools
and techniques. This paper examines the essence of software
metrics and bad smells in software maintenance. The study
considers various standard metrics and smells and examines the
role they play in software maintenance. The study concludes that
the software metrics have been used for defect prediction in quite
a number of researches whereas code smells are predominantly
used for refactoring and have been undermined when it comes to
defect prediction.
Keywords—code smells; defect prediction; machine learning;
software metrics
I. INTRODUCTION
Software maintenance is the longest phase of a successful
software lifecycle. The definition of software maintenance
as given in the IEEE Standard for Software Maintenance [1]
is as follows: “The totality of activities required to provide
cost-effective support to a software system. Activities are
performed during the pre-delivery stage as well as the post-
delivery stage”. This, in essence, means that any activity that
concerns software system after or before its release is
software maintenance. Further, the document defines four
different types of maintenance tasks:
 Adaptive maintenance is defined as: “The modification
of a software product, performed after delivery, to keep
a software product usable in a changed or changing
environment.”
 Corrective maintenance is defined as: “The reactive
modification of a software product performed after
delivery to correct discovered problems.”
 Perfective maintenance is defined as: “The
modification of a software product after delivery to
detect and correct latent faults in the software product
before they are manifested as failures.”
 Preventive maintenance is defined as: “The
modification of a software product after delivery to
detect and c orrect latent faults in the software product
before they become operational faults”
Satwinder Singh
Center for Computer Science and Technology
Central University of Punjab
Bathinda, India
satwindercse@gmail.com
Apart from these maintenance activities, emergency
maintenance, listed as a part of corrective maintenance is
defined as “An unscheduled modification performed to
temporarily keep a system operational pending corrective
maintenance”. Further down the line, maintainability of a
software system is defined as “The capability of the software
product to be modified. Modifications may include corrections,
improvements or adaptation of the software to changes in
environment, and in requirements and functional specifications”
As software maintenance is a continuous process that exists
throughout the overall lifespan of a software product, software
development organizations aim to design the software products
that are easy to maintain. There are various factors that help in
effective software maintenance by detecting the code anomalies
and their symptoms. More specifically, the prediction of faults
through metrics, or possible flaws in the software systems
through code smells helps in maintainability of a software. Code
smell, a symptom of poor design and implementation choice, has
been found to have significant effect on software
maintainability. Technically, code smells do not hamper the
software system functionality but they tend to increase the risk
of system failure in future. Likewise, software metrics, the
measure of different parameters of the software code, have also
been found to be effective in predicting faults in a software
system through the development of various defect prediction
models.
Metric rules and static code analysis have been employed to
design various tools for the detection of code smells [2], [3],
[4].Some studies have been conducted to determine the side
effects of code smells on software maintainability [5], [6], [7],
change-proneness [8], [9] and understandability [10]. In their
study, Yamashita and Moonen [7] have investigated the
relationship between certain inter-smells with some problems
during maintenance which also include the introduction of
defects to the system.
II. LITERATURE REVIEW
Software maintainability has to be measured or quantified for
understanding it better and for making comparisons based on it.
There have been various efforts on developing metrics for
quantifying a software system. Various studies that have
provided with some software metrics claim their metrics to be a
good indicator of software maintainability. Researchers have
recently been focusing their studies on evaluating software
maintainability through a group of metrics. This approach seems
to be more feasible as it helps to correlate metrics with the
maintainability and thus gives a better understanding of the
relation between metrics and maintainability.
We will focus on the object-oriented systems only and study the
various metrics and their effects on the object-oriented systems.
A. Object-Oriented metrics: Coupling and Cohesion
The main motive under object oriented programming is to
create a single unit of functionality, known as class, which
contains data and the methods. Metrics as quality is used in
several studies such as done by Basili et al. [11]. One of the
pioneering work in proposing a metrics suite for object-oriented
system has been done by Chidamber and Kemerer [12].The
metrics suite designed by them contained the following metrics:
Weighted Methods Per Class, Depth of Inheritance Tree,
Number of Children, Coupling Between Object Classes,
Response for a Class, and Lack of Cohesion Methods.
The concept of cohesion and coupling were introduced by
Stevens et al. [13] who were researchers at the IBM. Their
concept still holds and is an important factor in the object-
oriented programming as some important metrics are derived
from their concept, which holds good till this day also. The term
coupling in object-oriented programming means the dependence
between classes and/or objects. Chidamber and Kemerer, in their
study, presented a coupling metric which they name as coupling
between object classes (CBO) and they define it as follows
“CBO for a class is a count of the number of other classes to
which it is coupled” [12]. They explain that when methods of
one class use the instance variables or methods of another class,
it leads to coupling [12]. Therefore, it can be inferred that CBO
is count of the number of classes that interact with the measured
class. However, Chidamber & Kemerer don’t mention the
intensity that measured class uses the methods or instance
variables of the other class, referred to as tightness of coupling
[12]. Ma, Chang,Cleland-Huang [14], in their study, discuss
coupling tightness in context to the object-to-object
programming.
In their work, [15] state that the provision of friend class in
C++ increases coupling as it allows a friend class to access other
class members. They further hint that Java’s package
mechanism is analogous to C++ friendship mechanism and
hence it also affects coupling. Some studies such as that of [11],
[15], [16], [17] suggest that some kinds of coupling have a
degree of correlation with fault metrics, though all of them not
being equally significant.
In object-oriented paradigm, two levels of cohesion can be
defined, functional (between methods) and class level (between
classes). Functional cohesion is easy to analyze while
quantifying the class level cohesion is slightly more difficult.
Grigg, while discussing [18] states that an indication that a class
is too big can be found by answering the question “what does
this class do?” and counting the and-words thereof. But, this
measure does not provide us an unambiguous measure for class
level 5. In their study, Chidamber and Kemerer (Chidamber &
Kemerer 1994) propose a class level cohesion metric called
Lack of Cohesion in Methods (LCOM), as the number of
method pairs whose similarity (measured through used instance
variables) equals zero minus the number of method pairs whose
similarity is not zero. This, again, does not imply the measure of
strength of lack of cohesion as the class which have the same
value (zero) for it can have different intensity of cohesion.
Class cohesion being a good fault predictor is still a topic of
interest. Some studies suggest that cohesion provides indication
about fault-proneness [17] whereas some claim that it has no
relation with it [11] [15]. Misic [19] suggests that coherence (his
name for cohesion) can be measured by the usage of the class in
question by external classes. In their paper, Counsell et al. [20]
discuss the difficulty of confining the definition of cohesion.
Li & Henry [21] conducted a study on the correlation of
maintenance effort and object-oriented metrics. They have used
the object-oriented metrics as given by Chidamber & Kemerer
[12]with slight modifications. They conclude the object-oriented
metrics under study can be used as maintenance predictors. On
the basis of their comparison, they conclude that object-oriented
metrics are better predictors of maintenance effort than simple
size metrics (such as lines of code) alone [12]. Gyimothy et al.
[22] used logistic regression and other machine learning
techniques to study and compare the efficiency of sets of
Chidamber and Kemerer metrics to predict fault-prone classes
within Mozilla. They concluded CBO being the most efficient
metric and that the performance of LOC to discriminate fault-
prone classes is also good. In another study, Bandi et al. [23]
suggest maintenance performance to be dependent on design
complexity, maintenance task, and programmer ability.
Cartwright and Shepperd [24] conducted an empirical study on
an industry based C++ system and suggested that among the
metrics suite given by Chidamber and Kemerer, DIT and NOC
metrics [12] could be used efficiently to find classes having
higher fault rates. Zimmermann et al. [25]conducted an
empirical research on Eclipse suggesting that the faults in a code
are directly proportional to the code complexity and that
combination of complexity metrics can predict faults efficiently.
El Emam et al. [16] in their study concluded that the correlation
between metrics and fault-proneness disappeared when size was
not taken into consideration. They thus suggest that many of the
metrics are correlated with the function of size and, therefore,
are not useful in providing information to predict fault
proneness.
B. Code Smells
Webster [26] made the first attempt to explain antipatterns
in object-oriented development. In his study, he focusses on the
conceptual, coding, and quality-assurance problems. Riel [27],
in order to improve design and implementation of an object-
oriented system, defined 61 heuristics to assess a system quality
manually. These heuristics define good object-oriented
characteristics and are somewhat similar to code smells. Fowler
[28], in one of his books defines 22 code smells. Mantyl [29] and
Wake [30] have also proposed some classifications for code
smells. In their study, Brown et al. [31] have described 40
antipatterns, mostly in terms of lower-level code smells. These
literatures present in-depth theoretical views on antipatterns,
heuristics and code smells and form the basis of many
approaches to specify and detect code smells, both manually or
through some models.
 There have been a lot of studies proposing different
approaches to identify and detect code smells and antipatterns.
These works propose different approaches ranging from manual
inspection based techniques [32], to metric based heuristics [33],
[34].In metrics based heuristics, code smells and–or antipatterns
are identified according to defined sets of rules and already
defined threshold values of various metrics. There have been
various studies where rules have been defined using fuzzy logic
and executed by means of a visualisation techniques [35] , [36]or
rule-inference engine [37].Studies like [38], [39] suggest
approaches performing fully automatic detection and using
visualisation techniques to present the detection results. Some
studies have suggested that using Semi-automatic approaches is
more productive and suitable.Using semi-automatic approaches
has been regarded as an interesting tradeoff between fully
automatic detection techniques which can be efficient but stray
away from the context, and manual inspections that need human
expertise and are comparatively slow and more subjective [40].
Fowler et al. identified 22 different code smells in his
book.Those 22 code smells are listed as:
 Duplicate code : According to Fowler et. al. [28],
duplicate code is the number one problem in smell
intensity among smells.They firther state that we
should try to unify the duplicate code in our
program.They discuss duplicacy at method level and
class level and suggest possible remedies to remove
duplicate code in different scenarios.
 Long Method: Whenever methods stretch too much in
their length, they are called as long methods.The long
methods have an inherent problem of
understandability,changeability and extensibility.
Fowler et al. [28] strongly suggest in decomposing
methods and keeping them short.They also suggest
how methods can be kept short to yield the benefits of
the Indirection.
 Large Class: According to Fowler et al., “A class
with too many instance variables, a class with too much
code is prime breeding ground for duplicated code,
chaos, and death” [28].They suggest different remedies
for removing redundancy in different cases pertaining
to a class.
 Long Parameter List : If the paramter list is too long
or changes often, it is bound to cause some problems.
Fowler et al. suggest to pass a method enough so that
the method gets to everything it needs.They suggest
some changes to reduce the number of parameters in
the argument list of a method.They also caution about
the scenario when to reduce dependency deliberate
long parameter list is used [28].
 Divergent Change: This is the type of smell that is
indicative of the fact that a class is changed frequently,
in different ways for different reasons. This reults in the
frequent change in the pattern of a class for entirely
different reasons (functionalities) of databases and
financial instruments and thus may cause problems in
aa software.
 Shotgun Surgery: This smell is prevalent when one
change requires altering of many classes. The process
to reduce this kind of smell will push the system
towards another smell, the divergent change. But, with
the right balance of it, the system can work efficiently.
 Feature Envy: This smell indicates that a method
seems more interested and involved in other class(es)
than the one where it is located currently.The most
common focus of a method like this is the data in other
classes. Therefore, this method can be regarded at
wrong place as it is more tightly coupled to some other
class than to the one where it is actually belongs.Fowler
et al. have listed various remedies to remove this kind
of smell [28].
 Data Clumps:This type of smell means some data
items in a software often appear together in different
classes,parameter and method signatures and that
removing one of the group’s data items renders them
meaningless.Fowler et al. suggest that a new object
creation is the remedy [28].
 Primitive Obsession: This kind of smell represents a
situation when primitives are used for small tasks,
instead of small classes. For example, to represent
money in a program, programmers are reluctant to use
a separate class that could encapsulate various
functionalities like currency conversion ,and tend to
use primitives thereby generating this smell.
 Switch Statements: This type of smell is associated
with the wrong use of switch (or case) statements
through duplication in the code.It should be noted that
mere presence of a switch operator does not imply a
smell. The smell originates in the case when type codes
or runtime class type detection are used as switch
determinants instead of polymorphism.
 Parallel Inheritance Hierarchies: This smell has
been regarded as a special case of shotgun surgery by
Fowler et al. .It is implied by a situation where parallel
class hierarchies exist and if we want to make some
changes in one classes hierarchy, it necessaciates
extension of both hierarchies.
 Lazy Class: A class that is not useful enough or has
ceased to be useful due to refactoring, non
implementaton of plans etc. comes under this
smell.Such a class should be removed with appropriate
action.
 Speculative Generality: This kind of smell is
generated when unnecessary code is added to the
system, anticipating the future augmentations in the
software. This leads to a code that is harder to maintain
and understand. Fowler et al. [28] suggest some
remedies for this kind of smell.
 Temporary Field: This smell is present when an
instance variable is making code difficult to
comprehend, as it is used in certain circumstances only.
 Beck suggests creating method object for dealing with
this type of scenario [28].
 Message Chains: This smell arises when a class asks
an object for another object, which then asks another
and so on.This results in the series of calls which occur
back to back. This means that the first class will be
coupled to the structure of navigation and any change
in the intermediate relationships necessiate the first
class to have change. To reduce this coupling,Fowler et
al. suggest to do this work with methods or use objects
as middlemen through hiding them [28].
 Middle Man: This smell prevails when a class
delegates most of its tasks to other classes. Although,
delegation through classes is a common practice in
object-oriented programming,if there is too much
delegation it can seriously affect the program.
 Inappropriate Intimacy: This smell emanates when
two classes are too tightly coupled with each other.
Fowler et al. suggest that this intimacy may lead to
some unacceptable behavior in the system. They
suggest the techniques to break them up [28].
 Alternative Classes with Different Interfaces: This
smell is indicative of a case when a class operates with
different classes, but the interface to these alternative
classes being different.
 Incomplete Library Class: This smell is indicative of
the situation when the software utilizes a library that is
in bad form or incomplete. This implies that developers
need to extend the functionality of the library for
making software run properly.
 Data Class: This smell is characterised by a class
which contains data, but almost no methods. This is a
bad practice as classes, in practice, must contain both
data and logic.
 Refused Bequest: This type of smell emanates when a
child class does not fully support all the data or method
it inherits from a parent. When a class refuses to
implement an interface, this makes the worse case of
smell.
 Comments: Every comment is not necessarily a bad
smell.Comments, when superflous can cause some
trouble as they can be misused to adjust poorly
structured code and act as deodrant.
III. CONCLUSION
There has been a lot of research on the topic of software metrics.
The research mostly focuses on the software metrics to be used
for different purposes. Apart from this, software metrics as
defect predictors have also been widely discussed in the
literature. The software code smells have not been rigidly
defined and as such their definition varies from a researcher to
another. There have been very less studies on the role of
software smells as defect predictors in object oriented systems
and no model has been developed for defect prediction through
code smells. Therefore, more studies are needed to study the
effect of combination of software metrics and code smells for
defect prediction through the application of any advanced
technique such as machine learning algorithms, and the
software under study being an industrial one.
IV. REFERENCES
[1] "IEEE Standard for Software Maintenance," IEEE, 2006.
[2] M. Boussaa, W. Kessentini, W. Kessentini, S. Bechikh and S. B. Chikha,
"Competitive co-evolutionary code smells detection," International
Symposium on Search Based Software Engineering, pp. 50-65, 2013.
[3] R. Marinescu, "Detection strategies: Metrics-based rules for detecting
design flaws," in Proceedings. 20th IEEE International Conference on
Software Maintenance, 2004.
[4] N. Moha, Y. G. Gueheneuc, L. Duchien and A. F. Le Meur, "Decor: A
method for the specification and detection of code and design smells,"
IEEE Transactions on Software Engineering, vol. 36, no. 1, pp. 20-36,
2010.
[5] D. Sjoberg, A. Yamashita, B. C. D. Anda, A. Mockus and T. Dybå,
"Quantifying the effect of code smells on maintenance effort," IEEE
Transactions on Software Engineering, vol. 39, no. 8, pp. 1144-1156,
2013.
[6] A. Yamashita and L. Moonen, "Do code smells reflect important
maintainability aspects?," in 28th IEEE International Conference on
Software Maintenance (ICSM), 2012.
[7] A. Yamashita and L. Moonen, "Exploring the impact of inter-smell
relations on software maintainability: An empirical study.," in
Proceedings of the 2013 International Conference on Software
Engineering, 2013.
[8] F. Khomh, M. D. Penta, Y. -G. Gueheneuc and G. Antoniol, "An
exploratory study of the impact of antipatterns on class change-and fault-
proneness," Empirical Software Engineering, vol. 17, no. 3, pp. 243-275,
2012.
[9] F. Khomh, M. D. Penta and Y. -G. Gueheneuc, "An exploratory study of
the impact of code smells on software change-proneness," in 16th
Working Conference on Reverse Engineering,WCRE’09, 2009.
[10] M. Abbes, F. Khomh, Y. G. Gueheneuc and G. Antoniol, "An empirical
study of the impact of two antipatterns, Blob and Spaghetti Code, on
program comprehension.," in 15th European Conference on Software
Maintenance and Reengineering (CSMR) , Oldenburg, 2011.
[11] V. R. Basili, L. C. Briand and W. L. Melo, "A validation of object-
oriented design metrics as quality indicators," IEEE Transactions on
software engineering, vol. 22, no. 10, pp. 751-761, 1996.
[12] S. R. Chidamber and C. F. Kemerer, "A metrics suite for object oriented
design," IEEE Transactions on software engineering, vol. 20, no. 6, pp.
476-493, 1994.
[13] W. P. Stevens, G. J. Myers and L. L. Constantine, "Structured design,"
IBM Systems Journal, vol. 13, no. 2, pp. 115-139, 1974.
[14] C. S. Ma , C. K. Chang and J. Cleland-Huang, "Measuring the intensity
of object coupling in c++ programs," in 25th Annual International
Computer Software and Applications Conference, COMPSAC 2001,
2001.
[15] L. C. Briand, C. Bunse , J. W. Daly and C. Differding , "An experimental
comparison of the maintainability of object-oriented and structured
design documents," Empirical Software Engineering, vol. 2, no. 3, pp.
291-312, 1997.
[16] K. El Emam, S. Benlarbi, N. Goel and S. Rai, "The confounding effect
of class size on the validity of object-oriented metrics," IEEE
Transactions on Software Engineering, vol. 27, no. 7, pp. 630-650, 2001.
[17] Y. Ping, T. Systa and H. Muller, "Predicting fault-proneness using OO
metrics. An industrial case study," in Sixth European Conference on
Software Maintenance and Reengineering, 2002.
[18] J. Grigg, Re: [refactoring] Size of Java Classes? Refactoring mailing list,
2002.
[19] V. B. Misic, "Cohesion is structural, coherence is functional: Different
views, different measures," in Seventh International Software Metrics
Symposium, METRICS 2001, 2001.
[20] S. Counsell, E. Mendes and S. Swift, "Comprehension of object-oriented
software cohesion: the empirical quagmire," in 10th International
Workshop on Program Comprehension, 2002, 2002.
[21] W. Li and S. Henry, "Maintenance metrics for the object oriented
paradigm," in First International Software Metrics Symposium, 1993.
[22] T. Gyimothy, R. Ferenc and I. Siket, "Empirical validation of object-
oriented metrics on open source software for fault prediction," IEEE
Transactions on Software engineering, vol. 31, no. 10, pp. 897-910,
2005.
[23] R. K. Bandi, V. K. Vaishnavi and D. E. Turk, "Predicting maintenance
performance using object-oriented design complexity metrics," IEEE
Transactions on software engineering, vol. 29, no. 1, pp. 77-87, 2003.
[24] M. Catwright and M. Shepperd, "An empirical investigation of an object-
oriented software system," IEEE Transactions on software engineering,
vol. 26, no. 8, pp. 786-796, 2000.
[25] T. Zimmermann, R. Premraj and A. Zeller, "Predicting defects for
eclipse," in International Workshop on Predictor Models in Software
Engineering PROMISE'07: ICSE Workshops 2007, 2007.
[26] B. F. Webster, Pitfalls of object oriented development, M & T Books,
1995.
[27] A. J. Riel, Object-Oriented Design Heuristics, Addison Wesley, 1996.
[28] M. Fowler, K. Beck, J. Brant, W. Opdyke and D. Roberts, in Refactoring:
Improving the Design of Existing Code, Addison Wesley, 2002, pp. 63-
72.
[29] M. Mäntylä, "Bad smells in software-a taxonomy and an empirical
study," Helsinki University of Technology, 2003.
[30] W. C. Wake, Refactoring Workbook, Addison-Wesley Professional,
2003.
[31] W. J. Brown, R. C. Malveau, H. W. McCormick and T. J. Mowbray,
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis,
First ed., Wiley, 1998.
[32] G. Travassos, F. Shull, M. Fredericks and V. R. Basili, "Detecting defects
in object-oriented designs: using reading techniques to increase software
quality," in 14th Conference on Object-Oriented Programming, Systems,
Languages, and Applications, 1999.
[33] R. Marinescu, "Detection strategies: Metrics-based rules for detecting
design flaws," in 20th IEEE International Conference on Software
Maintenance, 2004.
[34] M. J. Murno, "Product metrics for automatic identification of" bad smell"
design problems in java source-code.," in 11th IEEE International
Software Metrics Symposium (METRICS'05), 2005.
[35] K. Dhambri, H. Sahraoui and P. Poulin, "Visual detection of design
anomalies," in 12th European Conference on Software Maintenance and
Reengineering (CSMR 2008), 2008.
[36] S. Frank, F. Steinbruckner and C. Lewerentz, "Metrics based
refactoring," in Fifth European Conference on Software Maintenance
and Reengineering, 2001.
[37] E. H. Alikacem and H. Sahraoui, "Generic metric extraction framework,"
in 16th International Workshop on Software Measurement and Metrik
Kongress (IWSM/MetriKon), 2006.
[38] M. Lanza and M. Radu, Object-Oriented Metrics in Practice, Springer,
2006.
[39] V. Emden, Eva and L. Moonen, "Java quality assurance by detecting
code smells," in Ninth Working Conference on Reverse Engineering,
2002.
[40] G. Langelier, H. Sahraoui and P. Poulin, "Visualization-based analysis
of quality for large-scale software systems," in 20th IEEE/ACM
international Conference on Automated software engineering, 2005.
[41] T. Menzies, J. Greenwald and A. Frank, "Data mining static code
attributes to learn defect predictors," IEEE Transactions on Software
Engineering, vol. 33, no. 1, pp. 2-13, 2007.