Automatically Extracting and Verifying Design Patterns in Java Code by pa7E4jCO


									Automatically Extracting and
Verifying Design Patterns in Java
James Norris Ruchika Agrawal
Computer Science Department
Stanford University
{jcn, ruchika}}
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.
 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).
 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.
The Challenges
 designing the analysis needed to extract the design
 as complexity of design patterns increases, making
  it harder to extract them, the complexity of the
  analysis necessary to detect violations also
 Programmers sometimes intentionally implement
  slight variations of design patterns
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
Federico Bergenti and Agostino Poggi, Improving UML Designs Using
Automatic Design Pattern Detection

 finding and  improving the realizations of
   design patterns in UML diagrams
Niere, Wadsack and Zundorf, Recovering UML Diagrams from Java Code using

 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
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
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
 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
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
 Examples:   Adapter, Bridge, Decorator,
  Proxy, Singleton, Visitor
 techniques relying on structural information
  from static analysis and work well to extract
  structural design patterns
 Examples:   Facade, Interpreter, Composite,
  Iterator, Chain of
 Often requires analysis of runtime behavior
  and code semantics
 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
Design Pattern Specification
 Provide an interface that programmers can
 use to specify new design pattern models or
 modify existing ones
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
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
Other Extensions
 suggest improvements to    design pattern
  implementation in addition to reporting
 report violations with a certain level of
 rank the detected violations

To top