International Journal of Scientific & Engineering Research Volume 4, Issue3, March-2013 1
ISSN 2229-5518
A Review Report on Approaches to Software
Metrics and Process Improvement
Preety Verma Dhaka, Dr. Amita Sharma
Abstract— Software metrics are useful in different phase of the Object-Oriented Software Development Life Cycle (SDLC). Metrics are used by the software industry to itemize the development, operation and maintenance of software. Application of proper metrics reduces mainternnace costs and efforts. The practice of applying software metrics to a software process and to a software product is a complex task that requires study and restraint, which brings knowledge of the status of the process and / or product of software in regards to the goals to achieve. In this paper, we have presented metrics for Object Oriented Software Systems. They provide a basis for measuring all characteristics. 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 needs for such metrics are important while 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— Metrics, Object Oriented Design, Coupling, Cohesion, Complexity, Size, SDLC.
—————————— ——————————
t is important to further define the term software metrics as used in this module. Essentially, software metrics deals with the measurement of the software product and the process
by which it is developed. In this discussion, the software product should be viewed as an abstract object that evolves from an initial statement of need to a finished software sys- tem, including source and object code and the various forms of documentation produced during development. Ordinarily, these measurements of the software process and product are studied and developed for use in modeling the software de- velopment process [1]. These metrics are then used to estimate or predict product costs and schedules and to measure productivity and product quality. Information gained from the metrics and the model can then be used in the management and control of the development process, leading, to improved results. Good metrics should facilitate the development of models that are capable of predicting process or product pa- rameters, not just describing them. Software metrics can be classified into three categories: product metrics, process met- rics, and project metrics (Victor Basili and Walcelio L Melo) 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 modifi- cations. But the OOAD software development life cycle is not easier than the typical procedural approach [2]. Therefore, it is necessary to provide dependable guidelines that one may fol- low to help ensure good OO programming practices and write reliable code. Object-Oriented programming metrics is an as-
————————————————
Dr.Amita Sharma is currently associated as Assistant Professor with
I.I.S. University Jaipur, India. E-mail: amita214@rediffmail.com
pect to be considered. Metrics is supposed to to be a set of standards against which one can measure the effectiveness of Object-Oriented Analysis techniques in the design of a system. In Object Oriented software development process, the system is viewed as collection of objects. The functionality of the ap- plication is achieved by interaction among these objects in terms of messages. Whenever, one object depends on another object to do certain functionality, there is a relationship be- tween those two classes
Following are the five characteristics of Object Oriented
Metrics.
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 abstrac-
tion
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
IJSER © 2013 http://www.ijser.org
International Journal of Scientific & Engineering Research Volume 4, Issue3, March-2013 2
ISSN 2229-5518
Does a class reflect all the properties of the problem domain? (for reuse)
Cohesion
scope of properties. DIT is a measure of how many ancestor classes can potentially affect this class.
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 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.
The likelihood that a change will occur in the design or implementation of a class
Chidamber and Kemerer's metrics suite for OO Design is the deepest research in OO metrics nvestigation. They have de- fined six metrics for the OO design. In this section we’ll have a complete description of their metrics:
If all method complexities are considered to be unity, then WMC = n, the number of methods. Theoretical basis: WMC relates directly to Bunge's1 definition of complexity of a thing, since methods are properties of object classes and complexity is determined by the cardinality of its set of properties. The number of methods is, therefore, a measure of class definition as well as being attributes of a class, since attributes corre- spond to properties.
The number of methods and the complexity of meth-
ods involved is a predictor of how much time and ef-
fort is required to develop and maintain the class.
The larger the number of methods in a class the great-
er 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.
Greater the number of children, greater the reuse,
since inheritance is a form of reuse.
Greater the number of children, the greater the likeli-
hood 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.
Excessive coupling between object classes is detri-
mental 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 encap-
sulation, 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 testings of various parts of a design are
likely to be. The higher the inter-object class coupling,
IJSER © 2013 http://www.ijser.org
International Journal of Scientific & Engineering Research Volume 4, Issue3, March-2013 3
ISSN 2229-5518
the more rigorous the testing needs to be.
RS = { M }È all i { Ri } where { Ri } = set of methods called by method i and { M } = set of all methods in the class The re- sponse 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 class26. The cardinality of this set is a measure of the attributes of objects in the class. Since it specifically includes methods called from outside the class, it is also a measure of the poten- tial communication between the class and other classes.
If a large number of methods can be invoked in re-
sponse 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 in-
voked 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.
LCOM = |P| - |Q|, if |P| > |Q| = 0 otherwise
Example: 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 non-empty, but {I1} {I3} and {I2} {I3} are null sets.
LCOM is the (number of null-intersections - number of non- empty intersections), which in this case is 1.
Theoretical basis: This uses the notion of degree of similarity of methods. The degree of similarity for two methods M1 and M2 in class C1 is given by:
() = {I1} {I2} where {I1} and {I2} are the sets of instance vari- ables used by M1 and M2
The LCOM is a count of the number of method pairs whose similarity is 0 (i.e. s() is a null set) minus the count of method pairs whose similarity is not zero. The larger the number of similar methods, the more cohesive the class, which is con- sistent with traditional notions of cohesion that measure the interrelatedness between portions of a program. If none of the methods of a class display any instance behavior, i.e. do not
use any instance variables, they have no similarity and the LCOM value for the class will be zero. The LCOM value pro- vides a measure of the relative disparate nature of methods in the class. A smaller number of disjoint pairs (elements of set P) implies greater similarity of methods. LCOM is intimately tied to the instance variables and methods of a class, and therefore is a measure of the attributes of an object class.
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 sub-classes.
Any measure of disparateness of methods helps iden-
tify flaws in the design of classes.
Low cohesion increases complexity, thereby increas-
ing the likelihood of errors during the development process.
The MOOD metrics set refers to a basic structural mechanism of the OO paradigm as encapsulation ( MHF and AHF ), inher- itance ( MIF and AIF ), polymorphisms ( PF ) , message- passing ( CF ) and are expressed as quotients. The set includes the following metrics:
MHF is defined as the ratio of the sum of the invisibilities of all methods defined in all classes to the total number of meth- ods defined in the system under consideration. The invisibility of a method is the percentage of the total classes from which this method is not visible. (note : inherited methods not con- sidered.) [3].
AHF is defined as the ratio of the sum of the invisibilities of all attributes defined in all classes to the total number of attrib- utes defined in the system under consideration.
MIF is defined as the ratio of the sum of the inherited methods in all classes of the system under consideration to the total number of available methods ( locally defined plus inherited) for all classes.
AIF is defined as the ratio of the sum of inherited attributes in all classes of the system under onsideration to the total num- ber of available attributes ( locally defined plus inherited ) for all classes.
PF is defined as the ratio of the actual number of possible dif- ferent polymorphic situation for class Ci to the maximum number of possible distinct polymorphic situations for class
IJSER © 2013 http://www.ijser.org
International Journal of Scientific & Engineering Research Volume 4, Issue3, March-2013 4
ISSN 2229-5518
Ci.
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.
There are many metrics that are applied to traditional func- tional development. The SATC (Software Assurance Technol- ogy Center at NASA Goddard Space Flight Center) from expe- rience has identified three of these metrics that are applicable to object oriented development: Complexity, Size, and Reada- bility. To measure the complexity, the cyclomatic complexity is used.
Cyclomatic complexity (McCabe) is used to evaluate the com- plexity of an algorithm in a method. It is a count of the num- ber of test cases that are needed to test the method compre- hensively. The formula for calculating the cyclomatic complex- ity 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 lternative path is tested [4].
Figure 1 shows a method with a low cyclomatic complexity is generally better. This may imply decreased testing and in- creased understandability or that decisions are deferred through message passing, not that the method is not complex. Cyclomatic complexity cannot be used to measure the com- plexity 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 Com- plexity, it also is related to all of the other attributes
Figure 1: Cylomatic Complexity
Number of Indepenenet Test path → edges – nodes + 2
Example of calculations for the cyclomatic complexity for four basic programming structures
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 re- ferred 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 pro-
grammer or language style. Therefore, since NASA programs
are frequently written using multiple languages, the SATC
uses executable statements to evaluate project size [5]. Thresh-
olds for evaluating the meaning of size measures vary de- pending 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.
The line counts done to compute the Size metric can be ex- panded 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 com- ments assist developers and maintainers, higher comment percentages increase understandability and maintainability.
The Software Science developed by M.H.Halstead principally attempts to estimate the programming effort. The measurable and countable properties are:
n1 = number of unique or distinct operators appearing in that implementation
n2 = number of unique or distinct operands appearing in
that implementation
N1 = total usage of all of the operators appearing in that
implementation
N2 = total usage of all of the operands appearing in that implementation
From these metrics Halstead defines: I. the vocabulary n as n = n1 + n2
II. the implementation length N as N = N1 + N2
Operators can be "+" and "*" but also an index "[...]" or a state- ment separation "..;..". The number of operands consists of the numbers of literal expressions, constants and variables.
IJSER © 2013 http://www.ijser.org
International Journal of Scientific & Engineering Research Volume 4, Issue3, March-2013 5
ISSN 2229-5518
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 [10].
In order to find Quantification of Intelligence Content we need some other metrics and formulas:
V = Nlog2n
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 [9].
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 intelli- gence 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 imple- mentation 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 pro- gram volume equation determines, because the program vol- ume V is a measure of it. Another aspect that influences the effort equation is the program difficulty. Each mental compar- ison consists of a number of elementary mental discrimina- tions. This number is a measure for the program difficulty [6,7].
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 cy- clomatic 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 com- puted 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 [11].
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 struc- tures that the program updates. The data flow count includes updated procedure parameters and procedures called from within a module.
IJSER © 2013 http://www.ijser.org
International Journal of Scientific & Engineering Research Volume 4, Issue3, March-2013 6
ISSN 2229-5518
Complexity = Length x (Fan-in x Fan-out)2
Length is any measure of length such as lines of code or alter- natively McCabe's cyclomatic complexity is sometimes substi- tuted.
Henry and Kafura validated their metric using the UNIX sys- tem and suggested that the measured complexity of a compo- nent allowed potentially faulty system components to be iden- tified. They found that high values of this metric were often measured in components where there had historically been a high number of problems [8].
We have 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). Further, sufficient experimental results may be used for new findings. Also there are metrics for measuring software’s run-time properties and would be worth studying more. These can be used for process improvement which is a continuous process.
This paper highlight on the basic metric suite for object- oriented design. The needs for such metrics are important while an organization is adopting a new technology for which established practices have ye to be developed. The metric suite is not adoptable as such and according to some other re- searches it isstill 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 up- on 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 lan- guages were to be provided.
It is economical and can lead to a significant reduction in costs of the overall implementation and improvements in quality of the final product. This improves quality and reduces mainte- nance costs and efforts. Using early quality indicators based on objective empirical evidence is therefore a realistic objec- tive. 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 met- rics 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.
The authors would like to acknowledge Seyyed Mohsen Ja- malai, Department of Computer Engineering, Sharif Universi- ty of Technology, Tehran, Iran, for his contribution in the field of Software Engineering.
[1] Shyam R. Chidamber, Chris F. Kemerer, A METRICS SUITE FOR OB- JECT ORIENTED DESIGN, 1993
[2] Carnegie Mellon School of Computer Science, Object-Oriented Testing
& Technical Metrics, PowerPoint Presentation , 2010
[3] Sencer Sultanoðlu, Ümit Karakaþ, Object Oriented Metrics, Web Doc-
ument, 2008
[4] Linda H. Rosenberg, Applying and Interpreting Object Oriented Met-
rics
[5] Sencer Sultanoðlu, Ümit Karakaþ, Complexity Metrics and Models, Web Document, 1998
[6] Jaana Lindroos, Code and Design Metrics for Object-Oriented Sys- tems, 2006
[7] Ralf Reißing, Towards a Model for Object-Oriented Design Measure-
ment
[8] Magiel Bruntink, Testability of Object-Oriented Systems: a Metrics-
based Approach, 2005
[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 Ob- ject-Oriented Software Development Projects, 2004
IJSER © 2013 http://www.ijser.org