Design Metrics Software Engineering Fall 2003 Aditya P. Mathur Last update: October 28, 2003.
-
date post
19-Dec-2015 -
Category
Documents
-
view
219 -
download
2
Transcript of Design Metrics Software Engineering Fall 2003 Aditya P. Mathur Last update: October 28, 2003.
October 23, 2001 Design Metrics 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.
October 23, 2001 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)
October 23, 2001 Design Metrics 4
WMC
Let class C have methods M1, M2, .....Mn.
icLet denote the complexity of method
iM
∑=
=n
1ii
cWMC
How to measure WMC?
October 23, 2001 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.
October 23, 2001 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.
October 23, 2001 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.
October 23, 2001 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.
October 23, 2001 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.
October 23, 2001 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.
CBC of C=total number of other classes to which C is coupled.
Coupling is usually easy to identify though often pointers may make it difficult.
October 23, 2001 Design Metrics 11
Validation of CBC
Most classes are self contained and have CBC=0.
CBC is significant in predicting fault-proneness of classes.
Interface classes tend to have higher CBC values.
October 23, 2001 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.
October 23, 2001 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.
October 23, 2001 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.
October 23, 2001 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.
October 23, 2001 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
October 23, 2001 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)
October 23, 2001 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.
October 23, 2001 Design Metrics 22
Summary of OO metrics
SOURCE METRIC OO CONSTRUCT
Traditional Cyclomatic complexity (CC) MethodTraditional Lines of Code (LOC) MethodTraditional Comment percentage (CP) Method
NEW Weighted methods per class Class/MethodNEW Response for a class (RFC) Class/MessageNEW Lack of cohesion of methods (LCOM) Class/CohesionNEW Coupling between objects (CBC) CouplingNEW Depth of inheritance tree (DIT) InheritanceNEW Number of children (NOC) Inheritance
Ref: http://satc.gsfc.nasa.gov/support/STC_APR98/apply_oo/apply_oo.html