Presentation is loading. Please wait.

Presentation is loading. Please wait.

OORPT Object-Oriented Reengineering Patterns and Techniques 7. Problem Detection Prof. O. Nierstrasz.

Similar presentations


Presentation on theme: "OORPT Object-Oriented Reengineering Patterns and Techniques 7. Problem Detection Prof. O. Nierstrasz."— Presentation transcript:

1 OORPT Object-Oriented Reengineering Patterns and Techniques 7. Problem Detection Prof. O. Nierstrasz

2 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.2 Roadmap  Metrics  Object-Oriented Metrics in Practice  Duplicated Code

3 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.3 Roadmap  Metrics —Software quality —Analyzing trends  Object-Oriented Metrics in Practice  Duplicated Code

4 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.4 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!

5 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.5 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

6 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.6 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

7 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.7 Sample Size and Inheritance Metrics Class Attribute Method Access Invoke BelongTo Inherit Inheritance Metrics hierarchy nesting level (HNL) # immediate children (NOC) # inherited methods, unmodified (NMI) # overridden methods (NMO) Class Size Metrics # methods (NOM) # instance attributes (NIA, NCA) # Sum of method size (WMC) Method Size Metrics # invocations (NOI) # statements (NOS) # lines of code (LOC)

8 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.8 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....

9 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.9 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| 0otherwise  Tight Class Cohesion (TCC)  Loose Class Cohesion (LCC) —[Bieman 95] for definition —Measure method cohesion across invocations

10 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.10 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?

11 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.11 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

12 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.12 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

13 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.13 System Complexity View Nodes = Classes Edges = Inheritance Relationships Width = Number of Attributes Height = Number of Methods Color = Number of Lines of Code System Complexity View Color Metric Position Metrics Width Metric Height Metric

14 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.14 Detection strategy  A detection strategy is a metrics-based predicate to identify candidate software artifacts that conform to (or violate) a particular design rule

15 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.15 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

16 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.16 God Class  A God Class centralizes intelligence in the system —Impacts understandibility —Increases system fragility

17 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.17 ModelFacade (ArgoUML)  453 methods  114 attributes  over 3500 LOC  all methods and all attributes are static

18 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.18 Feature Envy  Methods that are more interested in data of other classes than their own [Fowler et al. 99]

19 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.19 ClassDiagramLayouter

20 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.20 Data Class  A Data Class provides data to other classes but little or no functionality of its own

21 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.21 Data Class (2)

22 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.22 Property

23 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.23 Shotgun Surgery  A change in an operation implies many (small) changes to a lot of different operations and classes

24 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.24 Project

25 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Problem Detection 7.25 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. 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.


Download ppt "OORPT Object-Oriented Reengineering Patterns and Techniques 7. Problem Detection Prof. O. Nierstrasz."

Similar presentations


Ads by Google