Design for Verification for Concurrent and Distributed Programs

1
Design for Verificationfor Concurrent and
DistributedPrograms

• Dr. Aysu Betin Can
• Department of Computer Science
• University of California, Santa Barbara
• aysu_at_cs.ucsb.edu
• http//www.cs.ucsb.edu/aysu

2
Motivation

• Automated software verification
• Reliable, consistent and correct software
• Important for safety critical software systems
• Bridge between programmers and software
  verification techniques
• Write a model of the program in a specification
  language -- unlikely
• Automated model extraction -- difficult

3
Design For Verification

• Structure software in ways that facilitate
  verification
• Embed the intention of the programmer into design
  and code
• Making automated software verification techniques
  scalable to large systems
• Encourage automated software verification
• Novice programmer can apply without model
  checking background

4
Outline

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

5
DFV Approach

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

6
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
7
DFV for Asynchronously Communicating Web Services
WWW05

• Goal Analyzing interaction properties and
  assuring that services conform to their published
  specifications
• Peer Controller Pattern
• Decoupling of application logic from
  communication details with peer interfaces
• Application to several web service
  implementations
• Loan Approval, BookCD Order, Travel Agency,
  Purchase Order Handling
• Domain specific functionality
• Adapting synchronizability analysis
• BPEL generation
• Extension to hierarchical interfaces

8
Loan Approval System
Messages request, approval,
risk check, nocheck
9
Loan Approval System
Messages request(amount), approval(accept),
risk(level) check(amount), nocheck()
10
Peer Controller Pattern
ApplicationThread
used at runtime
used at interface verification
used all times
11
Interfaces of Loan Approval
LoanApprover
CustomerRelations
Sample Conversation request(amountlarge),check(a
mountlarge), risk(levelhigh),
approval(acceptfalse)
RiskAssessor
12
Interface Verification

• Does each peer interact with others as specified?

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()eturn
approval.accepttrue SendTransition
trans new SendTransition(approval,3,5,gc)
sm.addTransition(trans) ReceiveTransition
rtrans new ReceiveTransition (request,0,1)
sm.addTransition(rtrans)
CommunicationInterface for LoanApprover
13
Interface Verification Performance
Book-CD Order Service
Loan Approval Service
Travel Agency Service
Purchase Order Handling Service
14
Behavior Verification

• Analyzing global interaction properties
• Modeling global behavior and properties as
  conversations Fu04

define size 5 mtype requestType, approvalType,
nocheckType, checkType, riskType
/message types/ typedef approval bool
accept .... message lastmsg /channels/ chan
customerQsize of mtype, msg chan
approverQsize of mtype, msg chan
assessorQsize of mtype, msg proctype
CustomerRelations()... proctype
RiskAssessor()... proctype LoanApprover()
short state0 approval approvalmsg ..

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

15
Behavior Verification (2)

• Sample conversation property
• Whenever a request with a small amount is sent,
  eventually an approval message accepting the loan
  request will be sent
• G(request(amountsmall) ? F(approval(accepttrue))
  )

16
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!
• Issue is not only unbounded queues, but also
  efficiency
• Solution Adapting synchronizability analysis

17
Synchronizability

• Synchronizability analysis FBS04
• if a composition is synchronizable, then
• Verify web services efficiently by replacing
  communication channels with channels of size 0
  (i.e., synchronous communication)
• No message buffering
• Verification results hold for unbounded channels

18
Behavior Verification Performance
19
Hierarchical Peer Interfaces
19 states and 13 transitions vs. 35 states and 78
transitions
ICWS05, also invited to JWSR
20
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

21
DFV of Concurrent Programming
ASE04 and ASE05

• Goal Eliminating synchronization errors
• 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

22
Concurrent Editor
Server
ltltRMIgtgt
23
Concurrent Editor
2800 lines of code with 17 Java classes and 4
concurrency controllers
24
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
25
Concurrency Controller Pattern
ThreadA
SharedInterface
ThreadB
int
used at runtime
used at interface verification
used all times
26
Reader-Writer Controller
This helper class is provided, no need to rewrite
it

• 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()

• 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)
• public void w_enter()
• act_w_enter.blocking()
• public boolean w_exit()
• return act_w_exit.nonblocking()
• public void r_enter()

27
Concurrency Controller Pattern
ThreadA
SharedInterface
ThreadB
int
used at runtime
used at interface verification
used all times
28
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
29
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
30
Behavior Verification

• Analyzing properties of the synchronization
  policy encapsulated with a concurrency controller
  and its interface

