Synthesis of Interface Specifications for Java Classes Rajeev Alur, Pavol Cern, P' Madhusudan, Wornh

1
Synthesis of Interface Specifications for Java
ClassesRajeev Alur, Pavol Cerný, P. Madhusudan,
Wornhong Nam

• Marchetti Davide
• davidema_at_student.ethz.ch
• ETH Zürich

2
(No Transcript)
3
Outline

• Motivation
• Global overview of JIST
• Predicate abstraction
• JIST Java Interface Synthesis Tool
• Interface synthesis
• Experiment

4
Motivation

• Today software development emphasizes components
  with clearly specified API
• Static interface
• But implicit constraints are given
• Dynamic interface
• How to deal safely with the class?

• class myStack
• public
• myStack(int n)
• void push(int i)
• int pop()

5
The JIST brief overview

• Set of automated tools and techniques to
  synthesize interfaces
• Given class C with set of method-calls M,
  exception E
• A (dynamic) interface
• small set of rules
• capture the correct sequences of method calls so
  that E is not raised
• JIST extracts small interface automatically using
  boolean abstraction and solving games over the
  boolean model

6
Symbolic class (I) formal definition
Finite set of methods
Finite set of variables
C ( M, X, Dxx?X, Xr, Init, Tmm?M, Rmm?M )
Transition relation for the method m
Return predicate for the method m
7
Symbolic class (II)
when m is invoked in a state s, Tm is applied
repeatedly until a return state s satisfying Rm
is reached
Tm
Tm
Tm
State
Tm
Exception predicate E set of bad states
8
Interface (I) formal definition
set of all possible valuations of Xr
Finite set of methods

• Representation finite state automaton

I (M x Sr) ? 2M
Set of methods that can be invoked
9
Interface (II) example

• Class Signature from package java.security
• initSign(), initVerify(), sign(), verify(),
  update()
• A DFA over the alphabet (M x Sr) is used

q0
Simplified!
initVerify()
initSign()
update() verify() initVerify()
update() sign() initSign()
initSign()
q2
q1
initVerify()
10
Predicate abstraction (I)

• Given (concrete) class C (with infinite possible
  states) and set of abstraction predicates P
• Result conservative abstract class A with
• Finite number of states
• Same set of methods
• Abstract domain is the set 0,1,
• Abstract class is nondeterministic

11
Predicate abstraction (II) Example

• int x, y
• if (x gt 0)
• y x 1
• else
• y x 1

• bool bx, by
• if (bx)
• by true
• else
• by // true, false

bx x gt 0
by y gt 0
12
JIST complete tool chain
Predicates
Exception Predicate E
Tool chain
Predicate Abstractor
Interface Synthesis
Game Lang. Convertor
Java
Java byte code
Jimple
Boolean Jimple
NuSMV Lang.
Interface Automaton
Soot
Partial Information Game Solving
Symbolic Class
Boolean Symbolic Class
Interface
Abstraction
Concept chain
13
Partial information two player game (I)

• Player 0 the user of the class
• Chooses to invoke one method
• Player 1 the abstract class
• Chooses a corresponding possible execution
  through the abstract state-transition graph
  (nondeterministic)

Player 1
Player 0
m,r
m,r
m
14
Partial information two player game (II)

• Player 0
• Doesnt know current abstract state
• Has to choose next method based on history of
  invoked methods and return values
• Winning strategy
• If the game always stays away from the abstract
  states satisfying the requirement E (exception E
  will be raised)

m,r
m,r
m
15
Using JIST to synthesize interfaces
Exception Abstraction predicates
Java
Most Permissive?
JIST
Yes
No
Interface
Method Call seq.
Adequate?
Yes
No
Safe?
No
Yes
16
Interface Synthesis (I)

• Old (standard) method generate a new
  complete-information game
• But cost in computation is too high (exponential
  time)
• New idea use L algorithm
• Learning algorithm
• Asks two kinds of queries to a teacher
• Membership queries string s is in U
• Equivalence queries L equal U?
• Complexity number of queries dependent on final
  automaton polynomial time

17
Interface Synthesis (II) L algorithm
L algorithm
Membership query s ? L
Equivalence query L ? U
Subset query L ? U
Superset query L ? U

• NP-hard
• Heuristic method
• Check stronger property ?
• If false, check some strings

18
Interface Synthesis (III) Subset query

• Subset query L(J) ? U
• Equal to ask if J is safe
• Use a CTL model checker
• State-space interaction SAJ tA, tJ x M x
  S x Q
• state s ? SAJ ( tA, m, sA, q)
• Transitions?

States of abstract class A
States of interface J
Currently executing method
19
Subset query (II)
Interface J
Abstract class A
m
m
m

• Initially
• interface has turn, selects method m ? LM(q0).
• Then pass turn to abstract class

20
Subset query (III)
Interface J
Abstract class A
m
m
m

• A gets turn.
• m is simulated.
• Turn kept until state satisfying Rm reached.
• Turn passed to J with return value r sAXr

