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

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

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

4. October 23, 2001Design Metrics4 WMC zLet class C have methods M1, M2,.....Mn. zLet denote the complexity of method zHow to measure WMC?

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

6. October 23, 2001Design Metrics6 Depth of inheritance tree (DIT) zDepth 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. zInheritance increases coupling. Changing classes becomes harder. zDepth of Inheritance (DIT) of class C is the length of the shortest path from the root of the inheritance tree to C. zIn the case of multiple inheritance DIT is the maximum length of the path from the root to C.

7. October 23, 2001Design Metrics7 DIT evaluation zBasili et al. study,1995. zChidamber and Kemerer study, 1994. 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.

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

9. October 23, 2001Design Metrics9 Validation of NOC zClasses generally have a small NOC value. zVast majority have NOC=0. zLarger NOC value is associated with lower probability of detecting faults in that class.

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

11. October 23, 2001Design Metrics11 Validation of CBC zMost classes are self contained and have CBC=0. zCBC is significant in predicting fault-proneness of classes. zInterface classes tend to have higher CBC values.

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

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

14. October 23, 2001Design Metrics14 Lack of cohesion in methods (LCOM) [1] zLet I1 and I2 denote sets of instance variables accessed by methods M1 and M2, respectively, in class C. zM1 and M2 are considered similar, or cohesive, if I1 and I2 are not disjoint. zLet Q be the set of all cohesive method pairs. zLet P be the set of all non-cohesive method pairs. zLCOM=|P| - |Q| if |P| > |Q|, 0 otherwise.

15. October 23, 2001Design Metrics15

16. October 23, 2001Design Metrics16 LCOM [2] zA larger number of cohesive pairs implies smaller LCOM. zA 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. zLCOM is not found to be very significant in predicting fault-proneness.

17. October 23, 2001Design Metrics17 Guidelines for interpretation [1] Ref: http://satc.gsfc.nasa.gov/support/STC_APR98/apply_oo/apply_oo.html METRICOBJECTIVE Cyclomatic ComplexityLow Lines of Code/Executable StatementsLow Comment Percentage~ 20 – 30 % Weighted Methods per ClassLow Response for a ClassLow

18. October 23, 2001Design Metrics18 Guidelines for interpretation [2] METRICOBJECTIVE Lack of Cohesion of Methods Cohesion of Methods/Low/ High Coupling Between ObjectsLow Depth of InheritanceLow (trade-off) Number of ChildrenLow (trade-off)

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

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

21. October 23, 2001Design Metrics21 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.

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