Detection and Evolution of Design Patterns: Two Decades Later?

Transcription

1 Definition of design patterns Detection and Evolution of Design Patterns: Two Decades Later? Laleh M. Eshkevari E cole Polytechnique de Montre al, Que bec, Canada March 5th, 2013 Laleh M. Eshkevari March 5th, / 23

2 Outline Definition of design patterns 1 Definition of design patterns Laleh M. Eshkevari March 5th, / 23

3 Where everything started GOF: Design patterns: elements of reusable object-oriented software Patterns: creational, structural, and behavioral Laleh M. Eshkevari March 5th, / 23

4 Detection - Pioneers I Kyle Gene Brown (1996) Approach: automated reveres engineering tool, Smalltalk Technique: information retrieved from class hierarchies, association, aggregation relationships,and messages exchanged between classes Patterns: composite, decorator, template method and chain of responsibility Case study: applied the detection tool on four projects Laleh M. Eshkevari March 5th, / 23

5 Detection - Pioneers II Christian Kramer and Lutz Prechelt (WCRE 1996) Motivation: improve the maintainability of software, because larger chunks could be understood as a whole. Approach: Pat tool, C++ source code Patterns: Adapter, Bridge, Composite, Decorator, and Proxy Case study: four real-life projects: (NME, LEDA, the zapp class library and ACD). Precision: 14-50% limitation: definition of new Prolog rules in case a novel design pattern had to be detected, and the complexity of algorithm to match classes Laleh M. Eshkevari March 5th, / 23

6 Overview of Detection I Technique: constraint programming fuzzy reasoning net query base static and dynamic analysis Artifact: design, and code (Java, C++ ) Accuracy: 55% to 64%* precision and 80% recall Pattern: all patterns except for Flyweight Command, Interpreter, Memento, State Tools: SPOOL, Columbus, Ptidej, Maisa Laleh M. Eshkevari March 5th, / 23

7 Overview of Detection II Technique: code transformation relational algebra unification metrics and machine learning static and dynamic analysis similarity scoring Artifact: design, and code (Java, C++, Smalltalk, Eiffel ) Accuracy: 91%- 100% precision and 100% *recall Pattern: all GOF patterns Tools: Crocopat, DP-Miner,FUJABA,PINOT, SPQR Laleh M. Eshkevari March 5th, / 23

8 Overview of Detection III Technique: constraint-programming Visual language parsing Combination of structural and a numerical approach Artifact: Code (Java) Accuracy: 34% precision with 100% recall, 62% to 97% precision Pattern: all GOF patterns Tools: DeMIMA, DPRE, Laleh M. Eshkevari March 5th, / 23

9 Empirical studies - Pioneer Patterns in industry- Beck et al., 1996 improved communication between developers through pattern novice developers learn from good examples in team speed up novice developers contribution to the team good patterns are hard to write pattern is not a rule to follow blindly there is a need to measure the benefits over the disadvantage in practice Laleh M. Eshkevari March 5th, / 23

10 Patterns during maintenance dilemma of using design pattern [Prechelt et al., 01] Control experiment: four programs, 32 professional developers, C++ Dependent variables: cost and correctness Patterns: Abstract Factory, Composite, Decorator, Facade, Observer and Visitor Objective: if using design pattern is helpful harmful or neutral? Finding: not always useful to use design pattern sometimes design patterns have non obvious advantages it is useful to have knowledge over design pattern specially if the program have one it is wise to choose the design pattern over the simple solution Laleh M. Eshkevari March 5th, / 23

11 Patterns during maintenance visitor Pattern [Jeanmart et al., 09] Control experiment: Eye tracker, three open-source programs, 24 subjects Dependent variables: Average Duration of Relevant Fixations Average Duration of Non-Relevant Fixations Normalized Rate of Relevant Fixations Objective: dose class diagrams containing visitor patterns require more effort for comprehension and modification task? Finding: visitor pattern does not reduce the subjects efforts for comprehension tasks the canonical representation of visitor pattern reduces the developers efforts for modification tasks Laleh M. Eshkevari March 5th, / 23