module main() integer nR boolean busy
module RWController() enumerated pc IDLE
, READING, WRITING initial nR 0 and
busy false and 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() endmodule
Reader-Writer Controller
31
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 numInstance gt 0
• 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
• .//other actions
• RWControllerw_enter_0 w_exit_0 w_exit_1
  r_enter_0 r_exit_0 r_exit_1
• endmodule
• main RWController()
• endmodule

32
Three Types of Controller Properties

• Properties that only refer to controller
  variables
• AG(busy gt nR0)
• AG(busy gt AF(!busy))
• Properties that refer to interface states
• AG(pcWRITING gt AF(pcIDLE)
• AG(pcREADING gt nR gt 0)
• Properties for arbitrary number of threads
• AG(WRITING gt 0 gt AF(IDLE gt 0)
• AG(READING nR)

33
Behavior Verification Performance
Concurrency controllers used in the
implementation of the Concurrent Editor and TSAFE
34
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?

public class BufferImpl implements Buffer
RWInterface controller public
BufferImpl(RWInterface c) controllerc
public void put() assert(controller.inState
( RWStateMachine.WRITING))
...

• 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")
• ...

35
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

36
Interface Verification Performance
37
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

ASE05 (Best paper and ACM distinguished paper
awards)
38
Falsification Performance
39
Summary

• A DFV approach for concurrent programs and for
  asynchronously communicating web services
• Peer controller pattern
• Concurrency controller pattern
• An assume-guarantee style verification strategy
• Combining different model checking techniques
• Thread and peer isolation
• Experiments on 2 real-life concurrent systems and
  several composite web services

40
Future Directions

• Automated discovery of forgotten shared objects
• Concurrency controller pattern assumes each
  shared data is protected by a controller
• Verifying this assumption
• Escape analysis techniques
• More powerful properties for concurrency domain
• Extend to full CTL properties

41
Future Directions

• Application of DFV approach to other programming
  paradigms
• Sequential programming
• e.g., encapsulate mission critical components
• Aspect oriented programming
• Component-based development and verification
• More complex structures for controllers using
  theorem provers

42
Thank YouQuestions?
43
Related Work Design for Verification

• Design for Verification
• Magee, Kramer 99
• uses LTSA model checker for verification of
  finite state models of Java concurrent programs
• Sharygina, Browne, Kurshan FASE 01
• presents design rules for object-oriented design
  models to facilitate verification
• Mehlitz, Penix Workshop on Component-Based Soft.
  Eng. 03
• promotes using design patterns and exploiting
  their properties in verification

44
Related Work Design for Verification

• Design patterns for concurrency
• Schmidt, Stal, Rohmert, Buschmann 00, Lea 99,
  Grand 02
• Environment extraction/generation
• Godefroid, Colby, Jagadeesan PLDI 98, Tkachuk,
  Dwyer ASE 03, Tkachuk, Dwyer, Pasareanu
  ESEC/FSE 03
• Conformance checking for asynchronously
  communicating processes
• Rajamani, Rehof CAV02
• conformance checking between specification model
  and a model extracted from the implementation

45
Related Work Web Services

• Verification of web services
• Analysis of interacting BPEL web services Fu,
  Bultan, Su WWW04.
• Simulation, verification, composition of web
  services using a Petri net model Narayanan,
  McIlraith WWW02
• Using MSC to model BPEL web services which are
  translated to labeled transition systems and
  verified using model checking Foster, Uchitel,
  Magee, Kramer ASE03
• Model checking Web Service Flow Language
  specifications using Spin Nakajima ICWE04

46
(No Transcript)
47
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

48
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

49
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

50
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

51
Communication Controller 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)

52
Extra slides
53
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

54
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

55
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

56
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

57
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

58
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

59
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

60
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

61
HSM Class Diagram
HSM
sendTransition() receiveTransition()
And
Or
substatesState defaultStateState
substatesState
SendTransition
guardExpGuardedUpdate
62
HSM for TravelAgent Peer
?process
?transResv
!reqFlight
!reqCar
!travelInv
!reqFlight
?carInv
?flightInv
?transNoResv
63
HSM for TravelAgent Peer
?process
?transResv
!reqFlight
!travelInv
!reqCar
!reqFlight
?carInv
?flightInv
?transNoResv
?msg
64
HSM for TravelAgent Peer
?process
?transResv
!reqFlight
!reqCar
!travelInv
!reqFlight
?carInv
?flightInv
?transNoResv
!msg
65
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

66
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

67
Example Travel Agency
HotelReserve
Customer
reqHotel
travelInv
TravelAgent
carInv
flightInv
FlightReserve
CarReserve
date place process transResv transNoResv
reqFlight
reqCar
hotelInv