Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Model Checking: A Different Approach to Testing Concurrent Programs, Exams of Computer Science

Model checking as an alternative approach to testing and verifying concurrent programs. Traditional testing methods have limitations, especially when it comes to finding bugs in complex, concurrent software. Model checking offers a fully automated, systematic, and exhaustive analysis that provides error traces for debugging. The concept of model checking, its advantages, and how it can be applied to concurrent systems using finite-state models and temporal logics.

Typology: Exams

Pre 2010

Uploaded on 07/22/2009

koofers-user-p4i
koofers-user-p4i 🇺🇸

10 documents

1 / 3

Toggle sidebar

Related documents


Partial preview of the text

Download Model Checking: A Different Approach to Testing Concurrent Programs and more Exams Computer Science in PDF only on Docsity! 9/16/2008 1 CS6910: Testing/Verification of Concurrent Programs Introduction to a different approach: Model Checking Traditional Approaches Not Sufficient Testing Finds many bugs early on, but after some time bugs are harder to find Have I found all bugs in my system when testing fdoesn’t ind any new bugs anymore? Requires test harness and drivers: Manual effort Not scalable for concurrent programs How to control scheduling? … Any alternative approach? Model checking has been used successfully in hardware Hardware design bear similarity with concurrent software Very complex Inherently concurrent Designed by high level language Inventors of model checking won 2008 Turing award What is Model Checking? Model checking is the process of exhaustively checking that system behavior is correct Fully automated Static analysis Does not require any test vectors Systematic and exhaustive analysis Provides error trace for debugging Tool View of a Model Checker “Correct”: All behaviors are checked and correct. “Error-trace”: A step-by-step explanation of the bug. “Don’t know”: Tool ran out of time, or out of memory; but so far, no bug was found. Model Checker How do we describe the system? Finite-state models Formally: Kripke Structures How do we specify properties of interest? Temporal Logics 9/16/2008 2 Finite-State Machines (FSM) Set of states S S ={s0, s1, s2 , s3} Set of initial states S0 S, S0 = {s0} Set of transitions R S×S R= { (s0,s1), (s1,s2), (s1,s0), (s2,s0), (s3,s2)} ⊆ ⊆ Kripke Structures Representation: (S,S0,R,L) over atomic propositions AP L labels each state with the set of “atomic propositions” that are true in that state. Concurrent System Model Typically, an overall system is specified as a collection of modules and the environment of the system Each module is modeled as an automaton There are two ways of constructing overall system model Synchronous composition Asynchronous composition Synchronous Product Often used in modeling hardware At each step, all modules proceed in lock-step Given two structures Mi=(Si,Si0,Ri), the synchronous product is defined as M=(S,S0,R) using Synchronous Model Example Asynchronous Product Often used to model software (interleaved model) At each time step, one module is chosen randomly, which can proceed a single step Given two structures Mi=(Si,Si0,Ri), the asynchronous product is defined as M=(S,S0,R) using
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved