Efficacy of Inheritance Aspect in Software Fault Prediction—A Survey Paper

Software fault prediction (SFP) is a research area that helps development and testing process deliver software of good quality. Software metrics are of various types and are used in SFP for measurements. Inheritance is a prominent feature, which measures the depth, breadth, and complexity of object-oriented software. A few studies exclusively addressed the efficacy of inheritance in SFP. This provokes the need to identify the potential ingredients associated with inheritance, which can be helpful in SFP. In this paper, our aim is to collecting, organizing, categorizing, and investigating published fault prediction studies. Findings include identification of 54 inheritance metrics, 78 public datasets with various combinations of 10 inheritance metrics, 60% use of method level & use of private datasets, an increased number of studies using machine learning approaches. This study will facilitate scholars to studying previous literature on software fault prediction having software metrics, with their methods, public data sets, performance evaluation of machine learning algorithms, and findings of experimental results in a comfortable, and efficient way, emphasizing the inherited aspect specifically.


I. INTRODUCTION
Measurement is needed to validate the effectiveness of software development process. The phrase software metrics describes measurements made on an artifact of software whereas a software artifact has two significant elements: the coded implementation, and the document of its design specification. The initially calculated McCabe, Halstead, and Albrecht metrics, presented during the 1970s, were typically constructed on the coded final software products. Examples of software science metrics include [1] function point analysis [2], and cyclomatic complexity metric [3], which predominated in the early 1980s to measure software product.
Worldwide software development expenditure, for year 2014, was 3.8 billion dollars which included 23% quality control and testing cost for business applications [4]. Early fault detection helps save costs, time, and reduce the complexity of the software because it is proportionate to the testing. It is a well known fact that extensive testing are impossible [5]. Testing cost sometimes amounts to over fifty percent of the The associate editor coordinating the review of this manuscript and approving it for publication was Claudio Agostino Ardagna . entire software development cost. It is for these reasons that it is more feasible to detect and test classes with faults to produce software with better quality.
The faults are not uniformly dispersed within the software components. Some classes have a relatively high number of faults as compare to others and are clustered in a limited number of classes [6]. Source code quality is measured through internal metrics whereas the behavior or functionality of the software is measured by external metrics [4]. In general, these two types of metrics are utilized to assess the quality of the software to indicate the degree of reliability of the software. Presently in software engineering, numerous prediction approaches are being used in the research that includes prediction of reuse, prediction of testing effort, prediction of cost, prediction of security, prediction of faults, prediction of quality, and prediction of stress [7]. Out of these, software fault prediction is an emergent research domain where defective classes are identified during the initial phases of development project [8] by utilizing machine learning [9]. Many approaches make use of typical methods of machine learning, which consist of Support Vector Machines (SVM), Naive Bayes (NB) [10], Decision Trees [11], and Neural Networks [12]. In SFP, these techniques are exercised by using metric measurements, and the fault information obtained by similar software projects [13] or previous versions to construct models to predict faults. Suppose, by using metrics to build a model of fault prediction [14] for the calculation of inheritance of software, cohesion, coupling, size, and complexity.
Typically, fault prediction process includes two stages. The first part is called, the training phase, while the part two called the prediction stage. In the first stage of training, the prediction model is constructed that utilizes method level or class level metrics of software with fault information associated with all the components of software programs. Later, the same model is used in the next version of the software for the prediction of fault proneness.
Methods of classification are utilized to put a label on classes as fault-free or faulty by employing metrics set with fault data. The software quality is improved by locating faulty classes in the software with the use of fault prediction models. The model performance influences the model technique [15], along with metrics [16]. Many scholars have built and endorsed machine learning, and statistical techniques on the models of fault prediction utilizing datasets, metrics, and reduction of feature techniques to make improvements in the performance of the models.
In the object-oriented paradigm, besides others, inheritance is an important feature. The metrics of inheritance are useful to recognize the class's complexity based on fault prediction [17]. Abreu, and Carapuca [18] mention, the larger the relation of inheritance, less a class is expected to inherit methods in larger numbers, therefore turn out to become further complex and consequently necessitating extra testing. Inheritance is helpful in the reuse, and many other aspects for example testability, complexity etc. [19]. It should be contained in limits to avoid technical hitches. In the literature, researchers suggested several metrics associated with inheritance to identify the fault tendency and quality software systems.The metric of inheritance defines the tree showing software inheritance, the order of classes with linkage within the master, and its child classes. Furthermore, specialization, and generalization offer code re-usability. It must utilize within a suitable range thus the software system does not turn out to be a complex one [19].
While exploring the SFP domain, it is observed that so much work has already been done on the properties supported by Object-oriented software like cohesion, coupling, etc. These are used either independently or in combination with other metrics. C&K metrics set is an example where these are used in combination and widely accepted by researchers [20]. It is observed that inheritance metrics are used in combine cases widely in C&K suite, however, exclusive usage and evaluation of inheritance metrics are missing. This spurs to conduct a study to focus specifically on inheritance to show the viability of its metrics in the context of SFP.
This paper aims to show up the available resource to draw the effectiveness of inheritance in SFP since it is not exclusively addressed in the research arena. This paper contributes to cataloging about 54 inheritance metrics defined so far in the literature. Object-oriented metrics, datasets, techniques, and performance measures used in software fault prediction. Also, identified 78 publicly available data sets that have inheritance metrics with various combinations. Lastly, discussion, and conclusion to show the effectiveness of inheritance in SFP.
Henceforth, the paper is planned into different Sections where: • Section II explained the theoretical background of an object-oriented paradigm, software inheritance, SFP techniques, performance measures, and datasets.
• Section III depicted literature review where the survey of inheritance metrics, object-oriented metrics, their usage in SFP, datasets with inheritance metrics, algorithms, performance measures, and datasets used so far in the literature are enlisted.
• Section IV elaborates on discussions specifically focusing on the inheritance context.
• Section V discuss about Threat to Validity aspect.
• In the end, in Section VI, the conclusions, and future directions of the survey are provided.

II. THEORETICAL BACKGROUND A. OBJECT ORIENTED PARADIGM
Ole-Johan Dahl and Kristen Nygaard from Norway are the innovators of the object-oriented language with their launch of Simula67 in 1967. The subsequent foremost development was Smalltalk, developed at XEROX by Palo Alto in the 1970s, followed by Eiffel who restored an earlier language to incorporate object-oriented capabilities, such as C++, Object Pascal, and Ada95. Key feature in an object-oriented software is an object, which encloses both data named attributes, and functionality named methods. Besides, message passing, and inheritance functionalities. This is opposite to the traditional structured programming, where data is dealt with separately from the procedures that act on them. Objects are typically formed by an instantiation process, which utilizes a general template called a class. Classes may be master or root class, constructed in conjunction through the group of attributes, and methods. A child class gets features from a master class and may include or exclude functionality as preferred.

