International Journal of Computer Applications (0975 – 8887)

Volume78– No.1, September 2013

Object Oriented Metrics Evaluation

S. Pasupathy1 and R. Bhavani2, Ph.D
1.
Associate Professor, Dept. of CSE, FEAT, Annamalai University, Tamil Nadu, India.
2.
Associate Professor, Dept. of CSE, FEAT, Annamalai University, Tamil Nadu, India.

ABSTRACT OO applications used to determine the success or failure of a

This paper presents the results derived from the survey on process or person, and to quantify improvements throughout
metrics used in object oriented environments. The survey the software process. These metrics can be used to reinforce
includes a small set of the most well known and commonly good OO programming techniques, which leads to more
applied traditional software metrics which could be applied to reliable code.
object oriented programming and a set of object oriented One metric alone is not enough to determine any information
metrics. In short, the metrics based assessment of a software about an application under development. Several metrics must
system and measures taken to improve its design differ be used in tandem to gain insight into improvements during a
considerably from tool to tool. To support the case, we software process [3]. There are several software packages that
conducted an experiment with a number of commercial and can be used to determine the metrics on a software
free metrics tools. We calculated metrics values using the applications.
same set of standard metrics for three software systems of
different sizes. These metrics were evaluated using object 2. TYPES OF METRICS
oriented metrics tools for the purpose of analyzing quality of
the product, encapsulation, inheritance, message passing, The metrics presented hereinafter have been selected from
polymorphism, reusability and complexity measurement. It metrics proposed specifically for object–oriented
defines a ranking of the classes that are most vital note down measurements and cannot be applied to another programming
and maintainability. The results can be of great assistance to style. This is a small fraction of the most well-known metrics
quality engineers in selecting the proper set metrics for their analyzed in various real time applications. The categories
software projects and to calculate the metrics, which was chosen to present the metrics are not defining a metrics
developed using a sequential object oriented life cycle classification but used simply to ease the presentation and
process. sometimes a metric may fall in more than one category. The
metrics presented are: class related metrics, method related
Index: Software development, Object oriented metrics, encapsulation metrics, cyclometic complexity
programming, Object oriented metrics tool. measuremetnt,inheritance metrics, metrics measure coupling
and metrics measure general (system) software production
1. INTRODUCTION [4,5]. The types of metrics are shown in table 1.
Object-oriented design and development is becoming very Table 1: Types of Metrics
popular in today's software development environment. Object
oriented development requires not only a different approach to S.NO Metrics Types
design and implementation, it requires a different approach to 01 Size Metrics
software metrics. Since object oriented technology uses
objects and not algorithms as its fundamental building blocks, 02 Class Metrics
the approach to software metrics for object oriented programs 03 Encapsulation Metrics
must be different from the standard metrics set. Some metrics,
04 Complexity Metrics
such as lines of code and cyclomatic complexity, have
become accepted as "standard" for traditional functional/ 05 Inheritance Metrics
procedural programs, but for object oriented, there are many 06 Polymorphism Metrics
proposed object oriented metrics in the literature [1]. The 07 Message Passing Metrics
question is, "Which object oriented metrics should a project
08 Coupling Metrics
use, and can any of the traditional metrics”. This paper
presents the possibility of using object-oriented software 09 Reuse Metrics
metrics for the automatic detection of a set of design 10 Quality Measurement
problems.
It will illustrate the efficiency of this approach by discussing 2.1 SIZE METRICS
the conclusions of an experimental study that uses a set of This metrics is used to evaluate overall program size and
three metrics for problem detection and applies them to three specify the module wide metrics. Each metrics has different
projects. These three metrics are “touching” three main factors. The size oriented metrics are,
aspects of object-oriented design, aspects that have an
important impact on the quality of the systems – i.e. Lines of code (LOC): This measure provides a count of total
maintenance effort, class hierarchy layout and cohesion [2]. number of lines in the module. It includes source lines, blank
For each of these metrics we will present the design flaw that lines, comment lines.
it may detect together with some of our experimental Physical lines of code: This measure provides a count of total
observations – and a possible redesign solution for that number of source lines in the module.
problem. Object-oriented (OO) metrics are measurements on

30
 International Journal of Computer Applications (0975 – 8887)
Volume78– No.1, September 2013

