1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 24 Technical Metrics for Object-Oriented Systems

2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OO metrics have been introduced to help a software engineer use quantitative analysis to assess the quality of the design before a system is built. The focus of OO metrics is on the class—the fundamental building block of the OO architecture.

3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The first step in the measurement process is to derive the software measures and metrics that are appropriate for the representation of software that is being considered. Next, data required to derive the formulated metrics are collected. Once computed, appropriate metrics are analyzed based on pre-established guidelines and past data. The results of the analysis are interpreted to gain insight into the quality of the software, and the results of the interpretation lead to modification of work products arising out of analysis, design, code, or test.

4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The primary objectives for object-oriented metrics are no different than those for metrics derived for conventional software: to better understand the quality of the product to better understand the quality of the product to assess the effectiveness of the process to assess the effectiveness of the process to improve the quality of work performed at a project level to improve the quality of work performed at a project level

5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Distinguishing Characteristics of OO Metrics  Localization—the way in which information is concentrated in a program  Encapsulation—the packaging of data and processing Information hiding—the way in which information about operational details is hidden by a secure interface. A well-designed OO system should encourage information hiding. Therefore, metrics that provide an indication of the degree to which hiding has been achieved should provide an indication of the quality of the OO design. Inheritance—the manner in which the responsibilities of one class are propagated to another Because inheritance is a pivotal haracteristic in many OO systems, many OO metrics focus on it. Examples (discussed later in this chapter) include number of children (number of immediate instances of a class), number of parents (number of immediate generalizations), and class hierarchy nesting level (depth of a class in an inheritance hierarchy). Berard argues that the following characteristics require that special OO metrics be developed:

6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Abstraction—The mechanism that allows a design to focus on essential details. Because a class is an abstraction that can be viewed at many different levels of detail and in a number of different ways (e.g., as a list of operations, as a sequence of states, as a series of collaborations), OO metrics represent abstractions in terms of measures of a class (e.g., number of instances per class per application, number or parameterized classes per application, and ratio of parameterized classes to nonparameterized classes).

7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Metrics for OO Design  Size  Complexity  Coupling  Sufficiency  Completeness  Cohesion  Primitiveness  Similarity  Volatility

8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

9  Sufficiency - a design component (e.g., a class) is sufficient if it fully reflects all properties of the application domain object that it is modeling— that is, that the abstraction (class) possesses the features required of it.  Completeness considers multiple points of view. Because the criterion for completeness considers different points of view, it has an indirect implication about the degree to which the abstraction or design component can be reused.

10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001  Cohesion. Like its counterpart in conventional software, an OO component should be designed in a manner that has all operations working together to achieve a single, well-defined purpose  Primitiveness. A characteristic that is similar to simplicity, primitiveness (applied to both operations and classes) is the degree to which an operation is atomic—that is, the operation cannot be constructed out of a sequence of other operations contained within a class.

11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001  Similarity. The degree to which two or more classes are similar in terms of their structure, function, behavior, or purpose is indicated by this measure.  Volatility of an OO design component measures the likelihood that a change will occur.

12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class-Oriented Metrics  weighted methods per class  depth of the inheritance tree  number of children  coupling between object classes  response for a class  lack of cohesion in methods Proposed by Chidamber and Kemerer (): Proposed by Chidamber and Kemerer (CK Metrics):

13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001  Depth of the inheritance tree (DIT). This metric is “the maximum length from the node to the root of the tree”  As DIT grows, it is likely that lower-level classes will inherit many methods. This leads to potential difficulties when attempting to predict the behavior of a class. A deep class hierarchy (DIT is large) also leads to greater design complexity. On the positive side, large DIT values imply that many methods may be reused.

15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001  Lack of cohesion in methods (LCOM). Each method within a class, C, accesses one or more attributes (also called instance variables). LCOM is the number of methods that access one or more of the same attributes.4  If no methods access the same attributes, then LCOM = 0. To illustrate the case where LCOM ≠ 0, consider a class with six methods. Four of the methods have one or more attributes in common (i.e., they access common attributes). Therefore, LCOM = 4.  If LCOM is high, methods may be coupled to one another via attributes. This increases the complexity of the class design. In general, high values for LCOM imply that the class might be better designed by breaking it into two or more separate classes.  Although there are cases in which a high value for LCOM is justifiable, it is desirable to keep cohesion high; that is, keep LCOM low.

