1. Introduction to Model Checking

Transcription

1 CSE6009 Model Checking 1. Introduction to Model Checking Scott Uk-Jin Lee Department of Computer Science and Engineering Hanyang University ERICA Campus 2 nd Semester 2015

2 System Correctness Correctness of System system s design requirements are satisfied Correctness of Software System (possibly concurrent) not that a system can meet its requirements, but that a system cannot fail to meet its requirements Program testing can be used to show the presence of bugs, but never to show their absence - Dijkstra 2

3 Checking System Correctness Correctness of Concurrent Software System cannot meet the degree of certainty with : traditional test suite : - difficult to devise due to the non-determinism standard mathematics : - hand proof is challenging even for competent mathematician mechanical proof procedure : - impossible to construct a general procedure for arbitrary programs Checking Correctness of Concurrent Software System if modest conditions are met, mechanical verification of the system correctness is possible 3

4 Logical Model Checking Checking the Correctness of Software Design used when software cannot be verified exhaustively due to the size and complexity of software and the cost of verification build & verify simplified model of underlying design of software essential characteristics are preserved known sources of complexity are avoided e.g.) bridge builders and airplane designers build and analyse models to reduce the risk of implementing a flawed design as it is too costly to fix once implementation phase is reached 4

5 SPIN Modelling Language & Techniques works very well for concurrent software which is the most difficult to debug and test abstract language that is executable provides significantly different perspective on programming problem & may lead to a new solution Model Checker simulates and verifies software behaviours for logical errors uses efficient procedure for characterising all possible executions => can apply a sanity checks to design model & identify unexecutable code or deadlocking concurrent execution & check compliance with user-defined correctness criteria Verification System developed at Bell Labs in 80s and 90s & supported with continual evolution and updates one of the most widely used model checker in the world ACM s most prestigious Software System Award winner 5

6 SPIN in System Design SPIN is particularly suitable for modelling & verifying distributed system with concurrently executing processes 1. Direct Method : use tool to construct verification models that captures required system properties verify the correctness requirements for a system by thoroughly checking the model if requirements are not satisfied, a counter-example is produced once logical soundness of a system is proven, implement the system with confidence 2. Less Direct Method : from the system implementation, convert critical parts of implementation mechanically into verification models automated model extraction tool is available for mainstream programming languagesc analyse and verify the models with SPIN 6

7 Reasoning about Concurrent System is too difficult : tool such as SPIN is needed is not limited to Software Design : concurrency / access to shared resources are very common in our world at supermarket : customers compete for shared resources such as food items, carts, checkout clerks, etc on road : cars compete for access to road intersections, parking spots, and etc with telephone : large number of simultaneous users compete for the shared resources with such cases many interaction problem occurs new and untried set of rules for solving these problems can backfire in unexpected manner 7

8 Concurrency Example 1: Circular Blocking various protocols for intersection exists over different countries commonly priority is given to cars leaving the circle over cars entering to prevent congestion problems unexpected consequence can be resulted under heavy traffic condition as illustrated these situations are only be resolved by breaking the protocols or rules such solution is only possible in our world and NOT possible in Software hence, for Software, all cases must be covered 8

9 Concurrency Example 2: Deadly Embrace In Telephone System : to establish a call, a person must obtain calling line then called line when two people are trying to call each other at the same time, deadly embrace occurs In OS : two processes require two shared resources simultaneously to complete a task and compete for these resources when each process obtains one resource and wait indefinitely for the other, deadly embrace occurs 9

10 Concurrency Example 3: Mismatched Assumptions The most pernicious and subtle bugs are system bugs arising from mismatched assumptions made by the authors of various components. - Fred Brooks Large Complex Integrated System : often assembled with smaller components that are tested still fails due to some design problems which can exist at system level system level errors are difficult to imagine & often there is no reliable way of testing need a design tool which auto-detects error scenarios from descriptions of individual components e.g.) Lufthansa Airbus A landing in heavy rain at Warsaw airport, Poland (Sept 14, 1993) not much traction is expected from wheels in the landing gear on a wet runway & reverse thrust on the main engine is used to bring the plane to stop safely BUT thrust reverser failed & the plane overshot the end of runway, lives were lost! there were no mistakes in design or operation of plane the control software was not designed to cope with unexpected combination of events 10

11 Fundamental Problems of Concurrency Concurrency Problems quite common in software engineering & fundamental part of our lives not a rare or bizarre thing that happens in special circumstances very difficult to predict in advance cannot be solved by taking system apart and inspecting individual components occur uniquely with the interaction of multiple and concurrently executing components Standard System Testing Techniques cannot control many aspects of concurrent system execution (especially process execution and interleaving) suffers from having difficulties in identifying concurrency problems impossible to create and manage reproducible tests and evaluate results Limited Observability & Controllability prevents thorough exercise on concurrent system behaviours causes the presence of residual defects in production code 11