OORPT — Problem Detection OORPT Object-Oriented Reengineering Patterns and Techniques 7. Problem Detection Prof. O. Nierstrasz © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — Problem Detection Roadmap > Metrics > Object-Oriented Metrics in Practice > Duplicated Code © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 2
OORPT — Problem Detection Roadmap > Metrics — Software quality — Analyzing trends > Object-Oriented Metrics in Practice > Duplicated Code © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 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 4
OORPT — Problem Detection ISO 9126 Quantitative Quality Model Functionality Reliability Software Quality Error tolerance Accuracy Efficiency defect density = #defects / size Consistency Usability Simplicity correction time Portability Modularity correction impact = #components changed Factor Characteristic Metric Maintainability ISO 9126 Leaves are simple metrics, measuring basic attributes © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 5
OORPT — Problem Detection Product & Process Attributes Process Attribute Definition: measure aspects of the process which produces a product Example: time to correct defect, number of components changed per correction © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz Product Attribute Definition: measure aspects of artifacts delivered to the customer Example: number of system defects perceived, time to learn the system 6
OORPT — Problem Detection External & Internal Attributes Internal Attribute Definition: measured purely in term of the product, separate from its behaviour in context Example: class coupling and cohesion, method size © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz External Attribute Definition: measures how the product/process behaves in its environment Example: mean time between failure, #components changed 7
OORPT — Problem Detection External vs. Internal Product Attributes External Internal Advantage: Disadvantage: > close relationship with quality factors > relationship with quality factors is not empirically validated Disadvantages: Advantages: > measure only after the product is > can be measured at any time > data collection is quite easy and used or process took place > data collection is difficult; often involves human intervention/interpretation > relating external effect to internal cause is difficult © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz can be automated > direct relationship between measured attribute and cause 8
![OORPT — Problem Detection Metrics and Measurements > Weyuker [1988] defined nine properties that](https://present5.com/presentation/0e175e53984732c9dddbd393d6c565fd/image-9.jpg "OORPT — Problem Detection Metrics and Measurements > Weyuker [1988] defined nine properties that")
OORPT — Problem Detection Metrics and Measurements > Weyuker [1988] defined nine properties that a software metric should hold. — Read Fenton & Pfleeger for critiques. > For OO only 6 properties are really interesting [Chidamber 94, Fenton & Pfleeger ] — Noncoarseness: – – Given a class P and a metric m, another class Q can always be found such that m(P) m(Q) Not every class has the same value for a metric — Nonuniqueness. – – There can exist distinct classes P and Q such that m(P) = m(Q) Two classes can have the same metric — Monotonicity – m(P) m (P+Q) and m(Q) m (P+Q), P+Q is the “combination” of the classes P and Q. © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 9
OORPT — Problem Detection Metrics and Measurements (ii) — Design Details are Important – The specifics of a class must influence the metric value. Even if a class performs the same actions details should have an impact on the metric value. — Nonequivalence of Interaction – m(P) = m(Q) m(P+R) = m(Q+R) where R is an interaction with the class. — Interaction Increases Complexity – – m(P) + (Q) < m (P+Q). when two classes are combined, the interaction between the too can increase the metric value > Conclusion: Not every measurement is a metric. © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 10
OORPT — Problem Detection Selecting Metrics > Fast — Scalable: you can’t afford log(n 2) 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 11
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 12
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 Belong. To Method Size Metrics # invocations (NOI) # statements (NOS) # lines of code (LOC) Invoke Method © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz Attribute Access 13
![OORPT — Problem Detection Sample class Size > (NIV) — [Lore 94] Number of](https://present5.com/presentation/0e175e53984732c9dddbd393d6c565fd/image-14.jpg "OORPT — Problem Detection Sample class Size > (NIV) — [Lore 94] Number of")
OORPT — Problem Detection Sample class Size > (NIV) — [Lore 94] Number of Instance Variables (NIV) — [Lore 94] Number of Class Variables (static) (NCV) — [Lore 94] Number of Methods (public, private, protected) (NOM) > (LOC) Lines of Code > (NSC) Number of semicolons [Li 93] number of Statements > (WMC) [Chid 94] Weighted Method Count — WMC = ∑ ci — where c is the complexity of a method (number of exit or Mc. Cabe Cyclomatic Complexity Metric) © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 14
![OORPT — Problem Detection Hierarchy Layout > (HNL) [Chid 94] Hierarchy Nesting Level ,](https://present5.com/presentation/0e175e53984732c9dddbd393d6c565fd/image-15.jpg "OORPT — Problem Detection Hierarchy Layout > (HNL) [Chid 94] Hierarchy Nesting Level ,")
OORPT — Problem Detection Hierarchy Layout > (HNL) [Chid 94] Hierarchy Nesting Level , (DIT) [Li 93] > > > Depth of Inheritance Tree, HNL, DIT = max hierarchy level (NOC) [Chid 94] Number of Children (WNOC) Total number of Children (NMO, NMA, NMI, NME) [Lore 94] Number of Method Overridden, Added, Inherited, Extended (super call) (SIX) [Lore 94] — SIX (C) = NMO * HNL / NOM — Weighted percentage of Overridden Methods © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 15
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 16
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 17
OORPT — Problem Detection Sample Metrics: Class Coupling (i) > Coupling Between Objects (CBO) — [Chidamber 94 a] for definition, — [Hitz 95 a] for a discussion — Number of other classes to which it is coupled > Data Abstraction Coupling (DAC) — [Li 93] for definition — Number of ADT’s defined in a class > Change Dependency Between Classes (CDBC) — [Hitz 96 a] for definition — Impact of changes from a server class (SC) to a client class (CC). © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 18
OORPT — Problem Detection Sample Metrics: Class Coupling (ii) > Locality of Data (LD) — [Hitz 96] for definition LD = ∑ |Li | / ∑ |Ti | Li = non public instance variables + inherited protected of superclass + static variables of the class Ti = all variables used in Mi, except non-static local variables Mi = methods without accessors © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 19
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 20
OORPT — Problem Detection Conclusion: Metrics for Quality Assessment > > Can internal product metrics reveal which components have good/poor quality? Yes, but. . . — Not reliable – – false positives: “bad” measurements, yet good quality false negatives: “good” measurements, yet poor quality — Heavyweight Approach – – Requires team to develop (customize? ) a quantitative quality model Requires definition of thresholds (trial and error) — Difficult to interpret – > Requires complex combinations of simple metrics However. . . — Cheap once you have the quality model and the thresholds — Good focus (± 20% of components are selected for further inspection) > Note: focus on the most complex components first! © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 21
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 22
OORPT — Problem 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 23
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 24
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 25
OORPT — Problem Detection Model. Facade (Argo. UML) > 453 methods > 114 attributes > over 3500 LOC > all methods and all attributes are static © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 26
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 27
OORPT — Problem Detection Class. Diagram. Layouter © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 28
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 29
OORPT — Problem Detection Data Class (2) © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 30
OORPT — Problem Detection Property © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 31
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 32
OORPT — Problem Detection Project © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 33
OORPT — Problem Detection Roadmap > Metrics > Object-Oriented Metrics in Practice > Duplicated Code — Detection techniques — Visualizing duplicated code © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 34
OORPT — Problem Detection Code is Copied Small Example from the Mozilla Distribution (Milestone 9) Extract from /dom/src/base/ns. Location. cpp © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 35
OORPT — Problem Detection How Much Code is Duplicated? Usual estimates: 8 to 12% in normal industrial code 15 to 25 % is already a lot! Case Study LOC Duplication without comments gcc 460’ 000 8. 7% 5. 6% Database Server 245’ 000 36. 4% 23. 3% Payroll 40’ 000 59. 3% 25. 4% Message Board 6’ 500 29. 4% 17. 4% © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz with comments 36
OORPT — Problem Detection What is Duplicated Code? > Duplicated Code = Source code segments that are found in different places of a system. — in different files — in the same file but in different functions — in the same function > The segments must contain some logic or structure that can be abstracted, i. e. , > Copied artifacts range from expressions, to functions, to data structures, and to entire subsystems. © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 37
OORPT — Problem Detection Copied Code Problems > General negative effect — Code bloat > Negative effects on Software Maintenance — — > Copied Defects Changes take double, triple, quadruple, . . . Work Dead code Add to the cognitive load of future maintainers Copying as additional source of defects — Errors in the systematic renaming produce unintended aliasing > Metaphorically speaking: — Software Aging, “hardening of the arteries”, — “Software Entropy” increases even small design changes become very difficult to effect © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 38
OORPT — Problem Detection Code Duplication Detection Nontrivial problem: • No a priori knowledge about which code has been copied • How to find all clone pairs among all possible pairs of segments? © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 39
OORPT — Problem Detection General Schema of Detection Process Author Level Transformed Code Comparison Technique Johnson 94 Lexical Substrings String-Matching Ducasse 99 Lexical Normalized Strings String-Matching Baker 95 Syntactical Parameterized Strings String-Matching Mayrand 96 Syntactical Metric Tuples Discrete comparison Kontogiannis 97 Syntactical Metric Tuples Euclidean distance Baxter 98 Syntactical AST Tree-Matching © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 40
OORPT — Problem Detection Recall and Precision © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 41
OORPT — Problem Detection Simple Detection Approach (i) > Assumption: – > Code segments are just copied and changed at a few places Noise elimination transformation – – remove white space, comments remove lines that contain uninteresting code elements – (e. g. , just ‘else’ or ‘}’) … //assign same fastid as container fastid = NULL; const char* fidptr = get_fastid(); if(fidptr != NULL) { int l = strlen(fidptr); fastid = newchar[ l + 1 ]; © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz … fastid=NULL; constchar*fidptr=get_fastid(); if(fidptr!=NULL) intl=strlen(fidptr) fastid = newchar[l+] 42
OORPT — Problem Detection Simple Detection Approach (ii) > Code Comparison Step — Line based comparison (Assumption: Layout did not change during copying) — Compare each line with each other line. — Reduce search space by hashing: – – Preprocessing: Compute the hash value for each line Actual Comparison: Compare all lines in the same hash bucket > Evaluation of the Approach — Advantages: Simple, language independent — Disadvantages: Difficult interpretation © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 43
OORPT — Problem Detection A Perl script for C++ (i) © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 44
OORPT — Problem Detection A Perl script for C++ (ii) • Handles multiple files • Removes comments and white spaces • Controls noise (if, {, ) • Granularity (number of lines) • Possible to remove keywords © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 45
OORPT — Problem Detection Output Sample Lines: create_property(pd, pn. Impl. Objects, st. Reference, false, *i. Impl. Objects); create_property(pd, pn. Elttype, st. Reference, true, *i. Elt. Type); create_property(pd, pn. Minelt, st. Integer, true, *i. Minelt); create_property(pd, pn. Maxelt, st. Integer, true, *i. Maxelt); create_property(pd, pn. Ownership, st. Bool, true, *i. Ownership); Locations: </face/typesystem/SCTypesystem. C>6178/6179/6180/6181/6182 </face/typesystem/SCTypesystem. C>6198/6199/6200/6201/6202 Lines: create_property(pd, pn. Supertype, st. Reference, true, *i. Supertype); create_property(pd, pn. Impl. Objects, st. Reference, false, *i. Impl. Objects); create_property(pd, pn. Elttype, st. Reference, true, *i. Elt. Type); create_property(pd, p. Minelt, st. Integer, true, *i. Minelt); create_property(pd, pn. Maxelt, st. Integer, true, *i. Maxelt); Locations: </face/typesystem/SCTypesystem. C>6177/6178 </face/typesystem/SCTypesystem. C>6229/6230 Lines = duplicated lines Locations = file names and line number © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 46
OORPT — Problem Detection Enhanced Simple Detection Approach > Code Comparison Step — As before, but now – – Collect consecutive matching lines into match sequences Allow holes in the match sequence > Evaluation of the Approach — Advantages – Identifies more real duplication, language independent — Disadvantages – – Less simple Misses copies with (small) changes on every line © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 47
OORPT — Problem Detection Abstraction — Abstracting selected syntactic elements can increase recall, at the possible cost of precision © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 48
OORPT — Problem Detection Metrics-based detection strategy > Duplication is significant if: — It is the largest possible duplication chain uniting all exact clones that are close enough to each other. — The duplication is large enough. © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 49
![OORPT — Problem Detection Automated detection in practice > Wettel [ MSc thesis, 2004]](https://present5.com/presentation/0e175e53984732c9dddbd393d6c565fd/image-50.jpg "OORPT — Problem Detection Automated detection in practice > Wettel [ MSc thesis, 2004]")
OORPT — Problem Detection Automated detection in practice > Wettel [ MSc thesis, 2004] uses three thresholds: — Minimum clone length: the minimum amount of lines present in a clone (e. g. , 7) — Maximum line bias: the maximum amount of lines in between two exact chunks (e. g. , 2) — Minimum chunk size: the minimum amount of lines of an exact chunk (e. g. , 3) Mihai Balint, Tudor Gîrba and Radu Marinescu, “How Developers Copy, ” ICPC 2006 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 50
OORPT — Problem Detection Visualization of Duplicated Code > Visualization provides insights into the duplication situation — A simple version can be implemented in three days — Scalability issue > Dotplots — Technique from DNA Analysis — Code is put on vertical as well as horizontal axis — A match between two elements is a dot in the matrix © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 51
OORPT — Problem Detection Visualization of Copied Code Sequences Detected Problem File A contains two copies of a piece of code File B contains another copy of this code Possible Solution Extract Method All examples are made using Duploc from an industrial case study (1 Mio LOC C++ System) © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 52
OORPT — Problem Detection Visualization of Repetitive Structures Detected Problem 4 Object factory clones: a switch statement over a type variable is used to call individual construction code Possible Solution Strategy Method © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 53
OORPT — Problem Detection Visualization of Cloned Classes Class A Class B Detected Problem: Class A is an edited copy of class B. Editing & Insertion Class A Possible Solution Subclassing … Class B © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 54
OORPT — Problem Detection Visualization of Clone Families Overview Detail 20 Classes implementing lists for different data types © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 55
OORPT — Problem Detection Conclusion > Duplicated code is a real problem — makes a system progressively harder to change > Detecting duplicated code is a hard problem — some simple techniques can help — tool support is needed > Visualization of code duplication is useful — basic tool support is easy to build (e. g. , 3 days with rapid-prototyping) > Curing duplicated code is an active research area © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz 56
OORPT — Problem Detection License > http: //creativecommons. org/licenses/by-sa/2. 5/ Attribution-Share. Alike 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 57
Скачать презентацию OORPT Problem Detection OORPT Object-Oriented Reengineering Patterns
0e175e53984732c9dddbd393d6c565fd.ppt