Design for Verification for Concurrent and Distributed Programs

1
Design for Verificationfor Concurrent and
DistributedPrograms

• PhD Defense
• Aysu Betin-Can
• September 23, 2005

2
Design for Verification

• Objective
• Making the automated software verification
  techniques scalable to large systems
• Design for Verification (DFV)
• Design the software system in a way that
• embeds the intentions of developers into software
  
• makes software systems amenable to automated
  verification

3
Outline

• Design for Verification (DFV) approach
• DFV for concurrent programming
• Concurrency controller pattern
• Thread Isolation
• Case studies
• DFV for asynchronously communicating web services
• Peer controller pattern
• Hierarchical interfaces
• Experiments
• Summary of contributions

4
DFV Approach

• Use of stateful behavioral interfaces
• Isolation of the behavior and support modular
  verification
• Domain specific verifiable design patterns
• An assume-guarantee style verification strategy
• Interface verification
• Behavior verification
• A general model checking technique for interface
  verification
• Domain specific and specialized verification
  techniques for behavior verification

5
System Architecture
Multithreaded and/or distributed program based
on a DFV pattern
Behavior spec
Automated Behavior Translator
Domain Specific Model Checker
Thread Isolation and Stub Substitution
Verified
Error trace
Controllers
Java PathFinder
Notification Optimizer
Isolated program
Interfaces
Counting Abstraction
Optimized concurrency controller
Synchronizability Analyzer
Rest of the program
BPEL and WSDL for web services
BPEL Generator
6
Verifiable Design Patterns

• Concurrency Controller Pattern BCB04
• Goal Eliminating synchronization errors
• Verification
• Behavior using Action Language Verifier BYK01
• Specialization Counting abstraction
• Peer Controller Pattern BCBF05
• Goal Analyzing interaction properties and
  assuring conformance of service implementations
  to their specifications
• Verification
• Behavior using SPIN Hol97
• Specialization Synchronizability analysis
  FBS04
• Interface verification Java PathFinder
  VHBP03 with stubs

7
Verification Approach

• Assume-guarantee style verification based on
  behavioral interfaces
• Assuming interface correctness during behavior
  verification
• Guaranteeing the interface correctness
• Combination of strengths of different model
  checking techniques
• Specialized model checkers with their own
  specification language
• Model checkers targeted to a programming language
• Thread isolation and modular interface
  verification

8
DFV of Concurrent Programming

• Concurrency Controller Pattern
• Decoupling of concurrency behavior from user
  threads
• Application to real-life concurrent software
• Concurrent text editor Concurrent Editor
• Air traffic control software TSAFE
• Thread isolation
• Closing the environment of a thread
  conservatively
• Thread-modular interface verification

9
Concurrent Editor
Server
ltltRMIgtgt
10
Concurrent Editor
2800 lines of code with 17 Java classes and 4
concurrency controllers
11
Tactical Separation Assisted Flight Environment
(TSAFE)
ltltTCP/IPgtgt
User
Server
Radar feed
Client
EventThread
ltltRMIgtgt
21,057 lines of code with 87 classes and 2
concurrency controllers
12
Concurrency Controller Pattern
ThreadA
SharedInterface
ThreadB
int
used at runtime
used at interface verification
used all times
13
Controller Interfaces
produce_acquire
release
consume_acquire
Bounded buffer with Mutex Controller Interface
Reader-Writer Controller Interface
acquire
b_enter
release
b_exit
Barrier Controller Interface
Mutex Controller Interface
14
Modular Verification (1)

• Behavior verification
• Analyzing properties of the synchronization
  policy encapsulated with a concurrency controller
  and its interface
• Assuming threads obey interfaces
• Behavior verification with Action Language
  Verifier
• Infinite state symbolic model checker
• Suitable for specifications with unbounded
  variables and parameterized constants
• Translation to Action Language BY01
• Counting abstraction Del00YKB02
• Behavior verification for arbitrary number of
  threads

15
Modular Verification (2)

• Interface verification
• Does the thread invoke controller method in the
  order as defined with its interface?
• Does the thread access shared data only at
  correct interface state?
• Interface verification with Java PathFinder
• Arbitrary Java implementations of threads
• Property specification as assertions
• Look for assertion violations
• Assertions are embedded in StateMachine
• Improvement with Thread Isolation and interface
  usage

16
Thread Isolation

• Modeling thread influence on its environment with
  stubs
• File I/O, updating GUI components, socket
  operations, RMI call to another program
• Replace with pre-written or generated stubs
• Modeling environment influence on threads with
  drivers
• Thread initialization, RMI events, GUI events
• Enclose with drivers that generate all possible
  events that influence controller access

17
Thread Isolation

• Modeling thread-thread interactions with
  interfaces
• Concurrency controller action, shared data method
  invocation
• Replace concurrency controller with controller
  interface state machines
• Replace shared data with shared stubs
• Modeling asynchronous messaging with peer
  interfaces
• Communication controller, message classes
• Replace communication controller with peer
  interface state machines
• Replace messages with message stubs

18
Interface Verification Performance
19
Behavior Verification Performance
Concurrency controllers used in the
implementation of the Concurrent Editor and TSAFE
20
Experiment on TSAFE

• Experimental study on TSAFE with fault seeding
• Concurrency controller faults
• initialization faults, guard faults, update
  faults, blocking/nonblocking faults
• Interface faults
• modified-call faults, conditional-call faults,
  program variable faults, new-variable faults

21
Falsification Performance
22
DFV for Asynchronously Communicating Web Services

• Peer Controller Pattern
• Decoupling of application logic from
  communication details
• Application to several web service
  implementations
• Loan Approval, BookCD Order, Travel Agency,
  Purchase Order Handling
• Adapting synchronizability analysis FBS04
• Extension to hierarchical interfaces

23
Asynchronously Communicating Web Services

• Web services
• Web accessible software that can be described,
  published, located, and invoked over the Internet
  standard technologies
• Composite web services
• Loosely coupled interacting services through
  standard interfaces
• Opportunity for modular analysis
• Supporting asynchronous communication
• Undecidability in analysis FBS04
• Standard data transmission via XML

24
Loan Approval System
Messages request, approval,
risk check, nocheck
25
Loan Approval System
Messages request(amount), approval(accept),
risk(level) check(amount), nocheck()
26
Peer Controller Pattern
ApplicationThread
used at runtime
used at interface verification
used all times
27
Interfaces of Loan Approval
LoanApprover
CustomerRelations
Sample Conversation request(amountlarge),check(a
mountlarge), risk(levelhigh),
approval(acceptfalse)
RiskAssessor
28
Modular Verification (1)

• Interface verification
• Does each peer interact with others as specified?
• Interface verification with Java PathFinder
• Assertions embedded in StateMachine
• Abstracting asynchronous messaging by using peer
  interfaces as stubs
• Peer-modular interface verification
• Further reduction of state space with message
  stubs

29
Modular Verification (2)

• Behavior Verification
• Analyzing global interaction properties
• Modeling global behavior and properties as
  conversations Fu04
• Conversation The sequence of messages exchanged
  among peers, recorded in the order they are sent
• Sample Property Whenever a request with a small
  amount is sent, eventually an approval message
  accepting the loan request will be sent.
• Behavior verification with SPIN
• Translation to specification language of SPIN
  Hol97
• Peer interfaces are already a model of the system
• Finite state model checker
• Need to bind the message queue sizes

30
BookCD Service

• SPIN runs out of memory for queue size 15!!!
• Reachable state space is infinite
• Absence of error for queue size 15 does not
  ensure freedom of bugs!
• Not only unbounded queues, but also efficiency
• Solution Adapting synchronizability analysis

31
Synchronizability

