Seminar

InvestigatetheResultofObjectOrientedDesignSoftware MetricsonFaultPronenessinObjectOrientedSystems
A SEMINAR REPORT Submitted by
Ms. Ravneet Kaur Dhillon

in partial fulfilment for the award of the degree of
MASTER OF TECHNOLOGY
in
COMPUTER SCIENCE & ENGINEERING
at
PTU RAYAT & BAHRA INSTITUTE OF ENGINEERING & BIO-TECHNOLOGY

DEC, 2011
ACKNOWLEDGEMENT
I take immense pleasure in thanking. Dr.Parvinder Singh Sandhu, Principal and Prof. Neeraj Mohan, our beloved Head of departemt for having permitted me to carry out this seminar work. I wish to express my deep sense of gratitude to my Internal Guide, Mr.Neeraj Mohan,Head of department, Rayat and Bahra Institute of Engineering and BioTechnology for his able guidance and useful suggestions, which helped me in completing the seminar work, in time. Needless to mention that Ms. Ashima, AP, RBIEBT who had been a source of inspiration and for his timely guidance in the conduct of our seminar work. Words are inadequate in offering my thanks to the Project Trainees and Project Assisatants, for their encouragement and cooperation in carrying out the project work. Also would like to thank my beloved friends Raminder Singh and Preety Chaudhary in encouraging me to complete my seminar in time and for their appropriate guidance. Finally, yet importantly, I would like to express my heartfelt thanks to my beloved parents for their blessings, my friends/classmates for their help and wishes for the successful completion of this seminar.
Ravneet Kaur Dhillon
RavneetKaurDhillonM.Tech.(CSE),100586580326
ABSTRACT
Fault-proneness of a software module is the probability that the module contains faults. A correlation exists between the fault-proneness of the software and the measurable attributes of the code (i.e. the static metrics) and of the testing (i.e. the dynamic metrics). Early detection of fault-prone software components enables verification experts to concentrate their time and resources on the problem areas of the software system under development. This seminar introduces the evaluation of the fault proneness of modules in e software system using various algorithm based on Object-Oriented metrics. The contribution of this seminar is that it has used Metric values of software for generation of the rules for the classification of software modules in the categories of faulty and nonfaulty modules and thereafter empirically validation is performed. The results show that the proposed approach can be used satisfactorily for finding the fault proneness in object oriented software components. Empirical validations of software metrics are used to predict software quality in the past years. This seminar provides a review of empirical studies to predict software fault proneness with a specific focus on techniques used. The seminar highlights the milestone studies done from 1995 to 2010 in this area. Results show that use of machine learning languages have started. This seminar reviews works done in the field of software fault prediction studies. The study is concentrated on statistical techniques and their usage to predict fault proneness. The conclusion drawn is the future studies should use more of class level metrics and the best technique to derive fault predictors amongst statistical techniques is logistic regression. Object-oriented design has emerged as a dominant method in software industry and many new metrics have been proposed for quality prediction of object-oriented programs, but the significance of those metrics is not yet confirmed. Software process control can be improved and high software reliability can be achieved if faults are predicted early in the software life cycle. Testing quality related issues of software has become critical with the increasing importance of the quality of software. Many authors have suggested theoretical validation followed by empirical evaluation using proven statistical and experimental techniques for evaluating in the field of usefulness and relevance of any new metrics. In this paper, we have presented an empirical validation of software quality metric suites on open source
ii
software for fault-proneness prediction in Object Oriented Systems. The three metrics used here are Chidamber and Kemerer (CK) Metrics, Robert C. Martin Metric Suite and McCabes Metric Suite. From the results and empirical analysis, it is clear that the different metric suites have different efficiency in faults prediction. With the aid of this empirical analysis, we can suggest that software professionals to find out those metric suites that can predict faults while developing the quality metric software products using the OO approach.
iii
TABLE OF CONTENTS
Title
Introduction Quality Metric Suited Validated in Research Metrics Milestone Studies Measuring Quality Hypotheses Significance of Metrics Performance Evaluation Research Methodology Conclusion References
Page No.
1 5 13 13 18 20 23 23 24 29 30
iv
INTRODUCTION
The engineering field related with all the sectors of software creation is software engineering. It means application of engineering to software and it deals with the development, operation, and maintenance of software by means of a methodical, disciplined, quantifiable approach and the study of these approaches. The latest software engineering literature has expressed their anxiety over internal software attribute validation methods. The reason for their anxiety is at least to a certain extent because of the fact that (i) (ii) common practices are not adequate for validation, and necessity of valid
measures for software project management and good empirical research. Hence it is vital that an agreement on accurate methods for validating measure is arrived at the software engineering community. Software engineering is commonly misunderstood to be chiefly dealing with process oriented activities, i.e., requirements, design, quality assurance, process improvement, and project management. Significance of quality software is no more a benefit but a necessity, because software error can have effects in terms of life, financial loss, or time delays. Software measurement process must be a goal oriented methodical process that measures, evaluates, adjusts, and finally improves the software development process. Data related to known or predictable development problems, affairs, and question, are gathered. Then, the data are examined in connection with the development process and products. All through the entire life cycle phase, quality, progress, and performance are evaluated utilizing the measurement process. Software metrics deals with the measurement of software product and software product development process and it guides and evaluates software development. It has been used in the assessment of the advantages of software engineering methods and tools. Metric is the quantitative measure of the extent to which a system, component, or process possesses a given feature. Product metrics, process metrics, and project metrics are three important types of software metrics. Product metrics measures the efficiency of accomplishing product targets for instance size, complexity, design features, performance, and quality level. Process metrics measures the efficiency of performing the product development process for instance turnover rate. Project metrics measures the efficiency of product development process, for instance schedule performance, cost
P a g e |1
performance, team performance and more. The necessary features of the preferred object oriented metrics are recognized as capability of covering all quality related and design features, capability of representing the diverse system aspects that are measured, capability of obtaining same measurement values for a given system at different time and for different people, capability of using least number of metrics, capability to have an experimental validation and the capability of reliable operation. At present Object-oriented (OO) design and development are famous concepts in software development environment. They are often publicized as the guaranteed solution for solving software problems. But actually there is no guaranteed solution, though object-oriented development has been proved to be valuable for systems that must be maintained and modified. A conventional experimental validation of object-oriented metrics is done by examining the relationship between each metric and the outcome of concern. In the long cycled framework iterative process, design alterations indicated by added, changed, and deleted source lines of code in classes from one iteration (release) to the next can be forecasted using OO metrics. The predictive capability of OO metrics cannot be applied in different releases of the long term development of an established system and it is limited to the design and implementation changes of the development iterations. For the short-cycled acute processes OO metrics successfully predicts error-fixing and refactoring efforts. Figure: Metrics hierarchy
P a g e |2
Besides stating process and product metrics, it is helpful to group OO metrics into four groups: System size. More exact estimates can be made if for instance number of function calls and objects to be used in a system is forecasted. Class or method size. Different methods of measurement are in practice. Small, simple classes and methods are more desirable than large, complex ones. Coupling and inheritance. Number and kinds of these relationships shows the interdependency of classes. Few, simple relationships are more desirable than numerous, complex ones. Class or method internals. This metric indicates the complexity of the classes and methods and also how proficiently they are documented in the comment code. The majority of the metrics existing for object oriented software analysis, depend upon the information extracted on the operationalization of the software and may usually be utilized in later phase of system development life cycle. Too late indication of quality supplied by such metrics makes product improvement impossible before product completion. In fact on the whole a few object oriented metrics may be utilized to gauge all aspects of the object oriented design. The metrics concentrate on the internal object structure of each individual entity that exposes internal complexity and on the interactions among entities that exposes external complexity. Computational complexity surrounding the efficiency of an algorithm, utilization of machine resources in addition to intellectual complexity issues that affect the capability of a programmer to create, alter, and understand software and the capability of end user to successfully utilize the software are measured by metrics. Quality estimations are made using fault proneness data available from previously developed similar type of projects and the training data consisting of software measurements. However, while most other studies have focused on the analysis on a single version, or release, of a software system, we focused on empirical validation of the software produced by a highly iterative software development process that can be considered an agile software process. In this paper, we have presented an empirical validation of software quality metric suites on software for fault-proneness prediction in Object Oriented Systems. The three
P a g e |3
metrics used here are Chidamber and Kemerer (CK) Metrics, Robert C. Martin Metric Suite and McCabes Metric Suite. By means of these metrics suites, the different versions of Rhino software have analyzed to predict the software quality by making use of the fault proneness. The bugs present in different versions of the Rhino software have taken from the bugzilla database to analyze the fault proneness. Also, we have included the spearman rank correlation to define the quality of the metrics by make use of the defects. The results and empirical analysis have clearly shown that the chosen metrics clearly helps in fault predictions in diverse manners.
The study is divided into following parts:

