2009 First International Conference on Computational Intelligence, Communication Systems and Networks

EXPERIMENTAL ANALYSIS OF DIFFERENT METRICS (OBJECT-OREINTED AND STRUCTURAL ) OF SOFTWARE Lalji Prasad*,Aditi Nagar**
* lalji_prasad @rediffmail.com, Sanghvi Institute of Management and Science /Computer Engineering,

INDORE, INDIA ** [email protected], Sanghvi Institute of Management and Science /Computer Engineering, INDORE, INDIA

Abstract In this paper first investigate the relationships between existing object-oriented metrics (coupling, cohesion) and procedureoriented metrics (Line of code, Cyclomatic complexity and knot metric) measure the probability of error detection in system classes during testing and is to propose an investigation and analysis strategy to make these kinds of studies more reusable and comparable, a problem which is persistent in the quality measurement. The metrics are first defined and then explained using practical applications finally, a review of the empirical study concerning chosen and coupling metrics and subset of these measures that provide sufficient information is given and metrics providing overlapping information are expelled from the set. The paper defines a new set of operational measures for the conceptual coupling of classes, which are theoretically valid and empirically studied. In this paper, we shows that these metrics capture new dimensions in coupling measurement, compared to existing structural metrics. Keywords: Procedural oriented metrics, Cyclomatic complexity, Knot metric, Objectoriented coupling and Object-Oriented cohesion. 1. INTRODUCTION In the field of software quality, metrics are used for assessing several software attributes (size, coupling, cohesion etc.). They provide, therefore, an important assistance to developers and managers in order to assess and improve software quality during the development process. These metrics try to capture different aspects of software product and its process. Some of the metrics also try to
978-0-7695-3743-6/09 $25.00 2009 IEEE DOI 10.1109/CICSYN.2009.22 235

capture the same aspect of software e.g., there are number of metrics to measure the coupling between different classes. Software developers need to explicitly state the relation between the different metrics measuring the same aspect of software. Size metrics show us the basic information about the system, counted (e.g. classes, function, methods, parameters, statements, etc.) and are easy to understand, these metrics can be very useful in analyzing the system. Design and code metrics could be classified according to the paradigm they adhere to. In this classification, metrics are categorized into either procedural or objectoriented metrics. Procedural (PO) metrics are used to measure the properties related to software developed in procedural programming languages.They are organized around a view of the software in which the individual procedure or subprogram is the most significant unit. Procedural metrics include Lines Of Code (LOC) [5,6], McCabes Cyclomatic complexity [4] and knot metric [8]. Lines-of-code are the most traditional measures used to quantify software complexity. They are simple, easy to count, and very easy to understand. They do not, however, take into account the intelligence content and the layout of the code. In this study, we use a LOC pro measure, which counts the number of program lines (declarations, definitions, directives, and code). McCabes cyclomatic complexity which measures something else than just length: Longer the program it have more predicate nodes. This leads to normal conclusion that McCabes cyclomatic number is strongly

correlated with length. The problem with McCabes cyclomatic number is that is not a good measure of complexity, since smaller programs (in terms of lines of code) are much more complex in terms of their intrinsic functions. In order to eliminate the correlation, some authors proposed other measures such as complexity density defined as the ratio of cyclomatic complexity to thousand of lines of code Object-Oriented (OO) Metrics reflect the impact of using object-oriented mechanisms such as inheritance, association, aggregation, polymorphism and message passing. Examples of object-oriented metrics include Weighted Methods per Class [1], Number of Children [7], and Response for Class [1]. Object-oriented metrics could be further categorized according to the objectoriented property they measure. For example, there are metrics for measuring size such as number of methods, number of attributes and number of classes. There are metrics for measuring coupling such as direct class coupling, number of dependencies in, and coupling factor. There are metrics for measuring inheritance, cohesion, and encapsulation. Metrics are important source of information for decision making, a large number of OO metrics have also been proposed over the last decade to capture the structural quality of OO code and design and are related to external quality measures .As the number of metrics available in literature is large, it becomes a tedious process to understand the computation of these metrics and draw inferences from their values. Secondly, as number of metrics proposed in literature is quite large as compared to number of features (e.g., coupling, cohesion, polymorphism, size and inheritance) captured by these metrics, our aim is to find whether each measure is independent Cohesion is an attribute of a software unit or module that refers to the relatedness of module components. Highly cohesive software is a module that has one basic function and is invisible- it is difficult to split a cohesive module into separate components.