12 Patterns during maintenance Documenting patterns [Prechelt et al., 02] Control experiment: two programs, 74 student (Java) and 22 students ( C++) Dependent variables: performance, and correctness Patterns: Template Method, Composite and Visitor Objective: Does it help the maintainer if the design patterns are documented explicitly in Code? Finding: explicit comments for design patterns may reduce the time required for change explicit comments for design patterns may improve the quality of change recommended that design patterns always be documented explicitly Laleh M. Eshkevari March 5th, / 23

13 Fault proneness Defect rates of design pattern [Vokáč, 2004] Case study: commercial C++, three years weekly evolution and maintenance, own tool for detection Variables: presence of a defect ( response variable), presence of the five patterns, size, week number, and their interaction (explanatory variables) Patterns: Singleton,Template Method, Decorator, Observer, Factory Objective:is there a correlation between the use of design patterns, and the error rates? Laleh M. Eshkevari March 5th, / 23

14 Fault proneness Defect rates of design pattern [Vokáč, 2004] Finding: Factory is correlated with lower defect rate Observer is correlated with higher defect rates Singleton and Observer, have significant interactions with size Template Method no strong conclusion is made Decorator did not occur often, so no statistically significant results Laleh M. Eshkevari March 5th, / 23

15 Fault proneness Effective use of design pattern [Ng et al., 2007] Experiment: 215 students, Java, three programs, three RQs Dependent variables: performing tasks related to patterns, and correctness (number of fault) Patterns: Factory Method, Command, Composite, Observer and State Objective: does effective use of design pattern produce less faulty code during maintenance Laleh M. Eshkevari March 5th, / 23

16 Fault proneness Effective use of design pattern [Ng et al., 2007] Finding: almost all subjects perform the task (T1: adding new concrete participants) majority of the subjects perform the task (T3: involving clients) about half of the subjects perform the task (T2: involving abstract participants) codes done by the subjects who utilize the design patterns are significantly less faulty Laleh M. Eshkevari March 5th, / 23

17 Change proneness Design pattern does not support adaptability [Bieman, 03] Case study: three industrial and two open source systems, Java and C++, 39 versions Patterns: 12 patterns Objective: do pattern classes change more than non-pattern classes? Finding: no strong support to predict change by size in four systems, pattern classes are change prone key functionality of the system are provided by design pattern classes pattern classes in one system are less change prone than the other Laleh M. Eshkevari March 5th, / 23

18 Change proneness The Evolution of Design Patterns [Aversano et al., 07] Case study: three open source Java systems, used Tsantalis et al. approach for detection, used CVS to find change and co-change Patterns: three structural, three creational, and four behavioral Objective: how frequently do the pattern change? what are the kind of changes? how much code change with patterns? Laleh M. Eshkevari March 5th, / 23

19 Change proneness The Evolution of Design Patterns [Aversano et al., 07] Finding: pattern change frequently some patterns change more than the others patterns are often changed by adding subclasses or changing method interfaces patterns playing the key functionality change more and involved in large maintenance activities Laleh M. Eshkevari March 5th, / 23

20 Change proneness Design Pattern Roles and Class Change Proneness [Di Penta et al., 08] Case study: three Java open source systems, used DeMIMA detection tool, Dependent variables: Patterns: 12 patterns Objective: are some roles more change-prone than others? are some changes more likely to occur to certain roles? Laleh M. Eshkevari March 5th, / 23

21 Change proneness Design Pattern Roles and Class Change Proneness [Di Penta et al., 08] Finding: Adapter pattern the classes playing the role of Adapter are more change prone Abstract Factories and Products change less frequently than concrete classes Command receivers change more frequently than the commands roles more subjects to changes need more careful attention class playing the role of Composite is more change prone Laleh M. Eshkevari March 5th, / 23

22 Reusability of automated approach Measure the accuracy Data for replication Laleh M. Eshkevari March 5th, / 23

23 Thank you! Definition of design patterns Questions? Laleh M. Eshkevari March 5th, / 23