Structuring Software for Verifiability

1
Structuring Software for Verifiability

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• bultan_at_cs.ucsb.edu
• http//www.cs.ucsb.edu/bultan

2
Joint Work with My Students

• Interface Grammars
• Graham Hughes (PhD candidate)
• Design for verification
• Aysu Betin-Can (PhD 2005) Middle East Technical
  University
• Verification of Service Interactions
• Xiang Fu (PhD 2004) Georgia Southwestern State
  University
• (co-advised with Jianwen Su)
• Action Language Verifier
• Tuba Yavuz-Kahveci (PhD 2004) University of
  Florida, Gainesville
• Constantinos Bartzis (PhD 2004) Carnegie Mellon
  University

3
Outline
Action Language Verifier
Synchronizability Analysis
Design for Verification
enables
enables
uses
uses
Verification of Synchronization in
Concurrent Programs
Analyzing Web Service Interactions
type of
Interface Grammars
4
Action Language Verifier (ALV)
Action Language Specification CTL property
Action Language Parser
Composite Symbolic Library
Model Checker
Omega Library
CUDD Package
MONA
Counter-example
Verified
BDD Manipulator
Automata Manipulator
Presburger Arithmetic Manipulator
Not sure
5
Composite Symbolic Library
Symbolic

• intersect()
• union()
• complement()
• isSatisfiable()
• isSubset()
• pre()
• post()

CUDD Library
OMEGA Library
6
Composite Symbolic Library, Extended
Symbolic

• union()
• isSatisfiable()
• isSubset()
• forwardImage()

HeapSym
representation list of ShapeGraph

• union()

OMEGA
CUDD
MONA
7
Action Language

• A state based language
• Actions correspond to state changes
• States correspond to valuations of variables
• boolean
• enumerated
• integer (possibly unbounded)
• heap variables (i.e., pointers)
• Parameterized constants
• specifications are verified for every possible
  value of the constant

8
Action Language

• Transition relation is defined using actions
• Atomic actions Predicates on current and next
  state variables
• Action composition
• asynchronous () or synchronous ()
• Modular
• Modules can have submodules
• A module is defined as asynchronous and/or
  synchronous compositions of its actions and
  submodules

9
What Can One Do with ALV?

• Check if a specification satisfies a CTL property
• What type of specification?
• For example, specification of a concurrent
  program
• For example, Read-Write lock

integer nr boolean busy initial !busy and
nr0 r_enter !busy nr nr1 r_exit nr
nr-1 w_enter !busy nr0 busy
true w_exit busy false
10
Read-Write Lock in Action Language

• module main()
• integer nr
• boolean busy
• restrict nrgt0
• initial nr0 and !busy
• module ReaderWriter()
• enumerated state idle, reading, writing
• initial stateidle
• r_enter stateidle and !busy and nrnr1
  and statereading
• r_exit statereading and nrnr-1 and
  stateidle
• w_enter stateidle and !busy and nr0 busy
  and statewriting
• w_exit statewriting and !busy and
  stateidle

11
Arbitrary Number of Threads?

• What if we wish to check the read-write lock with
  respect to arbitrary number of threads?
• Counting abstraction
• Create an integer variable for each thread state
• Each variable counts the number of threads in a
  particular state
• Generate updates and guards for these variables
  based on the specification
• Counting abstraction is automated

12
Parameterized Read-Write Lock

• module main()
• integer nr
• boolean busy
• restrict nrgt0
• initial nr0 and !busy
• module ReaderWriter()
• enumerated state idle, reading, writing
• initial stateidle
• r_enter stateidle and !busy and nrnr1
  and statereading
• r_exit statereading and nrnr-1 and
  stateidle
• w_enter stateidle and !busy and nr0 busy
  and statewriting
• w_exit statewriting and !busy and
  stateidle