B. SOFTWARE INHERITANCE
Software metrics are foundation to quantify complexity, quality of software, and project costs with effort estimation. Function points and cyclomatic complexity are traditional metrics. These are being utilized in the paradigm of procedure language. Nonetheless, these may not merely be utilized in the context of object-oriented [21]. The procedural languages are less complex while comparing with object-oriented programming language [22]. The majority of studies specified hurdles in moving from a procedural approach towards an objectoriented paradigm [23].In object-oriented, it is problematic to VOLUME 8, 2020 comprehend how inheritance, abstraction, and encapsulation associated with each other.
It is vital to distinguish between functionally oriented approach and object-oriented design principles. Consecutively to explain numerous features of object orientation to allow superior administration, and quality management [24]. Pressman purposes five conditions, in which metrics of object-oriented may be established [25].
• Location. It is linked with information tendency as soon as it is centralized.
• Inheritance. Inheritance allows the choice to create a new class. Permitting the methods, and attributes of one or more classes fully or partially.
• Encapsulation. Encapsulation denotes the objects encompass their attributes and data.
• Object abstraction. The method object abstraction authorizes the designer to focus merely on rudimentary with essential aspects of particular program sections.
• Information hiding. Information hiding means to hide the object structures having attributes, and data. In the object-oriented paradigm, inheritance makes it possible for newly created objects to utilize the elements of earlier objects. The source of inheritance is a base class or superclass whereas a derived class or subclass, which inherits through a base class. The term secondary class and main class may also be utilized interchangeably for super class, and sub class. The sub class may possess his elements and methods, but it may also inherit properties and visible methods from the main class. Inheritance acquisition offers [26]: • Reusability. Reuse is a method established through inheritance where super class public methods utilize into sub class without code rewriting.
• Overriding. The secondary class may rewrite the primary class methods so the desired execution of the primary class method is constructed in the secondary class.
• Data hiding. Inheritance offers a data hiding feature. in which super class marks a method as private therefore this method may not be used or modify by child class.
• Extensibility. Expand logic of the main class as per the business logic of the secondary class.
• Overriding. The secondary class may rewrite the primary class methods so the desired execution of the method of a primary class is constructed in the secondary class.
• Maintainability. In the case where the program is splinted into parts. It is comfortable to walk through the code. The foundation of inheritance is an IS-A relationship In the object-oriented paradigm, which explains ''R is a Z type of thing''. Red is a color; the computer is a machine. The inheritance is unidirectional, ''the house is a building'', but ''the building is not a house''. The inheritance has further additional prominent features [26]: • Specialization. Increasing a class functionality is described as specialization [27].
• Generalization. Distribution of commonalities among multiple classes is described as a generalization. There are many forms of inheritance in the literature. These are described in subsequent lines as under [28]: • Single inheritance. A case where a subclass only inherits with one main class is denoted as single inheritance.
• Multiple inheritance. In the case of multiple inheritance, a child class is expending or inheriting from numerous main classes. The issue in this type of inheritance is that child class should handle the dependencies on multiple main classes.
• Hierarchical Inheritance. In the case of hierarchical inheritance a main class is expended by several child classes.
• Multi-level inheritance. Multilevel inheritance indicates a method where a subclass expanding through a derived class, turning a derived class to a parent of the newly created class.
• Hybrid inheritance. Hybrid inheritance is a combination of multiple inheritance and multi-layer inheritance. As in multiple inheritance child classes are expended with two main classes. But these main classes are not base classes rather derived classes. The advantages of inheritance features in the object-oriented paradigm are mentioned as under: • The Inheritance aspect supports reusability. After a class derives or inherits a new class, it may gain access to all the functionality of the inherited class.
• The reusability boosted reliability. Since the code of the supper class has previously tested and debugged.
• Since the present code is being reused so it shows the way to reduce efforts on software development, and subsequently on the cost of maintenance.
• Inheritance causes the subclasses to pursue a single general interface.
• Inheritance aids to decrease code duplication, and promotions extensibility of code.
• Inheritance makes the possible formation of class libraries. Similarly, the drawbacks of inheritance features are explained as under: • Inherited functions act normally sluggish since there is indirection.
• Misuse of inheritance might steer to bad results. • Frequently, data members from the superclass remain not being used, which might result in wasted main memory.
• Inheritance enhances the coupling among the superclass with the child class. So a modification in superclass might affect every subclass.

C. SOFTWARE FAULT PREDICTION
Software fault prediction process typically involves two phases which are denoted as training phase and the second is prediction phase where in the first phase, a model for prediction is constructed, which utilizes method or class level metrics of software with fault information associated with every single module of the software. Later, the same model is used to predict faulty classes in a new version of the software. SFP is effective to enhance the quality of software along with reducing the cost of testing. Also, it assists testing teams to limit testing on faulty classes only. Fault prediction in software possibly lays down yardstick for knowing, which areas may require attention. Many software fault prediction methods have been utilized [29], which contribute to three main elements [30]; Set of features, Label of Class, and finally the Model. The set of features are consisting of single or multiple metrics derived through artifacts of software, it is believed that these are useful to predict labels of class. All of the metrics are grouped into the product, project, and process metrics. It is observed that metrics of the product are mostly utilized in the research arena [31]. The further level of product metrics includes method, class, and file levels where overall 60% method-level metrics are utilized followed by 24% classlevel metrics [15]. Metrics of the product also consist of, volume, design, code, and complexity metrics. The performance of SFP heavily depends on these metrics. Researchers have assessed the utilization rate of metrics in [32] where highly use product metrics in software fault prediction are Halstead [1], McCabe [3], LoC in structural programming, and in object-oriented paradigm C&K metrics suite [33]. The subject metrics are become the approved standard metrics in software fault prediction. PROMISE and D'Ambros [34] are frequently used datasets repositories having these metrics. Both the repositories encompass datasets of about fifty-two percent of the research paper published after 2005 [9]. Since these datasets are publicly available therefore it is frequently used. The other reason is the non-availability of bug's data of industrial software.
The second extremely significant component in SFP is the class label, which contains the real value of the metrics. In SFP, the faulty / fault-free instances are marked as nominalbinary or continuous to mark the number of faults in any occurrence. Although, use of continuous labels exist in the literature [35], but dominating class labels in SFP or nominal class labels [7], [29].
The third important pillar of SFP is model building, which is a connection in-between class label, and feature set. This may be utilized with the assistance of Statistical methods, Machine learning algorithm (ML), or even expert opinion [15] where ML is an excessively used technique for model building [30]. It expressively expands the accuracy of classification [36]. In SFP many algorithms of ML are used. Malhotra et.al compared the performance of these ML algorithms who deduce Random forest, and Bayesian networks are outperformer as compare to other ML algorithms [9].

D. FAULT PREDICTION TECHNIQUES
Fault prediction is topic of numerous researches studies. A number of methods are recommended for the prediction of software faults, which include machine learning, and Statistical methods. Both methods are explained in detail in subsequent lines.