Cohesiveness of methods within a class is desirable since it promotes encapsulation and lack of cohesion implies that classes should probably be split into two or more sub classes. Coupling in software has been linked with maintainability and existing metrics are used as predictors of external software quality attributes such as fault-proneness, impact analysis. Many coupling measures for objectoriented software have been proposed, each of them capturing specific dimension of coupling. Coupling is one of the properties either most influences on maintenance as it has a direct effect on maintainability. Excessive coupling indicates the weakness of class encapsulation and may inhibit reuse. High coupling also indicates that more faults may be introduced due to inter-class activities. 2. METRICS AND APPLICATION In this section PO and OO metrics chosen in this work are defined and their application. In PO metrics we discuss about Line of code, Cyclomatic complexity and knot metric. The Object Oriented metrics chosen for analysis f can be divided into different categories viz. size, coupling, cohesion and reuse metrics. 2.1 Procedural Oriented Metrics 2.1.1 Line of Code (LOC) LOC is possibly the most widely used metric for program size. It would seem to be easily and precisely definable; how- ever, there are a number of different definitions for the number of lines of code in a particular program. These differences involve treatment of blank lines and comment lines, non-executable statements, multiple statements per line, and multiple lines per statement, as well as the question of how to count reused lines of code. The most common definition of LOC seems to count any line that is not a blank or comment line, regard- less of the number of statements per line. LOC has been theorized to be useful as a predictor of program complexity, total development effort and programmer performance (debugging, productivity).
236

Numerous studies have attempted to validate these relationships. Examples are those of [9] comparing LOC, McCabes V (G) and [14] E as indicators of programming effort and [10] and [11] comparing LOC with other metrics, as indicators of programmer performance. 2.1.2 Cyclomatic Complexity Metrics Numerous metrics have been proposed for measuring program complexity-probably more than for any other program characteristics. For size metrics, measures of complexity that can be completed early in the software development cycle will be of greater value in managing the software process. The McCabes measure is based on the final form of the computer code. Cyclomatic complexity is used to evaluate the complexity of an algorithm in a method. A method with a low cyclomatic complexity is generally better, although it may mean 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. In general, the cyclomatic complexity for a method should be below ten, indicating decisions are deferred through message passing. Although this metric is specifically applicable to the evaluation of quality attribute Complexity, it also is related to all of the other attributes. The McCabe Complexity Metric {V(G)}a software module can be described by a control flow graph where Each node correspond to a block of sequential code Each edge corresponds to a path created by a decision V(G) = e - n + 2 Where, e = number of edges in the graph n = number of nodes in the graph In Figure 1 value of e=8 n=7
V(G)= 8-7+2 So, V(G)=3

Figure 1: Cyclomatic complexity metrics 2.1.3 Knot The concept of program knots is related to drawing the program control flow graph with a node for every statement or block of sequential statements. A knot is then defined as a necessary crossing of directional lines in the graph. The same phenomenon can also be observed by simply drawing transfer-ofcontrol lines from statement to statement in a program listing. The number of knots in a program has been proposed as a measure of program complexity. 2.2 Object-Oriented Metrics 2.2.1 Size Metrics In this section four size metrics are discussed. This measure size of the system in terms of attributes and methods included in the class and capture the complexity of the class. Number of Attributes per Class (NOA) It counts the total number of attributes defined in a class. [7] Figure 2 shows the class diagram of Book Information System. In this system, Number of Attributes (NOA) for Publication class is 2. So NOA = 2 for Publication class. Number of Methods per Class (NOM) NOM counts number of methods

237

defined in a class[7]. In Figure 2, class Publication has one methods getdata ( ) and display ( ). Hence NOM = 1 for Publication class. Weighted Methods per Class (WMC) The WMC is a count of sum of complexities of all methods in a class. To calculate the complexity of a class, the specific complexity metric that is chosen should be normalized so that nominal complexity for a method takes on value 1.0. Consider a class K1, with methods M1 Mn that are defined in the class. Let C1 .Cn be the complexity of the methods. WMC= Ci If all method complexities are considered to be unity, then WMC = n, the number of methods in the class. In Figure 2, WMC for Book is 2 (considering each method complexity to be unity).

Publication::getdata(), Sales::getdata() RS= {Book::getdata1,Book::display1, Book::delete} U {Publication::getdata} U {Sales::getdata()} RFC=5 2.2.2 Coupling Metrics Coupling relations increase complexity, reduce encapsulation, potential reuse, and limit understanding and maintainability. Coupling Between Objects (CBO) CBO [1] for a class is count of the number of other classes to which it is coupled. In Figure3, Book class contains declarations of instances of the classes Publication and Sales. The Book class delegates its publication and sales issues to instances of the Publication and Sales classes. The value of metric CBO for class Book is 2 and for class Publication and Sales is 0.

Figure 2: Class Diagram for book Information System Response for a Class (RFC):The response set of a class is defined as set of methods that can be potentially executed in response to a message received by an object of that class. It is given by RFC=|RS|, where RS, the response set of the class, is given by RS = Mi U all j {Rij} Where Mi = set of all methods in a class (total n) and Ri = {Rij} = set of methods called by Mi. In Figure 2, class Book has one functions getdata1 which call methods
238

Figure 3: Class Diagram of Sales Information System Data Abstraction Coupling (DAC) Define as DAC = number of ADTs defined in a class [7] In Figure 3 there are two ADTs in class Book, pub and Market. DAC for Book Abstraction is a technique of creating new data types suited for an application to be programmed. It provides the ability to create user-defined data types called Abstract Data Types (ADTs). Li and Henry defined Data Abstraction Coupling (DAC) class is 2. Message passing Coupling (MPC) Li and Henry defined Message Passing Coupling

