Object metrics

1
Object metrics

• CONTENTS
• Definition of metric
• Usefulness of metrics
• Factors of quality
• Object metrics The CK Metrics Suite
• Example tool
• Problems Conclusions

2
What is a metric?

• Metric is a quantitative measure of the degree
  to which a system, component, or process
  possesses a given attribute (IEEE term
  definition)
• Metric measurement of an attribute or computed
  value from several attributes
• There is metrics for processes, projects and
  products. My focus is on product metrics
• Given software design (e.g. UML chart) or source
  code, what can we say about its quality?

3
What is a metric?

• Applying metric gives numeric value for some
  property as a result, but that alone is not
  useful in general
• Every metric model should define
• how it should be measured
• limits what does measured values mean (what is
  good/bad)
• information about how metric is used to improve
  software quality
• relation with quality factors
• what can be done with software to improve result

4
What is a metric?
5
Why metrics should be used?

• Metrics give us objective information about
  properties of software, e.g. structure and
  complexity of the design
• That information can be used to
• evaluate software quality
• estimate duration, costs etc. of software project
• evaluate development of software engineering
  process within company
• Metrics should be used as thresholds or
  indicators of concern, not as absolute measures
  of quality
• Metrics can help us to identify modules which
• would benefit from code reviews
• might be difficult to test and maintain
• violate standards

6
External internal factors of quality

7
Internal characteristics

• External characteristics are difficult to measure
  directly
• Internal characteristics are measurable and can
  be used as indicators for externals!
• Some internal characteristics
• size number of lines in a method, number of
  methods in a class, etc.
• complexity of method how many test cases are
  needed to test it comprehensively
• cohesion do the attributes and methods in a
  class achieve a single well-defined purpose?
• coupling number of connections between classes

8
Object orientation

• Modeling of real-world concepts
• Encapsulation data functions related to given
  concept within same module (class)
• Information hiding private data public
  operations to use data
• Inheritance subclass inherits all properties of
  its superclass
• Polymorphism instance of a superclass can be
  replaced with an instance of its subclass
• Connections between concepts message passing

9
Object metrics

• Some of traditional metrics are useful with oo
  software
• size measures for methods and classes
• complexity measures for methods
• comment percentage
• But new metrics are necessary for oo features
  (inheritance, polymorphism, etc.)
• Metrics suite set of metrics to measure
  different aspects of software. E.g.
• MOOD (Metrics for Object Oriented Design)
• The CK Metrics Suite (Chidamber Kemerer)
• Metrics Proposed by Lorenz and Kidd

10
The CK Metrics Suite (1994)

• One of most referenced set of metrics
• Six metrics measuring class size and complexity,
  use of inheritance, coupling between classes,
  cohesion of a class and collaboration between
  classes

11
CK_1 Weighted Methods per Class (WMC)

• Number of methods weighted by their procedural
  complexity (complexity of class). Using unity
  weights gives simply number of methods in a
  class.
• WMC is indicator of the amount of effort required
  to implement and test a class.
• As the number of methods for a class grows, it is
  likely to become more application specific and
  thus limiting possibilities for reuse
• High WMC value means also greater potential
  impact on children
• Difficult to set exact limits for metric, but WMC
  should be kept as low as possible
• High WMC values -gt split class
• Easy to measure, but should we count inherited
  methods too?

12
CK_2 Lack of Cohesion in Methods (LCOM)

• Cohesion measures togetherness of a class high
  cohesion means good class subdivision
  (encapsulation)
• LCOM counts the sets of methods that are not
  related through the sharing of some of the
  classs instance variables
• LCOM normalized version, range of values between
  0..1
• LCOM 0 if every method uses all instance
  variables
• LCOM 1 if every method uses only one instance
  variable
• High values of LCOM indicate scatter in the
  functionality provided by a class, i.e. class
  attempts to provide many different objectives
• Classes with high LCOM can be fault-prone and are
  likely to behave less predictable ways than
  classes with low LCOM
• High LCOM -gt split class

13
CK_2 Lack of Cohesion in Methods (LCOM)

• Problems with LCOM
• Gives equal values for very different classes
• Classes with getters setters (getProperty(),
  setProperty()) get high LCOM values although this
  is not an indication of a problem
• Dont even try to measure logical cohesion

14
CK_3 Response For a Class (RFC)

• Number of methods that can be invoked in response
  to a message
• Measure of potential communication between
  classes
• Often computed simply by counting number of
  method calls at classs method bodies (computing
  full transitive closure of each method is slow)
