1 / 24

Automatic Extraction of Object-Oriented Component Interfaces

Automatic Extraction of Object-Oriented Component Interfaces. John Whaley Michael C. Martin Monica S. Lam Computer Systems Laboratory Stanford University July 24, 2002. Motivation. Component programming is widespread. Interface specifications are important!

vaughan
Download Presentation

Automatic Extraction of Object-Oriented Component Interfaces

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automatic Extraction of Object-Oriented Component Interfaces John Whaley Michael C. Martin Monica S. LamComputer Systems LaboratoryStanford UniversityJuly 24, 2002

  2. Motivation • Component programming is widespread. • Interface specifications are important! • Misunderstanding the API is a common source of error • Ideally, we want formal specifications. • However, many components don’t have any specifications, formal or informal! • Our goal: automatic generation of interface specifications • For large, object-oriented programs • Partial specifications ISSTA 2002

  3. Why Automatic Extraction? • Documentation • Based on the actual code, so no divergence • Rules for static or dynamic checkers • Find errors in API usage • Find API bugs • Discrepancy between code & intended API • Dynamic extraction: • Evaluation of test coverage ISSTA 2002

  4. Overview • Component Model • Product of Finite State Machines • Static Analysis • Dynamic Analysis and Checker • Implemented for Java • Analyzed >1 million lines of code • Java class libraries • Java 2 Enterprise Edition • Java network libraries • joeq virtual machine ISSTA 2002

  5. Example: File • Use a Finite State Machine (FSM) to express ordering constraints. read START open close END write ISSTA 2002

  6. A Simple OO Component Model • Each object follows an FSM model. • One state per method, plus START & END states. • Method call causes a transition to a new state. read m1 m2 open close START END m1 ; m2 is legal,new state is m2 write ISSTA 2002

  7. START set_a get_a set_b get_b END Problem 1 • An object has two fields, a and b. • Each field must be set before being read. • Solution: a product of FSMs, one for each field. START set_a set_b set_a get_b get_a get_b ISSTA 2002

  8. set_b get_a get_a set_a START get_b set_b get_b START set_a START END END END Splitting by fields set_a set_b get_b get_a Separate by fields into different, independent submodels. ISSTA 2002

  9. create START Problem 2 Model for Socket • getFileDescriptor is state-preserving. • Solution: distinguish betweenstate-modifying and state-preserving. start START START connect connect getFileDescriptor getFileDescriptor close END ISSTA 2002

  10. create START State-preserving methods start START getFileDescriptor connect m1 m2 m1 is state-modifying m2 is state-preserving m1 ; m2 is legal,new state is m1 close END ISSTA 2002

  11. Summary of Model • Product of FSMs • Per-thread, per-instance • One submodel per field • Interprocedural mod-ref analysis • Identifies methods belonging to submodel • Separates state-modifying and state-preserving methods. • One submodel per Java interface • Implementation not required. ISSTA 2002

  12. Extraction Techniques ISSTA 2002

  13. START connect read Static Model Extractor • Defensive programming • Implementation throws exceptions (user or system defined) on illegal input. public void connect() { connection = new Socket(); }public void read() { if (connection == null) throw new IOException();} connection connection ISSTA 2002

  14. Detecting Illegal Transitions • Only support simple predicates • Comparisons with constants, implicit null pointer checks • Find <source, target> pairs such that: • Source must execute: • field = const ; • Target must execute: • if (field == const)throw exception; ISSTA 2002

  15. Algorithm • Source method: Constant propagation • Constant at exit node • Target method: Control dependence • Throw of exception is control dependent on predicate ISSTA 2002

  16. Dynamic Extractor • Goal: find the legal transitions that occur during an execution of the program • Java bytecode instrumentation • For each thread, each instance of a class: • Track last state-modifying method for each submodel. • Same mechanism for dynamic checking • Instead of adding to model, flag exception. ISSTA 2002

  17. Experiences • We applied our tool to several real-life applications. ISSTA 2002

  18. Automatic documentation • java.util.AbstractList.ListItrslice on lastRet field (static) START next,previous set add remove ISSTA 2002

  19. START begin Automatic documentation J2EE TransactionManager (dynamic) start commit suspend rollback resume END ISSTA 2002

  20. Test coverage J2EE IIOPOutputStream(dynamic) No self-edges implies amax recursion depth of 1 START increaseRecursionDepth increaseRecursionDepth simpleWriteObject decreaseRecursionDepth END ISSTA 2002

  21. create Upper/lower bound of model SocketImpl model(dynamic) start START (+static) getFileDescriptor availablegetInputStreamgetOutputStream connect close END ISSTA 2002

  22. load load Finding API bugs • Applied our tool to the joeq virtual machine START START Expected APIfor jq_Method: Actual APIfor jq_Method: prepare setOffset prepare compile compile ISSTA 2002

  23. Related Work • Dynamic • Daikon (Ernst99) • DIDUCE (Hangal02) • K-limited FSM extraction (Reiss01) • Machine-learning (Ammons02) • Static • Metal (Engler00) • Vault (DeLine01), NIL, Hermes (Strom86) • SLAM toolkit (Ball01) • ESC (Detlefs98) • ESC + Daikon (Flanagan01, Nimmer02) ISSTA 2002

  24. Conclusion • Product of FSM • Model is simple, but useful • Upper/lower bound: static/dynamic • Useful for: • Documentation generation • Test coverage • Rules for automatic checkers • Finding API bugs ISSTA 2002

More Related