(MPC) metric as number of send statements defined in a class. then MPC = 2. In Figure 3, MPC value for class Book is 2 as methods in class Book calls Sales::getdata(), Publication::getdata() Coupling Factor (CF) Coupling can be due to message passing (dynamic coupling) or due to semantic association links (static coupling) among class instances. It has been known that it is desirable that classes communicate with as few other classes and even when they communicate, they exchange as little information as possible. [12] Couplings due to the use of the inheritance are not included in CF, because a class is because a class is heavily coupled to its ancestors via inheritance. If all classes are coupled with all other classes, CF=100% 2.2.3 Cohesion Metrics Cohesion is a measure of the degree to which the elements of a module are functionally related. A strongly cohesive module implements functionality that is related to one feature of the software and requires little or no interaction with other modules. Thus we want to maximize the interactions within a module. Four cohesion metrics are discussed here. Lack of Cohesion in Methods (LCOM) LCOM [1] measures the dissimilarity of methods in a class by looking at the instance variable or attributes used by methods .Consider a class C1 with n methods M1, M2., Mn. Let (Ij) = set of all instance variables used by method Mi. There are n such sets {I1},.{In}.Let P = {(Ii , I j ) | Ii I j = 0} Q = {((Ii , I j ) | Ii I j 0} . If all n sets {(I1},.........(In)} are 0 then p=0. LCOM =| P | - | Q |, if | P | > | Q | For ex. there are three methods N1,N2,N3 I1={book_id,pub_id,book_name,author_name, price}
239

I2={book_id} I3={book_name} I4={author_name} Where I1 I2, I1 I3, I1 I4 Are not null but I2 I3, I2 I3, I3 I4 are null sets. LCOM is 0 if numbers of null intersections are not greater than number of on-null intersections. Hence LCOM in this case is 0 [|P|=|Q|=3]. Thus a positive high value of LCOM implies that classes are less cohesive. So a low value of LCOM is desirable. Tight Class Cohesion (TCC) The measure TCC [13] is defined as the percentage of pairs of public methods of the class with common attribute usage. In Figure4, methods defined access the following attributes: add_book = {book_id, pub_id, book_name, author_name, price} delete = {book_id} search name = {book_name} search_author = {author_name} search_publisher={pub_id}

Figure 4:- Class Diagram for book in library management All methods in class Book are public. Number of pairs of methods = 6. Methods pairs with common attribute usage

={add_book,delete},{add_book,search_name} {add_book,search_author}and (add_book,search_publisher) TCC= 4/6 * 100 = 66 Then TCC is 66%. 2.2.4 Reuse Metrics An object-oriented development environment supports design and code reuse, the most straightforward type of reuse being the use of a library class (of code), which perfectly suits the requirements. Hendersonsellers discuss two measures designed to evaluate the level of reuse possible within classes [7]. Reuse Ratio Define as ratio of number of super class and total number of class. Specialization ratio Define as ratio of number of sub classes and number of super class. 3. CONCLUSION Theoretical analysis of these metrics suggests that 14 class level metrics and 3 structural metrics, out of 14 class metrics 6 Metrics (NOA, NOM, MPC, DAC, LCOM and TCC) provide sufficient information for usage and other metrics. This simply supports the conclusions drawn from theoretical analysis i.e. many of the metrics proposed are based on comparable ideas and therefore provide somewhat redundant information .The correlation analysis between different metrics and size shows that hardly any of the metric is strongly correlated to size and finally these metrics very useful for determining characteristic of any software metrics References.
[1]

[3]

Woodward, M. R., M. A. Hennell, and D. Hedley. A Measure of Control Flow Complexity in Program Text. IEEE Trans. Software Eng. SE-5, 1 (Jan 1979), 45-50. McCabe, T. J. A Complexity Measure. IEEE. Trans. Software Eng. SE-2, 4 (Dec. 1976), 308320. JonesJones, T. C. Programming Productivity. New York:. TheMcGraw-Hill, 1986 Boehm, B. W. Software Engineering Economics.Englewood Cliffs, N. J.: PrenticeHall, 1981. B.Henderson-sellers, Object-Oriented Metrics, Measures of Complexity. Prentice Hall, 1996. Woodward, M. R., M. A. Hennell, and D. Hedley.A Measure of Control Flow Complexity in Text. IEEE Trans. Software Eng. SE-5, 1 (Jan 1979) Woodfield ,S. N., V. Y. Shen, and H. E. Dunsmore. A Study of Several Metrics for programmingEffort. J. Syst. and Software 2, 2 (June 1981), Curtis, B., S. B. Sheppard, P. Milliman, M. A. Borst,. Measuring the Psychological Complexity of Software Maintenance Tasks with theHalstead and McCabe Metrics. IEEE Trans. Software Eng. SE-5, 2 (March 1979), 96-104 CurtisB., S. B. Sheppard, and P. Milliman. Third Time Charm: Stronger Prediction of Programmer Performance by Software Complexity Metrics. Proc. 4th Int. Conf. on Software Engineering. New York: IEEE, Sept. 1979, 356-360. Harison R.Harrison, S.J.Counsell, and R.V.Nithi, An Evaluation of MOOD set of ObjectOriented Software Metrics. IEEE Trans. Software Engineering, vol. SE-24, no.6, pp. 491496 June1998. L.Briand, W.Daly and J. Wust, Unified Framework for Cohesion Measurement in Object-Oriented Systems. Empirical Software Engineering, 3 65-117, 1998. Halstead,M. H. Elements of Software Science. NewYork: Elsevier North-Holland, 1977.

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

S.R Chidamber and C.F.Kemerer Towards metrics suite for object oriented design ,in Proc. 6th ACM Conf.Object Oriented Programming .Syst..Lang. and Applicat.(Prentice Hall. 1994) Lee, Y., Liang,Based Wang, F., Some Complexity Metrics for Object-Oriented Programs on Information Flow, Proceedings: CompEuro, March, 1993, pp. 302-310.

[2]

240