Improving Applicability of Object-Oriented Class ...

The Impact of Inheritance on the Internal Quality Attributes of Java Classes Jehad Al Dallal Department of Information Science Kuwait University P.O. Box 5969, Safat 13060, Kuwait [email protected] Abstract Inheritance is a key concept in object-oriented programming. Designing and implementing the inheritance relations in a software system properly is expected to improve the quality of the system. This paper uses the class flattening approach to empirically investigate the impact of inheritance on three internal quality attributes: size, cohesion, and coupling. This paper explains how to flatten Java classes and reports the application of the process on classes of five Java open-source systems. The size, cohesion, and coupling of the original and flattened classes were measured using 28 existing metrics, and the results are compared to empirically explore the relationship between inheritance and class quality. The results show that considering inheritance relations in software development significantly improves the class quality. In addition, the results of the study demonstrate that class flattening improves some cohesion metrics that indicate class quality. Finally, this paper discusses the relationship between class flattening and some applications of interest to software practitioners, such as refactoring and indicating external quality attributes. Keywords: object-oriented design, inheritance, quality metric, internal quality attribute, external quality attribute, class flattening. 1. Introduction An object-oriented programming approach is built on several key concepts, such as data encapsulation and inheritance. Implementing these concepts properly results in highquality systems (Fayed and Laitinen 1998). A class in an object-oriented system is the basic unit of design, and it encapsulates a set of attributes and methods. Instead of redefining the attributes and methods that are included in other classes, a class can inherit these attributes and methods and only implement its unique attributes and methods, which results in reducing code redundancy and improving code testability and maintainability (Sheldon et al. 2002). Representing a class with its inherited attributes and methods is called class flattening (Beyer et al. 2001). Several class quality attributes were proposed in the literature, and they are categorized into internal and external attributes. Internal quality attributes, such as size, cohesion, and coupling, can be measured using software artifacts such as the software code. On the other hand, external quality attributes, such as reusability, maintainability, and testability, cannot be measured using only software artifacts (Morasca 2009). 1

Researchers have proposed many metrics that use different approaches to measure the class internal quality attributes and indicate the external quality attributes. In addition, they use several approaches to validate their measures and explore correlations among the internal quality attributes and between internal attributes and external quality attributes. Inheritance is a concept that may have an impact on the quality of the system. However, the relationship between inheritance and size, coupling, and cohesion attributes has not been thoroughly investigated. For example, Beyer et al. (2001) and Chhikara et al. (2011) considered a few internal-quality metrics. They used a small number of classes in the empirical study, and did not discuss the practical influences of class flattening. Several works (e.g., Bieman and Kang 1995, Briand et al. 1998, Al Dallal and Briand 2010, and Al Dallal and Briand 2012) discussed the impact of considering the inherited attributes and methods on quality measurement theoretically, but not empirically. In this paper, we explain how to perform class flattening for Java classes. Our explanation considers the related key concepts of object-oriented programming, such as data encapsulation, overriding, and overloading. We provide four different views of a subclass in Java systems: (1) the original class, (2) the original class with the inherited attributes, (3) the original class with the inherited methods, and (4) the original class with both the inherited attributes and the inherited methods. We applied the class flattening process to all of the subclasses in the five Java open-source systems, which resulted in the construction of three versions of each subclass in addition to the original version. Each version considers one of the four previously mentioned views. We used the class flattening idea to explore the relationship between inheritance and size, cohesion, and coupling attributes. We applied 28 metrics to measure the quality attributes for each version of the classes considered in the empirical study. The collection of the flattened subclasses and the classes without inheritance relations represents the system that does not consider the inheritance relations in its implementation. This version is expected to have lower quality than the system with inheritance relations. Therefore, to investigate the impact of inheritance on the quality of the system considered, we measured and compared the qualities, in terms of size, cohesion, and coupling, of the different versions. To explore whether the quality indication of a specific metric among the considered metrics can be improved when considering the inherited attributes and/or the inherited methods, we used the metric to obtain the quality values for each of the four versions and compared the results. The version that has the best quality indication must be adopted. Finally, we discussed whether it is better to apply the class flattening process when using the metrics that measure the internal quality attributes in applications of interest for software practitioners, including refactoring and indicating external quality attributes. The results of the empirical study show that implementing the inheritance relations in object-oriented systems enhances the quality of the systems. In addition, the results showed that, for some of the cohesion metrics, their quality indications were significantly improved when the inherited attributes were considered in the cohesion measurement. In summary, the major contributions of this paper are as follows: 1. It explains how to flatten Java classes. 2

