272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 16: Automated Interface Extraction.

Slides:



Advertisements
Similar presentations
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Advertisements

Giving a formal meaning to “Specialization” In these note we try to give a formal meaning to specifications, implementations, their comparisons. We define.
Composition CMSC 202. Code Reuse Effective software development relies on reusing existing code. Code reuse must be more than just copying code and changing.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
CS 267: Automated Verification Lecture 10: Nested Depth First Search, Counter- Example Generation Revisited, Bit-State Hashing, On-The-Fly Model Checking.
1 Program Slicing Purvi Patel. 2 Contents Introduction What is program slicing? Principle of dependences Variants of program slicing Slicing classifications.
ISBN Chapter 3 Describing Syntax and Semantics.
Using Programmer-Written Compiler Extensions to Catch Security Holes Authors: Ken Ashcraft and Dawson Engler Presented by : Hong Chen CS590F 2/7/2007.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 13: Runtime Monitoring.
Road Map Introduction to object oriented programming. Classes
Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.
Slides prepared by Rose Williams, Binghamton University Chapter 1 Getting Started 1.1 Introduction to Java.
CS 290C: Formal Models for Web Software Lecture 10: Language Based Modeling and Analysis of Navigation Errors Instructor: Tevfik Bultan.
Next Section: Pointer Analysis Outline: –What is pointer analysis –Intraprocedural pointer analysis –Interprocedural pointer analysis (Wilson & Lam) –Unification.
1 Chapter 4 Language Fundamentals. 2 Identifiers Program parts such as packages, classes, and class members have names, which are formally known as identifiers.
272: Software Engineering Fall 2008 Instructor: Tevfik Bultan Lecture 15: Interface Extraction.
Slides prepared by Rose Williams, Binghamton University Chapter 13 Interfaces and Inner Classes.
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Automatically Extracting and Verifying Design Patterns in Java Code James Norris Ruchika Agrawal Computer Science Department Stanford University {jcn,
Synthesis of Interface Specifications for Java Classes Rajeev Alur University of Pennsylvania Joint work with P. Cerny, G. Gupta, P. Madhusudan, W. Nam,
Automatic Extraction of Object-Oriented Component Interfaces John Whaley Michael C. Martin Monica S. Lam Computer Systems Laboratory Stanford University.
Communication in Distributed Systems –Part 2
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Data Abstraction and Object- Oriented Programming CS351 – Programming Paradigms.
Describing Syntax and Semantics
1 ES 314 Advanced Programming Lec 2 Sept 3 Goals: Complete the discussion of problem Review of C++ Object-oriented design Arrays and pointers.
Data Flow Analysis Compiler Design Nov. 8, 2005.
1 Further OO Concepts II – Java Program at run-time Overview l Steps in Executing a Java Program. l Loading l Linking l Initialization l Creation of Objects.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Pointer analysis. Pointer Analysis Outline: –What is pointer analysis –Intraprocedural pointer analysis –Interprocedural pointer analysis Andersen and.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 5 Data Flow Testing
Java Methods By J. W. Rider. Java Methods Modularity Declaring methods –Header, signature, prototype Static Void Local variables –this Return Reentrancy.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 17: Code Mining.
Reverse Engineering State Machines by Interactive Grammar Inference Neil Walkinshaw, Kirill Bogdanov, Mike Holcombe, Sarah Salahuddin.
1 CISC181 Introduction to Computer Science Dr. McCoy Lecture 19 Clicker Questions November 3, 2009.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
MT311 Java Application Development and Programming Languages Li Tak Sing( 李德成 )
Presented By Dr. Shazzad Hosain Asst. Prof., EECS, NSU
CSC3315 (Spring 2009)1 CSC 3315 Programming Languages Hamid Harroud School of Science and Engineering, Akhawayn University
Compiler Chapter# 5 Intermediate code generation.
Type Systems CS Definitions Program analysis Discovering facts about programs. Dynamic analysis Program analysis by using program executions.
Problem Solving Techniques. Compiler n Is a computer program whose purpose is to take a description of a desired program coded in a programming language.
Comp 249 Programming Methodology Chapter 13 Interfaces & Inner Classes Dr. Aiman Hanna Department of Computer Science & Software Engineering Concordia.
Encapsulation COMP 401, Fall 2014 Lecture 06 9/4/2014.
Topic 1 Object Oriented Programming. 1-2 Objectives To review the concepts and terminology of object-oriented programming To discuss some features of.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University IWPSE 2003 Program.
An Undergraduate Course on Software Bug Detection Tools and Techniques Eric Larson Seattle University March 3, 2006.
Learning Symbolic Interfaces of Software Components Zvonimir Rakamarić.
Software Engineering Research Group, Graduate School of Engineering Science, Osaka University A Slicing Method for Object-Oriented Programs Using Lightweight.
Object-Oriented Programming Chapter Chapter
 In the java programming language, a keyword is one of 50 reserved words which have a predefined meaning in the language; because of this,
1 Chapter 38 RPC and Middleware. 2 Middleware  Tools to help programmers  Makes client-server programming  Easier  Faster  Makes resulting software.
CMSC 202 Advanced Section Classes and Objects: Object Creation and Constructors.
Lecture 4 Mechanisms & Kernel for NOSs. Mechanisms for Network Operating Systems  Network operating systems provide three basic mechanisms that support.
/ PSWLAB Evidence-Based Analysis and Inferring Preconditions for Bug Detection By D. Brand, M. Buss, V. C. Sreedhar published in ICSM 2007.
ECE 750 Topic 8 Meta-programming languages, systems, and applications Automatic Program Specialization for J ava – U. P. Schultz, J. L. Lawall, C. Consel.
1 Chapter 2: Operating-System Structures Services Interface provided to users & programmers –System calls (programmer access) –User level access to system.
CS223: Software Engineering Lecture 26: Software Testing.
Sung-Dong Kim, Dept. of Computer Engineering, Hansung University Java - Introduction.
Software Testing and QA Theory and Practice (Chapter 5: Data Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 4 Control Flow Testing
Type Checking, and Scopes
Compositional Pointer and Escape Analysis for Java Programs
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Java Programming Language
Software Testing and QA Theory and Practice (Chapter 5: Data Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Presentation transcript:

272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 16: Automated Interface Extraction

Software Interfaces Here are some basic questions about software interfaces –How to specify software interfaces? –How to check conformance to software interfaces? –How to extract software interfaces from existing software? –How to compose software interfaces? Today we will talk about some research that addresses these questions

Software Interfaces In this lecture we will talk about interface extraction for software components Interface of a software component should answer the following question –What is the correct way to interact with this component? –Equivalently, what are the constraints imposed on other components that wish to interact with this component? Interface descriptions in common programming languages are not very informative –Typically, an interface of a component would be a set of procedures with their names and with the argument and return types

Software Interfaces Let’s think about an object oriented programming language –You interact with an object by sending it a message (which means calling a method of that object) –What do you need to know to call a method? The name of the method and the types of its arguments What are the constraints on interacting with an object –You need a reference to the object –You have to have access (public, protected, private) to the method that you are calling One may want to express other kinds of constraints on software interfaces –It is common to have constraints on the order a component’s methods can be called For example: a call to the consume method is allowed only after a call to the produce method –How can we specify software interfaces that can express such constraints?

Software Interfaces Note that object oriented programming languages enforce one simple constraint about the order of method executions: –The constructor of the object must be executed before any other method can be executed –This rule is very static: it is true for every object of every class in every execution We want to express restrictions on the order of the method executions –We want a flexible and general way of specifying such constraints

Software Interfaces First, I will talk about the following paper –``Automatic Extraction of Object-Oriented Component Interfaces,'' J. Whaley, M. C. Martin and M. S. Lam Proceedings of the International Symposium on Software Testing and Analysis, July –The following slides are based on the above paper and the slides from Whaley’s webpage

Automatic Interface Extraction The basic idea is to extract the interface from the software automatically –Interface is not written as a separate specification There is no possibility of inconsistency between the interface specification and the code since the interface specification is extracted from the code The extracted interface can be used for dynamic or static analysis of the software It can be helpful as a reverse engineering tool

What are Software Interfaces In the scope of the work by Whaley et al. interfaces are constraints on the orderings of method calls For example: –method m1 can be called only after a call to method m2 –both methods m1 and m2 have to be called before method m3 is called

How to Specify the Orderings Use a Finite State Machine (FSM) to express ordering constraints States correspond to methods Transitions imply the ordering constraints M2M1 Method M2 can be called after method M1 is called

open S TART read write close E ND Example: File There are two special states Start and End indicating the start and end of execution

open S TART read write close E ND m1(); m2() is legal, new state is m2 m1m2 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.

The Interface Model Note that this is a very simple model It only remembers what the last called method is There is no differentiation between different invocations of the same method This simple model reduces the number of possible states Obviously all the orderings cannot be expressed this way

Adding more precision With above model we cannot express constraints such as –Method m1 has to be called twice before method m2 can be called We can add more precision by remembering the last k method calls –If we have n methods this will create n k states in the FSM Whaley et al. suggest other ways of improving the precision without getting this exponential blow up

The Interface Model If the only state information is the name of the last method called then what are the situations that this information is not precise enough? Problem 1: Assume that there are two independent sequences of methods that can be interleaved arbitrarily –once we call a method from one of the sequences we will lose the information about the other sequence Problem 2: Assume that there is a method which can be followed by all the other methods –then once we get to that method any following behavior is possible independent of the previous calls

Problem 1 Consider the following scenario –An object has two fields, a and b –There are four methods set_a(), get_a(), set_b(), get_b() –Each field must be set before being read We would like to have an interface specification that specifies the above constraints –Can we build an FSM that corresponds to these constraints?

Problem 1 These kind of constraints create a problem because once we call the set_a method it is possible to go to any other method –FSM does not remember the history of the method calls –FSM only keeps track of the last method call Solution: Use one FSM for each field and take their product set_a get_a set_b get_b S TART set_aget_aset_bget_bE ND set_a get_b FSM below allows the following sequence: start; set_a(); get_b();

set_a get_a set_b get_b S TART set_aget_aset_bget_bE ND S TART set_bget_bE ND S TART set_a get_a E ND ImpreciseAdds more precision Splitting by fields Separate the constraints about different fields into different, independent constraints: –Use multiple FSMs executing concurrently (or use a product FSM)

S TART set_a,start E ND get_a,start set_a,set_bget_a,get_bstart,set_b start,get_b get_a,set_bset_a,get_b There is a transition from each state to the END state The product FSM does not allow the following sequence: start; set_a(); get_b(); Product FSM

Product FSM has more number of states than the FSM which just remembers the last call Assume that there are n 1 methods for field 1 and n 2 methods for field 2 –simple FSM n 1 + n 2 states –product FSM n 1  n 2 states Note that the number states in the product FSM will be exponential in the number of fields

Problem 2 It is common to have methods which are used to query the state of an object These methods do not change the state of the object After such state-preserving methods (aka query methods) all other methods can be called –Calling a state preserving method does not change the state of the object –If a method can be called before a call to a state preserving method, then it can be called after the call to the state preserving method –Since only information we keep in the FSM is the last method call, if there exists an object state where a method can be called, then that method can also be called after a call to a state-preserving method

Problem 2 getFileDescriptor is state- preserving Once getFileDescriptor is called then any behavior becomes possible The FSM for Socket allows the sequence: start; getFileDescriptor(); connect(); Solution –distinguish between state-modifying and state- preserving methods –Calls to state-preserving methods do not change the state of the FSM start S TART create E ND connect close getFileDescriptor S TART getFileDescriptorconnect FSM for Socket

State-preserving methods start S TART create E ND connect close S TART getFileDescriptor m1 is state-modifying m2 is state-preserving m1(); m2() is legal, new state is m1 m1m2 Calls to state-preserving methods do not change the state of the FSM

Summary of Model Product of FSMs –Per-thread, per-instance One submodel per field –Use static analysis to find the methods that either read the value of the field or modify the value of the field. Identifies the methods that belong to a submodel –The methods that read and write to a field will be in the FSM for that field Separates state-modifying and state-preserving methods. One submodel per Java interface –Implementation not required

Extraction Techniques StaticDynamic For all possible program executionsFor one particular program execution ConservativeExact (for that execution) Analyze implementationAnalyze component usage Detect illegal transitionsDetect legal transitions Superset of ideal model (upper bound) Subset of ideal model (lower bound)

Static Model Extraction Static model extraction relies on defensive programming style Programmers generally put checks in the code that will throw exceptions in case the methods are not used in the correct order Such checks implicitly encode the software interface The static extraction algorithm infers the method orderings from these checks that come from defensive programming

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(); } S TART connectread connection

Extracting Interface Statically The static algorithm has two main steps 1.For each method m identify those fields and predicates that guard whether exceptions can be thrown 2.Find the methods m’ that set those fields to values that can cause the exception This means that immediate transitions from m’ to m are illegal Complement of the illegal transitions forms the model of transitions accepted by the static analysis

Detecting Illegal Transitions Only support simple predicates –Comparisons with constants, null pointer checks The goal is to find method pairs such that: –Source method executes: field = const ; –Target method executes: if (field == const) throw exception;

Algorithm How to find the target method: Control dependence –Find the following predicates: A predicate such that throwing an exception is control dependent on that predicate This can be done by computing the control dependence information for each method –For each exception check if the predicate guarding its execution (i.e., the predicate that it is control dependent on) is a single comparison between a field of the current object and a constant value the field is not written in the current method before it is tested –Such fields are marked as state variables

Algorithm The second step looks for methods which assign constant values to state variables How to find the source method: Constant propagation –Does a method set a field to a constant value always at the exit? If we find such a method and see that –that constant value satisfies the predicate that guards an exception in an other method then this means that we found an illegal transition

Sidenote: Control Dependence A statement S in the program is control dependent on a predicate P (an expression that evaluates to true or false) if the evaluation of that predicate at runtime may decide if S will be executed or not For example, in the following program segment if (x > y) max:=x; else max:=y; the statements max:=x; and max:=y; are control dependent on the predicate (x > y) A common compiler analysis technique is to construct a control dependence graph –In a control dependence graph there is an edge from a node n 1 to another node n 2 if n 2 is control dependent on n 1

Sidenote: Constant Propagation Constant propagation is a well-known static analysis technique Constant propagation statically determines the expressions in the program which always evaluate to a constant value Example y:=0; if (x > y) then x:=5; else x:=5+y; z := x*x; The assigned value to z is the constant 25 and we can determine this statically (at compile time) Constant propagation is used in compilers to optimize the generated code. –Constant folding: If an expression is known to have a constant value, it can be replaced with the constant value at compile time preventing the computation of the expression at runtime.

Static Extraction Static analysis of the java.util.AbstractList.ListItr with lastRet field as the state variable The analysis identifies the following transitions illegal: –start  set –start  remove –remove  set, add  set –remove  remove –add  remove The interface FSM contains all the remaining transitions

next, previous S TART set remove add Automatic documentation Interface generated for java.util.AbstractList.ListItr

Dynamic Interface Extractor Goal: find the legal transitions that occur during an execution of the program Java bytecode instrumentation –insert code to the method entry and exits to track the last-call information For each thread, each instance of a class: –Track last state-modifying method for each submodel.

Dynamic Interface Checker Dynamic Interface Checker uses the same mechanism as the dynamic interface extractor –When there is a transition which is not in the model instead of adding it to the model it throws an exception

Experiences Whaley et al. applied these techniques to several applications ProgramDescriptionLines of code Java.net 1.3.1Networking library12,000 Java libraries 1.3.1General purpose library300,000 J2EE 1.2.1Business platform900,000 joeqJava virtual machine65,000

start S TART begin E ND suspend resume rollbackcommit J2EE TransactionManager (dynamic) An example FSM model that is dynamically generated and provides a specification of the interface Automatic documentation

Test coverage Dynamically extracted interfaces can be used as a test coverage criteria The transitions that are not present in the interface imply that those method call sequences were not generated by the test cases For example, the fact that there are no self-edges in the FSM on the right implies that only a max recursion depth of 1For example, the fact that there are no self-edges in the FSM on the right implies that only a max recursion depth of 1 was tested increaseRecursionDepth decreaseRecursionDepth increaseRecursionDepth simpleWriteObject S TART E ND J2EE IIOPOutputStream (dynamic)

Upper/lower bound of model start S TART create E ND connect available getInputStream getOutputStream close SocketImpl model (dynamic) (+static) getFileDescriptor Statically generated transitions provide an upper approximation of the possible method call sequences Dynamically generated transitions provide a lower approximation of the possible method call sequences

S TART load prepare compile Expected API for jq_Method: S TART load prepare compile Actual API for jq_Method: setOffset Finding API bugs Automated interface extraction can be used to detect bugs The interface extracted from the joeq virtual machine showed unexpected transitions

Summary: Automatic Interface Extraction Product of FSM –Model is simple, but useful Static and dynamic analysis techniques –Generate upper and lower bounds for the interfaces Useful for: –Documentation generation –Test coverage –Finding API bugs

Automated Interface Extraction, Continued There has been a lot of work on automated interface extraction. Here is another more recent work on interface extraction –"Static Specification Mining Using Automata-Based Abstractions" Sharon Shoham, Eran Yahav, Stephen Fink, Marco Pistoia. International Symposium on Software Testing and Analysis (ISSTA 2007). I will discuss this work in the rest of the lecture.

Representing interfaces with automata In the earlier paper we discussed we saw a way to represent interfaces as state machines where the states represent the last called method and the transitions are not labeled Another way to represent interfaces is to use automata as an interface specification –The method names form the alphabet of the automata –The transitions are labeled with method names –An interface automaton accepts the allowable sequences of method calls

Representing interfaces with automata The automata representing the interface for the Java class Signature The method calls are represented by the transitions The paths from the initial state to accepting states identify the acceptable method call sequences s0s0 s1s1 s2s2 initSign initVerify update sign initSign initVerify initSign update verify initVerify Signature class interface s2s2

Component vs. Client-side extraction Work on interface extraction can be categorized as component-side or client-side extraction Component-side extraction: Analyze the component code and based on the error conditions in the component code (such as thrown exceptions) identify the illegal method call orderings –This was the approach used in the first paper we discussed Client-side extraction: Analyze a set of client-code that uses the component. Identify the ordering of method calls from the clients to the component and generate an interface that summarizes all the ways the clients interact with the component –This is the approach used in the second paper

Static Analysis for Interface Extraction The first paper we discussed used both static and dynamic analysis The second paper uses only static analysis to extract the interfaces There are many variants of static analysis (ones on the left are less precise variants): –intra-procedural vs. inter-procedural –flow-insensitive vs. flow-sensitive –context-insensitive vs. context-sensitive –without alias analysis vs. with alias analysis In the client-side interface extraction work they use the more precise variants –Static analysis techniques over-approximate program behavior, less precise analysis leads to more coarse approximation –Precise static analysis is more expensive takes more time and memory

Techniques for Interface extraction Heap abstraction: Combine the behavior of objects that are allocated at the same program location Trace abstraction: Merge states in the automaton that have equivalent past/future behaviors –Defined based on the sequences of incoming or outgoing transitions Merge: Merge automata with similar behavior –Similarity can be defines using past/future abstractions Noise Reduction: Remove transitions that are only observed in a small number of clients –Could be erroneous use of the API