Software Fault Estimation Tool Based on Object-Oriented Metrics

A fault is an error that has effects on system behaviour. A software metric is a value that represents the degree to which software processes work properly and where faults are more probable to occur. In this research, we study the effects of removing redundancy and log transformation based on threshold values for identifying faults-prone classes of software. The study also contains a comparison of the metric values of an original dataset with those after removing redundancy and log transformation. E-learning and system dataset were taken as case studies. The fault ratio ranged from 1%-31% and 0%-10% for the original dataset and 1%-10% and 0%-4% after removing redundancy and log transformation, respectively. These results impacted directly the number of classes detected, which ranged between 1-20 and 1-7 for the original dataset and 1-7 and 0-3) after removing redundancy and log transformation. The Skewness of the dataset was deceased after applying the proposed model. The classified faulty classes need more attention in the next versions in order to reduce the ratio of faults or to do refactoring to increase the quality and performance of the current version of the software.


I. Introduction
Software systems have become very common, and because they depend on the programming of many people, there is a possibility of the emergence of errors. These errors may affect code quality [1], reliability [2] and maintainability [3]. After diagnosing the error in the classes, refactoring can be performed to increase accuracy of the applications [4]. Object-oriented metrics are used to measure software quality during software development and beyond. There are metrics that aid to measure the quality of the code and give suggestions to improve reuse, ease of maintenance, and detection errors, the most important of which are CK (Chidamber and Kemerer) metrics [5]. The CK metrics cover the most significant object-oriented properties, including cohesion, coupling, size, inheritance, and complexity [6]. They take high importance in applications that need accuracy. The used CK metrics are summarized in Table-1 [7,8]. A measure representing the total complexity of class's methods.
DIT ("Depth of Inheritance Tree") A measure representing the depth of a class diagram.

NOC ("Number Of Children")
A measure representing the number of classes associated with a class with an inheritance relationship. CBO ("Coupling Between Object classes") A measure representing the number of classes associated with a class with any relationship.

RFC ("Response For Class")
A measure representing the total number of methods of class taking into account received messages. LCOM ("Lack Of Cohesion Metric") A measure representing the correlation between methods and local variables of a certain class.
There are many previous research attempts to locate the error in the source code, which relied on different principles. Till now, no study and model have been identified that can be applied to all software and gives accurate results for all projects. Thus, this paper tried to have a different equation for each software to meet with it by adding a constant value, ranging from zero to one and then to the threshold value, as determined by the experiment to increase the accuracy of results. In order to improve the quality of the program, these errors must be identified more precisely. In this study, an indicator is needed to reduce the effort to understand, maintain, and refactor. Therefore, the software metrics were used to determine which classes are needed more to focus on the testing and refactoring. After detecting the faulty classes, the refactoring process can be performed. The present study aims to apply a methodology that focuses on removing redundancy and then applying log transformation to improve the quality of software metrics for identifying faults-prone classes of open source software and to view a comparison of the metric values of the original dataset with the values of the metric after performing the remove redundancy, log transformation, and recording of results. The research is organized as follows. Section two describes related work. Section three describes methodology and contains a representation of UML (Unified Modelling Language) diagrams that shows the overall structure of the research. Section four introduces case studies, followed by the results that are obtained from the proposed methodology implementation. Finally, Sections five and six describe the conclusions and recommendations for the future of the research.