2. It empirically explores the importance of addressing whether to include/exclude inherited attributes and methods in size, cohesion, and coupling measurements. 3. It empirically investigates the impact of inheritance on class internal quality attributes. 4. It empirically explores the impact of class flattening on improving the quality indication of some cohesion metrics. 5. It discusses the practical applications of class flattening. This paper is organized as follows. Section 2 reviews related work. Section 3 explains how to flatten Java classes. Section 4 explains the design of the empirical study. Section 5 reports and discusses the empirical study results and lists validity threats to the empirical study. Section 6 discusses the applications of class flattening. Finally, Section 7 concludes the paper and discusses future work. 2. Related Work In this section, we provide an overview of several existing quality class metrics for object-oriented systems and other related work in the area of measuring software quality. In addition, we review and discuss related work that explores the relationship between inheritance and class quality attributes. 2.1. Class quality metrics Researchers have divided class quality attributes into internal and external categories (Morasca 2009). External quality attributes are attributes that indicate the quality of the class based on factors that cannot be measured using only knowledge of the software artifacts. For example, class maintainability cannot be measured unless the class is actually maintained. Similarly, class reusability cannot be measured unless the class is actually reused. It is difficult to anticipate the number of classes that will reuse the class in the future or to measure the effort that is required to maintain the class. On the other hand, internal class quality attributes, such as size, coupling, and cohesion, are attributes that can be measured based on only the knowledge of class artifacts. The internal quality attributes are not of interest for software practitioners unless they are used to indicate external quality attributes or perform activities of interest, such as refactoring (Morasca 2009). Several metrics have been proposed to measure the size of a class. The most commonly used metrics are lines of code (LOC), number of local methods (NOM), and number of local attributes (NOA). Class coupling refers to the extent to which the class is coupled with other classes (Briand et al., 1999a). Several coupling metrics have been proposed to assess class coupling (e.g., Briand et al., 1997, Chidamber and Kemerer 1991, Chidamber and Kemerer 1994, Li and Henry 1993, Lee et al., 1995). In this paper, we consider five coupling metrics, including RFC, MPC, DAC1, DAC2, and OCMEC, as defined in Table 1. The theoretical validation of these coupling metrics has been studied by Briand et al., (1999a). 3

Class Coupling Metric Definition/Formula Response for a class (RFC) The number of methods directly invoked by the methods of class A. (Chidamber and Kemerer 1994) Message Passing Coupling The total number of method invocations in a class. (MPC) (Li and Henry 1993) Data Abstraction Coupling The number of attributes that have types of other classes. (DAC1) (Li and Henry 1993) DAC2 (Li and Henry 1993) The number of distinct classes used as types of the attributes of the class. OCMEC (Briand et al., 1997) The number of distinct classes that are used as types of the parameters of the methods in the class.