1) STATISTICAL METHODS
Several strategies of statistics are utilized to identify a simple straight mathematical numerical equation, which certainly recognizes in what way classification would be achieved. Kapila et. [37] utilized two approaches of statistic to do his study that includes univariate binary logistic regression (UBR), and logistic regression. Both the approaches are beneficial to investigate data contains binary variables. In the technique of Bayesian inference [37], a model strategy is to correlates metrics with software faults, and faults propensity. The regression analysis method is extensively applied for bad smell prediction, and method linear regression is applied in the case when the dependent variable available merely for dual classes.

2) MACHINE LEARNING
Typically machine learning focus on design and development of algorithms with techniques. That extricate rules, and patterns from massive databases. Neural Networks (NN) are previously being utilized within the software to create reliability growth models for the prediction of total modification or reusability metrics. The NN model is trained to do again a stipulated series of exact instances classification, as an alternative to creating formulas or rules. Mahajan et. al [38] mentioned that machine learning methods are beneficial to determine software faults as complete processing is performed by the computer.
Multilayer Perceptron (MLP) is used to manage classes with faults. Radial Base methods are utilized for the categorization of faults as per dissimilar faults classes [39]. Xing et al. outline the importance of the SVM model which can be utilized for an ample quantity of data. It brings better Accuracy while making comparisons with other techniques to predict software quality. The outcomes of SVM is at a depleted level on public data sets [38].
Vapnik accompanied by his fellow researchers suggested SVM. It has been extensively explored and used in several disciplines. The fundamental concept of this model is to find a similar gap among the two objects/classes by contemplating a distance metric among both of them. The gap among these entities/classes are by practice stated as a function of vectors of its feature [40]. Additionally SVM may be utilized to manage unbalanced classes [41].

2) DECISION TREE
The classifiers of decision trees utilize comparisons to segregate dissimilar occurrences of a group into suitable classes. Classification falls into supervised learning that primarily, a collection of acknowledged occurrences, so-called learning sets, are presented into a model. The model categorizes individual instances of the collection, relates every type with the attributes of each instance, and ascertains to, which group all instances be appropriate. Established upon whatever the trained model understood throughout the phase of learning, you may categorize the instances of a set [42], which were not ever realized earlier.
One of the applications of the use of decision trees refers to form algorithms of pattern recognition [42]. The second type of application is an analysis of images in machine learning that include detection of tumor cells, and brain tumors examples [43].

3) AdaBoost
The AdaBoost algorithm is superior among known algorithms for building a set of the classifier [44]. Each instance of the learning data set is measured. The early measurement is defined in weight (wi) = 1 / n, where wi represents training occurrence, and n is the sum of training occurrence. The furthermost applied algorithms with AdaBoost are singlelevel decision trees. Since decision trees are concise and encompass single classification decisions, so that named decision stumps. A dull classifier called the decision segment is formulated upon the learning of facts utilizing the weighted samples. The algorithm AdaBoost makes a powerful classifier by applying the weights via a recurring method [24].

4) RANDOM FOREST(RF)
Breiman [45] proposed a novel and promising classifier in 2001 named as RF. It offers numerous benefits [32] for instance its execution effectiveness on huge databases to manage thousands of input variables. Then presenting approximations demonstrating which is a significant variable in a classification phase.

5) K NEAREST NEIGHBORS (KNN)
While discussed in the research paper [46], amongst the several approaches for the recognition of supervised statistical patterns, the Nearest Neighbor rule attains a continuous high performance, deprived of a priori suppositions regarding the dispersion through, which training instances are take out. It comprises a collection of positive, and negative case training. A novel occurrence is categorized by gauging the gap with the closest training data. The classifier KNN stretches out this notion by captivating the neighboring spots and giving the majority mark. It is usual to opt for a quantity for the k which must be a lesser number with an odd figure to breakdown draws generally 1, 3, or 5. The greater values of k support in decreasing the impacts of the anomalous elements in the training dataset. The selection of k is usually made by cross-validation [46].

6) ARTIFICIAL NEURAL NETWORKS (ANNs)
ANNs is applied for classification purpose which is not similar to Naive Bayes, and tree-based algorithm. Since none of them need the discretization of the dataset. These may even manage a solo feature that appears in the dataset. ANNs is an utmost operative technique, utilized for a classification task that is done on metrics of object-oriented [47]. The stateof-the-art tendency in SFP is the explicit usage of ANNs [5], [48]. Moreover, the choice of method to model is appointed though considering the numerical details of the training set. It is a dataset that guides towards ANNs, and the response we deduce outcomes.

F. PERFORMANCE MEASUREMENT
Evaluating machine learning models require performance measures, which are explained as follows:

1) ACCURACY
Accuracy (equation 1) gauges the fraction of the files categorized correctly, to the total of files. Accuracy, however, excludes a thorough evaluation for example the number of correct labels of various classes, and in this sense investigators, to assess the model, utilize the F1 Score along with recall and precision that is explained in the following lines.

2) PRECISION
Precision (equation 2) gauges the fraction of files that were classified correctly as faulty over the totality of files categorized as either faulty or faulty-free. Simply, Confidence or Precision as it is called in data mining expresses the ratio of predicted occurrences these are indeed actually defective files. This measures how decent a prediction model is at detecting real defective files.

3) RECALL
Recall explained in equation 3 computes the fraction of faulty instances, which are accurately labeled faulty by the sum of faulty instances existed. Sensitivity or Recall (as it is termed in Psychology) is the fraction of actual faulty instances which are properly predicted as faulty.

4) F1 SCORE
The F1 Score is calculated by getting the (weighted) harmonic average of recall, and precision as demonstrated in the equation (equation 4).

5) SPECIFICITY (TRUE NEGATIVE RATE (TNR)
TNR is the quantity of accurately predicted classes likely to be fault-free among entirely real classes likely to be fault-free.

6) PF (FALSE POSITIVE RATE (FPR)
FPR is the fraction of all classes likely to be fault-free. These are erroneously predicted as faulty.

7) FNR (FALSE NEGATIVE RATE)
FNR is the proportion of faulty classes, which are categorized as non-fault prone.

8) ROC (RECEIVER OPERATING CHARACTERISTIC CURVE), AND AUC (AREA UNDER THE CURVE)
ROC, and AUC is mapped out with the values of recall on the y-axis, and the values of 1-specificity on the x-axis. The usefulness of the model is determined by quantifying the area underneath the ROC curve.

9) BALANCE
It denotes the best possible cutoff point of (sensitivity, pf) for example the normalized Euclidean distance as from (0,1) position in the ROC curve.

10) COMPLETENESS
It is the summation of all faults categorized as faulty classes above the sum of authentic faults within a system.

11) F-MEASURE
F-measure is the harmonic mean of precision and sensitivity.

