CHAPTER 4 HEURISTICS BASED ON OBJECT ORIENTED METRICS

Transcription

1 CHAPTER 4 HEURISTICS BASED ON OBJECT ORIENTED METRICS Design evaluation is most critical activity during software development process. Design heuristics are proposed as a more accessible and informal means by which developers can evaluate software design. Software heuristics are legible, small, simple, selfcontained nuggets of design expertise. Heuristics target specific design problems within OO software and provide guidance on how to affect a solution. This chapter focuses on object oriented design metrics particularly, CK metrics and MOOD metric suite and proposes some heuristics based on them. Heuristics Based On Object Oriented Metrics Page 53

2 CHAPTER 4 HEURISTICS BASED ON OBJECT ORIENTED METRICS Software design is one of the most important and key activities in the system development life cycle. Software design metrics assess the size, quality and complexity of object-oriented software systems. 4.1 Heuristics Based on CK Metrics Chidamber and Kemerer s (Chidamber et al., 1994) suite for object-oriented systems consists of the six metrics. Heuristics based on theses metrics are described as follows: 1. Weighted Methods Per Class (WMC): According to this metric if a Class C, has n methods and c1, c2 cn be the complexity, then WMC(C)= c1 + c2 + + cn. Eq. (4.1) Mc Cabe s complexity metric is chosen for calculating the complexity values of the methods of a class. The value is normalized so that nominal complexity for a method takes on a value of 1.0. If all method complexities are considered to be unity, then WMC = n i.e. the number of methods existing in that class. Heuristic: Time and effort required to develop and maintain the class is dependent on the count and the complexity of methods. As the number of methods in a class increases, the potential impact on its children also increases, since children will inherit all the methods defined in the base class. Classes with large number of methods are more application specific which limits the possibility of reusability. This reasoning indicates that a smaller number of methods are good for usability and reusability. The derived classes inherit the methods of the base class therefore, large number of methods indicate greater potential impact on derived classes (Kumar et al., 2012). The WMC metric is the sum of the complexities of all class methods. It is an indicator of amount of effort required to develop and maintain a particular class. A class with a high WMC indicates that the class is complex and therefore harder to Heuristics Based On Object Oriented Metrics Page 54

3 reuse and maintain. Mc Cabe s complexity metric is used to compute the complexity values of the methods of a class. McCabe suggested that 10 is probably a good limiting value for v (G), and that number is certainly the most widely used. McCabe proposed that if a function has a complexity<=10, it indicates that it is simple but if this value exceeds 10, then it becomes complex and the resulting code would be excessively hard to understand or maintain. At the module level, this metric measures the number of linearly independent paths through the module. Modules that contain many possible paths are more complex than those with fewer paths, so as the cyclomatic complexity of a module increases, so does its complexity. Also, this metric is equal to one more than the number of decisions contained in the module and considers complexity of an individual module. Modules with low cohesion implement more than one function and therefore, testing the functionality of that module requires more test cases to cover all of that module s functionality (weblink 10). Cyclomatic complexity essentially measures the number of paths through a module, so modules with higher cyclomatic complexity will require more test cases to cover all the paths. It indicates that if a function is complex, it lacks function cohesion and therefore, it is better to decompose it into two methods. This decomposition is not so easy in case the function cohesion exists, as complexity can be an inherent feature of the function. A class with a low WMC usually points to greater polymorphism. In polymorphism, as the interface is common to objects, so, it offers advantage that objects are independent of each other and all objects can respond to some common set of tasks in a different way. Classes with a large Weighted Methods per Class value can often be refactored into two or more classes. The use of this metric enables the design team to focus the review and testing resources on those classes which have greatest potential for improvement. Software development trends support smaller methods over fewer larger methods for achieving increased readability, reduced complexity and improved understanding (Churcher et al., 1995). However, it is not advisable to have a method consisting of larger number of methods in a large inheritance tree. Heuristics Based On Object Oriented Metrics Page 55