19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class-Oriented Metrics  class size  number of operations overridden by a subclass  number of operations added by a subclass  specialization index Proposed by Lorenz and Kidd]:

20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Metrics Proposed by Lorenz and Kidd Lorenz and Kidd divide class-based metrics into four broad categories: size, inheritance, internals, and externals. Size-oriented metrics for the OO class focus on counts of attributes and operations for an individual class and average values for the OO system as a whole. Inheritance-based metrics focus on the manner in which operations are reused through the class hierarchy. Metrics for class internals look at cohesion and code-oriented issues, and external metrics examine coupling and reuse.

21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Number of operations overridden by a subclass (NOO). There are instances when a subclass replaces an operation inherited from its superclass with a specialized version for its own use. This is called overriding. Large values for NOO generally indicate a design problem. As Lorenz and Kidd point out: Since a subclass should be a specialization of its superclasses, it should primarily extend the services [operations] of the superclasses. This should result in unique new method names. If NOO is large, the designer has violated the abstraction implied by the superclass. This results in a weak class hierarchy and OO software that can be difficult to test and modify.

23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

24 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

25 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001

26 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class-Oriented Metrics  Method inheritance factor (MIF)  Coupling factor (CF)  Polymorphism factor (PF) The MOOD Metrics Suite

27 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class-Oriented Metrics  The degree to which the class architecture of an OO system makes use of inheritance for both methods (operations) and attributes is defined as: MIF = Mi(Ci)/ Ma(Ci) MIF = Mi(Ci)/ Ma(Ci) where the summation occurs over i = 1 to TC. TC is defined as the total number of classes in the architecture, Ci is a class within the architecture, and where the summation occurs over i = 1 to TC. TC is defined as the total number of classes in the architecture, Ci is a class within the architecture, and Ma(Ci) = Md(Ci) + Mi(Ci) Ma(Ci) = Md(Ci) + Mi(Ci) Where Where Ma(Ci) = the number of methods that can be invoked in association with Ci. Ma(Ci) = the number of methods that can be invoked in association with Ci. Md(Ci) ) = the number of methods declared in the class Ci. Md(Ci) ) = the number of methods declared in the class Ci. Mi(Ci) = the number of methods inherited (and not overridden) in Ci. Mi(Ci) = the number of methods inherited (and not overridden) in Ci. Method inheritance factor (MIF)

28 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class-Oriented Metrics  The MOOD metrics suite defines coupling in the following way: CF = Σi Σj is_client (Ci, Cj)]/(TC2 TC)  where the summations occur over i = 1 to TC and j = 1 to TC. The function is_client = 1, if and only if a relationship exists between the client class, Cc, and the server class, Cs, and Cc ≠ Cs = 0, otherwise Coupling factor (CF)

29 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class-Oriented Metrics The MOOD metrics suite defines PF in the following manner: MIF = i Mo(Ci)/i [Mn(Ci) DC(Ci)] MIF = i Mo(Ci)/i [Mn(Ci) DC(Ci)] where the summations occur over i = 1 to TC and where the summations occur over i = 1 to TC and Md(Ci) = Mn(Ci) + Mo(Ci) Md(Ci) = Mn(Ci) + Mo(Ci)Also, Mn(Ci) = the number of new methods. Mo(Ci) = the number of overriding methods. DC(Ci) = the descendants count (the number of descendant classes of a base class). Polymorphism factor (PF)

30 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Operation-Oriented Metrics  average operation size:  operation complexity  average number of parameters per operation Proposed by Lorenz and Kidd [LOR94]:

31 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Testability Metrics  encapsulation related  lack of cohesion in methods  percent public and protected  public access to data members  inheritance related  number of root classes  fan in  number of children and depth of inheritance tree Proposed by Binder [BIN94]:

32 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OO Project Metrics  number of scenario scripts  number of key classes  number of subsystems Proposed by Lorenz and Kidd [LOR94]: