Automatically Extracting and Verifying Design Patterns in Java Code

Document Sample
Automatically Extracting and Verifying Design Patterns in Java Code Powered By Docstoc
					Automatically Extracting and
Verifying Design Patterns in Java
Code
James Norris Ruchika Agrawal
Computer Science Department
Stanford University
{jcn, ruchika}@cs.stanford.edu}
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.
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).
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.
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
RELATED WORK
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
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
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
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
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
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
COMPLEX DESIGN PATTERNS
 Examples:   Facade, Interpreter, Composite,
  Iterator, Chain of
  Responsibility
 Often requires analysis of runtime behavior
  and code semantics
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
NEXT STEPS
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
  patterns
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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:9/15/2012
language:Unknown
pages:20