4 WMC measures the complexity of an individual class. Classes with more member functions are considered to be more complex and therefore, more error prone (Basili et al., 1996). So, a high WMC leads to more faults, therefore, it is better to keep it as low as possible. 2. Depth of Inheritance Tree (DIT): The maximum length from the node to the root of the tree is depth of the inheritance tree. Heuristic: More is the depth of the inheritance tree greater will be the reusability of class and reduces coding, testing and documentation time (Subramanyam et al., 2003). Inheritance also referred to as generalization, is an essential component in the object oriented programming approach. A class situated too deeply in the inheritance tree will be relatively complex to develop, debug and maintain. Therefore, it is useful to know and regulate this depth. DIT metric provides the position of the class in the inheritance tree and is a factor which influences cost of testing. If DIT is large, then testing will be more expensive. The deeper a class is in the inheritance hierarchy, the more variables and methods it is likely to inherit and therefore, it becomes more complex. Inheritance is a tool to manage complexity where as deep trees indicate greater design complexity as more methods and classes are involved (Chidamber et al., 1994). As a positive factor, deep trees promote reuse because of method inheritance. Although, inheritance decreases complexity by reducing the number of operators and operations, but this abstraction of objects can make design and maintenance difficult. The depth and breadth of the inheritance hierarchy are used to measure the amount of inheritance. As depth of the inheritance tree increases, the number of faults also increases. However, it is not necessary that the classes deepest in the class hierarchy contain a larger number of faults. Most fault-prone classes are the ones which lie in the middle of the tree. The root and deepest classes are often consulted more, and due to familiarity, they have low fault-proneness as compared to classes in the middle (Glasberg et al., 2000).Well structured OO systems have a forest of classes rather than one large inheritance lattice. The depth of a class within the inheritance Heuristics Based On Object Oriented Metrics Page 56

5 hierarchy is measured by the number of ancestor classes. In multiple inheritances, the DIT is the maximum length from the node to the root of the tree. Applications that contain too many classes near the root are considered to be top heavy. In such classes designers are not able to take advantage of reuse of methods through inheritance (Basili et al., 1996). Alternatively, applications are considered to be bottom heavy when too many classes are near the bottom of the hierarchy. Such classes result in greater design complexity and conceptual integrity concerns. Indeed, deep hierarchies are also a conceptual integrity concern because it becomes difficult to determine which class to specialize from (Basili et al., 1996). Additionally, interface changes within the tree must be reflected throughout the entire class tree and object instances. However, the deeper a particular tree is in a class, the greater will be potential reuse of inherited methods. Hence, it is advisable to regulate the depth of a tree and the value of DIT metric should be kept neither too high nor too low. 3. Number of Children (NOC): Number of children (NOC) of a class is the number of immediate sub-classes subordinated to a class in the class hierarchy. Heuristic: Greater is the value of NOC, greater will be the reusability of the parent class which in turn enhances productivity. Hence there should be some minimum value of NOC for a parent class for its reusability (Chidamber et al., 1994). This metric gives an indication of the number of direct descendants (subclasses) for each class. Classes with large number of children are harder to maintain and modify. Thus, such classes require more testing due to the effects of changes on all the children. They are also considered more complex and fault-prone as a class with numerous children may have to provide services in a larger number of contexts and therefore must be more flexible (Basili et al., 1996). High NOC has been found to indicate fewer faults due to high reuse, which is desirable. A large number of child classes, can indicate that base class may require more testing and there is improper abstraction of the parent class. Not all classes should have the same number of sub-classes. Classes that are higher in the hierarchy should have more sub-classes then those lower down (weblink 1). Heuristics Based On Object Oriented Metrics Page 57

