Software Design & Evolution. Lecture 04. You cannot control what you cannot measure. Metrics & Problem Detection. Michele Lanza

Transcription

1 Software Design & Evolution Lecture 04 Michele Lanza Metrics & Problem Detection Metrics? Don t trust them Michele Lanza & Radu Marinescu Object-Oriented Metrics in Practice Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems Springer, 2006 You cannot control what you cannot measure Galileo Galilei ( )

2 Metrics are functions Metrics are functions that assign numbers to products, processes, and resources Metrics are functions that assign numbers to products, processes, and resources Software metrics are measurements which relate to software systems, processes, or related documents

3 Size Metrics Metrics compress system traits into numbers Let s see some examples.. NOM NOA LOC NOS NOC NOC Number of Methods Number of Attributes Number of Lines of Code Number of Statements Number of Children Number of Classes Chidamber & Kemerer, 1994 Lorenz & Kidd, 1994 Mc Cabe s Cyclomatic Complexity counts the number of independent paths through the code of a function Weighted Method Count (WMC) sums up the complexity of a class methods (measured by the metric of your choice, usually CYCLO) It reveals the minimum number of tests to write Its interpretation does not directly lead to improvement actions It is configurable, thus adaptable to our precise needs Its interpretation does not directly lead to improvement actions Mc Cabe, 1976 Chidamber & Kemerer, 1994

4 Depth of Inheritance Tree (DIT) is the maximum depth level of a class hierarchy Coupling between objects (CBO) shows the number of classes from which methods or attributes are used Inheritance is measured Only the potential, not the real impact is quantified Takes into account real dependencies, not just declared ones No differentiation of types and/or intensity of coupling Chidamber & Kemerer, 1994 Chidamber & Kemerer, 1994 Tight Class Cohesion (TCC) counts the relative number of method pairs that access attributes of the class in common Interpretation can lead to improvement action TCC = 2 / 10 = Ratio values allow comparison between classes and systems Bieman & Kang, 1998

5 Suitability Accurateness Functionality Interoperability Compliance Security Maturity This is the essential Functionality characteristic and refers to the appropriateness (to specification) of the functions of the software. This refers to the correctness of the functions, an ATM may provide a cash dispensing function but is the amount correct? A given software component or system does not typically function in isolation. This subcharacteristic concerns the ability of a software component to interact with other components or systems. Where appropriate certain industry (or government) laws and guidelines need to be complied with, i.e. SOX. This subcharacteristic addresses the compliant capability of software. This subcharacteristic relates to unauthorized access to the software functions. This subcharacteristic concerns frequency of failure of the software. Reliability Fault Tolerance The ability of software to withstand (and recover) from component, or environmental, failure. Recoverability Understandability Ability to bring back a failed system to full operation, including data and network connections. Determines the ease of which the systems functions can be understood, relates to user mental models in Human Computer Interaction methods. Usability Learnability Learning effort for different users, i.e. novice, expert, casual etc. Operability Ability of the software to be easily operated by a given user in a given environment. Efficiency Time behavior Characterizes response times for a given thru put, i.e. transaction rate. Resource behavior Characterizes resources used, i.e. memory, cpu, disk and network usage. Analyzability Changeability Maintainability Stability Testability Adaptability Characterizes the ability to identify the root cause of a failure within the software. Characterizes the amount of effort to change a system. Characterizes the sensitivity to change of a given system that is the negative impact that may be caused by system changes. Characterizes the effort needed to verify (test) a system change. Characterizes the ability of the system to change to new specifications or operating environments. Portability Installability Conformance Replaceability Characterizes the effort required to install the software. Similar to compliance for functionality, but this characteristic relates to portability. One example would be Open SQL conformance which relates to portability of database used. Characterizes the plug and play aspect of software components, that is how easy is it to exchange a given software component within a specified environment. Functionality Suitability Accurateness Interoperability Compliance Security Maturity This is the essential Functionality characteristic and refers to the appropriateness (to specification) of the functions of the software. This refers to the correctness of the functions, an ATM may provide a cash dispensing function but is the amount correct? A given software component or system does not typically function in isolation. This subcharacteristic concerns the ability of a software component to interact with other components or systems. Where appropriate certain industry (or government) laws and guidelines need to be complied with, i.e. SOX. This subcharacteristic addresses the compliant capability of software. This subcharacteristic relates to unauthorized access to the software functions. This subcharacteristic concerns frequency of failure of the software. Reliability Fault Tolerance The ability of software to withstand (and recover) from component, or environmental, failure. Recoverability Understandability Ability to bring back a failed system to full operation, including data and network connections. Determines the ease of which the systems functions can be understood, relates to user mental models in Human Computer Interaction methods. Usability Learnability Learning effort for different users, i.e. novice, expert, casual etc. Efficiency Operability Time behavior Ability of the software to be easily operated by a given user in a given environment. Characterizes response times for a given thru put, i.e. transaction rate. Resource behavior Characterizes resources used, i.e. memory, cpu, disk and network usage. Analyzability Changeability Maintainability Stability Testability Characterizes the ability to identify the root cause of a failure within the software. Characterizes the amount of effort to change a system. Characterizes the sensitivity to change of a given system that is the negative impact that may be caused by system changes. Characterizes the effort needed to verify (test) a system change. Analyzability Changeability Stability ISO Maintainability Characterizes the ability to identify the root cause of a failure within the software. Characterizes the amount of effort to change a system. Characterizes the sensitivity to change of a given system that is the negative impact that may be caused by system changes. Portability Adaptability Installability Conformance Replaceability Characterizes the ability of the system to change to new specifications or operating environments. Characterizes the effort required to install the software. Similar to compliance for functionality, but this characteristic relates to portability. One example would be Open SQL conformance which relates to portability of database used. Characterizes the plug and play aspect of software components, that is how easy is it to exchange a given software component within a specified environment. Testability Characterizes the effort needed to verify (test) a system change.