Number of statements: This measure indicates total number  WMSG Number of message sends, sum of number
of statements in the module. It includes if, else, switch, case, of message sends in all method bodies of class.
while, do while, for statements.  WMCX Sum of method complexities.
Comment lines: This measure indicates total number of  WNAA Number of times all attributes defined in the
comment lines in a module. class are accessed.
Blank lines: This measure indicates total number of blank  WNI Number of method invocations, i.e. in all
lines in a module. method bodies of all methods.
 WNMAA Number of all accesses on attributes.
Non-comment Non-blank (NCNB): This measure provides
 WNOC Number of all descendants, i.e. sum of all
count of all lines that are not comments and not blanks.
direct and indirect children of a class.
Executable Statements (EXEC): This measure provides a  WNOS Number of statements, sum of statements in
count of executable statements regardless of number of all method bodies of class.
physical lines of code.

2.2 CLASS ORIENTED METRICS 2.2.2 Methods present in the class:

Classes, which are the central points of every object oriented
Methods can be seen as a flow of instructions which take
language implement methods and define attributes. The class
metrics address thus this aspect: their complexity can be input through parameters and which produce output. Methods
expressed through methods and attributes and the way these can invoke other methods or access attributes. The method
entities behave. HNL Hierarchy nesting level also called metrics are defined in this context.
depth of inheritance tree. The number of classes in superclass
chain of class. In case of multiple inheritances, count the  LOC Lines of code in method body.
number of classes in the longest chain. Summarizes the  MHNL Hierarchy nesting level of class in which
overall class metrics. method is implemented.
2.2.1 Number of Class Measurement  MSG Number of message sends in method body.
 NI Number of invocations of other methods in
 NA Number of accessors, the number of get/set - method body.
methods in a class.  NMAA Number of accesses on attributes in method
 NAM Number of abstract methods. body.
 NC Number of constructors.  NOP Number of parameters which the method
 NCV Number of class variables. takes.
 NIA Number of inherited attributes, the number of  NOS Number of statements in method body.
attributes defined in all superclasses of the subject  NTIG Number of times invoked by methods non-
class. local to its class, i.e. from methods implemented in
 NIV Number of instance variables. other classes.
 NMA Number of methods added, the number of  NTIL Number of times invoked by methods local to
methods defined in the subject class but not in its its class, i.e. from methods implemented in the same
superclass. class.
 NME Number of methods extended, the number of
methods redefined in subject class by invoking the 2.2.3 Attributes present in the class:
same method on a superclass. Attributes are properties to classes. Their main function is to
 NMI Number of methods inherited, i.e. defined in return their value when accessed by methods. The attribute
superclass and inherited unmodified. metrics are defined in such a context.
 NMO Number of methods overridden, i.e. redefined  AHNL Hierarchy nesting level of class in which
in subject class. attribute is defined.
 NOC Number of immediate children of a class.  NAA Number of times accessed. NAA = NGA +
 NOM Number of methods, each method counts as 1. NLA.
NOM = NMA + NME + NMO.  NCM Number of classes having methods that
 NOMP Number of method protocols. This is access it.
Smalltalk - specific: methods can be grouped into  NGA Number of times accessed by methods non-
method protocols. local to its class.
 PriA Number of private attributes.  NLA Number of times accessed by methods local to
 PriM Number of private methods. its class.
 ProA Number of protected attributes.  NM Number of methods accessing it.
 ProM Number of protected methods.
 PubA Number of public attributes.
 PubM Number of public methods.
 WLOC Lines of code, sum of all lines of code in all
method bodies of the class.

31
 International Journal of Computer Applications (0975 – 8887)
Volume78– No.1, September 2013

2.3 ENCAPSULATION METRIC Encapsulation has two major impacts on metrics:

The encapsulation metrics evolves packaging (or binding
together) of a collection of items.  the basic unit will no longer be the subprogram, but
rather the object, and
 Low-level examples of encapsulation include  we will have to modify our thinking on
records and arrays. characterizing and estimating systems.
 Subprograms (e.g., procedures, functions,
subroutines, and paragraphs) are mid-level 2.3.2 Information Hiding is the suppression
mechanisms for encapsulation.
 In object-oriented (and object-based) programming (or hiding) of details.
