Overview

This chapter discusses the use of metrics to assess the quality o object-oriented software. Software engineers need objective criteria to guide the OO system design and object design. Testers need quantitative guidance to help in selecting test cases and their targets. OO technical metrics can provide this guidance. As in the use of metrics in conventional software development, the first step in the OO measurement process is to derive measures and metrics that are appropriate to the software representation under consideration. The next step is to collect the necessary data and compute the metrics. Once computed, metrics are analyzed based on pre-established guidelines and historical data. The results of the analysis are interpreted to gain insight into the quality of the software and modifications to work products from OOA, OOD, OOP, or OOT may be made.

Goals for Using Object-Oriented Metrics

• To better understand product quality
• To assess process effectiveness
• To improve quality of the work performed at the project level

Distinguishing Characteristics of Object-Oriented Metrics

• Localization - OO metrics need to apply to the class as a whole and should reflect the manner in which classes collaborate with one another
• Encapsulation - OO metrics chosen need to reflect the fact that class responsibilities, attributes, and operations are bound as a single unit
• Information hiding -OO metrics should provide an indication of the degree to which information hiding has been achieved
• Inheritance - OO metrics should reflect the degree to which reuse of existing classes has been achieved
• Abstraction - OO metrics represent abstractions in terms of measures of a class (e.g. number of instances per class per application)

Object-Oriented Design Model Metrics

• Size(population, volume, length, functionality)
• Complexity (how classes interrelate to one another)
• Coupling (physical connections between design elements)
• Sufficiency (how well design components reflect all properties of the problem domain)
• Completeness (coverage of all parts of problem domain)
• Cohesion (manner in which all operations work together)
• Primitiveness (degree to which attributes and operations are atomic)
• Similarity (degree to which two or more classes are alike)
• Volatility (likelihood a design component will change)

Class-Oriented Metrics

• Chidamber and Kemerer (CK) Metrics Suite

• weighted metrics per class (WMC)
• depth of inheritance tree (DIT)
• number of children (NOC)
• coupling between object classes (CBO)
• response for a class(RFC)
• lack of cohesion in methods (LCOM)

• Lorenz and Kidd

• class size (CS)
• number of operations overridden by a subclass (NOO)
• number of operations added by a subclass (NOA)
• specialization index (SI)

• Harrison, Counsel, and Nithi (MOOD) Metrics Suite

• method inheritance factor (MIF)
• coupling factor (CF)
• polymorphism factor (PF)

Operation-Oriented Metrics

• Average operation size (OSavg)
• Operation complexity (OC)
• Average number of parameters per operation (NPavg)

Object-Oriented Testing Metrics

• Encapsulation

• lack of cohesion in methods (LCOM)
• percent public and protected (PAP)
• public access to data members(PAD)

• Inheritance

• number of root classes (NOR)
• fan in (FIN)
• number of children (NOC)
• depth of inheritance tree (DIT)

• Class complexity

• weighted metrics per class(WMC)
• coupling between object classes (CBO)
• response for a class (RFC)

Object-Oriented Product Metrics

• Number of scenario scripts (NSS)
• Number of key classes (NKC)
• Number of subsystems(NSUB)