• Model checking a composite web service that
  communicates asynchronously with unbounded queues
  is undecidable FBS03
• Automated Synchronizability analysis
• A composite web service is synchronizable, if it
  generates the same conversation set both under
  asynchronous and synchronous communication
  FBS04
• Promela with synchronous communication semantics
• No message buffering
• Reduced state space hence improved efficiency
• Enables unbounded behavior verification

32
Hierarchical Peer Interfaces

• A hierarchical state machine (HSM) model as
  behavioral interfaces of peers
• Finite state machine whose states can be
  composite or atomic states
• Advantages over flat finite state machines
• compact representation
• natural hierarchy of the service behavior
• exponentially less number of states and
  transitions
• specification of concurrent executions of
  operations

33
HSM Class Diagram
HSM
sendTransition() receiveTransition()
And
Or
substatesState defaultStateState
substatesState
SendTransition
guardExpGuardedUpdate
34
Example Travel Agency
HotelReserve
Customer
reqHotel
travelInv
TravelAgent
carInv
flightInv
FlightReserve
CarReserve
date place process transResv transNoResv
reqFlight
reqCar
hotelInv
35
HSM for TravelAgent Peer
?process
?transResv
!reqFlight
!reqCar
!travelInv
!reqFlight
?carInv
?flightInv
?transNoResv
36
Interface Verification Performance
Book-CD Order Service
Loan Approval Service
Travel Agency Service
Purchase Order Handling Service
37
Behavior Verification Performance
38
BPEL Generation

• A benefit of explicit peer interfaces
• Automated generation
• Both from flat peer interfaces and HSMs
• Mappings of send and receive transitions to BPEL
  activity blocks
• Hierarchy with scopes and flows
• Main activity block is
• a state machine

39
Summary of Contributions

• A DFV approach for concurrent programs and for
  asynchronously communicating web services
• Concurrency controller pattern
• Peer controller pattern
• An assume-guarantee style verification strategy
• Combining different model checking techniques
• Thread and peer isolation
• Experiments on 2 real-life concurrent systems
• Experiments on several composite web services
• Hierarchical interfaces
• Compact representation of the natural hierarchy
• Extended synchronizability analysis

40
Related Work

• Design for Verification
• MP03, Mehlitz et al. promote using design
  patterns and exploiting their properties
• Sharygina et al. SBK01 focus on verification of
  UML models
• Used in Circuit Design and Embedded Systems
  SF03, GSB02, SBBCM01
• Assume-guarantee style verification
• PDH99, CCGJV

41
Related Work

• Design Patterns for multi-threaded systems
• SSRB00, Lea99, Gra02,SPM96
• Verification and synthesizing monitors
• DDHM02, YKB02, MK99
• Environment extraction/generation
• PDH99,TD03, TDP03, extracts a model of the
  classes that influences a software unit

42
Related Work

• Model checking Web Services
• FBS04, Fu et al. use SPIN for composition check
• Global conversation
• FUMK03 , Foster et al.
• Composition behavior is specified with message
  sequence charts
• Behavioral Contracts of Peers
• too little, e.g. WSDL, or too powerful, e.g. BPEL
• State Machines Fu04
• Conformance check
• RR02, Rajamani et al. use SPIN for conformance
  check
• between specification model and a model extracted
  from implementation

43
Related Work

• Behavioral and stateful interfaces
• Interface compatibility checking CAHJM02
• Extended type systems with stateful interfaces
  and interface checking as a part of type checking
  DF01,DF04
• Interface discovery and synthesis by analyzing
  existing code WML02,ACMN05

44
Thank You
45
Extra slides
46
Synchronizability Conditions FBS04

• Autonomous Condition
• At any state a peer has exactly one of three
  choices send, receive or terminate
• Synchronous compatibility
• When one peer is ready to send a message, there
  should be another peer which is ready to receive
  that message
• Automated synchronizability analyzer
• Exploiting explicit peer interface implementations