languages, there are still larger encapsulating  The general idea is that we show only that
mechanisms, e.g., C++'s classes, Ada's packages, information which is necessary to accomplish our
and Modula 3's modules. [Figure 6 ] Summarizes immediate goals.
the Encapsulation metrics.  There are degrees of information hiding, ranging
from partially restricted visibility to total
invisibility.
2.3.1 Objects Encapsulate  Encapsulation and information hiding are not the
same thing, e.g., an item can be encapsulated but
 knowledge of state, whether statically maintained, may still be totally visible.
calculated upon demand, or otherwise, Information hiding plays a direct role in such metrics as object
 advertised capabilities (sometimes called coupling and the degree of information hiding.
operations, method interfaces, method selectors, or 2.4 COMPLEXITY METRICS
method interfaces), and the corresponding Complexity is everywhere in the software life cycle:
algorithms used to accomplish these capabilities requirements, analysis, design, and of course, implementation
(often referred to simply as methods), is usually an undesired property of software because
 [in the case of composite objects] other objects, complexity makes software harder to read and understand,
 [optionally] exceptions, and therefore harder to change; also, it is believed to be one
 [optionally] constants, and cause of the presence of defects. Summarizes the Complexity
 [Most importantly] concepts. measurement metrics. In a use net debate
surrounding Intelligent Design, the issue of measuring
In many object-oriented programming languages, complexity kept coming up. Are there any good objective
encapsulation of objects (e.g., classes and their instances) is metrics for "complexity"? The complexity measured output
syntactically and semantically supported by the language. In shown in Figure 2.
others, the concept of encapsulation is supported
conceptually, but not physically.

The types of complexity metrics are shown in table 2.

METRIC OBJECTIVE

Cyclomatic Complexity Low

Lines of Code/Executable Statements Low
Comment Percentage ~ 20 – 30 %
Weighted Methods per Class Low
Response for a Class Low

Lack of Cohesion of Methods Low

Cohesion of Methods High
Coupling Between Objects Low
Depth of Inheritance Low (trade-off)
Number of Children Low (trade-off)

Table 2: Types Of Complexity Metrics.

32
 International Journal of Computer Applications (0975 – 8887)
Volume78– No.1, September 2013

Figure 1: All Methods Available in Java Program and calculate Metrics Factor

Figure 2: Complexity Measurement for Java program

2.5 INHERITANCE METRICS software product can be viewed as an abstract object that
The mechanism supports the class hierarchy design and evolves from an initial statement of need to a finished
captures the IS-A relationship between a super class and its software system, including source and executable code and
subclass. the various forms of documentation produced during
development. Ordinarily, the measurements of the software
2.5.1 Types Available For Corresponding Metrics products and processes are studied and developed for use in
modeling the development process [6]. In this Work two
 Dynamic inheritance algorithms for estimation and Measurement of Messing
 Multiple inheritance passing, their metrics are then used to estimate/predict product
costs and schedules and to measure productivity and product
2.5.2 Types of Internal Metrics quality. Information gained from metrics can then be used in
the management and control of the development process in
 Average Degree of Understandability (AU) Metric order to improve results. Summarizes the overall method
 Average Degree of Modifiability (AM) Metric metrics.
 Average Inheritance Depth (AID)
 Derive Base Ratio Metric (DBRM) 2.7 REUSE METRICS
 Average Number of Direct Child (ANDC) Metric Reuse Ratio (U):
 Average Number of Indirect Child (ANIC) Metric
The reuse ratio (U) is given by U=number of super class/total
number of class.
2.6 MESSAGE PASSING METRICS
Specialization Ratio(S):
Message passing describes the act of communication between
two or more computer processes (in the form of "messages"). This ratio measures the extent to which a super class has
A metric is a numerical value computed from a collection of captured abstraction. S=number of subclass/number of super
data. Message Passing metrics deal with the measurement class.
of Number of Message passing Iterations involved in
software product or a process by which it is developed. A

33
 International Journal of Computer Applications (0975 – 8887)
Volume78– No.1, September 2013

Average Inheritance Depth: 2.9.1 Object Oriented Programming