Table 1: Definitions of the considered class coupling metrics. Class cohesion refers to the relatedness of class members (i.e., methods and attributes) (Briand et al., 1998). Many class cohesion metrics have been proposed in the literature (e.g., Briand et al., 1998, Briand et al., 1999b, Counsell et al., 2006, Al Dallal and Briand 2010, Al Dallal and Briand 2012, Al Dallal 2007, Al Dallal 2012b, Chidamber and Kemerer 1991, Chidamber and Kemerer 1994, Hitz and Montazeri 1995, Bieman and Kang 1995, Chen et al., 2002, Badri 2004, Fernandez and Pena 2006, Li and Henry 1993, Zhou et al., 2002, Zhou et al., 2004, Chae et al., 2004, Etzkorn et al., 2004). In this paper, we consider 20 cohesion metrics, as defined in Table 2: LCOM1, LCOM2, LCOM3, LCOM4, LCOM5, Coh, TCC, LCC, DCD, DCI, CC, SCOM, LSCC, CBMC, ICBMC, OLn, PCCC, CAMC, NHD, and MMAC. The last three metrics are applicable during the high-level design phase, whereas the rest are applicable during the low-level design phase. All of the selected metrics have been theoretically and empirically studied (Briand et al., 1999b, Briand et al., 2001, Al Dallal 2010, Al Dallal 2011a, Al Dallal 2011b, Al Dallal 2012a, Al Dallal 2012c). Class Cohesion Metric Definition/Formula Lack of Cohesion of Methods LCOM1= Number of pairs of methods that do not share attributes. (LCOM1) (Chidamber and Kemerer 1991) LCOM2 (Chidamber and P= Number of pairs of methods that do not share attributes. Kemerer 1994) Q= Number of pairs of methods that share attributes. ìP - Q if P - Q ³ 0 LCOM 2 = í otherwise î 0 LCOM3 (Li and Henry 1993) LCOM3= Number of connected components in the graph that represents each method as a node and the sharing of at least one attribute as an edge. LCOM4 (Hitz and Montazeri Similar to LCOM3 and additional edges are used to represent method invocations. 1995) LCOM5 (Henderson-Sellers LCOM5=(a-kl)/(l-kl), where l is the number of attributes, k is the number of methods, 1996) and a is the summation of the number of distinct attributes accessed by each method in a class. Coh (Briand et al. 1998) Coh=a/kl, where a, k, and l have the same definitions above. Tight Class Cohesion (TCC) TCC= Relative number of directly connected pairs of methods, where two methods are (Bieman and Kang 1995) directly connected if they are directly connected to an attribute. A method m is directly connected to an attribute when the attribute appears within the method's body or within the body of a method invoked by method m directly or transitively.

Table 2 (Part 1): Definitions of the considered class cohesion metrics (modified from Al Dallal 2011b). 4

Class Cohesion Metric Definition/Formula Loose Class Cohesion (LCC) LCC=Relative number of directly or transitively connected pairs of methods, where two (Bieman and Kang 1995) methods are transitively connected if they are directly or indirectly connected to an attribute. A method m, directly connected to an attribute j, is indirectly connected to an attribute i when there is a method directly or transitively connected to both attributes i and j. Degree of Cohesion-Direct DCD= Relative number of directly connected pairs of methods, where two methods are (DCD) (Badri 2004) directly connected if they satisfy the condition mentioned above for TCC or if the two methods directly or transitively invoke the same method. Degree of Cohesion-Indirect DCI= Relative number of directly or transitively connected pairs of methods, where two (DCI) (Badri 2004) methods are transitively connected if they satisfy the same condition mentioned above for LCC or if the two methods directly or transitively invoke the same method. Class Cohesion (CC) (Bonja CC = Ratio of the sum of the similarities between all pairs of methods to the total number and Kidanmariam 2006) of pairs of methods. The similarity between methods i and j is defined as: I i  I j , where Ii and Ij are the sets of attributes referenced by methods i Similarity (i, j )  Ii  I j Class Cohesion Metric (SCOM) (Fernandez and Pena 2006)

and j, respectively. SCOM = Ratio of the sum of the similarities between all pairs of methods to the total number of pairs of methods. The similarity between methods i and j is defined as: Ii  I j I i  I j , where l is the number of attributes Similarity (i, j ) 

min( I i , I j )



l

0 Low-level design Similarity based Class Cohesion 1 (LSCC) (Al Dallal and LSCC(C)   l  x i (x i 1) Briand 2012)

if k  0 or l  0, if k  1,

i1  lk(k 1)

,

otherwise.