• Complexity of the class increases and
  understandability decreases as RFC grows
• Testing gets harder as RFC grows (better
  understanding required from a tester)
• RFC can be used as indicator of required testing
  time
• High RFC -gt there could be a better class
  subdivision (e.g. merge classes)

15
CK_4 Depth of Inheritance Tree (DIT)

• Maximum height of inheritance tree or level of a
  particular class in a tree
• As DIT grows, it is likely that classes on lower
  level inherits lots of methods and overrides
  some. Thus predicting behavior for an object of a
  class becomes difficult.
• Large DIT means greater design complexity
• DIT also measures reuse via inheritance
• High or low values of DIT might indicate problems
  with domain analysis

16
CK_5 Number Of Children (NOC)

• Number of immediate subclasses for a class
• Indicator of potential influence that class has
  on design
• High value of NOC might indicate misuse of
  subclassing (implementation inheritance instead
  of is-a relationship)
• Class with very high NOC might be a candidate for
  refactoring to create more maintainable hierarchy
• NOC is also measure of reuse via inheritance
• NOC can be used as indicator of required testing
  time

17
CK_6 Coupling Between Objects (CBO)

• coupling class x is coupled to class y iff x
  uses ys methods or instance variables (includes
  inheritance related coupling)
• CBO for a class is a count of the number of other
  classes to which it is coupled
• High coupling between classes means modules
  depend on each other too much
• Independent classes are easier to reuse and
  extend
• High coupling decreases understandability and
  increases complexity
• High coupling makes maintenance more difficult
  since changes in a class might propagate to other
  parts of software
• Coupling should be kept low, but some coupling is
  necessary for a functional system

18
Some other oo metrics

• Method Inheritance Factor (MIF) ratio of
  inherited methods to all methods in a system.
  MIF0 means inheritance mechanism is not used.
  Measure of reuse via inheritance.
• Number of overridden operations (NOO). High value
  of NOO is indication of a design problem. Since
  subclass should be a specialization of its
  superclass, it should primarily extend the
  operations of its superclass, not replace them.
• Attribute Hiding Factor (AHF) ratio of invisible
  (protectedprivate) attributes to all attributes
  (publicprotectedprivate). Ideally AHF should be
  1, meaning there is no public attributes.
  Measures the degree of information hiding. (In
  Java protected attributes are visible to classes
  in the same package and thus formula is not
  valid)

19
Example tool JStyle

• Automatic code reviewer
• Checks for style, allows defining own coding
  conventions
• Computes many traditional and object metrics
• size classes, methods/class,
  statements/method
• complexity cyclomatic complexity of methods,
  WMC, bugs predicted
• commenting comment lines/file, comment density
• inheritance reuse specialization ratio, av..
  inheritance depth, DIT, NOC
• Gives knowledge about project without need to
  inspect code

20
Example tool JStyle
21
Example tool JStyle
22
Problems with current object metrics

• Classes are designed for different purposes GUI,
  collections, data records, etc. -gt same limits
  for metrics dont apply!
• Classes should be divided into categories and
  give different ranges of metrics objective
  values for each
• Difficulty with limits dependencies with problem
  domain, programming language, etc.
• Definition of metric is often insufficient, e.g.
  what can be done to improve results
• Are we measuring what we think we are? E.g. LCOM?
• Lack of standards
• Many measures for same property, which one to
  use?

23
Conclusions

• Metrics can be useful indicators of unhealthy
  code and design, pointing out areas where
  problems are likely to occur
• Unfortunately good metric results doesnt
  necessarily imply good quality of software
• Metrics are easily collected automatically
  without laborious inspection of source code
• Metrics cant reveal semantic errors of domain
  analysis, but structural misuse of oo constructs
  can be seen

24
References

• Brian Henderson-Sellers. 1996. Object-oriented
  metrics Measures of complexity. Prentice Hall.
• Roger S. Pressman. 2000. Software Engineering A
  Practitioners Approach. McGraw-Hill
  International.
• Chidamber and Kemerer. 1994. A Metrics Suite for
  Object Oriented Design. IEEE Transactions On
  Software Engineering, vol. 20, no. 6, June 1994.
• Marko Mattila. 2003. Oliometriikat ja hyvien
  olio-ohjelmien ominaisuudet. Pro gradu, TY.
• Linda H. Rosenberg. 1998. Applying and
  Interpreting Object Oriented Metrics.
  http//satc.gsfc.nasa.gov/support/STC_APR98/apply_
  oo/apply_oo.html
• JStyle. www.mmsindia.com