6 Metrics assess and improve quality Really? Problems Problems Metrics capture symptoms, not causes of problems?? Metrics capture symptoms, not causes of problems In isolation, metrics do not lead to improvement actions??

7 Problems Metrics capture symptoms, not causes of problems In isolation, metrics do not lead to improvement actions We do not reason in terms of metrics, but in terms of design (principles) More Problems?? More Problems Thresholds make metrics hard to interpret Granularity makes metrics hard to use in isolation? Thresholds make metrics hard to interpret?

8 Metric Value LOC 35,175 NOM 3,618 How do we get an initial understanding of a system? NOC 384 CYCLO 5,579 NOP 19 CALLS 15,128 FANOUT 8,590 AHH 0.12 ANDC 0.31 Metric Value LOC 35,175 NOM 3,618 NOC 384 CYCLO 5,579 We need means to compare NOP 19 CALLS 15,128 FANOUT 8,590 AHH 0.12 ANDC 0.31 And now what?

9 The Overview Pyramid provides a metrics overview Inheritance Size Communication NOP 19 NOC 384 NOM 3618 LOC CYCLO 5579 Size Lanza & Marinescu, NOP NOC NOM LOC CYCLO 5579 Size 3618 NOM CALLS 8590 FANOUT Communication

10 Inheritance ANDC 0.31 AHH NOM CALLS FANOUT Communication Inheritance ANDC 0.31 AHH 0.12 Java C NOP NOC NOM NOM LOC CALLS 0.56 CYCLO/ LOC LOW AVG HIGH LOW AVG HIGH CYCLO FANOUT Size Communication LOC/NOM NOM/NOC

11 Inheritance ANDC 0.31 AHH NOP NOC NOM NOM LOC CALLS 0.56 CYCLO FANOUT Size Communication Inheritance ANDC 0.31 AHH NOP NOC NOM NOM LOC CALLS 0.56 CYCLO FANOUT Size Communication close to low close to average close to high Inheritance And Now? Size Communication close to low close to average close to high

12 Break How do I improve my code? Imagine... Quality is more than zero bugs Quality is about design principles, design heuristics, and best practices Breaking them leads to Code deterioration Design problems ~ Maintenance problems You change a small design fragment......and one third of all classes require changes!

13 Design Problems Expensive Frequent Unavoidable How can we detect and eliminate them? Identity Disharmony How do I define myself? God Class Data Class Brain Class Feature Envy Brain Method Collaboration Disharmony How do I interact with others? Intensive Coupling Dispersive Coupling Shotgun Surgery Classification Disharmony How do I define myself with respect to my ancestors and descendants? Futile Hierarchy Tradition Breaker Refused Parent Bequest

14 God Classes God Class In a good object-oriented design the intelligence of a system is uniformly distributed among the top-level classes. Arthur Riel, 1996 God Classes tend to centralize the intelligence of the system, to do everything and to use data from small dataclasses God Classes tend to centralize the intelligence of the system to do everything and to use data from small data-classes God Classes centralize the intelligence of the system do everything use data from small data-classes God Classes Detection Strategies God Classes centralize the intelligence of the system do everything use data from small data-classes God Classes are complex: high WMC are not cohesive: low TCC access external data: ATFD Compose metrics into queries using logical operators Detection strategies are metric-based queries to detect design flaws Rule 1 METRIC 1 > Threshold 1 Rule 2 METRIC 2 < Threshold 2 AND Quality problem

15 Design Flaws do not come alone Characteristics of a God Class uses Intensive Coupling Extensive Coupling Refused Parent Bequest Identity Disharmonies has God Class Brain Class has is is is is Shotgun Surgery has (partial) has Tradition Breaker has Futile Hierarchy Feature Envy Brain Method has (subclass) Collaboration Disharmonies uses is partially has has has Data Class Significant Duplication Classification Disharmonies Heavily accesses data of other lightweight classes, either directly or using accessor methods. God Class Has a lot of non-communicative behavior Is large God Class Detection Strategy Class uses directly more than a few attributes of other classes ATFD > FEW An envious method is more interested in data from a handful of other classes Functional complexity of the class is very high WMC! VERY HIGH Class cohesion is low AND GodClass Lanza & Marinescu 2006 TCC < ONE THIRD

16 Feature Envy Detection Strategy Method uses directly more than a few attributes of other classes ATFD > FEW Data Classes are dumb data holders Method uses far more attributes of other classes than its own LAA < ONE THIRD AND Feature Envy The used "foreign" attributes belong to very few other classes Lanza & Marinescu 2006 FDP! FEW Data Class Detection Strategy Data Class Detection Strategy More than a few public data Interface of class reveals data rather than offering services WOC < ONE THIRD Class reveals many attributes and is not complex AND Data Class NOPA + NOAM > FEW Complexity of class is not high WMC < HIGH Class has many public data AND OR Class reveals many attributes and is not complex NOPA + NOAM > MANY Complexity of class is not very high AND WMC < VERY HIGH

17 Follow A Clear and Repeatable Process And Now? o rms not Do Metrics are only half the truth! bers m u fn reas bo on a ut q te ty in i l a u

18 Homework Experiment tomorrow