Where l is the number of attributes, k is the number of methods, and xi is the number of methods that reference attribute i. Cohesion Based on Member CBMC(G) = Fc(G)×Fs(G), where Fc(G)=|M(G)|/|N(G)|, M(G)=the number of glue  Connectivity (CBMC) (Chae methods in graph G, N(G)=the number of non-special methods represented in graph G, n et al. 2000) Fs (G)  [ CBMC (G i )] / n, n=the number of child nodes of G, and glue methods is the i 1

minimum set of methods for which their removal causes the class-representative graph to become disjointed. Improved Cohesion Based on ICBMC(G)=Fc(G)×Fs(G), where Fc(G)=|M(G)|/|N(G)|, M(G)=the number of edges in the Member Connectivity cut set of G, N(G)=the number of non-special methods represented in graph G multiplied 2 (ICBMC) (Xu and Zhou by the number of attributes, F (G)  [ ICBMC (G i )] / 2, and cut set is the minimum set  s 2001, 2003) i 1

OLn (Yang 2002)

Path Connectivity Class Cohesion (PCCC) (Al Dallal 2012b)

of edges such that their removal causes the graph to become disjointed. OLn= The average strength of the attributes, wherein the strength of an attribute is the average strength of the methods that reference that attribute. The strength of a method is initially set to 1 and is computed, in each iteration, as the average strength of the attributes that it references, where n is the number of iterations that are used to compute OL. if l  0 and k  1, , 0 1 PCCC (C )   NSP(Gc )   NSP( FGc )

if l  0 and k  0,

otherwise.

where NSP is the number of simple paths in graph Gc, FGc is the corresponding fully connected graph, and a simple path is a path in which each node occurs once at most.

Table 2 (Part 2): Definitions of the considered class cohesion metrics (modified from Al Dallal 2011b). 5

Class Cohesion Metric Cohesion Among Methods in a Class (CAMC) (Bansiya et al. 1999, Counsell et al. 2006) Normalized Hamming Distance (NHD) (Counsell et al. 2006) Method-Method through Attributes Cohesion (MMAC) (Al Dallal and Briand 2010)

Definition/Formula CAMC= a/kl, where l is the number of distinct parameter types, k is the number of methods, and a is the summation of the number of distinct parameter types of each method in the class. Note that this formula is applied on the model that does not include the self parameter type that is used by all of the methods. l 2 NHD  1  x j (k  x j ) , where k and l are as defined above for CAMC, and xj  lk (k  1) j 1 is the number of methods that have a parameter of type j. if k  0 or l  0,

0 1  MMAC (C )   l xi ( xi  1)  i 1  lk (k  1) 

if k  1, otherwise.

, where xi is the number of methods that have a parameter or a return of type j (the type must match one of the attribute types).

Table 2 (Part 3): Definitions of the considered class cohesion metrics (modified from Al Dallal 2011b). The important difference between LCOM1, LCOM2, LCOM3, LCOM4, LCOM5, and the other cohesion measures is that LCOM1, LCOM2, LCOM3, LCOM4, and LCOM5 do not measure cohesion but, rather, its absence. Therefore, the impact of inheritance on these measures is expected to be the opposite of the impact of inheritance on the other cohesion measures. In addition, the behavior of NHD is not necessarily monotonic with respect to the number of methods that have a parameter of a given type j, which is the characteristic that contributes to the cohesion of the class for each type j. Therefore, the impact of inheritance on NHD may be the same or opposite of that of the other cohesion measures. 2.2. Impact of inheritance on internal quality attributes Bieman and Kang (1995) proposed three options for inherited methods and attributes when performing cohesion analysis. The options are (1) including both, (2) excluding both, and (3) including attributes and excluding methods. Briand et al. (1998) added the fourth option, which is excluding attributes and including methods. Some authors (e.g., Bieman and Kang 1995, Briand et al. 1998, Al Dallal and Briand 2010, and Al Dallal and Briand 2012) theoretically addressed the influence of inheritance on their proposed metrics and discussed whether to consider inheritance in the calculation of cohesion. However, they left the empirical investigation of this issue open for further research. Beyer et al. (2001) studied the impact of inheritance on class size, cohesion, and coupling. However, their study has several limitations. First, they used relatively small numbers of classes (57 classes) in their empirical study, which reduces the confidence in their results. Second, they examined only one option of inheritance, which is including both inherited attributes and methods. Third, they considered the impact of inheritance on only five quality metrics including three of the metrics considered in this paper, NOM, NOA, and LCOM1. Fourth, they did not discuss the impact of class flattening on the applications of interest for software practitioners, such as refactoring and indicating external quality attributes. Chhikara et al. (2011) represented a more limited analysis for the impact of inheritance on quality attributes. They considered four different designs of 6

