Software Engineering

1
Software Engineering

• Object Oriented Metrics

2
Objectives

1. To describe the distinguishing characteristics of
   Object-Oriented Metrics.
2. To introduce metrics suitable for design, testing
   and project management.
3. To focus on OO metrics at a class and method
   level.

3
Distinguishing Characteristics

• The following characteristics require that
  special OO metrics be developed
• Encapsulationthe packaging of data and
  processing. Conventional paradigms organize
  programs around data or function, OO does both.
  Concentrate on classes rather than functions.
• Information hidingthe way in which information
  about operational details is hidden by a secure
  interface. An information hiding metric will
  provide an indication of quality.
• Inheritancethe manner in which the
  responsibilities of one class are propagated to
  another. A pivotal indication of complexity.
• Abstractionthe mechanism that allows a design to
  focus on essential details. Metrics need to
  measure a class at different levels of
  abstraction and from different viewpoints.
• Conclusion the class is the fundamental unit of
  measurement.

4
CK Metrics Suite

• Weighted Methods per Class (WMC) Assume that n
  methods with cyclomatic complexity
  are defined for a class C
• Depth of the Inheritance Tree (DIT) The maximum
  length from a leaf to the root of the tree. Large
  DIT leads to greater design complexity but
  promotes reuse.
• Number of Children (NOC) Total number of
  children for each class. Large NOC may dilute
  abstraction and increase testing.
• Coupling between Object Classes (CBO) Total
  number of collaborations listed for each class in
  CRC cards. Keep COB low because high values
  complicate modification and testing.
• Response For a Class (RFC) Set of methods
  potentially executed in response to a message
  received by a class. High RFC implies test and
  design complexity.
• Lack of Cohesion in Methods (LCOM) Number of
  methods in a class that access one or more of the
  same attributes. High LCOM means tightly coupled
  methods.

5
Lorenz and Kidd Metrics

• Class Size (CS) total number of methods and
  attributes (both inherited and private)
  encapsulated by a class. Public methods and
  attributes are weighted more heavily. Large CS
  may imply too much responsibility.
• Number of Operations Overridden by a subclass
  (NOO) If many methods are replaced in a subclass
  this indicates a design problem. Specialization
  should lead to extension not replacement.
• Number of Operations Added by a subclass (NOA)
  Too many additional methods mean that a subclass
  is drifting away from its parent.
• Specialization Index (SI) A rough indication of
  the degree of specialization of a class. SI
  NOO x classlevel / totalmethods.

6
Method-Oriented Metrics

• Average Operation Size Number of messages sent
  by a method. Too many messages means that
  responsibilities have not been evenly
  distributed.
• Operation Complexity Cyclomatic complexity of a
  method. Strive to keep operation complexity low.
• Average Number of Parameters per Operation The
  larger the number of method parameters, the more
  complex the collaboration between objects.

7
Testability Metrics

• Encapsulation Related
• lack of cohesion in methods (LCOM) The higher
  the value of LCOM, the more states must be tested
  to ensure that methods do not generate side
  effects.
• Percent Public and Protected (PAP) Percentage of
  attributes that are public. Public attributes can
  be inherited and accessed externally. High PAP
  means more side effects.
• Public Access to Data members (PAD) Number of
  classes that access another classes attributes.
  Violates encapsulation.
• Inheritance Related
• Number of Root Classes (NRC) Count of distinct
  class hierarchies. Must all be tested separately.
• Fan In (FIN) The number of superclasses
  associated with a class. FIN gt 1 indicates
  multiple inheritance. Must be avoided.
• Number of Children (NOC) and Depth of Inheritance
  Tree (DIT) Superclasses need to be retested for
  each subclass.

8
Project Management Metrics

• Number of Scenario Scripts Number of use-cases
  is directly proportional the number of classes
  needed to meet requirements. A strong indicator
  of program size.
• Number of Key Classes A key class focuses
  directly on the business domain for the problem
  and is less likely to be implemented via reuse.
  Typically 20-40 of all classes are key, the rest
  support infrastructure (e.g. GUI, communications,
  databases).
• Number of Subsystems Provides insight into
  resource allocation, scheduling for parallel
  development and overall integration effort.