II. Related Work
In 2010, Shaik et al. demonstrated a study on the software metrics and their growing importance in software development and obtaining certain characteristics of the software [9]. In 2012, Ferreira et a.l studied open source projects, defined a threshold value for software metrics of object-oriented programs, and explored the importance of deriving a threshold value for the metrics of Software Engineering, which they used to enhance the quality of open source programs [10]. Also in the same year, Chawla utilized five software metrics for analysing a set of three sorting programs based on java.
There were 3 software measurement tools which were utilized for judging their performance in terms of metrics indicated. The tool's comparative analysis was specified for indicating how they are different in delivering results with regard to the same programs [11].
In 2013, Kapila et al. demonstrated all the approaches of faults prediction for getting aid with such work to design Bayesian inference and Logistic regression model. Also, it was indicated that the Bayesian inference graph might be provided for the probabilistic approach for faults identified and presented for the next upcoming release. With regard to the Probabilistic reliability analysis, the Bayesian inference was suggested for evaluating risk-related data. Such finding suggested a relation between object-oriented metrics and faulty classes [12]. In 2015, Shatnawi proposed a model which takes into consideration data distribution and skewness of the data and suggests log transformation and threshold value to identify faulty classes of open source programs. He showed the importance of using log transformation in fault predicting and its impact on the validity of the results [13].
In 2017, Zhang et al. studied the effects of the log, Box-Cox, and rank transformations on the normality of software metrics for open source software. Compared with their results, they selected the best training for a target open source software, then measured the performance based on it [14]. Gupta and Saxena proposed a model that used fourteen metrics from open source dataset and explored the importance of object oriented metrics and their relationship with bug prediction. The bug prediction was calculated based on equations that used these fourteen metrics [15]. Also in the same year, Gupta et a.l proposed a model to formulate some assumptions matching to each other and to object-oriented metrics , where the best appropriate metrics were chosen for the proposed model. The Logistic-Regression-Classifier offers precision among all classifiers. The proposed model was trained and tested on each of the dataset and the precision of the software was calculated in each case [16]. In 2018, three researches were done in this area, as follows.
Zhu and Pham identified the significant difference between software metrics and observed defect prediction. They also studied the relations involved in the object-oriented metrics "CK metrics suite" and the number of defects. They finally decided on the differences of the metrics, to eclipse classes as defective, and selected them with regard to defect prediction. They took a sample dataset from the bug prediction dataset of source code metrics as the data is based on Eclipse classes [17].  Zhu et a.l suggested a theoretic software reliability model which incorporates the process of fault detection which is a stochastic process because of randomness resulting from environmental factors. The environmental factor, Percentage of Reused Modules, has been specified as gamma distribution in their work on the basis of collected data from the industry. Furthermore, the Open Source Software project data have been involved for showing the efficiency and predictive power regarding the suggested model [18].  Belachew et al. assessed and analyzed software metrics utilized for measuring software quality, especially software products and processes. The software quality is used to measure how the software is developed and the way that software is in accordance with the design. Yet, the quality standard utilized from one organization was considered to be distinctive from the others. Thus, it was better to utilize the software metrics for measuring its quality as well as the quality of the majority of the current software metrics tools [19].
In 2019, Rahmann et al. applied the software change metrics with regard to defect prediction. Furthermore, the performances of excellent machine learning and hybrid algorithms were used in the estimation of the defect with changing metrics. Hybrid algorithms displayed improvements in performance, precision, and recall. The acquired results specified that GFS-logitboost-c has optimum defect prediction capability [20]. In the proposed model herein, the advantages of most previous studies were taken and combined in one model, starting with the metric collection, log transformation, and threshold value, while ending with skews calculation in each step and the use of these functions to identify faulty classes of open source projects.

III.
Methodology Figure-1 demonstrates the Use-Case diagram of the proposed tool to clarify the relationship of the system with the software engineer and the basic operation, as well as how to use it in detecting faulty classes in the software. It was supposed to add a constant value that ranged from 0 to 1 to the threshold equation. The higher value implies a higher accuracy of the results for the faulty classes. Values of 0.5 and 0.4 were selected, which were suitable for the selected software, while it was possible to increase or decrease the value for other types of software depending on the accuracy of the results required. Through experience, it was found that these values give the best results, and accordingly, they were relied upon. When the constant value is close to zero, the number of classes increases, while when it is close to one, the number of classes decreases. Thus, we can be more specific about the classes that need more attention by increasing the constant value.  The statistical results of other metrics are described in Tables-2, 3, 4 and 5 of the case studies. In all tables, the calculated value of the threshold is stated and, depending on it, the number of faulty classes and failure rate are computed. The results for E-learning and system datasets revealed that the fault ratio ranged from 1%-31% and 0%-10% for the original dataset and 1%-10% and 0%-4% after removing redundancy and log transformation. These results impacted directly the number of classes detected, which ranged between 1-20 and 1-7) for the original dataset and 1-7 and 0-3) after removing redundancy and log transformation.
As shown in Tables-3 and 5, the number of faulty classes and failure rate after removing redundancy and log transformation was decreased compared with those before removing redundancy and log transformation. Data in Tables-2 and 4 are in the form that aids a software engineer to focus the attention on specific classes to improve the quality of these classes. The skewness of the dataset was also decreased.

V. Conclusions
In this research, a method for finding the fault rate of software was proposed depending on the object-oriented metrics. The paper concludes that:  The proposed model classifies software classes as faulty or non-faulty based on metric values and the number of faulty classes, while the fault percentage is also determined.  The paper employs two software as case studies. When the proposed model was applied, the accuracy of determining the number of faulty classes and failure rate in the datasets was increased after each operation (removal of redundancy and Log transformation)  Decreasing the indicator of faulty classes and failure rate tends to reduce the effort of understanding the code. It also provides easy maintenance and easy refactoring by focusing on the classes that need more attention. Furthermore, it improves the quality and performance of the source code.

VI. Future Work
A set of improvements can be made, as summarized in the following points:  Applying the proposed model on many datasets of software and comparing the results.  Integrating the proposed model with other object-oriented metrics to predict faults of open source software to achieve more precise and reliable results.  Expending the proposed model by using artificial intelligence algorithms.