an artificial class example, measured the quality of each design using the six metrics proposed by Chidamber and Kemerer (1994), and compared the obtained quality values. They found that the design with the best inheritance architecture has the best quality values. In this paper, we extended similar existing empirical studies by considering larger systems and all of the possible scenarios of including/excluding inherited attributes and methods. In addition, we considered more metrics and discussed the impact of class flattening in practice. 3. Java Class Flattening Inheritance is a key concept in object-oriented programming. Implementing this concept implies distributing the features among the classes that have inheritance relations. Generally, a subclass inherits the members of its direct and transitive superclasses. The members of a class are its attributes and methods. A subclass c1 transitively inherits a superclass c2 when the subclass c1 directly inherits a superclass c3 that directly or transitively inherits the superclass c2. Syntactically, Java reserves the keyword extends to indicate the inheritance relation and allows for single inheritance only. By default, a class without a declared superclass inherits the Object class. Flattening a class refers to the process of representing the class as it really is, which means considering all of its inherited attributes and methods (Beyer et al. 2001). In this paper, we only consider local inheritance; we do not account for the inheritance of classes that are declared outside of the system under consideration (e.g., library classes). In addition, we consider only explicit inheritance caused by class extension using extends keyword, and therefore, we do not consider flattening inner classes. Java has some semantics that must be accounted for when performing class flattening. These semantics are related to data encapsulation, overriding, overloading, and dynamic binding concepts. 3.1. Inheritance related concepts in Java Java provides four accessibility levels for class members: public, package, protected, and private. A subclass can directly access its superclass members for any accessibility level except for private. Private members in a class can only be directly accessed within the class in which they are declared. Typically, developers are advised to declare the attributes to be private and make them accessible only through access methods (i.e., setters and getters). In this paper, we refer to the private attributes and methods as invisible attributes and methods. The rest of the attributes and methods are visible. In Java, attribute overriding occurs when an attribute of a subclass has the same name as an attribute in the direct or transitive superclass, regardless of the types of the two attributes. In this case, the subclass can access the superclass attribute either indirectly through the access methods of the attribute or directly by using the keyword super (given that the superclass attribute is not declared private). Method overriding occurs when a method in the subclass and a method in the superclass have identical signatures (i.e., method name and types, number, and ordering of the parameters). Similar to the overridden attributes, overridden methods can be accessed indirectly by calling a method (in the superclass) that invokes the overridden method or by using the keyword super. It is important to note that Java does not allow overriding an attribute when the attribute is 7