The inheritance structure can be measured in terms of depth of
each class with in its hierarchy. Average inheritance depth Coupling
=sum of depth of each class/number of class. Figure 3 and 4 Coupling between objects (CBO)
represents class oriented metrics also specifies each selected
class metrics. 1) coupling = class x is coupled to class y iff x uses y’s
methods or instance variables (includes inheritance
2.8 QUALITY METRICS related coupling).
2) CBO for a class is a count of the number of other
Reusability: Reusability means reflects the presence of OO classes to which it is coupled.
Design characteristics that allow a design to be reapplied to 3) High coupling between classes means modules
new problem without significant. Reusability formula= (- depend on each other too much.
0.25*coupling) + (0.25*cohesion) + (0.5*messaging) + 4) Independent classes are easier to reuse and extend.
(0.5*design size). 5) High coupling decreases understandability and
Flexibility: Characteristics that allow the incorporation of increases complexity.
change in a design. The ability of a design to be adapted to 6) High coupling makes maintenance more difficult
provide Functionality related capabilities. Flexibility formula= since changes in a class might propagate to other
(0.25*encapsulation)- parts of software.
(0.25*coupling)+(0.5*composition)+(0.5*polymorphism). 7) Coupling should be kept low, but some coupling is
necessary for a functional system.
Understandability: The properties of the design that enable it
to be easily learned and comprehend. Understandability 2.9.2 COUPLING VERSUS COHESION
formula= (-0.33*abstraction) + (0.33*encapsulation)-
(0.33*coupling) + (0.33*cohesion)-(0.33*polymorphism)- Coupling and Cohesion are the two terms which very
(0.33*complexity)-(0.33*design size). frequently occur together. Together they talk about the
quality a module should have. Coupling talks about the
Functionality: The responsibilities assigned to the classes of inter dependencies between the various modules while
design, which are made available by the classes through their cohesion describes how related functions within a
public interfaces. Functionality formula= (0.12*cohesion) + module are. Low cohesion implies that module performs
(0.22*polymorphism) + (0.22*messaging)+ (0.22*design tasks which are not very related to each other and hence
size) + (0.22*hierarchies) can create problems as the module becomes large.
Extendibility: It refers to the presence and usage of
properties in an existing design that allow for the 3. SOFTWARE ENGINEERING METRICS
incorporation of new requirements in the design. Extendibility ESTIMATION
formula = (0.5*Abstraction)-(0.5*coupling) + In software estimation process involved various
(0.5*inheritance) + (0.5*polymorphism). domains. Here are some observations [7,8,9]:

Effectiveness: It refers to a design's ability to achieve the

desired functionality and behavior using OO Design concepts.  A single software engineering metric in isolation is
Effectiveness formula= (0.2*abstraction) seldom useful. However, for a particular process,
+(0.2*encapsulation) + (0.2*composition) + (0.2*inheritance) product, or person, 3 to 5 well-chosen metrics seems
+ (0.2*polymorphism). to be a practical upper limit, i.e., additional metrics
(above 5) do not usually provide a significant return
2.9 COUPLING METRICS on investment.
 Although multiple metrics must be gathered, the
Coupling in software has been linked with maintainability and most useful set of metrics for a given person,
existing metrics are used as predictors of external software process, or product may not be known ahead of
quality attributes such as fault-proneness, impact analysis, time. This implies that, when it is first begin to
ripple effects of changes, changeability, etc. Many coupling study some aspect of software engineering, or a
measures for object-oriented (OO) software have been specific software project, we will probably have to
proposed, each of them capturing specific dimensions of use a large (e.g., 20 to 30, or more) number of
coupling. This paper presents a new set of coupling measures different metrics. Later, analysis should point out
for OO systems – named conceptual coupling, based on the the most useful metrics.
semantic information obtained from the source code, encoded  Metrics are almost always interrelated. Specifically,
in identifiers and comments. A case study on open source attempts to influence one metric usually have an
software systems is performed to compare the new measures impact on other metrics for the same person,
with existing structural coupling measures. The case study process, or product[10].
shows that the conceptual coupling captures new dimensions  To be useful, metrics must be gathered
of coupling, which are not captured by existing coupling systematically and regularly -- preferably in an
measures; hence it can be used to complement the existing automated manner.
metrics.  Metrics must be correlated with reality. This
correlation must take place before meaningful
decisions, based on the metrics, can be made[11].
 Faulty analysis (statistical or otherwise) of metrics
can render metrics useless, or even harmful.
 To make meaningful metrics-based comparisons,
both the similarities and dissimilarities of the

34
 International Journal of Computer Applications (0975 – 8887)