(i) Principal component method of factor analysis is used to find whether all these metrics are independent or are capturing same underlying property of the object being measured. (ii) Univariate logistic regression analysis is carried out to test the hypothesis that size, coupling and inheritance increase fault proneness of a class whereas cohesion increase decrease fault proneness of a class and find individual impact of metrics on fault proneness. (iii) Finally a model using multivariate logistic regression analysis for predicting fault proneness of classes is given to predict which classes of a java application released in future will be faulty. The results show that though the number of OO metrics is large but the number of dimensions actually found is much low. Further it was observed that import coupling (that count the number of other classes called by a class) metrics are strongly associated with fault proneness and predict faulty classes with high accuracy. Based on these results, it is reasonable to claim that such a model could help for planning and executing testing by focusing resources on fault prone parts of the design and code.
P a g e |4
QUALITY METRIC SUITED VALIDATED IN RESEARCH

The three different quality metric suites and empirically validated them using the software Rhino. The three metrics are Chidamber and Kemerer (CK) Metrics, Robert C. Martins Metric Suite and McCabes Metric Suite. The detailed description of the metrics in the validated metric suites is given in the following sub-sections. The block diagram of the Metric suites validated in the proposed approach is depicted in the figure. Figure: Metric suites validated in the proposed approach
1. Chidamber and Kemerer (CK) Metrics Classic set of metrics proposed by Chidamber and Kemerer in 1991 particularly for objectoriented software has been upgraded in 1994 The creators of this group of metrics say that these measures can assist users in understanding object oriented design complexity and in forecasting external software qualities for example software defects, testing, and maintenance effort. Utilization of the CK set of metrics and other corresponding measures
P a g e |5
are progressively growing in industry acceptance. The Chidamber and Kemerer (C&K) metrics suite is an extensively used metrics suite. It has been certified by a number of researchers and it forms the heart of our study. (i.) Weighted Methods per Class (WMC) The WMC of a class is the weighted sum of the complexities of its methods. More accurately, WMC is defined to be the weighted number of all member functions and operators defined in each class. WMC is a sum of complexities of methods of a class. Consider a class C, with methods M1. Mn that are defined in the class. Let c1cn be the complexity of the methods. Then
WMC measures size as well as the logical structure of the software. The number of methods and the complexity of the involved methods are predictors of how much time and effort is required to develop and maintain the class. The larger the number of methods in a class, the greater the potential impact on inheriting classes. Consequently, more effort and time are needed for maintenance and testing. Furthermore, classes with large number of complex methods are likely to be more application specific, limiting the possibility of reuse. Thus WMC can also be used to estimate the usability and reusability of the class. If all methods complexities are considered to be unity, then WMC equals to Number if Methods (NMC) metric.In Figure, class Book has two functions getdata and display which call methods Publication::getdata(), Sales::getdata(), Publication::display(), Sales::display()
P a g e |6
(ii.) Depth of Inheritance Tree (DIT) The depth of a class within the inheritance hierarchy is the highest number of steps from the class node to the root node of the tree and it measures the number of ancestor classes. The number of methods inherited by a class increases with the depth of the class within the hierarchy, making it more difficult to forecast its behavior. The depth of a class within the inheritance hierarchy is maximum number of steps from the class node to the root of the tree and is measured by number of ancestor class. 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,
P a g e |7
since more methods and classes are involved. The deeper a particular class is in the hierarchy, the greater potential reuse of inherited methods. For languages that allow multiple inheritances, the longest path is usually taken.
Fig : Depth of Inheritance The Depth of Inheritance of this tree is 4 (iii.) Number of Children (NOC) According to this metric, Number of children (NOC) of a class is the number of immediate sub-classes subordinated to a class in the class hierarchy. NOC metric is theoretically based on the idea related to the scope of properties. It measures the number of sub-classes that are going to inherit the methods of the parent class. As NOC metric counts only the immediate sub-classes instead of all its descendants, the definition of NOC metric presents a changed view of the system. The NOC metric equals to number of immediate subclasses subordinated to a class in the class hierarchy. 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.
P a g e |8
Fig : Number of Children In the preceding example the NOC for C3 is 3 i.e. C31, C32, C33. (iv.) Coupling between Objects (CBO) CBO is a measure of the number of other classes to which a class is coupled. Two classes are said to be coupled if methods and variables defined in one class are used by methods declared in the other class. In depth information about the methods, the detailed design description or the class code is required by this metric for making measurement. (v.) Response for a Class (RFC) The response set of a class is composed of the set of all the methods of the class and the set of methods called directly by the methods (i.e., the set of methods that can potentially be executed in response to a message received by an object of that class). This includes all methods accessible within the class hierarchy. This metric utilizes the number of methods to evaluate the complexity of the class and also the amount of communication it has with other classes . 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.
where Mi = set of all methods in a class (total n) and Ri = {Rij} = set of methods called by Mi.
P a g e |9
(vi.) Lack of Cohesion in Methods (LCOM) Lack of Cohesion (LCOM) measures how well the methods in a class are unrelated to each other. Methods in a cohesive class use the same set of variables. A highly cohesive module should be independent; high cohesion signifies good class subdivision. Lack of cohesion or low cohesion adds to complexity, thereby increasing the chances of errors during the development process. High cohesion signifies simplicity and high reusability. Classes with low cohesion could possibly be reconstructed into two or more smaller classes with increased cohesion. 2. Robert C. Martins Metric Suite (i.) Efferent Coupling (Ce) Efferent coupling between packages (Ce) measures the total number of external classes coupled to classes of a package because of outgoing coupling (external classes used by packages class). All classes are counted only once. If the package does not contain any class or the package's classes do not use any external class, then the value of Ce is zero. Ce is mainly appropriate for object-oriented systems. (ii.) Afferent Coupling (Ca) Afferent coupling between packages (Ca) measures the total number of external classes coupled to classes of a package because of incoming coupling. All classes are counted only once. If the package does not contain any class or external classes do not use any of the
P a g e |10
package's classes, then the value of Ca is zero. Ca is mainly appropriate for object-oriented systems. (iii.) Instability (I) Instability is the ratio of efferent coupling (Ce) to total coupling (Ce + Ca) such that I = Ce / (Ce + Ca). This metric signifies the package's adaptability to change. The range for this metric is 0 to 1, with I=0 signifying an absolutely stable package and I=1 signifying an absolutely instable package. (iv.) Abstractness (A) Abstractness is the ratio of the number of abstract classes (and interfaces) to the total number of classes in the evaluated package. The range for this metric is 0 to 1, with A=0 signifying an absolutely concrete package and A=1 signifying an absolutely abstract package. (v.) Normalized Distance from Main Sequence (Dn) Normalized Distance from Main Sequence is the perpendicular distance of a package from the idealized line A + I = 1. This metric is a measure of abstractness and stability. Ideal packages are either absolutely abstract or stable (x=0, y=1) or absolutely concrete and unstable (x=1, y=0). The range for this metric is 0 to 1, with D=0 representing a package that is coincident with the main sequence and D=1 representing a package that is as far away from the main sequence as possible . 3. McCabes Metric Suite The cyclomatic complexity (McCabe) is used to evaluate the complexity of an algorithm in a method.A method with a low cyclomatic complexity need not inevitably mean that the methods are not complex because it may mean that decisions are postponed through message passing. On account of inheritance, cyclomatic complexity cannot be used to measure the complexity of a class, but cyclomatic complexity of individual methods united with other measures can be used to calculate the complexity of a class. Though this metric is particularly applicable to the estimation of the complexity feature, it is also associated with all the other features. Number of flows through a section of code is measured by McCabeCC. Whenever a branch takes place, this metric is increased by one, (if, for, while, do, case, catch and the ?: ternary operator, as well as the && and || conditional logic operators in expressions). It is computed for methods only. High value of this metric indicates the
P a g e |11
complexity of the application or at least the presence of huge number of alternative flows in the application. Cyclomatic complexity is rooted in the program control structure and can be computed from the amount of conditional statements present in the source code. (i.) Lines of Code (LOC) The LOC of a class is the total number lines in the body of the class and its methods excluding empty and comment lines. LOC Metrics calculates total lines of code (LOC), blank lines of code (BLOC), comment lines of code (CLOC), lines with both code and comments (C&SLOC), logical source lines of code (SLOC-L), McCabe VG complexity (MVG), and number of comment words (CWORDS). Physical executable source lines of code (SLOC-P) are determined by subtracting the number of blank lines and comment lines from the total number of lines of source code. Count for the entire project was computed by adding the individual file count. A comment word histogram was also created by the LOC Metrics .
(ii.) Method Lines of Code (MLOC) A Method line of code (MLOC) is the total number of non-blank and non-comment lines present inside a method. Total number of lines of code inside method body includes avg, max, and sum but excludes blank and comment lines. (iii.) Source lines of code (SLOC) SLOC is normally used to forecast the amount of effort that will be necessary to build up a program, as well as to assess programming productivity or effort once the software is created. There are two main types in SLOC, physical and logical. Physical SLOC is the number of lines in the source code of the program including comment lines and blank lines. If a section consists of more than 25% blank lines then the blank lines that are in excess of 25% are ignored. Logical SLOC tries to measure the number of statements instead of lines in a programs source code . (iv.) Nested Block Depth (NBD) Avg, max, and sum are included in the calculation of the depth of nested blocks of code.
P a g e |12
METRICS
This section describes various metrics used by different researchers in studies.
1 C.K. Metrics Model