declared static in either the subclass or the superclass. That is, both of the attributes must be similarly declared as either static or nonstatic. The same constraint applies for method overriding. Final attributes and methods cannot be overridden. Overloading refers to the existence of two or more methods with the same names but different numbers, types, or ordering of parameters. The methods can be within the same class or in different classes with inheritance relations. In other words, Java allows for a method in a subclass to overload a method in a superclass. Dynamic method binding refers to resolving the references to subclass methods at runtime. The class flattening considered in this paper does not consider dynamic method binding because our analysis is performed statically, whereas studying the impact of dynamic method binding requires analyzing the classes dynamically. In the following, we will discuss the impact of considering these Java concepts on attribute and method flattening. Attribute flattening refers to the process of pulling down the attributes of the superclass to the subclass during the class flattening process. Similarly, method flattening refers to the process of pulling down the methods of the superclass to the subclass during the class flattening process. In case a chain of superclasses exists, class flattening is applied for each pair of subclass and superclass, starting from the subclass that inherits the superclass with no declared superclass. For example, if class c1 inherits class c2, which in turn inherits class c3, then class flattening will be applied for class c2 first. The resulting flattened version of class c2 will be used in the class flattening process of class c1. 3.2. Attribute flattening Nonoverridden attributes can be either visible or invisible. In the attribute flattening process, the nonoverridden attributes that are visible must be pulled down from the superclass to the subclass because these attributes are accessible through the subclass. A nonoverridden attribute that is invisible can be either accessed by some methods in the superclass or not. In the former case, the attribute must be pulled down to the subclass in the flattening process unless none of the methods that access the attribute in the superclass are pulled down to the subclass in the method flattening process. A compilation error will result if the invisible attribute is not pulled down to the subclass, and, at the same time, a method that accesses the attribute is pulled down to the subclass in the flattening process. In the flattening process, the nonoverridden attribute that is declared private will not be pulled down to the subclass if the attribute is not accessed by any of the methods in the superclass. Such an attribute is invisible and inaccessible. The existence of such an attribute is syntactically correct but meaningless. Regardless of its visibility, an overridden attribute must be renamed and pulled down to the subclass if it is accessed by some methods that are pulled down to the subclass in the flattening process; otherwise, the flattened class will have a compilation error. The pulled down methods that access the pulled down attribute and the original subclass code that accesses the pulled down attribute using the super keyword must be modified to refer to the new name of the attribute. Otherwise, the pulled down methods or the subclass code will be incorrectly accessing the overriding attributes instead of the overridden ones. On the other hand, if the overridden attribute is visible and it is not accessed by any of the 8

methods in the superclass, then the attribute must be renamed and pulled down to the subclass. In this case, the attribute is pulled down because it was allowed to use the keyword super to access the attribute in the original version of the subclass. The attribute is renamed to avoid a naming conflict, which causes a compilation error. The subclass code that accesses the pulled down attribute must be modified to refer to the new name of the attribute. Finally, an overridden attribute that is invisible will not be pulled down to the subclass if the attribute is not accessed by any of the methods that are pulled down during the flattening process. As discussed above, this attribute is invisible and inaccessible, and its existence in the superclass indicates an anomaly case. In summary, unless the attribute is invisible and not accessed by any of the superclass methods that are pulled down during the flattening process, the attribute must be pulled down to the subclass during the flattening process. The pulled down overridden attributes must be renamed, and the corresponding code must be modified. 3.2. Method flattening The above discussion regarding attribute flattening is also applicable for the superclass methods considered in the method flattening process. That is, invisible methods that are not accessed by any of the visible methods of the superclass must not be pulled down to the subclass during the class flattening process. These methods are meaningless. All of the other visible and invisible methods must be pulled down to the subclass for the same reasons mentioned above regarding the attributes. Pulled down overridden methods must be renamed, and the corresponding code must be modified. The diagram given in Figure 1 summarizes the different possibilities, discussed above, and the corresponding flattening actions.

Figure 1: The different possibilities of the attribute or method cases and the corresponding flattening actions 9

4. Design of the Empirical Study The goal of the empirical study is to explore the impact of Java class flattening on the size, cohesion, and coupling quality attributes. As a result, the study indirectly investigates the effect of implementing inheritance relations in Java systems on the quality of the classes. In addition, for each of the considered size, cohesion, and coupling metrics, the empirical study investigates whether class flattening improves the ability of the metric to indicate the intended class quality aspect. Finally, the study empirically determines whether the changes in the quality values, when performing class flattening, are significant and, consequently, empirically determines whether it is important for software engineers to consider the problem of class flattening when using size, cohesion, and coupling metrics in supporting software quality decisions. To perform this study, we selected five Java open-source software systems from different domains: Art of Illusion (Illusion 2010), FreeMind (FreeMind 2010), GanttProject (GanttProject 2010), JabRef (JabRef 2010), and Openbravo (Openbravo 2010). Art of Illusion is a 3-D modeling, rendering, and animation studio system. FreeMind is a hierarchical editing system. GanttProject is a project-scheduling application that features resource management, calendaring, and importing and exporting (MS Project, HTML, PDF, spreadsheets). JabRef is a graphical application for managing bibliographical databases. Finally, Openbravo is a point-of-sale application for touch screens. The versions and sizes of the considered systems are reported in Table 3. The number of classes reported in the fourth column of Table 3 excludes the interfaces and abstract classes because most of the considered quality metrics are not applicable for interfaces and abstract classes, and that number includes all of the other classes. We selected these five open-source systems from http://sourceforge.net. The restrictions placed on the choice of these systems were that they were (1) implemented using Java, (2) relatively large in terms of the number of classes, and (3) from different domains.