21
Subset query (IV)
Interface J
Abstract class A
m
m
m
m

• J gets turn
• Changes state to q
• Picks new method m ? LM(q)
• Then turn passed to A and stages are repeated

22
Subset query (V)

• CTL model checker check CTL specification
• AG(E)
• If true, then J is safe and subset query is true
• Else
• Counter-example string s ?L(J) \ U

23
Superset query (I)

• Superset query L(J) ? U
• Need to check ?s, s ? L(J) ? s ? U (some)
• NP-hard
• Stronger property ?
• ?s ? L(J), all corresponding runs of A do not
  stay within safe set
• Define new interaction AJ
• Legal method sequences in J followed by at most
  one method not allowed
• State-space interaction SAJ tA, tJ x M
  x S x Q x 0, 1
• Transitions?

bool legal
24
Superset query (II)
Interface J
Abstract class A
m
m, not legal
m
m, legal

• Initially
• interface has turn, selects method m. If m ?
  LM(q0) legal 1, else
• legal 0.
• Then pass turn to abstract class

25
Superset query (III)
Interface J
Abstract class A
m
m, not legal
m
m, legal

• A gets turn
• m is simulated as for AJ
• If legal 0 then model halts (turn will not be
  passed to J)
• else turn passed to J with return value r
  sAXr

26
Superset query (IV)
Interface J
Abstract class A
m
m
m, not legal
m
m, r
m
m

• Eventually J gets turn
• legal is 1
• Moves from q to q d(q, (m,r))
• Picks new method m ? M, sets legal 0 iff m ?
  LM(q)
• Pass turn to A

27
Superset query (V)

• CTL model checker check CTL specification
• AG((legal 0 ? turn tJ) ? EF E)
• If AJ satisfies the CTL specification, then
• Teacher answers true
• L algorithm stops and reports most permissive
  safe interface
• otherwise
• Counter-example

28
Experiment (I)

• class ListItr
• next(), previous(), remove(), set(), add()
• First try using only 1 predicate
• lastRet -1
• Safe, but too much restrictive!

(next, ) (prev, ) (add, )
29
Experiment (II)

• class ListItr
• Second try using 2 predicates
• lastRet -1, cursor -1

(next,0) (add,0) (set,1)
(next,1),(prev,1) (prev,0),(set,1)
(prev,0)
(prev, 1)
(next,1) (prev,1)
(prev,0)
(next,0), (add,0)
(prev,1) (next,1)
(remove,1) (add,1)
(prev, 0)
(remove,1)
(add, 1)
(next,0), (add, 0)
(add, 1)
(next,0), (add, 0)
30
Experiment (III)
q0

• class Signature
• 3 predicates state UNINITIALIZED, state
  SIGN, state VERIFY
• With programming error in the initSign method we
  get

initVerify()
initSign()
update() verify() initVerify()
update() sign() initSign()
initSign()
q2
q1
initVerify()
q0
initSign()
initVerify()
update() verify() initVerify()
update() initSign()
initSign()
q2
q1
initVerify()
31
Conclusion

• Prototype show promising results
• Idea can be (maybe) used in other contexts
• BUT many direction to improve
• For now only tiny subset of Java is supported
• Only simple forms of abstract predicates is
  supported

32
The JIST how?

• Safe set corresponds to requirements like
  exception E is never raised
• Dynamic interfaces can help programmers to write
  client code for the class
• Resulting interface not always the most
  permissive one
• Interface represented as a finite state automaton

Java Class
Safe set
JIST
Interface
33
Much deeper Abstraction algorithm

• WP(st, P) is the weakest precondition whose
  truth before a statement st entails the truth of
  P afterwards
• Assume(P) silently terminates if P evaluate to
  false
• Implies(Pr)(P) is the best boolean function on
  Pr that implies P, i.e. Implies(Pr)(P) gt P, and
  if F is a boolean function on Pr such that F gt
  P, then F gt Implies(Pr)(P)
• ImpliedBy(Pr)(P)
• Statement st is abstracted into a sequence of
  commands (one for each predicate p in Pr)
• b(p) Implies(Pr)(WP(st,p)) ? True
• Implies(Pr)(WP(st, not p)) ? False

34
Abstracting Jimple programs

• Jimple program gt symbolic class
• Boolean Jimple gt only boolean or enumerated vars
• Abstractor work on a subset of Jimple
• Not floating-point types, no arrays, no
  recursion, no other exception
• Abstraction algorithm proceeds line by line
• Predicate form x k
• b(x,k), domain is 0,1,

35
Abstraction algorithm example

• Statement st is abstracted into a sequence of
  commands
• Example
• x y 1. For each predicate (x,k)
• If (y,k-1) is in the predicate list
• b(x,k) b(y,k-1)
• else
• if( (b(y,l1) True) (b(y,l2) True)
  (b(y,ln) True) )
• b(x,k) False
• else
• b(x,k)