12) CONFUSION MATRIX
Equation 5 represents a simple cross-tabulation of class tags mapped to those perceived in the field or reference data for a sample of cases in certain locations. The matrix provides a visual foundation for the evaluation of accuracy (Campbell, 1996; Canters, 1997), as well as for the description of classification accuracy, and characterization errors, that may help to improve the classification or derivative approximations through it [49].
Numerous data sets have been utilized in software fault prediction. These may be grouped into private, public, partial, and unknown dataset categories [15]. The public data sets usage has risen from 31% to 52% since 2005 onward [9]. Fault information usually not accessible for private projects but there are datasets openly available with fault information, these may be downloaded for free. There are several bug libraries, from this Tera-PROMISE, repositories, and D'Ambros repositories that are often used for predicting faults [34]. A publicly accessible repository called Tera-PROMISE offers a large data set for multiple projects. An earlier version of this repository has named as NASA repository [50]. The datasets of NASA are an important source of the Tera-PROMISE repository since its datasets are an extensively utilized library of software fault prediction. About 60% of the papers published from 1991 to2013 make use of this library [51]. The repository of PROMISE offers metrics associated with the process, and product with digital nominal class labels for building classification, and regression models.
The repository of D'Ambros holds data sets of five opensource software applications, these are: Equinox, Eclipse JDT Core, Lucene, Eclipse PDE UI, Mylyn, and Framework.

III. LITERATURE REVIEW
Fault prediction of software is a vital field of study and the topic of several earlier types of research. These researches generally give off fault prediction models that permit software engineers to concentrate on development activities on source code failures, increasing software quality, and boosting resource utilization. In this section, the focus is on the object-oriented paradigm, specifically on the inheritance aspect, which helps predict faults. There is no systematic review of the literature in this study, but to investigate in what way distinct inheritance features are beneficial in software fault prediction.

A. INHERITANCE METRICS
Inheritance is one of the utmost strong facets of an objectoriented paradigm. Programming deprived of inheritance is not object-oriented programming rather termed as programming with an abstract data type. During the last decade or so, numerous metrics of object-oriented have been suggested by researchers, and in fact, only a few of them are being utilized by many establishments as a measurement to accomplish quality [52]. The metrics of inheritance are constructed on: • Deepness of the inheritance tree.
• Over-all quantities of classes inherited in a program. • Classes quantities indirectly or directly inherited by a class.
• Classes quantities indirectly or directly inheriting from a class.
• Methods quantities inherited by a class. • Methods quantities overridden by a class etc. The complexity of inheritance depends not solely upon the number of inherited classes, but additionally upon the number of inherited methods, together with their complexity, as endorsed by Abreu and Carapuca, [18]. The higher the inheritance relationship, the more complex the class, and the more it requires testing because the number of methods the class may inherit increases. Methods with complex decision-making structures are difficult to test, maintain, and VOLUME 8, 2020 are prone to errors [18]. They allow complexity metrics based upon the previously mentioned criteria to identify possibly large methods or classes, assist with the preparation of review, and testing jobs, which is a key part of the suggested software quality process that mentions [53]. There is no complete object-oriented inheritance metric that addresses all of these issues. The main motivation for this paper is to collect and organize the inheritance metrics defined so far by researchers in the field of SFP.

1) DEPTH OF INHERITANCE TREE (DIT) [33]
The depth of inheritance metrics is to determine how much ancestor classes might influence the metrics of this class. In the situation of multiple inheritances, DIT will be the greatest length from the root tree to the node. DIT = Max inheritance path from the class to the root (6) • The deepest class in the hierarchy will inherit a large number of methods, so predicting their behavior will be difficult.
• Into the design of software, at the bottom of the trees, will create more complexity since several classes, and methods have been used.
• At the bottom of a specific class within the hierarchy, it is possible the larger the reuse of methods which are inherited. Visual Studio .NET suggested that DIT ≤ 5, and some sources recommend up to 8. Extremely deep class hierarchies are very difficult to build. It is noted that a rise in DIT will increase the degree of errors, and eventually decrease the software quality.
2) NUMBER OF CHILDREN (NOC) [33] • Growing the NOC will rise in the reuse of methods since inherited methods are a mode of reusability.
• The larger the subclass, the larger the probability of inadequate abstraction of the parent class. In the case where class contains a large number of subclasses, that might be a situation of misappropriation of the child class.
• The quantity of subclasses provides the objectives of the possible effect of the class has on design. In the case where a class has a huge number of subclasses, it may require more method testing in the class.

NOC = number of immediate sub−classes of a class (7)
High NOCs show fewer faults since this might be due to excessive reuse that is suitable.
The breadth of a class hierarchy is measured by NOC since the depth is measured by the highest DIT since the depth is usually better as compared to the breadth.

3) ATTRIBUTE INHERITANCE FACTOR (AIF) [54]
Attribute Inheritance Factor is the proportion of the total of inherited attributes of all classes in the system to the sum of accessible attributes of all classes. It is a system-level metric that calculates the scope of attribute inheritance in the system. Mathematically AIF is calculated as follows:

4) METHOD INHERITANCE FACTOR (MIF) [54]
Method Inheritance Factor is the fraction of the total inheritance methods of all classes of the system to the sum of available methods of all classes. MIF is a system-level metric.
It is recommended to keep the MIF between 0.25, and 0.37. Mathematically MIF is calculated as follows: Subclasses that inherit more than one method or attribute from their parent class contribute to a higher MIF or AIF. Redefining methods or properties of its parent class, and adding subclasses of new classes may help reduce MIF (AIF). An independent class with no inheritance and no children helps to reduce the MIF (AIF).
The acceptable range of MIF is from twenty percent to eighty percent, and the suitable limit of AIF is from zero percent to forty-eight percent [55]. An alternative opinion about the AIF is that it must idyllically be a zero since every variable would be defined as private.

5) NUMBER OF METHODS INHERITED (NMI)
The metric NMI calculates the quantity of inherited methods by a child class. 6) NUMBER OF METHODS OVERRIDDEN (NMO) [56], [57] A larger quantity of methods overridden points out a issue in design, signaling these methods overridden as a last-minute design. Since it is recommended, a child class must be a specialization of all its superclasses, which resultantly create a new exclusive name for the methods. 7) NUMBER OF NEW METHODS (NNA) [56], [57] The typical expectancy of a child class is how to specialize (or add) superclass objects. If there is no method of the same name in a superclass, the said method is described as an appended method in the child class.

8) INHERITANCE COUPLING (IC) [58]
The IC metric is a connection between classes which allows the usage of formerly defined objects, comprising variables, and methods. Inheritance reduces the complexity of a class by decreasing the number of elements of a single class, however, due to this maintenance, and design became tough. Inheritance improves effectiveness, and reuse while using present objects. Concurrently, inheritance has led to complexities in software testing and understanding. This implies that inheritance coupling affects many quality attributes such as complexity, efficiency, reusability, testability, understandability, and maintainability.
The metric NIM is a fair metric that describes the quantity of behavior a class is supposed to reuse. It calculates the sum of methods a class may retrieve from his parent class. The higher the quantity of inherited methods, the superior the class reusability by the subclasses. Evaluating this metric with the number of parent classes sent, and the way it is sent to undefined methods in the class may be interesting because it indicates the number of internal reuses between the calling class, and its parent class. It may be an incoming call to an incoming method, although it is difficult to statistically evaluate it. Besides, inheriting large superclasses may be problematic because merely a subset of the methods may be required/desired within the subclasses. So it is a threshold of single inheritance basing on the object-oriented programming language.