47
Synchronizability Analyzer

• Analyzer checks the conditions on HSMs without
  flattening
• Autonomy check algorithm
• Transitions originating from a composite state
  have to be either all sends or all receives
• There are no configurations that follows a final
  configuration
• All transitions originating from a state are
  either send or receive transitions
• Synchronous compatibility
• Looking for violating configurations directly on
  HSMs by using next configuration computation

48
Reader-Writer Controller

• public void w_enter() act_w_enter.blocking()
• public boolean w_exit()
• return act_w_exit.nonblocking()
• public void r_enter() act_r_enter.blocking()
• public boolean r_exit()
• return act_r_exit.nonblocking()

• class RWController implements RWInterface
• int nR boolean busy
• final Action act_r_enter, act_r_exit
• final Action act_w_enter, act_w_exit
• RWController() ...
• gcs new Vector()
• gcs.add(new GuardedCommand()
• public boolean guard()
• return (nR 0 !busy )
• public void update()
• busy true )
• act_w_enter new Action(this,gcs)
• ..//other actions

49
Action Class

• class Action
• protected final Object owner
• private boolean GuardedExecute()
• boolean resultfalse
• for(int i0 iltgcV.size() i)
• try
• if(((GuardedCommand)gcV.get(i)).guard())
• ((GuardedCommand)gcV.get(i)).update()
• resulttrue break
• catch(Exception e)
• return result

• public void blocking()
• synchronized(owner)
• while(!GuardedExecute())
• tryowner.wait()catch (Exception e)
• owner.notifyAll()
• public boolean nonblocking()
• synchronized(owner)
• boolean resultGuardedExecute()
• if (result) owner.notifyAll()
• return result

50
Reader-Writer Controller

• module main()
• integer nR boolean busy
• module RWController()
• enumerated pc IDLE , READING, WRITING
• initial nR 0 and busy false
• initial pcIDLE
• r_enter_0 pcIDLE and ( ! busy ) and
  nR' nR 1 and pc'READING
• r_exit_0 pcREADING and true and nR'
  nR - 1 and pc'IDLE
• r_exit_1 pcREADING and !( ( true)) and
  pc' IDLE
• w_enter_0 pcIDLE and ( nR 0 and !
  busy ) and busy' true
• and pc'WRITING
• w_exit_0 pcWRITING and true and busy'
  false and pc'IDLE
• w_exit_1 pcWRITING and !( ( true)) and
  pc' IDLE
• RWControllerw_enter_0 w_exit_0 w_exit_1
  r_enter_0 r_exit_0 r_exit_1
• endmodule
• main RWController() RWController()
  RWController() RWController()
• endmodule

51
Abstract Reader-Writer

• module main()
• integer nR boolean busy
• parameterized integer numInstance
• module RWController()
• integer IDLE , READING, WRITING
• initial nR 0 and busy false
• initialIDLEnumInstance and READING 0
  and WRITING 0
• restrict IDLE READING
  WRITINGnumInstance and numInstancegt0
• r_enter_0IDLEgt0 and ( ! busy ) and nR'
  nR 1
• and READING'READING1
  and IDLE' IDLE-1
• r_exit_0READINGgt0 and true and nR'
  nR - 1 and IDLE'IDLE1
• and READING' READING-1
• r_exit_1 READINGgt0 and !( ( true)) and
  IDLE' IDLE1
• and READING' READING-1
• .//other actions
• RWControllerw_enter_0 w_exit_0 w_exit_1
  r_enter_0 r_exit_0 r_exit_1
• endmodule
• main RWController()
• endmodule

52
Concurrency Controller Interface

• public class RWStateMachine implements
  RWInterface
• StateMachine sm
• final static int IDLE0, READING1, WRITING2
• public RWStateMachine() ...
• sm.insert(
• "w_enter",IDLE, WRITING)
• .//other transitions
• public void w_enter()
• sm.transition("w_enter")
• ...

