Method Size Metrics

Download Report

Transcript Method Size Metrics

OORPT
Object-Oriented Reengineering Patterns
and Techniques
7. Problem Detection
Prof. O. Nierstrasz
OORPT — Problem Detection
Roadmap
Metrics
> Object-Oriented Metrics in Practice
> Duplicated Code
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.2
OORPT — Problem Detection
Roadmap
>
Metrics
— Software quality
— Analyzing trends
Object-Oriented Metrics in Practice
> Duplicated Code
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.3
OORPT — Problem Detection
Why Metrics in OO Reengineering (ii)?
> Assessing Software Quality
— Which components have poor quality?
(Hence could be reengineered)
— Which components have good quality?
(Hence should be reverse engineered)
 Metrics as a reengineering tool!
> Controlling the Reengineering Process
— Trend analysis: which components changed?
— Which refactorings have been applied?
 Metrics as a reverse engineering tool!
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.4
OORPT — Problem Detection
Selecting Metrics
>
Fast
— Scalable: you can’t afford log(n2) when n  1 million LOC
>
Precise
— (e.g. #methods — do you count all methods, only public ones,
also inherited ones?)
— Reliable: you want to compare apples with apples
>
Code-based
— Scalable: you want to collect metrics several times
— Reliable: you want to avoid human interpretation
>
Simple
— Complex metrics are hard to interpret
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.5
OORPT — Problem Detection
Assessing Maintainability
>
Size of the system, system entities
— Class size, method size, inheritance
— The intuition: large entities impede maintainability
>
Cohesion of the entities
— Class internals
— The intuition: changes should be local
>
Coupling between entities
— Within inheritance: coupling between class-subclass
— Outside of inheritance
— The intuition: strong coupling impedes locality of changes
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.6
OORPT — Problem Detection
Sample Size and Inheritance Metrics
Class Size Metrics
# methods (NOM)
# instance attributes (NIA, NCA)
# Sum of method size (WMC)
Inheritance Metrics
hierarchy nesting level (HNL)
# immediate children (NOC)
# inherited methods, unmodified (NMI)
# overridden methods (NMO)
Inherit
Class
BelongTo
Method Size Metrics
# invocations (NOI)
# statements (NOS)
# lines of code (LOC)
Invoke
Attribute
Method
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
Access
7.7
OORPT — Problem Detection
Method Size
(MSG) Number of Message Sends
> (LOC) Lines of Code
> (MCX) Method complexity
>
— Total Number of Complexity / Total number of methods
— API calls= 5, Assignment = 0.5, arithmetics op = 2, messages
with params = 3....
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.8
OORPT — Problem Detection
Sample Metrics: Class Cohesion
>
(LCOM) Lack of Cohesion in Methods
— [Chidamber 94] for definition
— [Hitz 95] for critique
Ii = set of instance variables used by method Mi
let
P = { (Ii, Ij ) | Ii  Ij =  }
Q = { (Ii, Ij ) | Ii  Ij   }
if all the sets are empty, P is empty
LCOM =
|P| - |Q|
if |P|>|Q|
0
otherwise
>
>
Tight Class Cohesion (TCC)
Loose Class Cohesion (LCC)
— [Bieman 95] for definition
— Measure method cohesion across invocations
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.9
OORPT — Problem Detection
The Trouble with Coupling and
Cohesion
>
Coupling and Cohesion are intuitive notions
— Cf. “computability”
— E.g., is a library of mathematical functions “cohesive”
— E.g., is a package of classes that subclass framework classes
cohesive? Is it strongly coupled to the framework package?
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.10
OORPT — Problem Detection
Roadmap
Metrics
> Object-Oriented Metrics in Practice
>
— Detection strategies, filters and composition
— Sample detection strategies: God Class …
>
Duplicated Code
Michele Lanza and Radu Marinescu,
Object-Oriented Metrics in Practice,
Springer-Verlag, 2006
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.11
OORPT — Problem Detection
Pattern: Study the Exceptional Entities
Problem
— How can you quickly gain insight into complex software?
Solution
— Measure software entities and study the anomalous ones
Steps
— Use simple metrics
— Visualize metrics to get an overview
— Browse the code to get insight into the anomalies
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.12
OORPT — Problem Detection
System Complexity View
System Complexity View
Nodes = Classes
Edges = Inheritance Relationships
Width = Number of Attributes
Height = Number of Methods
Color = Number of Lines of Code
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
Width Metric
Height
Metric
Position
Metrics
Color
Metric
7.13
OORPT — Problem Detection
Detection strategy
>
A detection strategy is a metrics-based predicate to
identify candidate software artifacts that conform to (or
violate) a particular design rule
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.14
OORPT — Problem Detection
Filters and composition
>
A data filter is a predicate used to focus attention on a
subset of interest of a larger data set
— Statistical filters
–
I.e., top and bottom 25% are considered outliers
— Other relative thresholds
–
I.e., other percentages to identify outliers (e.g., top 10%)
— Absolute thresholds
–
>
I.e., fixed criteria, independent of the data set
A useful detection strategy can often be expressed as a
composition of data filters
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.15
OORPT — Problem Detection
God Class
>
A God Class centralizes intelligence in the system
— Impacts understandibility
— Increases system fragility
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.16
OORPT — Problem Detection
ModelFacade (ArgoUML)
453 methods
> 114 attributes
> over 3500 LOC
> all methods and all
attributes are static
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.17
OORPT — Problem Detection
Feature Envy
>
Methods that are more interested in data of other classes
than their own [Fowler et al. 99]
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.18
OORPT — Problem Detection
ClassDiagramLayouter
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.19
OORPT — Problem Detection
Data Class
>
A Data Class provides data to other classes but little or
no functionality of its own
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.20
OORPT — Problem Detection
Data Class (2)
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.21
OORPT — Problem Detection
Property
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.22
OORPT — Problem Detection
Shotgun Surgery
>
A change in an operation implies many (small) changes
to a lot of different operations and classes
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.23
OORPT — Problem Detection
Project
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.24
OORPT — Problem Detection
License
>
http://creativecommons.org/licenses/by-sa/2.5/
Attribution-ShareAlike 2.5
You are free:
• to copy, distribute, display, and perform the work
• to make derivative works
• to make commercial use of the work
Under the following conditions:
Attribution. You must attribute the work in the manner specified by the author or licensor.
Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting
work only under a license identical to this one.
• For any reuse or distribution, you must make clear to others the license terms of this work.
• Any of these conditions can be waived if you get permission from the copyright holder.
Your fair use and other rights are in no way affected by the above.
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
7.25