10) FANIN AND FANOUT METRIC [59]
The Fanin/Fanout metrics first defined by Henry and Kafura [59], that is ''module-level'' metrics. Subsequently, these are expanded for the object-oriented paradigm. For each class A we record its fan-in as the count of classes, which use features of class A. Similarly, the fan-out for class A is the count of classes used by A.
Sheetz, Tegarden, and Monarchi derive a set of primitive counts. The complexity between modules called Structural complexity has been recognized as a significant part of structured system complexity. Several researchers have used module-defined fan-in and fan-out [60]. Expanding these thoughts to variables in object-oriented systems looks suitable, and up-front. The number of methods that use variables (fan input variable) is quite identical to the number of modules that call the module (input input), and the number of objects accessed by the variable (variable output input), and the digital module called by the module (fan).

11) FAN-DOWN
The metric Fan-Down is the quantity of classes under the hierarchy of classes (subclasses).

12) FAN-UP
The metric Fan-Up is the quantity of classes over in the hierarchy (superclass).

13) OBJECT-To-ROOT DEPTH
The metric Object to Root Depth is the largest number of stages within the hierarchy which is directly over the class object.

14) OBJECT-TO-LEAF DEPTH
The metric Object to Leaf Depth is the highest number of steps in the hierarchy of object which is under the class object.

15) MEASURE OF FUNCTIONAL ABSTRACTION (MFA)
The MFA metrics are the share between the number of methods inherited by a class to the sum of methods of the class. Its limits are between zero to one.

16) IFANIN
The metric IFANIN calculate the sum of immediate base classes of the hierarchy.

17) NUMBER OF ANCESTOR CLASSES (NAC) [61]
Number of Ancestor Classes (NAC) metric quantifies the over-all quantity of child classes, which a child class inherits in the class inheritance hierarchy. NAC is of the same type as {dit}, since it calculates the number of ancestors of a class. Li [62] validated the piece of evidence that the unit of the NAC metric is ''class'' as the trait obtained by the NAC metric is the number of other classes.

18) NUMBER OF DESCENDENT CLASSES (NDC) [61]
Number Descending Classes (NDC) metric specifies the overall quantity of child classes of the class. It is a substitute for NOC. The metric NOC calculates the extent of a class's influence on its inheritance subclass. Li [62] argued that NDC metrics obtain class attributes superior than {noc}.

19) CLASS-TO-LEAF DEPTH(CLD)
Tegarden et al. proposed the metric CLD, which is the highest quantity of stages in the hierarchy that are underneath the class [63].

20) NUMBER OF ANCESTOR(NOA)
Tegarden et al. proposed the NOA metric, which is the number of classes that a specified class directly or indirectly inherits from [63].

21) NUMBER OF PARENTS(NOP)
Lake and Cook suggested the metric, which is the number of classes that a particular class inherits directly [64].

22) NUMBER OF DESCENDANTS(NOD)
Lake and Cook [64] suggested the metric NOD, which is the number of classes that directly or indirectly inherit from a class.

23) DEPTH OF INHERITANCE TREE OF A Class (DITC)
Rajnish et al. [65], [66] introduced the metric. The DITC class inheritance hierarchy is calculated by totaling the protected, private, public inherited attributes, and the protected, private, public, and legacy methods at every stage [66]. The DITC metric of a class at the respective stage is measured as follows: where, LEVi = Method (Ca) +Attribute (Ca) VOLUME 8, 2020 Ca = A class in the ith level of the class inheritance hierarchy. Attribute (Ca) = Calculate the sum of private, protected, public, and inherited attributes inside a class in the class inheritance hierarchy at each stage.
Method (Ca) = Calculate the sum of private, protected, public, and inherited methods contained by a class in the class inheritance hierarchy at each stage. L = Total tallness in the class inheritance hierarchy. The most extreme distance from the last node for example top level in the class inheritance hierarchy, ignoring any shorter ways if there should be an occurrence of multiple inheritance is being utilized.

24) CLASS INHERITANCE TREE (CIT) METRIC
Rajnish et al. [65], [66] proposed the (CIT) metric, which is used to calculate the class inheritance tree [66]. The key objective of (CIT) is to calculate how the class is inherited by various classes, and in what way class inherits numerous classes at any level in the inheritance tree. CIT is expressed as under: where Ci represent a class at the i th stage in the inheritance tree. The value of CIN (Ci) = 1 in case Ci is inherits various classes in the inheritance tree, 0 in other case. The value of COUT (Ci) = 1 in case Ci is inherited by various classes in the inheritance tree, 0 in other case.

25) INHERITANCE COMPLEXITY OF CLASS(ICC) [67]
Sandip et al. [56], [68] presented metric for evaluation. The ICC metric is explained in [68], and is explained in equation 12 in the following lines: where ICC represents the quantity of a class of an inheritance tree. Ci = Represents the classes at the i th stage in an inheritance tree. A (Ci), calculate the quantity of private, protected, and public inherited attributes at every stage in an inheritance tree. M (Ci) = calculate the quantity of private, protected, and public inherited methods at every stage in an inheritance tree.

26) INHERITANCE COMPLEXITY OF TREE (ICT)
The ICT metric is described in [67] study, and is measured as per equation 13: N = Sum of classes in an inheritance tree.

27) NUMBER OF METHODS (NOM)
Quantity of Methods declared in a class.

28) NUMBER OF ATTRIBUTES (NOA)
Quantity of Attributes declare in a class.

31) NUMBER OF INHERITED ATTRIBUTE(NIA)
Quantity of inherited attribute in a class.

33) NUMBER OF OVERRIDDEN METHODS(NoVM)
Quantity of overridden methods in a class.

34) INHERITANCE TREE DEPTH (ITD)
Classes are designed for inheritance purposes, hierarchically in a tree structure. The depth of a class within the inheritance hierarchy is the highest distance from the class node to the root of the tree, and is computed through the quantity of ancestor classes.

ITD = max{Inheritance Tree Path Length}
The deep a class is in the inheritance hierarchy, the additional protected, and public methods it is probably attaining, making it extra complicated. Deeper trees specify more complexity of the design. Thus, deeper class inheritance is neither needed nor required. The tests are more problematic, and the world doesn't normally hold considerably specializations. Deeper hierarchies are also a theoretical integrity apprehension since it turns out to be hard to ascertain specialization from, which class. This metric principally appraises reusability. Besides also associate with understandability, and testing ability [69].

