Object Oriented Metrics

    How should we judge code?

●   1994 - Chidamber & Kemerer
●   A Metrics suite for Object Oriented design
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
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
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
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
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
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
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
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
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
A metric of your own

●   http://metric-fu.rubyforge.org/

●   http://getcaliper.com/
metric_fu

●   Saikuro, Flog → complexity
●   Flay          → duplication
●   Roodi, Reek   → code smells
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
Using metric_fu

In → lib/tasks/metric_fu.rake


  require 'metric_fu'
  config from
    http://metric-fu.rubyforge.org/
Using metric_fu

●   bundle install

●   bundle exec rake metrics:all
Let's go have a look
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
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      .

OO Metrics

  • 1.
    Object Oriented Metrics How should we judge code? ● 1994 - Chidamber & Kemerer ● A Metrics suite for Object Oriented design
  • 2.
    What did theysay? 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 PerClass 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 InheritanceTree 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 ObjectClasses 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 aClass 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 Cohesionof 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 reallymatter? 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 ofyour 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.
  • 17.
    What should youdo? ● 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 .