System Art of Illusion FreeMind GanttProject JabRef Openbravo Total

Version

LOC

2.5 0.8.0 2.0.5 2.3 beta 2 0.0.24 -

88 K 64 K 39 K 48 K 36 K 275 K

Number of Number and percentage considered classes of flattened classes 463 177 (38.2%) 378 170 (45.0%) 435 123 (28.3%) 540 111 (20.6%) 428 93 (21.7%) 2,245 674 (30.0%)

Table 3: The Java systems used in the empirical study We developed a tool to automate the flattening process. The tool takes the classes of a system as an input, analyzes the inheritance relations among the classes, and generates three flattened versions for each subclass in the system. The first flattened version of the subclass includes all of the directly and indirectly inherited attributes (that comply with the constraints discussed in Section 3) in addition to the code of the subclass itself. The second flattened version of the subclass includes all of the directly and indirectly inherited methods (that comply with the constraints discussed in Section 3) in addition to 10

the code of the subclass itself. Finally, the third version of the subclass considers both the inherited attributes and methods. As a result, we considered four versions of each subclass, including the original version before flattening and the three flattened versions. The goal is to investigate the impact of each of these flattening scenarios on the size, cohesion, and coupling quality attributes. The number and percentage of subclasses (flattened classes) in each of the considered systems are reported in the last column of Table 3. This table shows that the percentages of the subclasses in the considered systems range from 20.6% to 45%. This observation indicates that the class flattening is expected to substantially affect the overall quality of the considered systems. This expectation will be confirmed with empirical evidence in the next section of this paper. We developed our own Java tool to automate the size, cohesion, and coupling measurement process for Java classes. The tool was applied to each version of the classes considered in the five systems, which implies applying the tool on the 2,245 original classes in addition to the three flattened versions of each of the subclasses. For each of the classes considered, the tool analyzed the Java source code; extracted the required data; calculated the size, cohesion, and coupling values using the 28 metrics that were considered; and reported the results in an Excel spreadsheet. The selected metrics are listed in Tables 4, 5, and 6 and are summarized in Section 2. The selected quality metrics are widely applied, and they have been theoretically and empirically studied (Briand et al. 1999a, Briand et al. 1999b, Briand et al. 2001, Al Dallal 2010, Al Dallal 2011b, Al Dallal 2011a, Al Dallal 2012b, Al Dallal and Morasca 2012). It is important to note that these metrics do not represent all of the existing metrics in the literature. They are example metrics of different internal quality attributes used to investigate the general relationship between the internal quality attributes and inheritance and to show the importance of considering whether to include or exclude the inherited attributes and methods in quality measurement whenever a metric is proposed. To investigate whether the changes in the size, cohesion, and coupling values were statistically significant, we applied the paired z-test (Hines et al. 2003), a standard statistical technique applied to compare two independent sets of samples. We applied this technique because the quality values before and after performing the class flattening process are independent and the number of selected classes is sufficiently large. In our context, to apply the paired z-test for a metric, (1) the difference between the quality values before and after the change must be calculated for each class, (2) the means and standard deviation values of these differences must be obtained, and (3) the Z value must be calculated by multiplying the mean of the differences by the square root of the number of classes and dividing the result by the standard deviation of the differences. We applied the typical significance threshold (α = 0.05) to decide whether the differences between the quality values were significant. The corresponding critical Z value is 1.96. The differences were considered significant when the absolute value of Z was greater than that of the critical Z. We applied this analysis to compare the values of Scenarios 2 (attribute flattening), 3 (method flattening), and 4 (both attribute and method flattening) to the values of Scenario 1 (original code without flattening). 11

