1. Automatically Extracting and Verifying Design Patterns in Java Code James Norris Ruchika Agrawal Computer Science Department Stanford University {jcn, ruchika}@cs.stanford.edu}

2. 1. Overview  The goal of this proposal is to outline a project designed to extract well established design patterns in object-oriented software using static analysis and report violations of the patterns using dynamic analysis.  We hope to develop a tool that will extract design patterns from Java programs of various sizes and complexity, and report violations to aid programmers in ensuring that their usage of design patterns is correct.

3. Motivation  Designing object-oriented software is no trivial task, and software bugs are prevalent.  Design patterns offer a pre-thought out, pre-tested solution to day-to-day problems object-oriented designers and programmers face  Yet,programmers may inadvertently implement or use design patterns incorrectly, which may result in various types of bugs (some very subtle ones as discussed in our case study).

4. Applications  Industry programmers could use our tool to verify that they have implemented and used various design patterns correctly.  By extracting design patterns, we will be decomposing large programs into meaningful components, on which further types of analyses may be applied for optimization or correctness purposes.

5. The Challenges  designing the analysis needed to extract the design patterns  as complexity of design patterns increases, making it harder to extract them, the complexity of the analysis necessary to detect violations also increases  Programmers sometimes intentionally implement slight variations of design patterns

6. RELATED WORK

7. Christian Kramer and Lutz Prechelt, Design Recovery by Automated Search for Structural Design Patterns in Object-Oriented Software  extract design information directly from C++ header files and store them as Prolog facts  design patterns – specifically Adapter, Bridge, Composite, Decorator, and Proxy -- are encoded as Prolog rules  Prolog query is used to search for all patterns; the results show 40% precision

8. Federico Bergenti and Agostino Poggi, Improving UML Designs Using Automatic Design Pattern Detection  finding and improving the realizations of design patterns in UML diagrams

9. Niere, Wadsack and Zundorf, Recovering UML Diagrams from Java Code using Patterns  use fuzzy pattern detection techniques to recover UML collaboration diagrams from source code  detect simple instances of collaboration between individual classes and not the more complex semantics of generic design patterns  use annotation engines run over abstract syntax trees to detect code cliches and utilizes a particular form of fuzzy logic, generic fuzzy reasoning networks, to detect distorted or varying code cliches

10. Jagdish Bansiya, Automating Design-Pattern Identification  Algorithm (not described) is based on structural information: interfaces (abstract classes), base classes and subclasses, template classes, inheritance relationships, aggregation by physical containment of instance variables, aggregation by references/pointer instance variables, and method parameter-based uses relationships

11. Kyle Brown, Design Reverse-Engineering and Automated Design Pattern Detecting in Smalltalk  Infers type information and uses program traces to extract patterns from Smalltalk programs  pattern is detectable if its template solution is both distinctive and unambiguous  algorithm to detect patterns relies on a common set of design information representable by the class diagrams and object-message diagrams utilized and extracts this information from Smalltalk code

12. John Whaley, Michael Martin and Monica Lam, Automatic Extraction of Object- Oriented Component Interfaces  extract object-oriented component interfaces  use: multiple finite state machine (FSM) submodels to model the interface of a class, which includes methods that access particular fields, for example; dynamic instrumentation techniques to extract FSM models from execution runs; and static analyses to deduce illegal call sequences in a program, and a dynamic model checker to ensure that the code conforms to the model  Want to use their techniques to detect role-based patterns such as Iterator

13. SIMPLE DESIGN PATTERNS  Examples: Adapter, Bridge, Decorator, Proxy, Singleton, Visitor  techniques relying on structural information from static analysis and work well to extract structural design patterns

14. COMPLEX DESIGN PATTERNS  Examples: Facade, Interpreter, Composite, Iterator, Chain of Responsibility  Often requires analysis of runtime behavior and code semantics

15. SIMPLE CASE STUDY: THE SINGLETON DESIGN PATTERN  Only one instance of an object should be created during a program’s lifetime  Can use heuristics such as private constructors, public static final instance variables to recognize  Look for common violations of patterns with static and dynamic analyses

16. NEXT STEPS

17. Design Pattern Specification  Provide an interface that programmers can use to specify new design pattern models or modify existing ones

18. Extracting More Simple Patterns and Detecting Violations  attach probabilities to the various criteria used to recognize patterns in order to derive a confidence rating for each pattern extraction  Machine learning techniques could be used to optimize those probabilities based on training data derived from manually examining classes or dynamically instrumenting code to detect particular design patterns  examine available structural information not used by the pattern criteria and try to detect commonalities between classes implementing the patterns that could suggest additional pattern criteria or anti-criteria  use multiple FSM submodels to extract some of the role-based patterns such as Iterator or State

19. Extracting More Complex Patterns and Detecting Violations  apply dynamic analyses to extract more complex patterns and report violations of them  for example, we may want to try tracing method invocation histories across objects to detect patterns such as Chain of Responsibility, Decorator, and other complex behavioral patterns

20. Other Extensions  suggest improvements to design pattern implementation in addition to reporting violations  report violations with a certain level of confidence  rank the detected violations