6 NOC and DIT are closely related. DIT measures the depth where as NOC measures the breadth of a class hierarchy. Depth is generally considered to be better than breadth, since depth promotes reuse of methods through inheritance. Inheritance levels can be added to increase the depth and reduce the breadth. The class is potentially influencing a large number of descendant classes in an inheritance hierarchy. This can be a sign of poor design and redesign may be required. A class with a high NOC and a high WMC indicates complexity at the top of the class hierarchy. 4. Coupling between Object Classes (CBO): Coupling between Object Classes (CBO) for a class is a count of the number of other classes to which it is coupled. Heuristic: As Coupling between Object classes increases, reusability decreases and therefore, it becomes difficult to test and modify the software. Hence, there is a need to set some maximum value of coupling level for its reusability. Coupling metric provides insight into the interaction between the modules in the system. Two classes are coupled when methods declared in one class use methods or instance variables defined by another class. Excessive coupling between object classes is detrimental to modular design and prevents reuse of existing components and they are damaging for a modular, encapsulated software design. So, high value of coupling between object classes is undesirable. Therefore, more independent a class is, easier it is to reuse it. Inter-object class couplings should be kept to a minimum, in order to promote encapsulation and improve modularity. As coupling between objects increases, maintenance becomes difficult due to higher sensitivity to changes in other parts of the design. Designers suggest that for a good design coupling should be low. Moreover, a class that is coupled to other classes is sensitive to changes in those classes and as a result it becomes more difficult to maintain and gets more errorprone. And thus, higher value of CBO is an indication of fault-proneness. Additionally, it is harder to understand and test a heavily coupled class in isolation. Therefore, the number of dependencies should be kept as minimum as possible. Hence, it is better to keep value of CBO as low as possible. Heuristics Based On Object Oriented Metrics Page 58

7 5. Response for a Class (RFC): The response set of a class is a set of methods that can potentially be executed in response to a message received by an object of that class. RFC is the number of methods in the set. Heuristic: As RFC increases, the effort required for testing also increases because the test sequence grows. So, testing and debugging is complicated as there is more number of test sequences. It also follows that as RFC increases, the overall design complexity of the class increases. RFC is a measure of the potential communication between a class and other classes as it specifically includes methods called from outside the class. Classes with a high RFC are relatively more complex and harder to understand, debug and maintain. So, large RFC has been found to indicate more faults. If the Response for a class is high, it increases the test sequence, testing effort and the overall design complexity of the class. Therefore, the number of operations that maybe executed in response to a message received should be reduced. Hence, value of RFC should be kept to a minimum. 6. Lack of Cohesion in Methods (LCOM): Each method within a class accesses one or more attributes (Chidamber et al., 1994). LCOM is the number of methods that access one or more of the same attributes. If no methods access the same attributes, then LCOM=0. Heuristic: Cohesion measures degree to which the elements of each module are related to each other. A highly cohesive module performs a function using only the data required to accomplish that function. The high value of LCOM indicates that the methods in the class are not really related to each other and low value of LCOM depicts high internal strength of the class which results into high reusability. Therefore, there should be some maximum value of LCOM after which class becomes non-reusable. If LCOM is high, methods may be coupled to one another via attributes. This increases the complexity of the class design. As coupling increases, reusability decreases and testing and debugging are also complicated and expensive. Although there are cases in which high value for LCOM is justifiable, it is desirable to keep Heuristics Based On Object Oriented Metrics Page 59

8 cohesion high i.e. LCOM should be kept low. Higher value of Lack of Cohesion in Methods increases the complexity of class design. Therefore, the lack of cohesion in methods should be reduced by breaking down the class into two or more separate classes. There are two sub-categories of object-oriented design metrics namely; Intra-class and Inter-class metrics. Intra-class metrics measure characteristics related to one class like Weighted Methods per Class, Number of Children, and Depth of Inheritance Tree. Inter class metrics measure features between a set of classes like Coupling Factor (CF) and Method Hiding Factor (MHF). Each of these metric i.e. Weighted Methods Per Class (WMC), Depth of Inheritance Tree (DIT), Number of Children (NOC), Coupling between Object Classes (CBO), Response for a Class (RFC), Lack of Cohesion in Methods (LCOM) are associated with important modularity attributes like coupling, cohesion, size and inheritance as shown in Table 4.1. Table 4.1: Modularity Attributes for the CK Metrics Modularity Attribute CK Metric Suite Coupling Coupling between objects (CBO) Response for a class (RFC) Cohesion Size Inheritance Lack of cohesion in a class (LCOM) Weighted methods per class (WMC) Depth of inheritance (DIT) Number of children (NOC) 4.2 Heuristics Based on MOOD Metrics Several authors have suggested sets of metrics for the OO paradigm, one of the most important metrics is MOOD (Metrics for Object Oriented Design) suite (Abreu, 1995) (Abreu et al., 1996). Heuristics Based On Object Oriented Metrics Page 60

9 The metrics for object oriented design proposed by Harrison, Counsell and Nithi (Harrison et al., 1998) is as follows: 1. Method hiding factor (MHF): The MHF numerator is the sum of the invisibilities of all methods defined in all classes (Abreu et al., 1996). The invisibility of a method is the percentage of the total classes from which this method is not visible. The MHF (Method hiding factor) denominator is the total number of methods defined in the system under consideration (Abreu et al., 1996). The attribute hiding factor, AHF, is defined in an analogous manner. The AHF numerator is the sum of the invisibilities of all attributes defined in all classes. The invisibility of an attribute can be defined as the percentage of the total classes from which this attribute is not visible. The AHF (attribute hiding factor) denominator is the total number of attributes defined in the system under consideration. Heuristic: Method hiding factor is a type of interclass metrics as it measure features between a set of classes. Method/Attribute hiding factor measures the process with which variables and methods are encapsulated in a class. Visibility is counted with respect to other classes (Weblink 1). The value of MHF/AHF is related to the average amount of hiding among all classes in the system. A private method/attribute fully exhibits data hiding (Weblink 1). By keeping data private usability increases. Encapsulation promotes maintenance and code changes can be made independently with more flexibility. It also reduces coupling of modules and increases cohesion inside a module. For a good design, coupling should be kept low and cohesion should be high. The number of visible methods is a measure of the class functionality. MHF will reduce if overall functionality will increase. However, for implementing the functionality, hidden methods are used which offers information hiding benefits and favors increase in MHF. A low MHF indicates that the probability of errors is high. A high MHF indicates very less functionality and that the design includes a high proportion of specialized methods that are not available for reuse. Increased value of MHF decreases bug- Heuristics Based On Object Oriented Metrics Page 61

10 density, defect density and rework effort to find and correct defects and hence, increases quality (Kumar et al., 2013). If all methods/attributes are private then MHF/AHF=100%. If all methods/attributes are public, MHF/AHF=0%. Hence, MHF should be kept in a reasonable range, i.e. an acceptable range of 8% to 25%. Ideally, all attributes should be hidden, and thus AHF=100% is the ideal value. 2. Method Inheritance Factor (MIF): The degree to which the class architecture of an OO system makes use of inheritance for both methods (operations) and attributes is known as MIF. It is represented as follows: MIF = M i C i )/ M a (C i ) Eq. (4.2) Where the summation occurs over i = 1 to TC. TC is defined as the total number of classes in the architecture, C i is a class within the architecture and M a (C i ) = M d (C i ) + M i C i ) Eq. (4.3) M a (C i ) = the no. of methods that can be invoked in association with C i. M d (C i ) ) = the no. of methods declared in the class C i. M i (C i ) = the number of methods inherited (and not overridden) in C i. AIF i.e. Attribute Inheritance Factor is defined in an analogous manner. Heuristic: The value of MIF/AIF provides an indication of the impact of inheritance on the OO software. Inheritance increases reusability and productivity of class and reduces coding, testing and documentation time, error density and rework (Subramanyam et al., 2003). Inheritance decreases complexity by reducing the number of operations and operators but increases effort and time on testing. Additionally, the deeper classes in the inheritance hierarchy result in increased number of inherited methods and it becomes complex to predict its behavior and is more fault-prone and difficult to design and maintain. Deep inheritance trees and nesting should be avoided to improve comprehensibility. Inheritance hierarchies allow sharing of common code amongst several subclasses and reduce duplicate code and thereby tend to result in a better organization of code Heuristics Based On Object Oriented Metrics Page 62

11 with smaller and simpler compilation units. Use of inheritance makes the classes tightly coupled which means the classes cannot be used independent of each other. A class that inherits lots of methods/attributes from its base classes contributes to a high value of MIF/AIF. A sub class that redefines its base methods/attributes and adds new ones contributes to a lower MIF/AIF (Weblink 1). An independent class that does not inherit and has no children contributes to a lower value of MIF/AIF. A class which has no methods/ attributes or inheritance is not used at all, then value of MIF/AIF is equal to 0%. Hence, MIF and AIF should be kept in a reasonable range, i.e. neither too low, nor too high. Very high value indicates either superfluous inheritance or too wide member scopes (Weblink 1). A low value of MIF and AIF indicates lack of inheritance and heavy use of Overrides. 3. Coupling Factor (CF): Coupling Factor (CF) can be defined as; CF = i j is client (C i, C j ) / ( TC 2 TC ) Eq. (4.4) Where the summation occurs over i = 1 to TC and j = 1 to TC. The function is_client = 1, if C i and C j are coupled. is_client = 0, otherwise Heuristic: Coupling Factor measures the actual couplings among classes. If no classes are coupled, then value of CF = 0%. If all classes are coupled to all other classes, then value of CF=100%. As coupling increases, reusability decreases and it becomes harder to modify and test the software system. Excessive coupling prevents reusability and indicates faultproneness. The major root cause of poor reliability is non- compliance with good architectural and coding practices. In order to improve modularity and promote encapsulation, coupling should be kept to a minimum. As coupling increases, sensitivity to changes also increases in other modules of the design, and therefore maintenance and enhancement is more difficult. As the value for CF increases, the complexity of the OO software will also increase and maintainability, understandability and the potential for reuse may suffer as a Heuristics Based On Object Oriented Metrics Page 63

12 result. It has been suggested that CF should not exceed 12%. Therefore, very high values of CF should be avoided i.e. CF should have lower value. 4. Polymorphism Factor (PF): - PF can be defined as the number of methods that redefine inherited methods divided by the maximum number of possible distinct polymorphic situations. PF is defined as: PF = i M o (C i ) / i [ M n (C i ) x DC (C i ) ] Eq. (4.5) M n (C i ): no. of new method M o (C i ): no. of overriding methods DC(C i ) = no. of classes descendants from C i, where the summation occur over i = 1 to TC. Heuristic: The main advantage of polymorphism is that the interface is common to all objects, so objects respond differently to common set of tasks, and each object is independent of other one. Polymorphism enables a number of different operations to have the same name, reducing the number of lines of code required to implement a system and facilitating changes when they are made. Polymorphism factor increases as overriding increases. Polymorphism factor varies between 0% and 100%. When value of PF is 100%, it means that all methods are overridden in all derived classes. A PF value of 0% may indicate that there is no use of inheritance and polymorphism. A PF value well above 10% is considered very high and reduces quality benefits (Abreu et al., 1996). Polymorphism can be used to a reasonable extent to keep the code clear, but excessive use of polymorphic code may be too complex to understand (Weblink 1). There are conflicting recommendations for the acceptable values of PF. It is recommended that PF>=10% but Abreu and Melo suggested that PF values above 10% are very high and reduces quality benefits (Abreu et al., 1996). Polymorphism factor should lie in a reasonable range with a lower and an upper bound. 4.3 Summary Heuristic priorities serve as a management tool for designers during evaluation. They permit designers to focus upon the problems that are deemed most damaging to system s Heuristics Based On Object Oriented Metrics Page 64

13 maintainability. Design heuristics provide a vocabulary for common problems occurring in object oriented design documents. This chapter focused on two most popular metric suites for object oriented design. CK Metrics suite is the most popularly known metric suite for object oriented design which consist of Weighted Methods Per Class (WMC), Depth of Inheritance Tree (DIT), Number of Children (NOC), Coupling between Object Classes (CBO), Response for a Class (RFC), Lack of Cohesion in Methods (LCOM). MOOD metrics are another well known metrics suite for Object-Oriented design. Each metric is associated with important concepts of the object-oriented paradigm such as encapsulation (MHF and AHF), inheritance (MIF and AIF), polymorphism (PF) and association (CF). A wide variety of object oriented metrics have been proposed to assess the testability of an object oriented system. Most of the metrics focus on encapsulation, inheritance, class complexity and polymorphism. CK metrics suite is a set of six metrics which capture different aspects of an OO design and these metrics mainly focus on the class and the class hierarchy. CK metrics suite includes complexity, coupling and cohesion as well. On the other hand, MOOD metrics focus on system level which includes encapsulation, inheritance, polymorphism and message passing. Heuristics Based On Object Oriented Metrics Page 65