r_enter
READING
r_exit
IDLE
w_exit
WRITING
w_enter
53
Communication Servlet Example

• public class ApproverServlet extends PeerServlet
  implements AppServlet
• private Endpoint customernew Endpoint("urnCusto
  merRelations")
• private Endpoint mypointnew Endpoint("urnLoanAp
  prover")
• .....
• public Object approved(int sessionId, int peer,
  Object args)
• SOAPMessage msgsuper.wrap(sessionId,MSG_approv
  ed,peer,args)
• super.send(msg,customer,mypoint)
• return null
• public Object receive(int sessionId)
• return approver.getMessage(sessionId)
• public void onMessage(SOAPMessage message)
• MessageFields fieldsunwrap(message)
• approver.putMessage(fields)

54
CommunicatorStub Example

• public class CommunicatorStub implements
  LoanApprover
• private StateMachine sm
• private ApprovalMessage aproval
• private RequestMessage request
• public CommunicatorStub()
• smnew StateMachine(..)
• GuardedUpdate gcnew GuardedUpdate()
• public boolean guard()
• return last_risk.level()Low
• public boolean update()
• return approval.accepttrue
• SendTransition trans new SendTransition(appro
  val,3,5,gc)
• sm.addTransition(trans)
• ReceiveTransition rtrans new
  ReceiveTransition (request,0,1)
• sm.addTransition(rtrans)

55
Promela for Loan Approval

• do
• state0 -gtif
• approverQ?requestType,msg-gt
• approverQ?requestType,msg
• requestmsg.amountmsg.requestmsg.amount
• /update/
• state1
• fi
• state3 -gt if
• riskmsg.levellow -gt /guardV/
• approvalmsg.accepttrue/guardP/
• msg.approvalmsg.acceptapprovalmsg.accept
  
• atomic
• lastmsg.approvalmsg.accept
• approvamsg.accept/update
  /
• customerQ!approvalType,msg
• state5
• riskmsg.levelhigh -gt /guardV/
• approvalmsg.acceptfalse/guardP/

• define size 5
• mtype requestType, approvalType,
• nocheckType, checkType, riskType
• /data domains/
• mtype undef1,small,large//amount
• mtype undef2,low,high//level
• /message types/
• typedef approval bool accept
• typedef request mtype amount
• typedef risk mtype level
• ....
• message lastmsg
• /channels/
• chan customerQsize of mtype, message
• chan approverQsize of mtype, message
• chan assessorQsize of mtype, message
• proctype CustomerRelations()...

56
HSM for TravelAgent Peer
?process
?transResv
!reqFlight
!travelInv
!reqCar
!reqFlight
?carInv
?flightInv
?transNoResv
?msg
57
HSM for TravelAgent Peer
?process
?transResv
!reqFlight
!reqCar
!travelInv
!reqFlight
?carInv
?flightInv
?transNoResv
!msg
58
Transition Mappings

• ltsequencegt
• ltreceive partnerLink"RiskAssessor"
  portType"ns2ApproverPT"
• operation"ns2risk" variable"risk"gt
• lt/receivegt
• ltassigngtltcopygt
• ltfrom expression"'3'"/gt
• ltto variable"state"/gt
• lt/copygtlt/assigngt
• lt/sequencegt

59
Transition Mappings

• ltcase condition"getVariableData('risk',
  'level')'low'"gt
• ltsequencegt
• ltassigngtltcopygt
• ltfrom expression"'true'"/gt
• ltto variable"approval" part"accept"/gt
• lt/copygtlt/assigngt
• ltinvoke partnerLink"CustomerRelations"
• portType"ns1CustomerPT"
• operation"ns1approval"
• inputVariable"approval"gt
• lt/invokegt
• ltassigngt ltcopygt
• ltfrom expression"'5'"/gt ltto
  variable"state"/gt
• lt/copygt lt/assigngt
• lt/sequencegt
• lt/casegt