Chidamber and Kemmerers Metrics Suite define the CK Metric Suite .The suite helps designers and testers to make better design decisions.
2 MOOD Metrics Model

Metrics for Object Oriented Design referred as MOOD Metrics Model .It describes basic structural mechanism of the object oriented paradigm as encapsulation, inheritance, polymorphism and message passing. In MOOD metrics model, methods and attributes are used in every metrics. Methods are used to perform operations of several kinds. Attributes are used to represent the status of each object in the system.
MILESTONE STUDIES
This section briefly describes the various studies done in the field of predicting fault proneness. The studies show the progress in the field .Metrics played a pivotal role in the prediction of fault proneness.
[1] Basili et al. Empirically validated CK Metrics and found no correlation among metrics. It is stated that all metrics were effective in predicting fault proneness except LCOM. Advantage- It validates the metric set for predicting fault proneness modules. They can be used as quality indicators as most of them are independent. Disadvantage- Data collected is not of industry system so there can be increased complexity when it comes to large object oriented systems of organizations. Problems can increase in large systems. This seminar does not differentiate in couplings (CBO and RFC) within and across inheritance hierarchies.
P a g e |13
[2] Briand et al. The collected data from a project of a university. This seminar uses GEN++ to extract the values of metrics. Validated inheritance, coupling and cohesion metrics. Advantage- It validates the fact that many of the design measures present in literature are redundant. Coupling induced by method invocations, the rate of change in a class due to specialization and the depth of a class in its inheritance hierarchy appear to be important quality factors. Disadvantage- The data collected is not of industry system so there can be increased complexity when it comes to large object oriented systems of organizations. Secondly cohesion does not have impact on fault proneness so it might be that cohesion is not been understood thoroughly.
[3] Tang et al. It analyzed C K OO metrics suite on three industrial applications developed in C++. They found none of the metrics examined to be significant except RFC and WMC. Advantage- They proposed new set of metrics which proved to be helpful in which classes need to be tested using OO testing techniques. [4] Emam et al. It took confounding effect of size is taken into consideration. Investigations regarding class sizes are done and after that a validation study of object oriented metrics is conducted. After controlling for size, none of the metrics studied were associated with fault-proneness. Advantage- This seminar demonstrates a strong size confounding effect. Disadvantage- Study did not take severity of faults in consideration.
P a g e |14
[5] Emam et al. There is a validation studies on a huge telecommunications C++ system. This investigates 24 metrics proposed by CK and Briand et al.CBO and ACMIC metrics are good indicators of fault-prone classes. They are both associated with fault-proneness after controlling for size. Advantage- Empirically validates metrics keeping in mind confounding effects of class size. They prove accuracy of prediction models through the use of Receiver Operating Characteristic. Disadvantage- Severity of faults not taken in consideration. [6] Briand et al. Empirically explore the relationships between existing object oriented measures. It is seen here that with size of classes, frequency of method invocations and depth of inheritance also affect fault proneness. Classes with higher WMC, CBO, DIT and RFC were more fault prone, while classes with more children (NOC) were less fault prone. LCOM was not associated with defects. Advantage- They are able to find the relationships between metrics using univariate and multivariate analysis. Disadvantage- Cohesion does not have impact on fault proneness so there is a possibility that cohesion is not been understood thoroughly. [7] Fioravanti et al. It provides new approach to define models for fault proneness. Large set of metrics is taken and then it is being reduced using principal component analysis. Conclusion drawn was that only few of them are relevant for identifying fault prone classes. The three models made are accurate in terms of validating metrics. The hybrid model created with 12 metrics is of use Conclusion drawn was decision trees are more flexible and robust than statistical classification models. Advantage- Seminar uses tools to extract metrics. These models can help in defining new dimensions to validation studies.
P a g e |15
Disadvantage- This seminar does not differentiate in couplings (CBO and RFC) within and across inheritance hierarchies. The models were too large to be useful in practice. [8] Emam et al. The study shows to construct predictive models using object oriented models. One version of java application is used to make a predictive model and subsequent release is used to validate that model. Results show that an export coupling metric, depth of inheritance had the strongest association with fault proneness. Coupling across inheritance hierarchies (OC) is much more significant than coupling inside inheritance hierarchies to predict fault proneness. Advantage- Distinguished coupling inside and across inheritance hierarchies. Paid attention to locus of impact, whether the class is a user or used in coupling relationship. Disadvantage- This study did not account for the severity of faults. [9] Yu et al. It explores relationship between metrics and fault proneness. Data collected in java was examined for correlations among them. Highly correlated subsets were found. They found that metrics (CBOin, RFCin, and DIT) were significant but to a different extent. Advantage- Distinguished coupling inside and across inheritance hierarchies. Disadvantage- No attention to severity for faults or to the confounding effects of class size. [10] Subramanyam et al. It uses CK Metrics suite subset to determine software defects. It uses two programming languages C++ and Java. It takes care for confounding size effects on class. Size was good predictor in both the languages. Advantage-This work shows that relationship between dependent and independent variable can also depend on software language. Results are different in C++ and Java.
P a g e |16
Disadvantage-This covers subset of CK Metrics. Secondly it aims at analyzing defects. [11] Gyimothy et al. It describes how to calculate the object oriented metrics given by Chidamber and Kemerer of opensource software system. Systems opted for validations were Bugzilla and Mozilla. Techniques used were linear regression, logistic regression and machine learning methods. All techniques revealed approximately same results while CBO metrics seems to be best predictor of metrics. NOC metric cannot be used for prediction. Advantage- The study paves a way to a different approach for open source systems. Disadvantage- There are lots of errors in the model which have to be rectified. [12] Zhou et al. It uses logistic regression and machine learning methods to investigate the relationship between fault proneness and CK Metrics Suite. Machine Learning methods which are incorporated in the study are Nave Bayes network, Random Forest and NNge. It does not take account of severity of impact instead the relationship between metrics and fault proneness when fault severity is taken into account. Advantage- Stepping stone in the field as takes severity of faults into consideration. Machine Learning methods used to predict fault proneness can be of added advantage. [13] Olague et al. It validated object oriented metrics on versions of open source agile software. They found WMC, CBO, RFC and LCOM to be very significant. The MOOD metrics is direct measure of size when used over large classes. Conclusion drawn was decision trees are more flexible and robust than statistical classification models. Advantage- It reviews highly iterative or agile software development processes.
P a g e |17
Disadvantage- When the software is in the early stages of evolution and complexity is still low, the metrics will not be very effective. Also, for highly iterative or agile systems, the metrics will not remain effective forever. [14] Singh et al. Empirically validates software metrics for different levels of severity of faults. The techniques employed are regression and machine learning methods. The paper compares both techniques in order to find which one is better. Metrics used is CK Metrics suite.ROC analysis is also done. Advantage-Severity of faults is important aspect for predicting fault proneness. Used CK Metrics hence results could be of great help to researchers and practitioners. Disadvantage-Study done on industrial background could have been more beneficial.
MEASURING QUALITY
Measurement enables to improve the software process, assist in the planning, tracking the control of a design. A good software engineer uses measurements to assess the quality of the analysis and design model, the source code, the test cases, etc. What does quality mean? Quality refers to the inherent or distinctive characteristics or property of object, process or other thing. Such characteristics or properties may set things apart from other things, or may denote some degree of achievement or excellence. Many quality measures can be collected from literature, the main goal of metrics is to measure errors and defects. The following quality factor should have every metrics Efficiency - Are the constructs efficiently designed? The amount of computing resource and code required by a program to perform its function.
P a g e |18
Complexity - Could the constructs be used more effectively to decrease the architectural complexity? Understandability - Does the design increase the psychological complexity? Reusability - Does the design quality support possible reuse? Extent to which a program or part of a program can be reused in other application , related to the packaging and scope of the functions that the program performs. Testability/Maintainability - Does the structure support ease of testing and changes? Effort required locating and fixing an error in a program, as well as effort required to test a program to ensure that it performs its intended function.
Figure : Example of deriving metrics from goal and questions
P a g e |19
Table : Computation formulas for quality attributes
HYPOTHESES
We test the hypotheses given below to find our empirical consequences. H1 (for import coupling metrics): A class with more import coupling than its peers is more fault-prone as compared to them. (Null hypothesis: A class with more import coupling than its peers is less fault-prone prone as compared to them). H2 (for export coupling metrics): A class with more export coupling than its peers is more fault-prone as compared to them. (Null hypothesis: A class with more export coupling than its peers is less fault-prone as compared to them).
P a g e |20
H3 (for cohesion metrics): A class with lower cohesion than its peers is more fault prone as compared to them. . (Null hypothesis: A class with lower cohesion than its peers is less fault-prone as compared to them). H4 (for DIT metric): A class located lower in a class inheritance hierarchy than its peers is more fault-prone as compared to them. (Null hypothesis: A class located lower in a class inheritance hierarchy than its peers is less fault-prone as compared to them.). H5 (for NOC metric): A class with a larger number of descendants than its peers is more fault-prone as compared to them. (Null hypothesis: A class with a larger number of descendants than its peers is less fault-prone as compared to them). H6 (for size metrics): A class with a larger size i.e. more information than its peers is more fault-prone as compared to them. (Null hypothesis: A class with a larger size i.e. more information than its peers is less fault-prone as compared to them). TABLE: OBJECT ORIENTED METRICS
Metric Coupling between Objects (CBO) Coupling between Objects (CBO1) Lack of Cohesion (LCOM1) Lack of Cohesion (LCOM2)
Definition CBO for a class is count of the number of other classes to which it is coupled. Same as CBO, except that inheritance based coupling is not counted. It counts number of null pairs of methods that do not have common attributes. It measures the dissimilarity of methods in a class by looking at the instance variable or attributes used by methods. Number of The NOC is the number of immediate subclasses of a Children (NOC) class in a hierarchy. Depth of The depth of a class within the inheritance hierarchy is Inheritance (DIT) the maximum number of steps from the class node to the root of the tree and is measured by the number of ancestor classes. Weighted The WMC is a count of sum of complexities of all Methods per methods in a class. Class (WMC) Response for a The response set of a class (RFC) is defined as set of Class (RFC) methods that can be potentially executed in response to a message received by an object of that class.
Sources [Chidamber94] [Chidamber91] [Chidamber91] [Chidamber94]
[Chidamber94] [Chidamber94]
[Chidamber94]
[Chidamber94]
P a g e |21
These coupling metrics count number of interactions between classes. The metrics distinguish the relationship between the classes (friendship, inheritance, none), different types of interactions, and the locus of impact of the interaction. The acronyms for the metrics indicates what interactions are counted: The first or first two characters indicate the type of coupling relationship between classes (A: Ancestor, D: Descendents, F: Friend classes, IF: Inverse Friends [Braind99] (classes that declare a given class a as their friend), O: Others, i.e., none of the above relationships). The next two characters indicate the type of interaction: CA: There is a Class-Attribute interaction if class x has an attribute of type class y. CM: There is a Class-Method interaction if class x consist of a method that has parameter of type class y. MM: There is a Method-Method interaction if class x calls method of another class y, or class x has a method of class y as a parameter. The last two characters indicate the locus of impact: IC: Import coupling, counts the number of other classes called by class x. EC: Export coupling, count number of other classes using class y. Lines Of Code It is the count of lines in the text of the source code (LOC) excluding comment lines IFCAIC ACAIC OCAIC FCAEC DCAEC OCAEC IFCMIC ACMIC DCMIC FCMEC DCMEC OCMEC IFMMIC AMMIC OMMIC FMMEC DMMEC OMMEC
SIGNIFICANCE OF METRICS
The following statistics are reported for each significant metric: Odds Ratio: It is the probability of the event divided by the probability of the nonevent. The event in our study is having a fault and non event is probability of not having a fault. P a g e |22
Maximum Likelihood Estimation (MLE) and Coefficients (Ai's): MLE is a statistical method for estimating the coefficients of a model. The likelihood function (L) measures the probability of observing the set of dependent variable values (P1, P2 Pn). The statistical significance (sig): It is the significance level of the coefficient, larger the statistical significance less is the estimated impact of the independent variables (OO metrics). In our study we used 0.05 as the significance threshold. The R2 Statistic: It is the proportion of the variance in the dependent variable that is explained by the variance of the independent variables. The higher the effect of the model's explanatory variables implies better accuracy of the model.
PERFORMANCE EVALUATION
The model is evaluated in following ways: The sensitivity and specificity of the model is calculated to predict the correctness of the model. The percentage of classes correctly predicted to be fault prone is known as sensitivity of the model. Sensitivity can be formally defined as:
Senstivity = Classes correctly predicted as fault prone *100 Classes actually fault prone
The higher the sensitivity (% correct predictions), the better the model. The percentage of non-occurrences correctly predicted i.e. classes predicted not to be fault prone is called specificity of the model.
Specificity can be formally defined as:

Specificity = Classes correctly predicted not to be fault prone 100 Classes actually not fault prone Ideally both the sensitivity and specificity should be high. A low sensitivity means that there are many low risk classes that are classified as faulty. Therefore, the organization would waste resource in focusing additional testing effort on these classes. A low specificity means that there are many high risk classes that are classified as not faulty. Therefore, the organization would be passing high risk classes to customers.
P a g e |23
To predict the accuracy of model it should be applied on different data sets. Therefore we performed k-cross validation of model . The data set is randomly divided into k subsets. Each time one of the k subsets is used as the test set and the other k-1 subsets are used to form a training set. Thus we get the fault proneness for all the k classes.
RESEARCH METHODOLOGY
In this section, the procedure used to analyze the data collected for each measure is described in following stages: 1. Principal-Component Method: Principal Component Method (PCM) is a mathematical procedure that uses an orthogonal transformation to convert a set of observations of possibly correlated variables into a set of values of uncorrelated variables called principal components. PCM is used to maximize the sum of squared loadings of each factor extracted in turn. The PC Method aims at constructing new variable (Pi), called Principal Component (PC) out of a given set of variables Xj' s( j = 1,2,...., k).The variables with high loadings help identify the dimension P.C. is capturing, but this usually requires some degree of interpretation. In order to identify these variables, and interpret the PC.s, we consider the rotated components. As the dimensions are independent, orthogonal rotation is used. There are various strategies to perform such rotation. We used the varimax rotation, which is the most frequently used strategy in literature. Eigenvalue (or latent root) is associated with each PC. It refers to the sum of squared values of loadings relating to dimension, and then the sum is referred to as eigenvalue. Eigenvalue indicates the relative importance of each dimension for the particular set of variables being analyzed. In our study, the PC.s with eigenvalue greater than 1 is taken for interpretation. The coupling of system classes to system classes is counted separately from coupling of system classes to standard library classes. SL is suffixed with the metric name when coupling to standard library classes is counted. For instance CBO metric in such case is named as CBO_SL. The PC extraction method and varimax rotation method is applied on all metrics. The rotated component matrix is given in Table 3. The values above 0.7 (shown in bold in Table 3) are the metrics that are used to interpret the PC.s. For each PC, we also provide its eigenvalue, variance percent and cumulative percent. The interpretations of PCs are given as follows:
P a g e |24
P1: CBO_SL, OCAIC_SL, OCMIC_SL, CBO1_SL and OMMIC_SL measure coupling from standard library classes. P2: LCOM1, LCOM2, WMC and OCMIC. This dimension includes coupling, cohesion and size metrics. This indicates that import coupling and cohesion metrics have correlation with size. P3: OMMIC, RFC are coupling metrics. These metrics count import coupling from system classes through method invocations. P4: AMMIC_SL, OCAIC are import coupling metrics. P5: CBO, CBO1 are coupling metrics that count both import and export coupling. P6: NOC is an inheritance metric that counts number of children of a class.
P a g e |25
Table 4: Results for Principal Component Method

PC P1 P2 P3 P4 P5 P6
Cumulative% 32.608 44.97 56.010 63.676 70.424 75.603 Variance % Eigen value CBO CBO_ SL CBO1 LCOM 1 LCOM 2 DIT NOC LOC RFC WMC 32.608 12.3 6.84 0.12 0.80 0.03 0.28 0.28 -0.25 0.10 0.27 0.20 0.35 2.59 0.00 0.15 -0.03 0.87 0.88 -0.14 -0.07 0.41 0.34 0.74 11.03 2.31 0.18 0.07 0.18 0.26 0.21 0.36 0.17 0.68 0.76 0.49 7.665 1.60 0.14 0.37 -0.11 0.06 0.01 -0.29 -0.04 0.02 0.15 0.16 6.748 1.41 0.91 0.12 0.94 -0.07 -0.08 -0.28 -0.08 0.05 0.07 0.01 5.1788 1.08 -0.05 0.16 -0.01 0.01 0.00 -0.25 0.80 0.17 0.17 0.17
(2) Logistic Regression Model:

Logistic Regression (LR) model is the most widely used technique in literature to predict dependent variable from set of independent variables. In our work independent variable are OO metrics and dependent variable is fault proneness. LR is of two types: (i) (ii) Univariate LR Multivariate LR Univariate LR is a statistical method that formulates a mathematical model depicting relationship among each independent variable and dependent variable to determine if the measure is statistically related, in the expected direction, to fault proneness. Multivariate LR is used to construct a prediction model for the fault-proneness of classes. In this method combination of metrics are used to determine the effect on dependent variable. In our research we used univariate logistic regression model. The general form of an LR model is:
P a g e |26
where is the probability of a class having a fault, and the xs are the independent variables. In a univariate analysis only one xi, x1, is included in the model, and this is the product metric that is being validated:
When controlling for size, a second xi, x2, is included that measures size:
The magnitude of an association can be expressed in terms of the change in odds ratio as the x1 variable changes by one standard deviation. The odds ratio is a measure of association. The odds of an event, is the ratio of the number of ways the event can occur to the number of ways the event cannot occur. The odds ratio is the ratio of faulty classes and non-faulty classes. If a metric is not related to fault-proneness, then the odds ratio is equal to one. If there is a positive association, then the odds ratio will be greater than one, and if there is a negative association, then the odds ratio will be a fraction. Let D denote the presence of a fault (D . 1) or absence (D . 0), and let x be our coupling metric. Then, (4) is the probability of a fault given the value of x. The probability of there not being a fault given the value of x is:
(5) The odds of a class having a fault given the value of x is
The odds of a class having a fault if the product metric value x is increased by one standard deviation is:
The change in odds by increasing the value of x by one standard deviation is:
P a g e |27
In this subsection we find the relationship of independent variables (OO metrics) with dependent variable (fault proneness). Univariate LR analysis is done on 85 system classes. The table 2 provides the coefficient (B), standard error (SE), statistical significance (sig), R2 statistic and odds ratio (exp(B)), for each measure. Metrics with no variance or lower variance are excluded from the table. The metrics with a significant relationship to fault proneness, that is, below or at the significance (named as Sig. in Table 2) threshold of 0.05 are shown in bold (see Table 2). The metrics that are not shown in bold do not have a significant relationship with fault proneness.
Table: Statistical results for fault proneness.

Metric CBO CBO1 LCOM1 LCOM2 DIT NOC LOC RFC WMC B 0.8436 0.6180 0.0612 0.0800 0.7518 0.3147 0.0100 0.1817 0.2466 S.E. 0.2802 0.2491 0.0244 0.0347 0.4279 0.2666 0.0033 0.0410 0.0646 Sig. 0.0026 0.0131 0.0121 0.0212 0.0789 0.2379 0.0025 0.0000 0.0001 R2 0.1206 0.077 0.2155 0.1982 0.0344 0.0172 0.273 0.536 0.375 Exp(B) 2.3246 1.8553 0.0631 1.0832 0.4715 1.3698 1.0101 1.1993 1.2796
P a g e |28
CONCLUSION
In real-life systems, faults can differ significantly in their impact on the operation of a software system. It would be valuable to use OO design metrics to help to identify the faultproneness of classes when the severity of fault is taken into account. Previous studies have raised the need to validate OO design metrics across different fault severities. However , little is currently known on this subject. Our study attempts to fill this gap by empirically validating OO design metrics for different fault severities. In this study we first find the interrelationships among selected metrics and then found the individual and combined effect of selected metrics on fault proneness. The results of univariate LR analysis show that most of the import coupling and cohesion metrics are found related to fault proneness. On the other hand inheritance metrics were not found related to fault proneness . We are also applied Principal component method to these metrics to get the Fault proneness. The number of dimensions captured in PC analysis is much lower than the number of metrics. This simply supports the fact that many of the metrics proposed are based on comparable ideas and therefore provide somewhat redundant information. It was observed during testing the classes coupled with standard library classes were less fault prone than those coupled with system classes.
P a g e |29
REFERENCES
K.K.Aggarwal, Yogesh Singh, Arvinder Kaur, Ruchika Malhotra, Investigating effect of Design Metrics on Fault Proneness in Object-Oriented Systems,Published by ETH Zurich, Chair of Software Engineering,2008 K.El Emam, W. Melo, J. Machado, The Prediction of Faulty Classes Using Object-Oriented Design Metrics, Journal of Systems and Software, vol. 56, 63-75, 2001. S.Chidamber and C.Kemerer, A metrics Suite for Object-Oriented Design ,IEEE Trans. Software Engineering, vol. SE-20, no.6, 476-493, 1994. M-H. Tang, M-H. Kao, and M-H. Chen, An Empirical Study on Object Oriented Metrics, Proc. Sixth Int'l Software Metrics Symp., pp. 242-249, 1999. L. Briand, J. Wuest, J. Daly, and V. Porter, Exploring the Relationships Between Design Measures and Software Quality in Object-Oriented Systems, J. Systems and Software, vol. 51, pp. 245- 273, 2000. L. Briand, J. Wuest, S. Ikonomovski, and H. Lounis, A Comprehensive Investigation of Quality Factors in Object-Oriented Designs: An Industrial Case Study, Technical Report ISERN-98-29, Int'l Software Eng. Research Network, 1998. L. Briand, J. Daly, and J. Wuest, A Unified Framework for Coupling Measurement in Object-Oriented Systems, IEEE Trans. Software Eng., vol. 25, no. 1 pp. 91-121, Jan. 1999. L. Briand, J. Daly, and J. Wuest, A Unified Framework for Cohesion Measurement in Object-Oriented Systems, Empirical Software Eng., vol. 3, pp. 65-117, 1998. L. Dales and H. Ury, An Improper Use of Statistical Significance Testing in Studying Co-variables, International Journal of Epidemiology, vol. 7, no. 4, pp. 373-375, 1978. N. Fenton, Software Metrics: Theory, Tools and Validation, Journal of Software Engineering., pp. 65-78, Jan. 1990. Amjan Shaik, C. R. K. Reddy, Bala Manda, Prakashini. C, Deepthi. K An Empirical Validation of Object Oriented Design Metrics in Object Oriented Systems International Journal of Emerging Trends in Engineering and Applied Sciences (IJETEAS) 1 (2): 216-224 (ISSN: 2141-7016). Amjan Shaik, C. R. K. Reddy, Bala Manda, Prakashini. C, Deepthi, Metrics for Object Oriented Design Software Systems: A Survey International Journal of Emerging Trends in Engineering and Applied Sciences (IJETEAS) 1 (2): 190-198 (ISSN: 2141-7016).
P a g e |30

Seminar

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Seminar

Загружено:

Авторское право:

Доступные форматы

InvestigatetheResultofObjectOrientedDesignSoftware MetricsonFaultPronenessinObjectOrientedSystems

A SEMINAR REPORT Submitted by

Ms. Ravneet Kaur Dhillon

PTU RAYAT & BAHRA INSTITUTE OF ENGINEERING & BIO-TECHNOLOGY

Ravneet Kaur Dhillon

The study is divided into following parts:

QUALITY METRIC SUITED VALIDATED IN RESEARCH

1 C.K. Metrics Model

2 MOOD Metrics Model

Figure : Example of deriving metrics from goal and questions

Table : Computation formulas for quality attributes

Sources [Chidamber94] [Chidamber91] [Chidamber91] [Chidamber94]

Specificity can be formally defined as:

Table 4: Results for Principal Component Method

(2) Logistic Regression Model:

(5) The odds of a class having a fault given the value of x is

Table: Statistical results for fault proneness.

Вам также может понравиться