13
Parameterized Read-Write Lock
module main() integer nr boolean busy
parameterized integer numReaderWriter
restrict nrgt0 and numReaderWritergt1
initial nr0 and !busy module
ReaderWriter() integer idle, reading,
writing initial idlenumReaderWriter
r_enter idlegt0 and !busy and nrnr1
and idleidle-1 and readingreading1
r_exit readinggt0 and nrnr-1 and
readingreading-1 and
idleidle1 w_enter idlegt0 and !busy and
nr0 and busy and idleidle-1 and
writingwriting1 w_exit writinggt0 and
!busy and writingwriting-1 and
idleidle1 ReaderWriter r_enter
r_exit w_enter w_exit endmodule main
ReaderWriter() spec invariant(busy gt nr0)
spec invariant(busy gt eventually(!busy))
endmodule
14
Verification of Read-Write Lock with ALV
SUN ULTRA 10 (768 Mbyte main memory)
15
A Java Read-Write Lock Implementation

• class ReadWriteLock   private Object lockObj  
  private int totalReadLocksGiven  private boolean
   writeLockIssued  private int threadsWaitingForW
  riteLock  public ReadWriteLock()     lockObj 
   new Object()    writeLockIssued  false    
    public void getReadLock()     synchronized (lo
  ckObj)       while ((writeLockIssued)  (thread
  sWaitingForWriteLock ! 0))         try       
      lockObj.wait()         catch (InterruptedEx
  ception e)                     totalReadLock
  sGiven        public void getWriteLock() 
      synchronized (lockObj)       threadsWaiting
  ForWriteLock      while ((totalReadLocksGiven
   ! 0)  (writeLockIssued))         try      
       lockObj.wait()         catch (InterruptedE
  xception e)           //                   
   threadsWaitingForWriteLock--      writeLockIssu
  ed  true        public void done()     sy
  nchronized (lockObj)       //check for errors 
       if ((totalReadLocksGiven  0)  (!writeLock
  Issued))         System.out.println(" Error Inv
  alid call to release the lock")        return 
             if (writeLockIssued)        writeLoc
  kIssued  false      else        totalReadLocks
  Given--      lockObj.notifyAll()      
  

16
Checking Synchronization in Java

• There are some problems
• How do we translate the semantics of the
  read-write lock class in Java to Action Language?
• How do we deal with synchronized, wait, notify,
  notifyAll ?
• What about the threads that use the read-write
  lock class?
• Do we need to translate the whole Java program to
  and Action Language Specification?

Action Language Verifier
Verification of Synchronization in Java Programs
17
Design for Verification

• Abstraction and modularity are key both for
  successful designs and scalable verification
  techniques
• The question is
• How can modularity and abstraction at the design
  level be better integrated with the verification
  techniques which depend on these principles?
• Our approach
• Structure software in ways that facilitate
  verification
• Document the design decisions that can be useful
  for verification
• Improve the applicability and scalability of
  verification using this information

18
A Design for Verification Approach

• We have been investigating a design for
  verification approach based on the following
  principles
• Use of design patterns that facilitate automated
  verification
• Use of stateful, behavioral interfaces which
  isolate the behavior and enable modular
  verification
• An assume-guarantee style modular verification
  strategy that separates verification of the
  behavior from the verification of the conformance
  to the interface specifications
• A general model checking technique for interface
  verification
• Domain specific and specialized verification
  techniques for behavior verification

19
Concurrency Controller Pattern

• A verifiable behavioral design pattern for
  concurrent programs
• Defines customized synchronization policies
• Avoids usage of error-prone Java synchronization
  primitives synchronize, wait, notify
• Separates controller behavior from the threads
  that use the controller
• Supports a modular verification approach which
  exploits this modularity for scalable
  verification

20
Concurrency Controller Pattern
ThreadA
Shared
ThreadB
Helper classes
int
used at runtime
used at interface verification
used both times
21
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()

22
Controller Interfaces

• A controller interface defines the acceptable
  call sequences for the threads that use the
  controller
• Interfaces are specified using finite state
  machines

• public class RWStateMachine implements
  RWInterface
• StateTable stateTable
• final static int idle0,reading1, writing2
• public RWStateMachine() ...
  stateTable.insert("w_enter",idle,writing)
• public void w_enter()
• stateTable.transition("w_enter")
• ...

reading
r_enter
r_exit
idle
w_exit
writing
w_enter
23
Verification Framework
Behavior Verification
Action Language Verifier
Controller Behavior Machine
Controller Classes
Counting Abstraction
Concurrent Program
Controller Interface Machine
Interface Verification
Java Path Finder
Thread
Thread Isolation
Thread
Thread Class
Thread Classes
24
Modular Design / Modular Verification
Thread Modular Interface Verification
Concurrent Program
Thread 1
Thread 2
Thread n
Thread 1
Thread 2
Thread n
Interface Machine
Interface Machine
Interface Machine
Interface
Controller
Modular Behavior Verification
Shared Data
Controller Behavior
25
Modular Verification

• Behavior verification
• Verify the controller properties (e.g. safety,
  liveness) assuming that the user threads adhere
  to the controller interface
• Use a customized model checker
• Interface verification
• Check that each user thread obeys the interface
• A thread is correct with respect to an interface
  if all the call sequences generated by the thread
  can also be generated by the interface machine
• Use a software model checker with stubs
• Significant state space reduction because of stub
  substitution

26
Behavior Verification

• Analyzing properties (specified in CTL) of the
  synchronization policy encapsulated with a
  concurrency controller and its interface
• Assume threads obey the controller interfaces
• Behavior verification with Action Language
  Verifier
• We wrote a translator which translates controller
  classes to Action Language
• Using counting abstraction we can check
  concurrency controller classes for arbitrary
  number of threads

27
Interface Verification

• Checks if all the threads invoke controller
  methods in the order specified in the interfaces
• Checks if the threads access shared data only at
  the correct interface states
• Interface verification with Java PathFinder
• Verify Java implementations of threads
• Correctness criteria are specified as assertions
• Look for assertion violations
• Assertions are in the StateMachine and SharedStub
• Performance improvement with thread Isolation

28
Thread Isolation Part 1

• Interaction among threads
• Threads can interact with each other in only two
  ways
• invoking controller actions
• Invoking shared data methods
• To isolate the threads
• Replace concurrency controllers with controller
  interface state machines
• Replace shared data with shared stubs

29
Thread Isolation Part 2

• Interaction among a thread and its environment
• Modeling threads call to 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 the environments influence on threads
  with drivers
• Thread initialization, RMI events, GUI events
• Enclose with drivers that generate all possible
  events that influence controller access

30
Automated Airspace Concept

• Automated Airspace Concept by NASA researchers
  automates the decision making in air traffic
  control
• The most important challenge is achieving high
  dependability
• Automated Airspace Concept includes a failsafe
  short term conflict detection component called
  Tactical Separation Assisted Flight Environment
  (TSAFE)
• It is responsible for detecting conflicts in
  flight plans of the aircraft within 1 minute from
  the current time
• Dependability of this component is even more
  important than the dependability of the rest of
  the system
• It should be a smaller, isolated component
  compared to the rest of the system so that it can
  be verified

31
TSAFE

• TSAFE functionality
• Display aircraft position
• Display aircraft planned route
• Display aircraft future projected route
  trajectory
• Show conformance problems

32
TSAFE Architecture
ltltTCP/IPgtgt
User
Server
Radar feed
Client
EventThread
ltltRMIgtgt
21,057 lines of code with 87 classes
33
Reengineering TSAFE

• Found all the synchronization statements in the
  code
• (synchronize, wait, notify, notifyAll)
• Identified 6 shared objects protected by these
  synchronization statements
• Used 2 instances of a reader-writer controller
  and 3 instances of a mutex controller for
  synchronization
• In the reengineered TSAFE code the
  synchronization statements appear only in the
  Action helper class provided by the concurrency
  controller pattern

34
Behavior Verification Performance
P denotes parameterized verification for
arbitrary number of threads
35
Interface Verification Performance
36
Fault Categories

• Concurrency controller faults
• initialization faults (2)
• guard faults (2)
• update faults (6)
• blocking/nonblocking faults (4)
• Interface faults
• modified-call faults (8)
• conditional-call faults
• conditions based on existing program variables
  (13)
• conditions on new variables declared during fault
  seeding (5)

37
Effectiveness in Finding Faults

• Created 40 faulty versions of TSAFE
• Each version had at most one interface fault and
  at most one behavior fault
• 14 behavior and 26 interface faults
• Among 14 behavior faults ALV identified 12 of
  them
• 2 uncaught faults were spurious
• Among 26 interface faults JPF identified 21 of
  them
• 2 of the uncaught faults were spurious
• 3 of the uncaught faults were real faults that
  were not caught by JPF

38
Falsification Performance
39
Conclusions

• ALV performance
• Cost of parameterized verification was somewhere
  between concrete instances with 8 and 16 threads
• Falsification performance was better than
  verification
• Completeness of the controller properties
• Effectiveness of behavior verification by ALV
  critically depends on the completeness of the
  specified properties
• Concrete vs. parameterized behavior verification
• When no faults are found, the result obtained
  with parameterized verification is stronger
• However for falsification we observed that
  concrete instances were as effective as
  parameterized instances

40
Conclusions

• JPF performance
• Typically falsification performance is better
  than verification performance
• In some cases faults caused execution of new code
  causing the falsification performance to be worse
  than verification performance
• Thread isolation
• Automatic environment generation for threads
  result in too much non-determinism and JPF runs
  out of memory
• Dependency analysis was crucial for mitigating
  this
• Deep faults were difficult to catch using JPF
• Three uncaught faults were created to test this

41
Conclusions

• Unknown shared objects
• The presented approach does not handle this
  problem
• Using escape analysis may help
• We could not find a scalable and precise escape
  analysis tool
• Environment generation
• This is the crucial problem in scalability of the
  interface verification
• Using a design for verification approach for
  environment generation may help

42
Outline
Action Language Verifier
Synchronizability Analysis
Design for Verification
enables
enables
uses
uses
Verification of Synchronization in
Concurrent Programs
Analyzing Web Service Interactions
type of
Interface Grammars
43
Going to Lunch at UCSB

• Before Xiang graduated from UCSB, Xiang, Jianwen
  and I were using the following protocol for going
  to lunch
• Sometime around noon one of us would call another
  one by phone and tell him where and when we would
  meet for lunch.
• The receiver of this first call would call the
  remaining peer and pass the information.
• Lets call this protocol the First Caller Decides
  (FCD) protocol.

44
State machines for the FCD Protocol
Tevfik
Xiang
Jianwen
!tj1
?jt2
!xj1
?jx2
!jt1
?tj2
!tx1
?xt2
!xt1
?tx2
!jx1
?xj2
?xt1
?jt1
?tx1
?jx1
?xj1
?tj1
!tx2
!tj2
!xt2
!xj2
!jx2
!jt2
! send ? receive
t x 1
Message Labels
from Tevfik
to Xiang
1st message
45
FCD Protocol and Voicemail Problems

• When the university installed a voicemail system
  FCD protocol started causing problems
• We were showing up at different restaurants at
  different times!
• Example scenario tx1, jx1, xj2
• The messages jx1 and xj2 are never consumed
• Note that this scenario is not possible without
  voicemail!

46
A Different Lunch Protocol

• Jianwen suggested that we change our lunch
  protocol as follows
• As the most senior researcher among us Jianwen
  would make the first call to either Xiang or
  Tevfik and tell when and where we would meet for
  lunch.
• Then, the receiver of this call would pass the
  information to the other peer.
• Lets call this protocol the Jianwen Decides (JD)
  protocol

47
State machines for the JD Protocol
Tevfik
Xiang
Jianwen
?xt
?tx
?jt
?jx
!jt
!jx
!tx
!xt

• JD protocol works fine with voicemail!

48
Conversations

• The FCD and JD protocols specify a set of
  conversations
• A conversation is the sequence of messages
  generated during an execution
• As far as the set of conversations are concerned
• The implementation of the FCD protocol behaves
  differently with synchronous and asynchronous
  communication
• Whereas the implementation of the JD protocol
  behaves the same.
• Can we find a way to identify such
  implementations?
• Synchronizability analysis
• FCD protocol is not synchronizable
• JD protocol is synchronizable

49
Web Services Standards

• Loosely coupled, interaction through standardized
  interfaces
• Standardized data transmission via XML
• Asynchronous messaging
• Platform independent (.NET, J2EE)

WSCDL
Interaction
WSBPEL
Composition
Service
WSDL
Implementation Platforms
Microsoft .Net, Sun J2EE
SOAP
Message
XML Schema
Type
XML
Data
Web Service Standards
50
A Model for Composite Web Services

• A composite web service consists of
• a finite set of peers
• Lunch example T, X, J
• and a finite set of message classes
• Lunch example (JD protocol) jt, tx, jx, xt

tx
Peer T
Peer X
xt
jx
jt
Peer J
51
Communication Model

• We assume that the messages among the peers are
  exchanged using reliable and asynchronous
  messaging
• FIFO and unbounded message queues

Peer T
Peer X
tx
tx

• This model is similar to industry efforts such as
  
• JMS (Java Message Service)
• MSMQ (Microsoft Message Queuing Service)

52
Conversations

• A virtual watcher records the messages as they
  are sent

Peer T
Peer X
Watcher
tx
jt
Peer J

• A conversation is a sequence of messages the
  watcher sees during an execution

53
Effects of Asynchronous Communication

• Question Given a composite web service, is the
  set of conversations a regular set?
• Even when messages do not have any content and
  the peers are finite state machines the
  conversation set may not be regular
• Reason asynchronous communication with unbounded
  queues
• Bounded queues or synchronous communication
• ? Conversation set always regular

54
Properties of Conversations

• The notion of conversation enables us to reason
  about temporal properties of the composite web
  services
• LTL framework extends naturally to conversations
• LTL temporal operators
• X (neXt), U (Until), G (Globally), F (Future)
• Atomic properties
• Predicates on message classes (or contents)
• Example G ( payment ? F receipt )
• Model checking problem Given an LTL property,
  does the conversation set satisfy the property?

55
Synchronizability Analysis

• We know that analyzing conversations of composite
  web services is difficult due to asynchronous
  communication
• Model checking for conversation properties is
  undecidable even for finite state peers
• The question is
• Can we identify the composite web services where
  asynchronous communication does not create a
  problem?

56
Three Examples, Example 1
!a1
!a2
r1, r2
!e
e
?r1
?r2
?a1
?a2
?e
a1, a2
!r2
!r1
requester
server

• Conversation set is regular (r1a1 r2a2) e
• During all executions the message queues are
  bounded

57
Example 2
!a1
!a2
r1, r2
!e
?a1
?a2
e
?r1
?r2
?e
!r2
!r1
a1, a2
requester
server

• Conversation set is not regular
• Queues are not bounded

58
Example 3
r1, r2
!e
!r1
!r2
?r
!a
e
?r1
?r2
?a
!r
a1, a2
?e
requester
server

• Conversation set is regular (r1 r2 ra) e
• Queues are not bounded

59
State Spaces of the Three Examples
of states in thousands
queue length

• Verification of Examples 2 and 3 are difficult
  even if we bound the queue length
• How can we distinguish Examples 1 and 3 (with
  regular conversation sets) from 2?
• Synchronizability Analysis

60
Synchronizability Analysis

• A composite web service is synchronizable, if its
  conversation set does not change
• when asynchronous communication is replaced with
  synchronous communication
• If a composite web service is synchronizable we
  can check its properties about its conversations
  using synchronous communication semantics
• For finite state peers this is a finite state
  model checking problem

61
Synchronizability Conditions

• Sufficient conditions for synchronizability
• Synchronous compatible
• When the peer states machines are composed
  synchronously, there should not be a state where
  a peer is ready to send a message while the
  corresponding receiver is not ready to receive
• Autonomous
• At any state, each peer should be able to do only
  one of the following send, receive or terminate
• (a peer can still choose among multiple
  messages)

62
Are These Conditions Too Restrictive?
63
Web Service Analysis Tool (WSAT)
Verification Languages
WebServices
Front End
Analysis
Back End
Intermediate Representation
GFSA to Promela (synchronous communication)
success
BPEL to GFSA
SynchronizabilityAnalysis
Guarded automata
BPEL
fail
(bottom-up)
GFSA to Promela (bounded queue)
Promela
skip
GFSA parser
Conversation Protocol
Guarded automaton
GFSA to Promela(single process, no
communication)
success
Realizability Analysis
fail
(top-down)
64
Checking Service Implementations

• There are some problems
• People write web service implementations using
  programming languages such as Java, C, etc.
• Synchronizability analysis works on state machine
  models
• How do we generate the state machines from the
  Java code?

Synchronizability Analysis
Checking Service Implementations
65
Design for Verification Approach

• Use the same principles
• Use of design patterns that facilitate automated
  verification
• Use of stateful, behavioral interfaces which
  isolate the behavior and enable modular
  verification
• An assume-guarantee style modular verification
  strategy that separates verification of the
  behavior from the verification of the conformance
  to the interface specifications
• A general model checking technique for interface
  verification
• Domain specific and specialized verification
  techniques for behavior verification

66
Peer Controller Pattern

• Eases the development of web services
• Uses Java API for XML messaging (JAXM)
• Asynchronous communication among peers
• Supported by a modular verification technique
• Behavior Verification Checks properties of
  conversations of a web service composed of
  multiple peers
• assuming that peers behave according to their
  interfaces
• Interface Verification Checks if each peer
  behaves according to its interface

67
Peer Controller Pattern
used at runtime
Red Bordered classes are the ones the user has to
implement
used at interface verification
used both times
68
Verification Framework
Thread
Promela
WSAT
Thread
Peer State Machines
Promela Translation
Synchronizability Analysis
Conversation Verification
Composite Service
Spin
Peer State Machine
Interface Verification
Java Path Finder
Peer Code
69
Modular Design / Modular Verification
Peer Modular Interface Verification
Composite Service
Peer 1
Peer 2
Peer n
Peer 1
Peer 2
Peer n
Interface Machine
Interface Machine
Interface Machine
interface
interface
interface
Modular Conversation Verification
Conversation Behavior
70
Modular Verification

• Behavior Verification
• Uses WSAT for synchronizability analysis
• Uses Spin model checker for conversation
  verification
• Automated translation to Promela using WSAT
• Interface Verification
• Isolated check of individual peer implementations
  
• Uses JPF model checker

71
Behavior Verification

• Spin is a finite state model checker
• We have to bound the channel sizes, session
  numbers, message types
• Synchronizability analysis
• Enables us to verify web services efficiently by
  replacing communication channels with channels of
  size 0 (i.e., synchronous communication)
• The verification results hold for unbounded
  channels

72
Interface Verification

• If the call sequence to the Communicator class is
  accepted by the state machine specifying the
  interface, then the peer implementation conforms
  to the behavior in the contract
• Interface Verification
• CommunicationController is replaced with
  CommunicatorInterface
• Drivers simulating other peers are automatically
  generated
• State Space reduction
• Usage of stubs
• Each session is independent
• just need to check each peer for one session

73
Examples

• We used this approach to implement several simple
  web services
• Travel agency
• Loan approver
• Product ordering
• Performance of both interface and behavior
  verification were reasonable

74
Interface Verification
Interface Verification with JPF for Loan Approver
75
Behavior Verification

• Sample Property Whenever a request with a small
  amount is sent, eventually an approval message
  accepting the loan request will be sent.
• Loan Approval system has 154 reachable states
• because each queue length never exceeds 1.
• Behavior verification used lt1 sec and 1.49 MB
• SPIN requires restricted domains
• Have to bound the channel sizes ? bounded message
  queues
• In general there is no guarantee these results
  will hold for other queue sizes
• Using synchronizability analysis we use queues of
  size 0 and still guarantee that the verification
  results hold for unbounded queues!

76
Conclusions

• We were able to use our design for verification
  approach based on design patterns and behavioral
  interfaces in different domains
• Use of domain specific behavior verification
  techniques has been very effective
• Interface verification is challenging
• Model checking research resulted in various
  verification techniques and tools which can be
  customized for specific classes of software
  systems
• Automated verification techniques can scale to
  realistic software systems using design for
  verification approach

77
Conclusions

• Once the behavior is isolated (using concurrency
  controller or peer controller patterns) behavior
  verification was quite efficient
• Interface verification was very hard
• It is necessary to find effective behavioral
  interface specification and verification
  techniques
• Check out our work on interface grammars!

78
THE END