5. Empirical Study Results and Threats to Validity The empirical study considers the impact of inheritance on each of the considered internal quality attributes. The results of the empirical study are as follows. 5.1. Impact of inheritance on size metrics Typically, additional code is added to the subclasses when they are flattened, which results in enlarging the sizes of the subclasses. Therefore, when assessing the size quality of a specific class, the software engineer must decide which type of quality to evaluate based on the intended use of the size values. For example, if the software engineer is looking for small classes to be reused in other systems, then measuring the size of the classes without accounting for inheritance will give an incorrect size indication. This incorrect indication is, in this case, due to the need to consider the class of interest and all of its direct and indirect superclasses for reusability. In our empirical study, the original number of methods in the flattened classes was 5,300, and it was substantially increased by 8,777 methods (166%) to 14,077 methods. In addition, the number of attributes in the subclasses was greatly increased by 183% from 2424 attributes to 6869 attributes. The flattening process caused the mean number of methods in the subclasses to increase from 7.86 to 20.89. Moreover, it caused the mean number of attributes in the subclasses to increase from 3.59 to 10.18. Figures 2 and 3 depict the distribution of the inherited methods and inherited attributes, respectively, in the flattened classes. For example, Figure 2 shows that 237 classes (35% of the flattened classes) include zero to five inherited methods. Figures 2 and 3 show that a higher percentage of the flattened classes had fewer inherited methods and attributes. The high percentage of change in the number of methods and attributes when the subclasses were flattened indicates the importance of studying the impact of inheritance on the quality values that are obtained by the size, cohesion, and coupling metrics.

Figure 2: The distribution of the inherited methods.

12

Figure 3: The distribution of the inherited attributes. In each of the four scenarios considered, we obtained the descriptive statistics for each quality measure, including the minimum, 25% quartile, mean, median, 75% quartile, maximum value, and standard deviation. For each metric, the descriptive statistics cover all of the considered classes (i.e., the flattened and nonflattened classes). Because of space limitations, Tables 4, 5, and 6 show only the mean for the quality values of the metrics considered when applied to the four scenarios. The complete set of descriptive statistics is listed in Appendix A. In addition, Tables 4, 5, and 6 report the percentage of the difference between the mean value of the metric in each scenario and the corresponding mean value in Scenario 1. Finally, Tables 4, 5, and 6 show the Z absolute values resulting from applying the paired z-test analysis. It is important to note that the Z value is undefined when none of the values change (e.g., attribute flattening does not change the NOM values). The p-values that resulted from the paired z-test analysis were below the threshold for all of the metrics in all scenarios for which Z values were defined, except for a few results indicated by Z values that are highlighted in boldface in Table 5. Having a p-value below its threshold and the Z absolute value above its threshold indicates that the changes in the quality values are significant when the classes were flattened.

Metric

Scenario 1: Original classes Mean

NOM NOA LOC

7.17 4.20 92.10

Scenario 2: Attribute-flattened classes Percentage Mean of Mean |Z| Diff. 7.17 0.0% 6.18 47.1% 16.1 92.50 0.4% 3.0

Scenario 4: Both attribute- and method-flattened classes Percentage Percentage Mean of Mean |Z| Mean of Mean |Z| Diff. Diff. 11.08 54.5% 19.1 11.08 54.5% 19.1 4.20 0.0% 6.18 47.1% 16.1 120.56 30.9% 15.5 122.41 32.9% 15.8

Scenario 3: Method-flattened classes

Table 4: Paired z-test results and partial descriptive statistics for the considered size metrics. 13

For example, when accounting for all of the considered classes, Table 4 shows that the consideration of the inherited methods (Scenarios 3 and 4) caused the values of the NOM metric to change significantly (|Z|>1.96 and the Z value is not highlighted in boldface, i.e., p-value