35) AVERAGE DEGREE OF UNDERSTANDABILITY (AU)
Metric of F. T. Sheldon et al defines understandability, the ease of understanding a structure of the program, or the structure of class inheritance [70]. To compute AU, firstly expressing the level of class understandability, which is referred to by U, and explained in equation 17.

U of class Ci
In the above equation C i is i th class. PRED(C i ) is the overall number of ancestors of i th class.
Next, the Total Degree of Understandability (TU) of a class inheritance tree is expressed as under:

TU of a class Inheritnce
In the above equation t is the sum of the classes in the class inheritance tree. Finally, the Average Degree of Understandability (AU) of a class inheritance tree is described as under:

M of a class Ci
In the above equation C i is i th class. SUCC(C i ): the overall quantity of descendants of class i. Next, the total degree of modifiability (TM) of a class inheritance tree is defined as follows:

TM of a class Inheritnce
where t is sum of classes in the class inheritance hierarchy tree. Finally, the Average Degree of Modifiability (AM) of a class inheritance tree is calculated as per equation mentioned as under:

37) AVERAGE INHERITANCE DEPTH (AID)
Henderson-Seller stated that the AID metric of a class is computed by a following equation:

38) DERIVE BASE RATIO METRIC (DBRM)
DBRM is the share of the sum of derived classes to the sum of root classes in the class inheritance tree. DBRM is described as underneath: In the above equation N i=1 TD(C i) : Sum of derived classes in the class inheritance tree.

39) AVERAGE NUMBER OF DIRECT CHILD (ANDC) METRIC
The ANDC metric is the percentage of the overall quantity of instant child with the overall quantity of classes in the inheritance tree. The calculation of the ANDC metric is explained as under: where N i=1 TDC(C i) : Sum of instant child in the class inheritance tree.
N: Sum of classes in the class inheritance tree.

40) AVERAGE NUMBER OF INDIRECT CHILD (ANIC) METRIC
The ANIC metric is the ratio of sum of indirect child to the sum of classes in the inheritance tree. ANIC metric is described as follows: Sum of indirect child in the class inheritance tree.
N: Sum of classes in the class inheritance tree.

41) CLASS COMPLEXITY DUE TO INHERITANCE (CCI)
The idea of Class Complexity due to Inheritance (CCI) metrics is to forecast the superiority of a class in terms of reusability, understandability, maintainability, and testability. Class Complexity due to Inheritance (CCI) may be measured as mentioned in equation 27.
In the above equation CCI i is the complexity of an ith class due to inheritance. k is the number of classes, and ith class is directly inheriting class. CCI inherit the complexity of an inherited class. l is the number of methods excluding constructors, destructors, pure virtual function, the ith class has. MCj is the complexity of the jth method in the ith class, and it may be computed by utilizing a recently suggested method complexity metric (MC). The classes with greater CCI quantities are complex. Thus considered further prone to errors.

42) METHOD COMPLEXITY (MC)
Method Complexity is constructed on McCabe's cyclomatic complexity [3]. Besides it also takes into consideration, control structure's depth. MC metrics are described as under: In the aforementioned equation MC j is the complexity of j th method, P j is the number of predicates j th method has D j is the highest depth of control structures in j th method; the value of D j = 0 in the case where not nested control structures exist; if there is one inside another then D j = 1, and so on . . . VOLUME 8, 2020

43) AVERAGE COMPLEXITY OF A PROGRAM DUE TO INHERITANCE (ACI)
The use of the average complexity of a program due to inheritance metrics (ACI) is to forecast the quality of design of the program having multi-classes. ACI metrics described as under: where: CCI i is the complexity of an ith class due to inheritance, n is the sum of the classes in the program.

44) NUMBER OF METHODS EXTENDED (NME)
Abreu & Carapuca defined NME metrics. The number of methods extended (NME) i.e. redefined in child class by invoking a method with a similar name on a parent class.

45) TOTAL CHILDREN COUNT (TCC)
Abreu & Carapuca defined quantity of classes that inherit directly from a class is the TCC of that class.

46) TOTAL PROGENY COUNT (TPC)
Abreu & Carapuca defined quantity of classes that inherit directly or indirectly from a class is the TPC of that class.

47) TOTAL PARENT COUNT (TPAC)
Abreu & Carapuca defined The number of super classes from, which a class inherits directly is the TPAC of that class.

48) TOTAL ASCENDANCY COUNT (TAC)
Abreu & Carapuca defined the number of super classes from, which a class inherits directly or indirectly is the TAC of that class.

49) TOTAL LENGTH OF INHERITANCE CHAIN (TLI)
Abreu & Carapuca defined the sum of edges in the inheritance hierarchy graph.

50) CLASS COMPLEXITIES
There are two types of class complexities: Member Complexity (MC) and Relational Complexity (RC). A class consists of data members, methods, and relationships with other classes. Complexity due to data members, and methods are called member complexity, and complexity of class due to relationships is called relational complexity. Therefore, complexity (C) of a class may be denoted as The complexity (MC) due to the member function of the class depends upon the logic of the method whereas relational complexity (RC) of the class depends upon coupling and inheritance. Higher complexity causes higher fault proneness.

51) DEGREE OF INHERITANCE OF A CLASS (DIC)
DIC is constituted for two foremost characteristics of inheritance: with the growth in the level of inheritance, reuse rises to three levels of depth, but further, than three-level, the capability for reuse has a tendency to drop as it represents a deprived subclassification. Therefore, for each level of depth, if it increases further than three, there is a penalization factor that rises (DIC increases) and affects a reduction in reuse. The quantity of inherited methods or attributes plays a significant role in class inheritance and offers a clearer image of the inheritance factor. Inheritance of a class (DIC) is quantified in terms of methods and attributes such as: In the above equation, the level is the highest distance from the class to the root in an inheritance hierarchy, disregarding any concise route in the situation of multiple inheritance. Quantity of inherited attributes is a summation of attributes public, and protected methods within a class that are inherited from their instant superclass. The degree of inheritance of a class (DIC) is one of the main constructions to improve reuse and, thus, the software design quality.

52) EXTENDED DERIVED BASE RATIO METRICS (EDBRM)
This EDBRM make available the average quantity of the percentage of derived, and root shared attributes from each class in the class inheritance tree as described in the following equation:

53) EXTENDED AVERAGE NUMBER OF DIRECT CHILD METRICS
The Extended Average Number of Direct Child Metrics acronym as EANDC, calculates the averages of shared methods and attributes to its direct sub classes. When the number of shared properties, and directly connect sub classes are higher, the more shared each class, and it needs additional testing to be performed to guarantee that it does not disrupt the sub classes after modification are incorporated. The equation mentioned below is used to calculate EANDC:

54) EXTENDED AVERAGE NUMBER OF INDIRECT CHILD
The metrics EANIC calculates the averages of the number of shared methods and attributes to its indirect sub classes. The Class, which is at the deepest in inheritance tree has a greater EANIC number as compare to the one in inheritance tree with a lower depth. The depth quantity of a class inheritance tree must be more than three to calculate these metrics. The classes, which have depth quantity fewer than three may not have any indirect classes, hence these have zero value of EANIC. The EANDC may be calculated through the equation mentioned below.

B. INHERITANCE METRICS AND THEIR USAGE
Inheritance aspect is a vital attribute in the object-oriented paradigm. It facilitates design at class level, and forms 'IS-A' relations among classes. The design of the class is a basic component of system development [71]. The utilization of the inheritance aspect, shrinkages the cost of testing efforts along with maintenance of system [33]. The reuse with inheritance will consequently provide software, which is more maintainable, understandable, and reliable [72]. An experimental study of Harrison et al. depicts inheritance absence is simpler to grasp or control than software systems having inheritance aspect [72]. But, experiments of Daley shows software systems with tertiary inheritance may be easily updated compared to systems without inheritance [73]. The metrics of Inheritance compute several facets of inheritance, for example, the breadth, and depth of the hierarchy, in addition to the complexity of overriding [74]. Likewise, Bhattacherjee and Rajnish performed an investigation inheritance metrics addressing classes [62]. Yet, it is established that the greater the hierarchy of inheritance, the reusability of a class will be better but maintainability of the system under test (SUT) will be difficult. To simplify the understanding, designers trying to maintain inheritance hierarchy shallow, and discard reusability by the use of inheritance [33]. Therefore, it's essential to evaluate the complexity of the inheritance hierarchy to solve the difference between shallowness, and depth.
Many metrics addressing inheritance are defined by the researchers. In this regard, Table 1 showing these metrics with references. In this paper specifically, we get these inheritance metrics from the perspective of SFP.

C. INHERITANCE IN SFP
The metrics of object-oriented are utilized for prediction of software quality. The characteristics that ascertain the software quality are understandability, fault tolerance, maintainability, defect density, reusability, normalized rework rate, and many others. Numerous studies have been performed including object-oriented metrics verification through empirical research paper on open-source software in the context of fault prediction utilizing {loc}, {lcom}, {cbo}, {dit}, and {noc} metrics [80]. Reusability investigation on systems based on object-oriented utilizing metrics of coupling, inheritance, and cohesion [81], heuristic-based C&K metrics evaluation [82], reusability metrics for the design of objectoriented [83], empirical scrutiny of C&K metrics for the complexity of object-oriented design [84].
The metrics suite of C&K developed, and implemented by Chidamber et al. is the utmost often use metrics collection for object-oriented software [33]. Basili et al. [85] studied the set of design metrics of object-oriented proposed by Chidamber et al. [86]. R. Subramanyam endorsed that {dit}, {cbo}, and {wmc} metrics are class level fault predictor [84].
Empirical assessments of the classification algorithm have been constructed to predict faults through studies [87]. Basili et al. numerous C&K metrics are found to be related to failure propensity [86]. Tang et al. evaluated metrics suite of C&K, and discovered that not any of these metrics except {rfc}, and {wmc} were considered important [88]. Briand et al. takeout forty-nine metrics to determine, which model to use for fault prediction. Findings reveals except {noc} all metrics are helpful to predict failure propensity [85]. Wust and Briand discovered that {dit} metrics are inversely correlated to fault proneness, and {noc} measure is a trivial predictor of failure propensity [89]. Yu et al. VOLUME 8, 2020 selected 8 metrics, and they studied the association among them with the propensity to failure. Initial, they investigated the correlation amongst the metrics where they discovered four extremely related groups. Then they use univariate analysis to notice, which indicators may identify failures [90]. Malhotra and Jain used logistic regression methods to study the association among the object-oriented metrics with faults tendency. The receiver operating characteristics (ROC) investigation was utilized, and the accomplishment of the predictive model was assessed using ROC [90]. Yeresime et al. explored the methods including linear regression, logistic regression, and ANN to predict software failure using C&K metrics. They concluded the importance of {wmc} metric for classification of fault [91].
The review of the literature reveals that the {noc}, and {dit} metrics, correlated to inheritance features are used in fault prediction together within C&K metrics only. Consequently, it is deemed vital to authenticate the worth of inheritance metrics from the perspective of SFP.

D. METRICS UTILIZATION IN SFP
A sizeable quantity of object-oriented metrics has been formed previously, which includes Li and Henry (1993), Abreu and Carapuca (1994) [35].
Metrics have different levels including class, method, file, process, component, and quantitative levels. The metrics at method-level are extensively utilized for the problem of fault prediction. McCabe (1976) and Halstead (1977) metrics recommended in the 1970s however these are even now the furthermost prevalent method-level metrics. The metrics at class-level are only used in objectoriented programs where the metrics suite of C&K (Chidamber & Kemerer, 1994) is even now the utmost prevalent class-level metrics suite being utilized for prediction of faults.
Few scholars including Khoshgoftaar, Gao, & Szabo, 2001;Ostrand, Weyuker, & Bell, 2005 utilized metrics gathered per source file, which is termed file-level metrics [27]. Table 2 summarized the frequently used metrics set at method, class, and file-level for SFP. The overall distribution of metrics for SFP is shown in Figure 1.

E. DATASET
The information regarding the faults of software projects is honestly rarely reachable. The issue is that information on faults for the enterprise's business projects are accumulated digitally as these are propriety to the organization. On the other hand, in the smaller projects fault information is  not adequate. Consequently, data with labels seldom exist. The accessibility of public datasets will grant the assessment of the inheritance metrics in software fault prediction. Many datasets having inheritance metrics are found [92]. Some of them are situated in the repository of Tera-PROMISE, and five datasets on the repository of D'Ambros [34].
The It is found that about 63 public datasets having four inheritance metrics namely Depth of the Inheritance Tree  These are available at the repositories of D'Ambros, and Tera-PROMISE [93]. The Table 3 shows the public dataset name in 1st column, the total number of instances in the second column, the percentage of faults in the third column, and the availability of metrics are mentioned with mark.

