Brief discussion of the original Chidamber & Kemerer OO metrics.

1. Object Oriented Metrics
How should we judge code?
● 1994 - Chidamber & Kemerer
● A Metrics suite for Object Oriented design

2. What did they say?
WMC Weighted Methods Per Class
DIT Depth of Inheritance Tree
NOC Number of Children
CBO Coupling between Object Classes
RFC Response for a Class
LCOM Lack of Cohesion of Methods

3. Weighted Methods Per Class
Number of methods defined in class
● Complex methods weigh more
● Higher numbers = more faults
● Classes are more specific = hard to reuse
● Changes have more impact on subclasses
20-40 methods; 10% of classes > 24

4. Depth of Inheritance Tree
Number of superclasses
● Measures depth of hierarchy
● Deep trees imply more complexity
● Inheritance should reduce complexity not increase it
● Deep trees promote reuse
● Bugs are found in middle of tree
5 or less; some say 8 or less

5. Number of Children
Number of immediate subclasses
● Measures breadth of hierarchy
● Depth (DIT) implies reuse in a way breath (NOC) does not
● Large numbers mean high reuse of base class; test it!
● High NOC related to lower faults.
● BUT, perhaps improper use of base class
High NOC + high WMC; complexity at top

6. Coupling between Object Classes
Number of classes to which I am coupled
● Coupling → We use each others data or methods
● High CBO is undesirable
● Prevents reuse
● Sensitivity to changes in others increases maintenance
> 14 is too high

7. Response For a Class
Total number of methods executed
● Large RFC = more faults
● If most methods have a small RFC but one method has a
hugh RFC
→ you have a structured (not OO) application
Concentrate tests on high RFC methods

8. Lack of Cohesion of Methods
How well are the methods of a class are
related to each other?
● A cohesive class performs one function
● Highly cohesive classes promotes encapsulation
but have highly coupled methods
● Low cohesion = more errors
Measured by checking use of instance vars

9. Does these really matter?
Research says they do:
● 1995 - Victor Basili, etc – University of Maryland
● A Validation of Object-Oriented Design
Metrics
● 2001 – Victor Laing – SATC study at NASA
● Principal Components of Orthogonal
Object-Oriented Metrics

10. NASA Study
● A - Java. 50K LOC, 46 classes, lowq
● B - Java, 300k LOC, 1,000 classes, highq
● C - C++, 500K LOC, 1,617 classes, mediumq
Result: Bad metrics = faulty applications

11. A metric of your own
● http://metric-fu.rubyforge.org/
● http://getcaliper.com/

12. metric_fu
● Saikuro, Flog → complexity
● Flay → duplication
● Roodi, Reek → code smells

13. Using metric_fu
Gemfile . . .
group :test do
gem 'cucumber', '0.4.3'
...
gem 'metric_fu', '1.3.0'
gem 'reek'
gem 'roodi'
gem 'googlecharts'
end

14. Using metric_fu
In → lib/tasks/metric_fu.rake
require 'metric_fu'
config from
http://metric-fu.rubyforge.org/

15. Using metric_fu
● bundle install
● bundle exec rake metrics:all

16. Let's go have a look

17. What should you do?
● Run metric_fu on your new apps
get insight into the choices you're making
keep yourself honest
● Run metric_fu on existing apps
concentrate testing at boundaries of suspect code
protect yourself

18. References
● http://www.pitt.edu/~ckemerer/CK research
papers/MetricForOOD_ChidamberKemerer94.pdf .
● http://www.cs.umd.edu/users/basili/publications/journals/
J60.pdf .
● http://satc.gsfc.nasa.gov/support/OSMASAS_SEP01/Princip
al_Components_of_Orthogonal_Object_Oriented_Met
rics.pdf .
● http://www.aivosto.com/project/help/pm-oo-ck.html .