1 / 32

Chapter 24 Technical Metrics for Object-Oriented Systems

Chapter 24 Technical Metrics for Object-Oriented Systems. 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.

marion
Télécharger la présentation

Chapter 24 Technical Metrics for Object-Oriented Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 24Technical Metrics forObject-Oriented Systems

  2. 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. 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. 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 assess the effectiveness of the process • to improve the quality of work performed at a project level

  5. Distinguishing Characteristics of OO Metrics Berard argues that the following characteristics require that special OO metrics be developed: • 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).

  6. 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. Metrics for OO Design • Size • Complexity • Coupling • Sufficiency • Completeness • Cohesion • Primitiveness • Similarity • Volatility

  8. 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.

  9. 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.

  10. 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.

  11. Class-Oriented Metrics Proposed by Chidamber and Kemerer (CK 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

  12. 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.

  13. 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.

  14. Class-Oriented Metrics Proposed by Lorenz and Kidd]: • class size • number of operations overridden by a subclass • number of operations added by a subclass • specialization index

  15. 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.

  16. 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.

  17. Class-Oriented Metrics The MOOD Metrics Suite • Method inheritance factor (MIF) • Coupling factor (CF) • Polymorphism factor (PF)

  18. Class-Oriented Metrics Method inheritance factor (MIF) • 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) 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) Where 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. Mi(Ci) = the number of methods inherited (and not overridden) in Ci.

  19. Class-Oriented Metrics Coupling factor (CF) • 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

  20. Class-Oriented Metrics Polymorphism factor (PF) The MOOD metrics suite defines PF in the following manner: MIF = i Mo(Ci)/i [Mn(Ci) DC(Ci)] where the summations occur over i = 1 to TC and 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).

  21. Operation-Oriented Metrics Proposed by Lorenz and Kidd [LOR94]: • average operation size: • operation complexity • average number of parameters per operation

  22. Testability Metrics Proposed by Binder [BIN94]: • 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

  23. OO Project Metrics Proposed by Lorenz and Kidd [LOR94]: • number of scenario scripts • number of key classes • number of subsystems

More Related