Structuring Software for Verifiability Tevfik Bultan Department of Computer Science University of California, Santa Barbara

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

Outline Action Language Verifier Verification of Synchronization in Concurrent Programs Synchronizability Analysis Analyzing Web Service Interactions Design for Verification Interface Grammars uses enables type of

Action Language Verifier (ALV) Action Language Parser Model Checker OmegaLibraryCUDDPackage MONA Composite Symbolic Library PresburgerArithmeticManipulator BDDManipulatorAutomataManipulator Action Language Specification + CTL property Counter-exampleVerified Not sure

Composite Symbolic Library CUDD LibraryOMEGA Library Symbolic +intersect() +union() +complement() +isSatisfiable() +isSubset() +pre() +post() CompSym –representation: list of comAtom +intersect() + union() BoolSym –representation: BDD +intersect() +union() IntSym –representation: Polyhedra +intersect() +union() compAtom –atom: *Symbolic

OMEGA Symbolic +union() +isSatisfiable() +isSubset() +forwardImage() CompSym –representation: list of comAtom + union() compAtom –atom: *Symbolic InAutotSym –representation: automaton +union() IntPolySym –representation: list of Polyhedra +union() CUDD BoolSym –representation: BDD +union() MONA IntBoolAutoSym –representation: automaton +union() HeapSym –representation: list of ShapeGraph +union() shapeGraph –atom: *Symbolic Composite Symbolic Library, Extended

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

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

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 nr=0; r_enter: [!busy] nr := nr+1; r_exit: nr := nr-1; w_enter: [!busy && nr=0] busy := true; w_exit: busy := false;

Read-Write Lock in Action Language module main() integer nr; boolean busy; restrict: nr>=0; initial: nr=0 and !busy; module ReaderWriter() enumerated state {idle, reading, writing}; initial: state=idle; r_enter: state=idle and !busy and nr’=nr+1 and state’=reading; r_exit: state=reading and nr’=nr-1 and state’=idle; w_enter: state=idle and !busy and nr=0 busy’ and state’=writing; w_exit: state=writing and !busy’ and state’=idle; ReaderWriter: r_enter | r_exit | w_enter | w_exit; endmodule main: ReaderWriter() | ReaderWriter() | ReaderWriter(); spec: invariant(busy => nr=0) spec: invariant(busy => eventually(!busy)) endmodule

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

Parameterized Read-Write Lock module main() integer nr; boolean busy; restrict: nr>=0; initial: nr=0 and !busy; module ReaderWriter() enumerated state {idle, reading, writing}; initial: state=idle; r_enter: state=idle and !busy and nr’=nr+1 and state’=reading; r_exit: state=reading and nr’=nr-1 and state’=idle; w_enter: state=idle and !busy and nr=0 busy’ and state’=writing; w_exit: state=writing and !busy’ and state’=idle; ReaderWriter: r_enter | r_exit | w_enter | w_exit; endmodule main: ReaderWriter()*; spec: invariant(busy => nr=0) spec: invariant(busy => eventually(!busy)) endmodule

Parameterized Read-Write Lock module main() integer nr; boolean busy; parameterized integer numReaderWriter; restrict: nr>=0 and numReaderWriter>=1; initial: nr=0 and !busy; module ReaderWriter() integer idle, reading, writing; initial: idle=numReaderWriter; r_enter: idle>0 and !busy and nr’=nr+1 and idle’=idle-1 and reading’=reading+1; r_exit: reading>0 and nr’=nr-1 and reading’=reading-1 and idle’=idle+1; w_enter: idle>0 and !busy and nr=0 and busy’ and idle’=idle-1 and writing’=writing+1; w_exit: writing>0 and !busy’ and writing’=writing-1 and idle’=idle+1 ReaderWriter: r_enter | r_exit | w_enter | w_exit; endmodule main: ReaderWriter(); spec: invariant(busy => nr=0) spec: invariant(busy => eventually(!busy)) endmodule

Verification of Read-Write Lock with ALV IntegersBooleansCons. Time (secs.) Ver. Time (secs.) Memory (Mbytes) RW RW RW RW RW RW-P SUN ULTRA 10 (768 Mbyte main memory)

A Java Read-Write Lock Implementation class ReadWriteLock { private Object lockObj; private int totalReadLocksGiven; private boolean writeLockIssued; private int threadsWaitingForWriteLock; public ReadWriteLock() { lockObj = new Object(); writeLockIssued = false; } public void getReadLock() { synchronized (lockObj) { while ((writeLockIssued) || (threadsWaitingForWriteLock != 0)) { try { lockObj.wait(); } catch (InterruptedException e) { } } totalReadLocksGiven++; } } public void getWriteLock() { synchronized (lockObj) { threadsWaitingForWriteLock++; while ((totalReadLocksGiven != 0) || (writeLockIssued)) { try { lockObj.wait(); } catch (InterruptedException e) { // } } threadsWaitingForWriteLock--; writeLockIssued = true; } } public void done() { synchronized (lockObj) { //check for errors if ((totalReadLocksGiven == 0) && (!writeLockIssued)) { System.out.println(" Error: Invalid call to release the lock"); return; } if (writeLockIssued) writeLockIssued = false; else totalReadLocksGiven--; lockObj.notifyAll(); } } }

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

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

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

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 Concurrency Controller Pattern

Controller Shared Concurrency Controller Pattern ThreadA ThreadB StateMachine Controller -var1 -var2 +action1() +action2() Action +blocking() +nonblocking() -GuardedExecute SharedStub +a() +b() Shared +a() +b() GuardedCommand +guard() +update() int GuardedCommand ControllerStateMachine +action1() +action2() used at runtime used at interface verification used both times Helper classes

class Action{ protected final Object owner; … private boolean GuardedExecute(){ boolean result=false; for(int i=0; i<gcV.size(); i++) try{ if(((GuardedCommand)gcV.get(i)).guard()){ ((GuardedCommand)gcV.get(i)).update(); result=true; break; } }catch(Exception e){} return result; } public void blocking(){ synchronized(owner) { while(!GuardedExecute()) { try{owner.wait();} catch (Exception e){} } owner.notifyAll(); } } public boolean nonblocking(){ synchronized(owner) { boolean result=GuardedExecute(); if (result) owner.notifyAll(); return result; } } 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(){ act_r_enter.blocking();} public boolean r_exit(){ return act_r_exit.nonblocking();} } Reader-Writer Controller This helper class is provided, no need to rewrite it

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 idle=0,reading=1, writing=2; public RWStateMachine(){... stateTable.insert("w_enter",idle,writing); } public void w_enter(){ stateTable.transition("w_enter"); }... } writing reading idle r_enter r_exit w_exit w_enter

Concurrent Program Controller Classes Thread Classes Controller Interface Machine Controller Behavior Machine Java Path Finder Action Language Verifier Thread Isolation Thread Class Counting Abstraction Interface Verification Behavior Verification Verification Framework

Interface Machine Thread 1Thread 2Thread n Thread 1 Controller Shared Data Interface Machine Thread 2 Interface Machine Thread n Thread Modular Interface Verification Concurrent Program Controller Behavior Modular Behavior Verification Modular Design / Modular Verification Interface

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

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

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

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

Thread Isolation: Part 2 Interaction among a thread and its environment Modeling thread’s 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 environment’s influence on threads with drivers –Thread initialization, RMI events, GUI events Enclose with drivers that generate all possible events that influence controller access

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

TSAFE TSAFE functionality: 1.Display aircraft position 2.Display aircraft planned route 3.Display aircraft future projected route trajectory 4.Show conformance problems

Server Computation Flight Database Graphical Client > 21,057 lines of code with 87 classes Radar feed > User EventThread Feed Parser Timer TSAFE Architecture

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

Behavior Verification Performance RW Mutex Barrier BB-RW BB-Mutex ControllerTime(sec)Memory (MB)P-Time (sec)P-Memory (MB) P denotes parameterized verification for arbitrary number of threads

Interface Verification Performance ThreadTime (sec)Memory (MB) TServer-Main TServer-RMI TServer-Event TServer-Feed TClient-Main TClient-RMI TClient-Event

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)

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

Falsification Performance TServer-RMI TServer-Event TServer-Feed TClient-RMI TClient-Event ThreadTime (sec)Memory (MB) RW RW RW-P Mutex Mutex Mutex-p Concurrency ControllerTime (sec)Memory (MB)

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

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

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

Outline Action Language Verifier Verification of Synchronization in Concurrent Programs Synchronizability Analysis Analyzing Web Service Interactions Design for Verification Interface Grammars uses enables type of

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. Let’s call this protocol the First Caller Decides (FCD) protocol.

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

FCD Protocol and Voic Problems When the university installed a voic 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 voic !

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. –Let’s call this protocol the Jianwen Decides (JD) protocol

?xt ?jt !tx TevfikXiangJianwen ?tx ?jx !xt !jt!jx State machines for the JD Protocol JD protocol works fine with voic !

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

Web Services Standards Loosely coupled, interaction through standardized interfaces Standardized data transmission via XML Asynchronous messaging Platform independent (.NET, J2EE) Data Type Service Composition Message WSBPEL Web Service Standards Implementation Platforms Microsoft.Net, Sun J2EE WSDL SOAP XML Schema XML WSCDL Interaction

A Model for Composite Web Services tx xt jxjt Peer T Peer J Peer X 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

Communication Model We assume that the messages among the peers are exchanged using reliable and asynchronous messaging –FIFO and unbounded message queues This model is similar to industry efforts such as –JMS (Java Message Service) –MSMQ (Microsoft Message Queuing Service) tx Peer TPeer X tx

Conversations A virtual watcher records the messages as they are sent Watcher A conversation is a sequence of messages the watcher sees during an execution tx jt Peer T Peer J Peer X txjt

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

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?

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?

Three Examples, Example 1 requesterserver !r 2 ?a 1 ?a 2 !e !r 1 Conversation set is regular: ( r 1 a 1 | r 2 a 2 )* eConversation set is regular: ( r 1 a 1 | r 2 a 2 )* e During all executions the message queues are bounded r 1, r 2 a 1, a 2 e ?r 1 !a 1 !a 2 ?r 2 ?e

Example 2 Conversation set is not regularConversation set is not regular Queues are not bounded requesterserver !r 2 ?a 1 ?a 2 !e !r 1 r 1, r 2 a 1, a 2 e ?r 1 !a 1 !a 2 ?r 2 ?e

Example 3 Conversation set is regular: ( r 1 | r 2 | ra )* eConversation set is regular: ( r 1 | r 2 | ra )* e Queues are not bounded requesterserver !r 2 ?a!r !e !r 1 r 1, r 2 a 1, a 2 e ?r 1 ?r 2 ?e ?r !a

State Spaces of the Three Examples queue length # of states in thousands 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

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

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)

Are These Conditions Too Restrictive? Problem SetSizeSynchronizable? SourceName#msg#states#trans. ISSTA’04SAS91215yes IBM Conv. Support Project CvSetup444yes MetaConv446no Chat245yes Buy556yes Haggle858no AMAB81015yes BPEL spec shipping233yes Loan666yes Auction9910yes Collaxa. com StarLoan677yes Cauction576yes

BPEL to GFSA Guarded automata GFSA to Promela (bounded queue) BPEL Web Services Promela Synchronizability Analysis GFSA to Promela (synchronous communication) Intermediate Representation Conversation Protocol Front End Realizability Analysis Guarded automaton skip GFSA parser success fail GFSA to Promela (single process, no communication) success fail AnalysisBack End (bottom-up) (top-down) Verification Languages Web Service Analysis Tool (WSAT)

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

Design for Verification Approach Use the same principles: 1.Use of design patterns that facilitate automated verification 2.Use of stateful, behavioral interfaces which isolate the behavior and enable modular verification 3.An assume-guarantee style modular verification strategy that separates verification of the behavior from the verification of the conformance to the interface specifications 4.A general model checking technique for interface verification 5.Domain specific and specialized verification techniques for behavior verification

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

ApplicationThreadCommunicationInterface StateMachine CommunicatorCommunicationController PeerServletThreadContainer sessionId Peer Controller Pattern used at runtime used at interface verification used both times Red Bordered classes are the ones the user has to implement

Composite Service Peer State Machine Promela Java Path Finder Spin Peer Code Interface Verification Verification Framework Thread Peer State Machines WSAT Synchronizability Analysis Conversation Verification Promela Translation

Interface Machine Peer 1 Peer 2Peer n Peer 1 Interface Machine Peer 2 Interface Machine Peer n Peer Modular Interface Verification Composite Service Conversation Behavior Modular Conversation Verification Modular Design / Modular Verification interface

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

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

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

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

Interface Verification Interface Verification with JPF for Loan Approver ThreadsT (sec)M (MB) Customer Loan Approver Risk Assesor

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 <1 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!

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

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!

THE END