1 / 33

Object Oriented Metrics

Object Oriented Metrics. XP project group 30.08. – 08.10.2004 Saskia Schmitz. Contents. Why Metrics? Properties of Metrics Measurement, Validity, Usage Non OO Metrics OO Metrics GQM Paradigm Metric Suites Visualization Conclusion. Why Metrics?. goal: good software design  low costs

asoria
Download Presentation

Object Oriented Metrics

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. ObjectOrientedMetrics XP project group 30.08. – 08.10.2004 Saskia Schmitz

  2. Contents • Why Metrics? • Properties of Metrics • Measurement, Validity, Usage • Non OO Metrics • OO Metrics • GQM Paradigm • Metric Suites • Visualization • Conclusion object oriented software metrics

  3. Why Metrics? • goal: good software design low costs • small testing effort • low maintenance costs • many reusable fragments • definition of measurable criterions to distinguish „good“ from „bad“ design • use metrics to indicate source of „badness“ object oriented software metrics

  4. objective normative amenable to statistical analysis comparable repeatable consistent reliable useful valid Metrics: general properties object oriented software metrics

  5. Software metrics: properties • robust • prescriptive • computable (automatically + deterministically) • obtainable early in lifecycle • dimensionless or expressed in some unit system • nonsize metrics should be size independent • language independent object oriented software metrics

  6. Validity • theoretical soundness / „meaning“ of a measure: • how well does the measure cover the attribute? • how well are current and future situations estimated? • how general is the measure? object oriented software metrics

  7. Measurement • direct measurement: one independent attribute • indirect measurement: involves measurement of several attributes • Assessment measurement: current measure of an attribute • Predictive measurement: predicts future value of attribute A based on mathematical model relating A to current measure of attributes object oriented software metrics

  8. Usage • measured values… • do not hold „immediate“ information • do not imply a obvious recipe of what should be changed • threshold values („alarm“) • measured attributes should show values within certain ranges • empirically determined object oriented software metrics

  9. Non-OO Metrics • Size Metrics • Syntactical Structure Metrics • Logic Structure Metrics • Composite Metrics object oriented software metrics

  10. Lines of Code (LOC) • Advantages • easy to compute • applicable to all kinds of programs • Disadvantages • different possible counting methods • language and programmer dependent • no implications about maintainability or complexity object oriented software metrics

  11. Halstead Metrics • η¹ = number of unique operators • η² = number of unique operands • N¹ = total number of operators • N² = total number of operands • Difficulty • Volume • Effort E = V * D object oriented software metrics

  12. Halstead Metrics (2) • Advantages • easy to compute (scanner) • applicable for all languages • empirical studies: good measure for complexity • Disadvantages • only lexical / textual complexity • no namesspaces / visibility / … • language dependend object oriented software metrics

  13. Cyclomatic Complexity • control flow graph G • e = # edges • n = # vertices • p = # connected components • V(G) = e – n + 2p object oriented software metrics

  14. Cyclomatic Complexity (2) • rule of thumb: • begin restructuring your code with the component with highest V(G) object oriented software metrics

  15. Cyclomatic Complexity (3) • Advantages • easy to compute (parser) • empirical studies: good correlation between cyclomatic complexity and understandability • Disdvantages • only control flow • no data flow • may be inappropriate for OO programs (trivial functions) object oriented software metrics

  16. Composite Metrics • Problem • All introduced metrics are limited to one specific aspect in their ability to predict / measure software quality • Solution: • Combine these metrics to a new metric object oriented software metrics

  17. Maintainability Index (MI) • Combination of presented Metrics • V = average Halstead volume per module • V(G) = average cyclomatic complexity per module • LOC = average LOC per module • C = average percentage of comment lines MI = 171 – 5.2ln(V) – 0.23V(G) – 16.2ln(LOC) + 50sin√(2.4C) • high MI  good maintainability • MI < 30  code restructuring necessary object oriented software metrics

  18. OO Metrics • Measuring on class level • Coupling • Inheritance • Cohesion • Size • Structural Complexity • Measuring on package / higher level object oriented software metrics

  19. Measures of Coupling • Fan-Out / Coupling between Objects (CBO) • CBO(c) = #{class d | a method of class c calls a method or references a field of class d } • low CBO is desired  independent classes • Responce for Class (RFC) • RFC(c) = # methods of c (NLM) + # methods of other classes invoked by c (NRM, recursively) • measure of potential inter-class communication object oriented software metrics

  20. Measures of Coupling (2) • Message Passing Coupling • # send statements in a defined class (= number of procedure calls originating from a method in the class and going to other classes) object oriented software metrics

  21. Measuring Inheritance • Depth of Inheritance Tree (DIT) • high DIT has been found to increase faults • Number of Overridden Methods (NORM) • Specialization Index (SIX) • high value: specialisation sub-classing • low value: implementation sub-classing • Number of Children (NOC) • only immediate subclasses are counted • Number of Descendants (NOD) • all subclasses are counted object oriented software metrics

  22. Measuring Inheritance (2) • Reuse Ratio • value near 1: linear hierarchy  poor design • value near 0: shallow depth • Specialization Ratio • value near 1: poor design • high value: good capture of abstractions in superclasses object oriented software metrics

  23. Cohesion Metrics • Lack of Cohesion of Methods (LCOM) • NOMAF = number of methods that access a field • LCOM*: • value of 0: perfect cohesion • value of 1: complete lack of cohesion  split class • value >1: there is a field in C that is never used by a method of C object oriented software metrics

  24. Size Metrics • Number of Fields (NOF) • Number of Methods (NOM) • variations: consider only private / public / inherited / declared / … object oriented software metrics

  25. Structural Metrics • Weighted Methods per Class (WMC) • good predictor of how much time / effort is required to implement / maintain the class • variant: use size of method as weight object oriented software metrics

  26. Metrics on higher levels • Identify groups of highly cohesive classes (=„categories“) and measure: • Afferent Couplings CA: #classes outside category that depend on classes within category • Efferent Couplings CE: #classes outside category on which a class inside the category depend(1) • Instability I: • Abstractness A: (1) dsp, 30.11.05, corrected. Wrong defintion in the original better. Better defintion in later ones. object oriented software metrics

  27. well balanced categories are on „main sequence“ Distance D: D = | A + I – 1 |  restructure any category not near main sequence Design Quality Metric object oriented software metrics

  28. GQM Approach • List major Goals of measurement • From each goal derive the Questions that must be answered to determine if the goals are met. • Decide what Metrics must be collected in order to answer the questions. object oriented software metrics

  29. Metric Suites: Chidamber & Kemerer • includes WMC, DIT, NOC, CBO, RFC, LCOM • Advantages • OO Design is considered • NOC and RFC give some ideas as to budgeting for testing a class • Drawbacks • no good size and effort estimation • focus on design phase, not planning phase object oriented software metrics

  30. Metrics Suite: MOOD • Attribute Hiding Factor (AHF) • ideally 100 % • Method Hiding Factor (MHF) • low: insufficient abstraction • high: little functionality • Attribute Inheritance Factor (AIF) • Method Inheritance Factor (MIF) • AIF and MIF should be within acceptable range, neither too high nor too low object oriented software metrics

  31. MOOD • Polymorphism Factor (PF) • should be within acceptable range • Coupling Factor (CF) • high CF values should be avoided • MOOD conclusion • designed to measure overall quality of an OO project • not appropriate for projects relying mostly on forms and standard modules object oriented software metrics

  32. Visualize Metrics Results • Class Blueprint • Elements of a class are graphically represented as boxes • Their shape, size and color reflect semantical information. • The two dimensions of the box are given by two metrics object oriented software metrics

  33. Conclusion • Remaining problems: • metrics may not be valid in specific project • we need unambiguous interpretation for software metrics (individual result / result sets) to evaluate design • we need a transformation from design rules  measure, which would immediately lead to • recovery of design info • localization of design problems object oriented software metrics

More Related