Design Metrics Software Engineering Fall 2003

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

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

3. Effort • Assumption: The effort in developing a class is determined by the number of methods. • 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) Design Metrics

4. Let denote the complexity of method WMC • Let class C have methods M1, M2, .....Mn. • How to measure WMC? Design Metrics

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

6. Depth of inheritance tree (DIT) • 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. • Inheritance increases coupling. Changing classes becomes harder. • Depth of Inheritance (DIT) of class C is the length of the shortest path from the root of the inheritance tree to C. • In the case of multiple inheritance DIT is the maximum length of the path from the root to C. Design Metrics

7. DIT evaluation • Basili et al. study,1995. • Chidamber 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. Design Metrics

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

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

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

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

12. Response for a class (RFC) • 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. • This includes all methods of C and any methods executed outside of C as a result of this message. • RFC of class C is the cardinality of the response set of C. • Note that even when CBC=1 RFC may be high. This indicates that the “volume” of interaction is high. Design Metrics

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

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

15. Design Metrics

16. LCOM [2] • A larger number of cohesive pairs implies smaller LCOM. • 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. • LCOM is not found to be very significant in predicting fault-proneness. Design Metrics

17. Guidelines for interpretation [1] Ref: http://satc.gsfc.nasa.gov/support/STC_APR98/apply_oo/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 Design Metrics

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

19. Guidelines for interpretation [3] Design Metrics

20. Guidelines for interpretation [4] Design Metrics

21. 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. Design Metrics

22. Summary of OO metrics Ref: http://satc.gsfc.nasa.gov/support/STC_APR98/apply_oo/apply_oo.html SOURCE METRIC OO CONSTRUCT Traditional Cyclomatic complexity (CC) Method Traditional Lines 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 Design Metrics