Design Metrics Software Engineering Fall 2003 Aditya P

Design Metrics Software Engineering Fall 2003 Aditya P. Mathur Last update: October 28, 2003 October 23, 2001 Design Metrics

Design Metrics z Design Metrics are useful in measuring the complexity and “goodness” of a design. z A large number metrics have been proposed for OO designs. z Some of these have been validated experimentally, others are mere proposals or have received little or no validation. October 23, 2001 Design Metrics 2

Effort z Assumption: The effort in developing a class is determined by the number of methods. z Hence the overall complexity of a class can be measured as a function of the complexity of its methods. Proposal: Weighted Methods per class (WMC) October 23, 2001 Design Metrics 3

WMC z Let class C have methods M 1, M 2, . . . Mn. z. Let denote the complexity of method z How to measure WMC? October 23, 2001 Design Metrics 4

WMC: validation z Most classes tend to have a small number of methods, are simple, and provide some specific abstraction and operations. z WMC metric has a reasonable correlation with fault-proneness of a class. October 23, 2001 Design Metrics 5

Depth of inheritance tree (DIT) z Depth of a class in a class hierarchy determines potential for re-use as more methods are available. Deeper classes have higher potential for re-use though are more complex. z Inheritance increases coupling. Changing classes becomes harder. z Depth of Inheritance (DIT) of class C is the length of the shortest path from the root of the inheritance tree to C. z In the case of multiple inheritance DIT is the maximum length of the path from the root to C. October 23, 2001 Design Metrics 6

DIT evaluation z Basili et al. study, 1995. z Chidamber and Kemerer study, 1994. • • October 23, 2001 Most classes tend to be close to the root. Maximum DIT value found to be 10. Most classes have DIT=0. DIT is significant in predicting error proneness of a class. Higher DIT leads to higher error-proneness. Design Metrics 7

Number of children (NOC) z NOC is the number of immediate subclasses of C. z Higher values of NOC suggest reuse of the definitions in the super-class in a larger number of subclasses. z Higher NOC suggests the extent of influence of a class on other elements of a design. Higher influence demands higher quality of that class. October 23, 2001 Design Metrics 8

Validation of NOC z Classes generally have a small NOC value. z Vast majority have NOC=0. z Larger NOC value is associated with lower probability of detecting faults in that class. October 23, 2001 Design Metrics 9

Coupling between classes (CBC) z Class C 1 is coupled to class C 2 if at least one method of C 1 uses a method or an instance variable of C 2. z Coupling is usually easy to identify though often pointers may make it difficult. z CBC of C=total number of other classes to which C is coupled. October 23, 2001 Design Metrics 10

Validation of CBC z Most classes are self contained and have CBC=0. z Interface classes tend to have higher CBC values. z CBC is significant in predicting fault-proneness of classes. October 23, 2001 Design Metrics 11

Response for a class (RFC) z Response set of class C is the total number of methods that can be invoked when a message is sent to an object of C. y This includes all methods of C and any methods executed outside of C as a result of this message. z RFC of class C is the cardinality of the response set of C. z Note that even when CBC=1 RFC may be high. This indicates that the “volume” of interaction is high. October 23, 2001 Design Metrics 12

Validation of RFC z Most classes tend to invoke a small number of methods (low RFC values). z Classes for interface objects tend to have larger RFC values. z RFC is very significant in predicting the fault-proneness of a class. October 23, 2001 Design Metrics 13

Lack of cohesion in methods (LCOM) [1] z Let I 1 and I 2 denote sets of instance variables accessed by methods M 1 and M 2, respectively, in class C. z M 1 and M 2 are considered similar, or cohesive, if I 1 and I 2 are not disjoint. z Let Q be the set of all cohesive method pairs. z Let P be the set of all non-cohesive method pairs. z LCOM=|P| - |Q| if |P| > |Q|, 0 otherwise. October 23, 2001 Design Metrics 14

October 23, 2001 Design Metrics 15

LCOM [2] z A larger number of cohesive pairs implies smaller LCOM. z A high value of LCOM suggests that a class is trying to support multiple abstractions. Perhaps the class needs to be partitioned into smaller and more cohesive classes. z LCOM is not found to be very significant in predicting fault-proneness. October 23, 2001 Design Metrics 16

Guidelines for interpretation [1] Ref: http: //satc. gsfc. nasa. gov/support/STC_APR 98/apply_oo. html METRIC OBJECTIVE Cyclomatic Complexity Low Lines of Code/Executable Statements Low Comment Percentage ~ 20 – 30 % Weighted Methods per Class Low Response for a Class Low October 23, 2001 Design Metrics 17

Guidelines for interpretation [2] METRIC OBJECTIVE Lack of Cohesion of Methods/ Low/ High Coupling Between Objects Low Depth of Inheritance Low (trade-off) Number of Children Low (trade-off) October 23, 2001 Design Metrics 18

Guidelines for interpretation [3] October 23, 2001 Design Metrics 19

Guidelines for interpretation [4] October 23, 2001 Design Metrics 20

Guidelines for interpretation [5] Almost 66% of this project’s classes are below other classes in the tree, which indicates a moderate level of reuse. Higher percentages for DIT’s of 2 and 3 would show a higher degree of reuse, but increased complexity. October 23, 2001 Design Metrics 21

Summary of OO metrics Ref: http: //satc. gsfc. nasa. gov/support/STC_APR 98/apply_oo. html SOURCE METRIC Traditional Cyclomatic complexity (CC) Lines of Code (LOC) Comment percentage (CP) NEW NEW NEW Weighted methods per class Class/Method Response for a class (RFC) Class/Message Lack of cohesion of methods (LCOM) Class/Cohesion Coupling between objects (CBC) Coupling Depth of inheritance tree (DIT) Inheritance Number of children (NOC) Inheritance October 23, 2001 Design Metrics OO CONSTRUCT Method 22