2) THREE INHERITANCE METRICS [dit, noc, ic]
It is found that about 2 public datasets having three inheritance metrics namely Depth of the Inheritance Tree {dit}, the Number of Children {noc}, and Inheritance Coupling {ic}. These are available at the repositories of D'Ambros, and Tera-PROMISE. Table 4 illustrations the explanation of these datasets where the name of the dataset in the first column of the table, in second contains the number of instances, and the fault percentage in the third column. The remaining columns marked to show the availability of the metric data in the associated dataset. These are available at the Tera-PROMISE repository. Table 6 illustrations the explanation of these datasets where the name of the dataset in the first column of the table, in second contains the number of instances, and the fault percentage in the third column. The remaining columns marked to show the availability of the metric data in the associated dataset. These are available at the tera-PROMISE repository. These are available at the repositories of D'Ambros, and Tera-PROMISE. Table 7 illustrations the explanation of these datasets where the name of the dataset in the first column of the table, in second contains the number of instances, and the fault percentage in the third column. The remaining columns marked to show the availability of the metric data in the associated dataset. VOLUME 8, 2020   Table 8 illustrations the explanation of these datasets where the name of the dataset in the first column of the table, in second contains the number of instances, and the fault percentage in the third column. The remaining columns marked to show the availability of the metric data in the associated dataset.
In the literature review, it is perceived that researchers utilize public, and private datasets for the validation of their research works. In this regard, Table 9 shows the author's name, year of publication, and public/private datasets used in studies.
The utmost significant difficulties for software fault prediction experiments are the use of non-public (private) datasets. Numerous companies developed fault prediction models utilizing patented data and displayed these models in conferences. Nevertheless, it is not probable to match the outcomes of such studies with outcomes of our own models since their datasets may not be grasped [7]. The distribution of datasets is shown in Figure 2. Table 10 showed the fault distribution in the publicly available data sets. The dataset is grouped according to the percentage of fault they contain. The first column shows the range of percentage of fault, the second column number of public datasets fall in this group, and the third column shows the name of datasets with usage in studies.

F. ALGORITHMS AND PERFORMANCE MEASURES
Statistical methods are reflected as black-box solutions since these are extremely dependent on data, it is encouraging to perceive that more researchers are discovering the capability of machine learning methods to predict fault-prone modules.  The literature review revealed that 59% used machine learning, and 22% used statistical methods [21]. Different machine learning methods and performance measures are examined which use object-oriented metrics for fault prediction. These are grouped into tables where studies from 1990-2003 are depicted in Table 11, studies in between 2004-2007 in Table 12 and studies between 2008-2020 mentioned in Table 13 [7], [94]- [104].

IV. DISCUSSION
In this section, findings of the literature review mentioned in Section III will be discussed, and highlight the potential resources available to make use of inheritance aspects in SFP arena.
It is also important to mentioned here that many solutions have been developed to solve the class imbalance problem such as sampling, cost-sensitive, and ensemble methods [4], [105]. However, these solutions are not equally effective as most empirical studies do not take into consideration the impact of class imbalance on prediction models and which, imbalance method works well or help to learn capabilities in software defect prediction. Selecting models, which are stable and efficient with class imbalance will give a better result.

A. METRICS
Many object-oriented metrics are used in experiments where the C&K metrics suite is a widely used set of metrics in SFP [106].
The literature review reveals that about 54 inheritance metrics are defined in the literature by the researcher to address the inheritance aspect. Out of these only two inheritance metrics are used in SFP namely {dit}, and {noc}. The reason for their extensive use is that these metrics are the part of C&K metrics suite, which is widely utilized in research experiments by the researchers. There are fever studies, which address the inheritance aspect exclusively. The literature review also indicated that the use of methodlevel metrics is superior to then class level, which is 60, and 24 percent respectively.

B. DATASETS
The literature review reveals that experimental studies used public, and private datasets where the ratio to use private datasets is higher than public datasets, which is 60 to 31 percent respectively. The bug data are available at PROMISE, D'Admros, and NASA repositories.
The literature review indicate a total of 78 public datasets containing 10  Unluckily, all ten inheritance metrics have not discovered within a single dataset. But, the various combination of inheritance metrics is found in public datasets.
• A group of four inheritance Metrics {dit, noc, ic, {mfa} found in 63 public datasets available at PROMISE, and D'Adam repositories. VOLUME 8, 2020 • A group of three Inheritance Metrics {dit,noc,ic} found in 2 public datasets available at PROMISE, and D'Adam repositories.
• A group of five Inheritance Metrics {dit, noc, ic, doc,fanIn} found in 5 public datasets available at PROMISE, and D'Adam repositories.
• A group of five Inheritance Metrics {dit, noc, noai, nomi, ifanin}found in one public dataset available at PROMISE, and D'Adam repositories.
• A group of four Inheritance Metrics {dit, noc, noai, nomi} found in one public dataset available at PROMISE, and D'Adam repositories.
• A group of six Inheritance Metrics {dit, noc, noai, nomi, fanIn, fanOut} found in six public datasets available at PROMISE, and D'Adam repositories.

C. ALGORITHMS
The literature review reveals that experimental studies used statistical, and machine learning models for their experiments. Machine learning models have widely used a comparison to statistical methods in the context of SFP. Recent studies show the use of Support Vector Machine, Naive Bayes, Decision Tree, and ANN models for fault prediction.

D. PERFORMANCE MEASURES
The literature review reveals that experimental studies use many performance measures to validate the results of machine learning models. Frequently used performance measures include Accuracy, Precision, Recall, F1-Score, AUC, and ROC [107].

V. THREAT TO VALIDITY
Many inheritance metrics are described in the literature, however it is possible that other metrics might be a better indicator of faults. Since we only concentrate on inheritance metrics that were published in the various researches and these are accessible in the certain datasets. The survey results shown are basing on the inheritance metrics only. These datasets might not be characteristic of all business sectors. These datasets might not be excellent representatives in terms of class numbers and sizes.
The main threat to the validity of this survey is related to bias in selecting papers to inclusion and exclusion criteria.
There might be a slight risk that some important papers might have been missed in the search process. All the selected papers were extracted and quality assessed by the author which is reassessed twice a time specifically focusing inheritance aspect.
While performing a survey, it is essential to be mindful of possible threats to the validity of the acquired outcomes and drawn conclusions. A first potential cause of bias associates with the data being utilized, whether the data is representative of the domain in question and can result be generalized. Since the data utilized in this survey branches from the public domain, so our findings can be matched with others and can be subjected to reproduction if required. Also, numerous authors have debated in support of the suitability of the PROMISE data repository and eclipse datasets and/or applied some of its data sets for their experimentations. Thus, we believe the acquired findings to be suitable for the SFP community.

VI. CONCLUSION AND FUTURE WORK
In this paper, a literature review is conducted to see the efficacy of inheritance metrics on SFP is validated. The review is conducted by collecting, organizing, categorizing, and investigate published fault prediction studies. The outcomes of the study show 54 inheritance metrics defined so far by the researchers. Only two inheritance metrics are being used in SFP. Besides, 78 public datasets identified, which contain ten inheritance metrics with various combinations. The usage of method-level metrics is 60%, and a similar number is for the use of private datasets. The use of machine learning approaches is increasing, which uses many performance measures.
This study will assist scholars to examine the earlier studies from metrics, methods, datasets, performance evaluation metrics, and experimental outcomes viewpoints in an easy, and efficient way exclusive attention on the Inheritance aspect.
In the context of future work, we anticipate some scholars would make use of the inheritance aspect mentioned in this paper, and attempt to assess other inheritance metrics than the ones we utilized. Besides, utilizing regression using machine learning techniques for faults predict with inheritance metrics will be significant work to be done.