Volume78– No.1, September 2013

people, processes, or products being compared must 3.1 Object-oriented software engineering
be known.
 Those gathering metrics must be aware of the items
metrics are units of measurement that are
that may influence the metrics they are gathering. used to characterize:
For example, there are the "terrible H's," i.e., the
Heisenberg effect and the Hawthorne effect.  object-oriented software engineering products, e.g.,
 Metrics can be harmful. More properly, metrics can designs, source code, and test cases,
be misused.  object-oriented software engineering processes, e.g.,
the activities of analysis, designing, and coding, and
 Object-oriented software engineering people, e.g.,
the efficiency of an individual tester, or the
productivity of an individual designer. Summarizes
the overall Performance Evaluation.

Figure. 3: Methods Metrics for Selected Class

Figure. 4: Methods Metrics for Each Selected Class

35
 International Journal of Computer Applications (0975 – 8887)
Volume78– No.1, September 2013

Figure. 5: Method Metrics for Different Parameters.

Figure.6: Encapsulation Object Oriented Metrics

5. CONCLUSION AND FUTURE SCOPE Make sure the software quality metrics and indicators they
The above results can be used in order to determine when and employ include a clear definition of component parts are
how each of the above metrics can be used according to accurate and readily collectible, and span the development
quality characteristics a practitioner wants to emphasize. spectrum and functional activities. Survey data indicates that
most organizations are on the right track to making use of

36
 International Journal of Computer Applications (0975 – 8887)
Volume78– No.1, September 2013

metrics in software projects. For organizations which do not Reengineering, 2009. CSMR 2009. 9th European
reflect “best practices”, and would like to enhance their Conference on, pages 190{191, 21-23}, March 2010.
metrics capabilities, the following recommendations are
suggested to Measure the “best practices” list of metrics more [6] H. Bsar, M. Bauer, O. Ciupke, S. Demeyer, S. Ducasse,
consistently across all projects. Focus on “easy to implement” M. Lanza, R. Marinescu, R. Nebbe, O. Nierstrasz, M.
metrics that are understood by both management and software Przybilski, T. Richner, M. Rieger, C. Riva, A. Sassen, B.
developers, and provide demonstrated insight into software Schulz, P. Steyaert, S. Tichelaar, and J. Weisbrod. The
project activities. FAMOOS Object-Oriented Reengineering Handbook,
Oct. 2006.
6. REFERENCES [7] A. Albrecht: "Measuring application development
[1] A. Albrecht and J. Gaffney: Software Function, Source productivity", in Proc. Joint SHARE/GUIDE/IBM
Lines of Code, and Development Effort Prediction: A Applications Development Symposium, Monterey, CA,
Software Science Validation; in IEEE Trans. Software 2007.
Eng., 9(6), 2008, pp. 639-648.
[8] L. Briand, S. Morasca, V. Basili, Property-Based Software
[2] B. Bohem, Software Engineering Economics, Prentice Engineering Measurement, IEEE Trans. Software Eng.
Hall, Englewood Cliffs, 1981 [Briand et al 94] L. Briand, 22(1), 2000, pp. 68-85.
S. Morasca, V. Basili, Defining and Validating High-
Level Design Metrics, Tech. Rep. CS TR-3301, [9] S. Conte, H. Dunsmore, V. Shen, Software Engineering
University of Maryland, 2009. Metrics and Models, Benjamin/Cummings, Menlo Park,
CA.
[3] S. Chidamber, C. Kemerer, A Metrics Suite for Object
Oriented Design, IEEE Trans. Software Eng., 20/6), [10] J. Stathis, D. Jeffrey, An Empirical Study of Albrecht’s
2000, pp. 263-265. Function Points, in Measurement for Improved IT
management, Proc. First Australian Conference on
[4] S. Morasca, Software Measurement: State of the Art and Software Metrics, ACOSM 93, Sydney, 2002, pp. 96 -
Related Issues, slides from the School of the Italian 117.
Group of Informatics Engineering, Rovereto, Italy,
September 2008. [11] Boehm, Barry W., as quoted by Ware Myers, “Software
Pivotal to Strategic Defense,” IEEEComputer, January
[5] J. Alghamdi, R. Rufai, and S. Khan. Oometer: A software 2001.
quality assurance tool. Software Maintenance and

IJCATM : www.ijcaonline.org 37