Object Oriented Metrics
Object Oriented Metrics
(A Survey Approach)
Abstract
Given the central role that software development plays in the delivery and application of information
technology, managers are increasingly focusing on process improvement in the software development area.
This demand has spurred the provision of a number of new and/or improved approaches to software
development, with perhaps the most prominent being object-orientation (OO). In addition, the focus on
process improvement has increased the demand for software measures, or metrics with which to manage
the process. The need for such metrics is particularly acute when an organization is adopting a new
technology for which established practices have yet to be developed. This research addresses these needs
through the development and implementation of a suite of metrics for OO design.
Index Terms
Object Oriented, Design, Development, Metric, Measure, Coupling, Cohesion, Complexity, Size
1. Introduction
Object-Oriented Analysis and Design of software provide many benefits such as reusability, decomposition
of problem into easily understood object and the aiding of future modifications. But the OOAD software
development life cycle is not easier than the typical procedural approach. Therefore, it is necessary to
provide dependable guidelines that one may follow to help ensure good OO programming practices and
write reliable code. Object-Oriented programming metrics is an aspect to be considered. Metrics to be a set
of standards against which one can measure the effectiveness of Object-Oriented Analysis techniques in the
design of a system.
Five characteristics of Object Oriented Metrics are as following:
Localization operations used in many classes
Encapsulation metrics for classes, not modules
Information Hiding should be measured & improved
Inheritance adds complexity, should be measured
Object Abstraction metrics represent level of abstraction
We can signify nine classes of Object Oriented Metrics. In each of then an aspect of the software would be
measured:
Size
Population (# of classes, operations)
Volume (dynamic object count)
Length (e.g., depth of inheritance)
Functionality (# of user functions)
Complexity
How classes are interrelated
Coupling
# of collaborations between classes, number of method calls, etc.
Sufficiency
Does a class reflect the necessary properties of the problem domain?
Completeness
Does a class reflect all the properties of the problem domain? (for reuse)
Cohesion
Do the attributes and operations in a class achieve a single, well-defined purpose in the problem
domain?
Primitiveness (Simplicity)
Degree to which class operations can’t be composed from other operations
Similarity
Comparison of structure, function, behavior of two or more classes
Volatility
The likelihood that a change will occur in the design or implementation of a class
1
The ontological principles proposed by Bunge in his “Treatise on Basic Philosophy” form the basis of the concept of objects.
While Bunge did not provide specific ontological definitions for object oriented concepts, several recent researchers have employed
his generalized concepts to the object oriented domain.
Metric 3: Number of children (NOC)
Definition: NOC = number of immediate sub-classes subordinated to a class in the class hierarchy.
Theoretical basis: NOC relates to the notion of scope of properties. It is a measure of how many subclasses
are going to inherit the methods of the parent class.
Viewpoints:
• Greater the number of children, greater the reuse, since inheritance is a form of reuse.
• 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 sub-classing.
• 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.
Polymorphism Factor ( PF )
PF is defined as the ratio of the actual number of possible different polymorphic situation for class Ci to the
maximum number of possible distinct polymorphic situations for class Ci.
Coupling Factor ( CF )
CF is defined as the ratio of the maximum possible number of couplings in the system to the actual number
of couplings not imputable to inheritance.
2
Software Assurance Technology Center (SATC) at NASA Goddard
Space Flight Center
Metric 1: Cyclomatic Complexity (CC)
Cyclomatic complexity (McCabe) is used to evaluate the complexity of an algorithm in a method. It is a
count of the number of test cases that are needed to test the method comprehensively. The formula for
calculating the cyclomatic complexity is the number of edges minus the number of nodes plus 2. For a
sequence where there is only one path, no choices or option, only one test case is needed. An IF loop
however, has two choices, if the condition is true, one path is tested; if the condition is false, an alternative
path is tested.
Figure 1 shows a method with a low cyclomatic complexity is generally better. This may imply decreased
testing and increased understandability or that decisions are deferred through message passing, not that the
method is not complex. Cyclomatic complexity cannot be used to measure the complexity of a class
because of inheritance, but the cyclomatic complexity of individual methods can be combined with other
measures to evaluate the complexity of the class. Although this metric is specifically applicable to the
evaluation of Complexity, it also is related to all of the other attributes
Figure 1
Metric 2: Size
Size of a class is used to evaluate the ease of understanding of code by developers and maintainers. Size
can be measured in a variety of ways. These include counting all physical lines of code, the number of
statements, the number of blank lines, and the number of comment lines. Lines of Code(LOC) counts all
lines. Non-comment Non-blank (NCNB) is sometimes referred to as Source Lines of Code and counts all
lines that are not comments and not blanks. Executable Statements (EXEC) is a count of executable
statements regardless of number of physical lines of code. For example, in FORTRAN and IF statement
may be written:
IF X=3 THEN Y=0
This example would be 3 LOC, 3 NCNB, and 1 EXEC.
Executable statements is the measure least influenced by programmer or language style. Therefore, since
NASA programs are frequently written using multiple languages, the SATC uses executable statements to
evaluate project size. Thresholds for evaluating the meaning of size measures vary depending on the coding
language used and the complexity of the method. However, since size affects ease of understanding by the
developers and maintainers, classes and methods of large size will always pose a higher risk.
Metric 3: Comment Percentage
The line counts done to compute the Size metric can be expanded to include a count of the number of
comments, both on-line (with code) and stand-alone. The comment percentage is calculated by the total
number of comments divided by the total lines of code less the number of blank lines. Since comments
assist developers and maintainers, higher comment percentages increase understandability and
maintainability.
5. Complexity Metrics and Models
5.1 Halstead's Software Science
The Software Science developed by M.H.Halstead principally attempts to estimate the programming effort.
The measurable and countable properties are:
It may be necessary to know about the relationship between length N and vocabulary n. Length Equation
is as follows. " '" on N means it is calculated rather than counted :
N '= n1log2n1 + n2log2n2
It is experimentally observed that N 'gives a rather close agreement to program length.
The same algorithm needs more consideration in a low level programming language. It is easier to program
in Pascal rather than in assembly. The intelligence Content determines how much is said in a program.
In order to find Quantification of Intelligence Content we need some other metrics and formulas:
Program Volume: This metric is for the size of any implementation of any algorithm.
V = Nlog2n
Program Level: It is the relationship between Program Volume and Potential Volume. Only the most clear
algorithm can have a level of unity.
L = V* / V
Program Level Equation: is an approximation of the equation of the Program Level. It is used when the
value of Potential Volume is not known because it is possible to measure it from an implementation directly.
L '= n*1n2 / n1N2
Intelligence Content
I = L 'x V = (2n2 / n1N2 ) x (N1 + N2)log2(n1 + n2)
In this equation all terms on the right-hand side are directly measurable from any expression of an
algorithm. The intelligence content is correlated highly with the potential volume. Consequently, because
potential volume is independent of the language, the intelligence content should also be independent.
The programming effort is restricted to the mental activity required to convert an existing algorithm to an
actual implementation in a programming language.
In order to find Programming effort we need some metrics and formulas:
Potential Volume: is a metric for denoting the corresponding parameters in an algorithm'
s shortest possible
form. Neither operators nor operands can require repetition.
V '= (n*1 + n*2 ) log2 ( n*1 + n*2 )
Effort Equation
The total number of elementary mental discriminations is:
E = V / L = V2 / V’
If we express it: The implementation of any algorithm consists of N selections (nonrandom > of a
vocabulary n. a program is generated by making as many mental comparisons as the program volume
equation determines, because the program volume V is a measure of it. Another aspect that influences the
effort equation is the program difficulty. Each mental comparison consists of a number of elementary
mental discriminations. This number is a measure for the program difficulty.
Time Equation
A concept concerning the processing rate of the human brain, developed by the psychologist John Stroud,
can be used. Stroud defined a moment as the time required by the human brain to perform the most
elementary discrimination. The Stroud number S is then Stroud's moments per second with 5 <= S <= 20.
Thus we can derive the time equation where, except for the Stroud number S, all of the parameters on the
right are directly measurable:
T '= ( n1N2( n1log2n1 + n2log2n2) log2n) / 2n2S
A measure of the complexity of a program was developed by McCabe. He developed a system which he
called the cyclomatic complexity of a program. This system measures the number of independent paths in a
program, thereby placing a numerical value on the complexity. In practice it is a count of the number of test
conditions in a program.
The cyclomatic complexity (CC) of a graph (G) may be computed according to the following formula:
CC(G) = Number (edges) - Number (nodes) + 1
The results of multiple experiments (G.A. Miller) suggest that modules approach zero defects when
McCabe' s Cyclomatic Complexity is within 7 ± 2.
A study of PASCAL and FORTRAN programs (Lind and Vairavan 1989) found that a Cyclomatic
Complexity between 10 and 15 minimized the number of module changes.
Henry and Kafura (1981) identified a form of the fan in - fan out complexity which maintains a count of
the number of data flows from a component plus the number of global data structures that the program
updates. The data flow count includes updated procedure parameters and procedures called from within a
module.
Complexity = Length x (Fan-in x Fan-out)2
Length is any measure of length such as lines of code or alternatively McCabe'
s cyclomatic complexity is
sometimes substituted.
Henry and Kafura validated their metric using the UNIX system and suggested that the measured
complexity of a component allowed potentially faulty system components to be identified. They found that
high values of this metric were often measured in components where there had historically been a high
number of problems.
6. Future Works
I’ve defined a metric for software model complexity which is a combination of some of the metrics
mentioned above with a new approach. With this metric we can measure software’s overall complexity
(including all its components and classes). I’m trying to have sufficient experimental results to prepare a
new paper (other than this survey). Also there are metrics for measuring software’s run-time properties and
would be worth studying more.
7. Conclusion
This paper introduces the basic metric suite for object-oriented design. The need for such metrics is
particularly acute when an organization is adopting a new technology for which established practices have
yet to be developed. The metric suite is not adoptable as such and according to some other researches it is
still premature to begin applying such metrics while there remains uncertainty about the precise definitions
of many of the quantities to be observed and their impact upon subsequent indirect metrics. For example
the usefulness of the proposed metrics, and others, would be greatly enhanced if clearer guidance
concerning their application to specific languages were to be provided.
Metric data provides quick feedback for software designers and managers. Analyzing and collecting the
data can predict design quality. If appropriately used, it can lead to a significant reduction in costs of the
overall implementation and improvements in quality of the final product. The improved quality, in turn
reduces future maintenance efforts. Using early quality indicators based on objective empirical evidence is
therefore a realistic objective. According to my opinion it’s motivating for the developer to get early and
continuous feedback about the quality in design and implementation of the product they develop and thus
get a possibility to improve the quality of the product as early as possible. It could be a pleasant challenge
to improve own design practices based on measurable data.
It is unlikely that universally valid object-oriented quality measures and models could be devised, so that
they would suit for all languages in all development environments and for different kind of application
domains. Therefore measures and models should be investigated and validated locally in each studied
environment. It should be also kept in mind that metrics are only guidelines and not rules. They are
guidelines that give an indication of the progress that a project has made and the quality of design.
8. References:
[1] Shyam R. Chidamber, Chris F. Kemerer, A METRICS SUITE FOR OBJECT ORIENTED DESIGN,
1993
[2] Carnegie Mellon School of Computer Science, Object-Oriented Testing & Technical Metrics,
PowerPoint Presentation , 2000
[3] Sencer Sultanoðlu, Ümit Karakaþ, Object Oriented Metrics, Web Document, 1998
[4] Linda H. Rosenberg, Applying and Interpreting Object Oriented Metrics
[5] Sencer Sultanoðlu, Ümit Karakaþ, Complexity Metrics and Models, Web Document, 1998
[6] Jaana Lindroos, Code and Design Metrics for Object-Oriented Systems, 2004
[7] Ralf Reißing, Towards a Model for Object-Oriented Design Measurement
[8] Magiel Bruntink, Testability of Object-Oriented Systems: a Metrics-based Approach, 2003
[9] Aine Mitchell, James F. Power, Toward a definition of run-time object-oriented metrics, 2003
[10] Sencer Sultanoðlu, Ümit Karakaþ, Software Size Estimating, Web Document, 1998
[11] David N. Card, Khaled El Emam, Betsy Scalzo, Measurement of Object-Oriented Software
Development Projects, 2001