Modeling Software Systems Lecture 2 Book: Chapter 4.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

The Quest for Correctness Joseph Sifakis VERIMAG Laboratory 2nd Sogeti Testing Academy April 29th 2009.
Model Checking Lecture 1.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Symmetric Multiprocessors: Synchronization and Sequential Consistency.
Model Checking and Testing combined
Automatic Verification Book: Chapter 6. How can we check the model? The model is a graph. The specification should refer the the graph representation.
Softrare Reliability Methods
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Mutual Exclusion – SW & HW By Oded Regev. Outline: Short review on the Bakery algorithm Short review on the Bakery algorithm Black & White Algorithm Black.
Shortest Violation Traces in Model Checking Based on Petri Net Unfoldings and SAT Victor Khomenko University of Newcastle upon Tyne Supported by IST project.
Metodi formali dello sviluppo software a.a.2013/2014 Prof.Anna Labella.
Algorithmic Software Verification VII. Computation tree logic and bisimulations.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Partial Order Reduction: Main Idea
Models of Concurrency Manna, Pnueli.
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Monitoring Partial Order Snapshots Doron Peled Bar Ilan University, Israel & University of Warwick, UK Joint work with Peter Niebert.
ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
Enforcing Concurrent Temporal Behaviors Doron Peled, Dept. of CS University of Warwick.
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
CS6133 Software Specification and Verification
 Dr. Vered Gafni 1 Modeling Real-Time Systems.  Dr. Vered Gafni 2 Behavioral Model (Signature, Time) Signature: v 1 :D 1, v 2 :D 2,…,v n :D n S = (D.
Timed Automata.
Model Checking Inputs: A design (in some HDL) and a property (in some temporal logic) Outputs: Decision about whether or not the property always holds.
Run Time Monitoring of Reactive System Models Mikhail Auguston Naval Postgraduate School Mark Trakhtenbrot Holon Academic Institute of.
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture 05.
Lecture 2: Reasoning with Distributed Programs Anish Arora CSE 6333.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.
Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of.
Modeling Software Systems Lecture 2 Book: Chapter 4.
Temporal Logic of Actions (TLA) Leslie Lamport
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Operational Semantics Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
Flavio Lerda 1 LTL Model Checking Flavio Lerda. 2 LTL Model Checking LTL –Subset of CTL* of the form: A f where f is a path formula LTL model checking.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 3 (26/01/2006) Instructor: Haifeng YU.
Defining Programs, Specifications, fault-tolerance, etc.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Advanced Topics in Software Engineering Marjan Sirjani Tehran University Faculty of Engineering ECE Department Tehran,
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
This Week Lecture on relational semantics Exercises on logic and relations Labs on using Isabelle to do proofs.
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
Presented by: Belgi Amir Seminar in Distributed Algorithms Designing correct concurrent algorithms Spring 2013.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Model Checking Lecture 1: Specification Tom Henzinger.
Agenda  Quick Review  Finish Introduction  Java Threads.
Introduction to distributed systems description relation to practice variables and communication primitives instructions states, actions and programs synchrony.
Formal methods: Lecture
Axiomatic semantics Points to discuss: The assignment statement
CSCI1600: Embedded and Real Time Software
Formal Methods in software development
Formal Methods in software development
CSCI1600: Embedded and Real Time Software
An explicit state model checker
Formal Methods in software development
Translating Linear Temporal Logic into Büchi Automata
Presentation transcript:

Modeling Software Systems Lecture 2 Book: Chapter 4

Systems of interest Sequential systems. Concurrent systems. 1. Distributive systems. 2. Reactive systems. 3. Embedded systems (software + hardware).

Sequential systems. Perform some computational task. Have some initial condition, e.g., 0in A[i]0, A[i] integer. Have some final assertion, e.g., 0in-1 A[i]<A[i+1]. (What is the problem with this spec?) Are supposed to terminate.

Concurrent Systems Involve several computation agents. Termination may indicate an abnormal event (interrupt, strike). May exploit diverse computational power. May involve remote components. May interact with users (Reactive). May involve hardware components (Embedded).

Problems in modeling systems Representing concurrency: - Allow one transition at a time. - Allow coinciding transitions. - Allow a partial order between events. Granularity of transitions. Execution model (linear, branching). Global or local states.

Modeling V={v 0,v 1,v 2, …} - a set of variables, over some domain. p(v 0, v 1, …, v n ) - a parametrized assertion, e.g., v 0 =v 1 +v 2 /\v 3 >v 4. A state is an assignment of values to the program variables. For example: s= p(s) is p under the assignment s.

State space The state space of a program is the set of all possible states for it. For example, if V={a, b, c} and the variables are over the naturals, then the state space includes:,,, …

Atomic Transitions Each atomic transition represents a small peace of code such that no smaller peace of code is observable. Is a:=a+1 atomic? In some systems, e.g., when a is a register and the transition is executed using an inc command.

Non atomicity Execute the following when x=0 in two concurrent processes: P1:a=a+1 P2:a=a+1 Result: a=2. Is this always the case? Consider the actual translation: P1:load R1,a inc R1 store R1,a P2:load R2,a inc R2 store R2,a a may be also 1.

Representing transitions Each transition has two parts: The enabling condition: a predicate. The transformation: a multiple assignment. For example: a>b (c,d):=(d,c) This transition can be executed in states where a>b. The result of executing it is switching the value of c with d.

Initial condition A predicate p. The program can start from states s such that p(s) holds. For example: p(s)=a>b /\ b>c.

A transition system A (finite) set of variables V over some domain(s). A set of states. A (finite) set of transitions T, each transition e t has an enabling condition e, and a transformation t. An initial condition p.

Example V={a, b, c, d, e}. : all assignments of natural numbers for variables in V. T={c>0 (c,e):=(c-1,e+1), d>0 (d,e):=(d-1,e+1)} p: c=a /\ d=b /\ e=0 What does this transition relation do?

The interleaving model An execution is a finite or infinite sequence of states s 0, s 1, s 2, … The initial state satisfies the initial condition, I.e., p(s 0 ). Moving from one state s i to s i+1 is by executing a transition e t: e(s i ), I.e., s i satisfies e. s i+1 is obtained by applying t to s i.

Example: s 0 = (satisfies the initial condition) s 1 = (first transition executed) s 2 = (second transition executed) s 3 = (first transition executed again)

Temporal Logic (informal) First order logic or propositional assertions describe a state. Modalities: <>p means p will happen eventually. []p means p will happen always. p ppppppp

More temporal logic We can construct more complicated formulas: []<>p -- It is always the case that p will happen again in the future (infinitely often). <>p /\ <>q -- Both p and q will happen in the future, the order between them not determined. The property must hold for all the executions of the program.

L0:While True do NC0:wait(Turn=0); CR0:Turn=1 endwhile || L1:While True do NC1:wait(Turn=1); CR1:Turn=0 endwhile T0:PC0=L0 PC0:=NC0 T1:PC0=NC0/\Turn=0 PC0:=CR0 T2:PC0=CR0 (PC0,Turn):=(L0,1) T3:PC1=L1 PC1=NC1 T4:PC1=NC1/\Turn=1 PC1:=CR1 T5:PC1=CR1 (PC1,Turn):=(L1,0) Initially: PC0=L0/\PC1=L1 The transitions

The state space Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

[]¬(PC0=CR0/\PC1=CR1) Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

[](Turn=0--><>Turn=1) Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

Interleaving semantics Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=1 L0,CR1 Turn=1 L0,NC1

Interleaving semantics Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=1 L0,CR1 Turn=1 L0,NC1 Turn=0 L0,L1 Turn=0 L0,NC1

An unfolding Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,NC1 Turn=0 CR0,NC1

Partial Order Semantics Sometimes called real concurrency. There is no total order between events. More intuitive. Closer to the actual behavior of the system. More difficult to analyze. Less verification results. Natural transformation between models. Partial order: (S, <), where < is Reflexive: x<y /\ y<z x<z. Antisymmetric: for no x, y, x x. Antireflexive: for no x, x<x.

Bank Example Two branches, initially $1M each. In one branch: deposit, $2M. In another branch: robbery. How to model the system?

Global state space $1M, $1M $3M, $0M $1M, $0M$3M, $1M deposit robbery

Should we invest in this bank? $1M, $1M $3M, $0M $1M, $0M$3M, $1M deposit robbery Invest! Do not Invest! Invest!

Partial Order Description $1M $3M$0M $1M depositrobbery

Constructing global states $1M $3M$0M $1M depositrobbery

Modeling with partial orders m0:x:=x+1 m1:ch!xn1:y:=y+z n0:ch?z P1P2 m0 n0 m0 n1 m0 m1 pc1=m0,x=0 pc1=m0,x=2 pc1=m0,x=1 pc1=m1,x=1 pc1=m1,x=2 pc2=n0,y=0,z=0 pc2=n0,y=1,z=1 pc2=n1,y=0,z=1 pc2=n1,y=1,z=2

Linearizations m0 n0 m0n1 m0 m1 pc1=m0,x=0 pc1=m0,x=2 pc1=m0,x=1 pc1=m1,x=1 pc1=m1,x=2 pc2=n0,y=0,z=0 pc2=n0,y=1,z=1 pc2=n1,y=0,z=1 pc2=n1,y=1,z=2 pc1=m0,x=0,pc2=n0,y=0,z=0 pc1=m1,x=2,pc2=n0,y=1,z=1 pc1=m1,x=2,pc2=n1,y=0,z=1 pc1=m0,x=1,pc2=n1,y=0,z=1 pc1=m1,x=1,pc2=n0,y=0,z=0 pc1=m0,x=2,pc2=n1,y=1,z=2

Linearizations m0 n0 m0 n1 m0 m1 pc1=m0,x=0 pc1=m0,x=2 pc1=m0,x=1 pc1=m1,x=1 pc1=m1,x=2 pc2=n0,y=0,z=0 pc2=n0,y=1,z=1 pc2=n1,y=0,z=1 pc2=n1,y=1,z=2 pc1=m0,x=0,pc2=n0,y=0,z=0 pc1=m1,x=2,pc2=n0,y=1,z=1 pc1=m0,x=1,pc2=n0,y=1,z=1 pc1=m0,x=1,pc2=n1,y=0,z=1 pc1=m1,x=1,pc2=n0,y=0,z=0 pc1=m0,x=2,pc2=n1,y=1,z=2

Bank with one teller $1M $3M $0M $1M deposit robbery deposit $1.1M $3.1M deposit

Partial order execution 1 $1M $3M $0M $1M deposit robbery $3.1M deposit

Partial order execution 2 $1M $0M $1M robbery deposit $1.1M $3.1M deposit

L0:While True do NC0:wait(Turn=0); CR0:Turn=1 endwhile || L1:While True do NC1:wait(Turn=1); CR1:Turn=0 endwhile T0:PC0=L0 PC0:=NC0 T1:PC0=NC0/\Turn=0 PC0:=CR0 T1:PC0=NC0/\Turn=1 PC0:=NC0 T2:PC0=CR0 (PC0,Turn):=(L0,1) T3:PC1==L1 PC1=NC1 T4:PC1=NC1/\Turn=1 PC1:=CR1 T4:PC1=NC1/\Turn=0 PC1:=N1 T5:PC1=CR1 (PC1,Turn):=(L1,0) Initially: PC0=L0/\PC1=L1 Bust waiting

[](Turn=0--><>Turn=1) Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1

Fairness Restriction on the set of legal sequences. Weak process fairness: if some process is enabled continuously from some state, it will be executed. Weak transition fairness: if some transition is enabled continuously from some state, it will be executed. Strong process fairness: if some process is enabled infinitely often, it will be executed (infinitely often). Strong transition fairness: if some transition is enabled infinitely often, then it will be executed.

Example P1::x:=1 P2::while y=0 do [z:=z+1 [] if x=1 then y:=1] end while Initially: x=0 /\ y=0 /\ z=0 /\pc 1 =l0 /\ pc 2 =r0 Termination? Termination of P1? No fairness?. Nothing guaranteed Weak transition (process) fairness? P1 terminates Strong process fairness? P1 terminates. Strong transition fairness? P1 and P2 terminate.

Hierarchy of fairness assumptions Strong transition weak process weak transition Strong process φψ If φ holds then also ψ. If a sequence is fair w.r.t. φ it is also fair w.r.t. Ψ. A system which assumes φ has no more executions than one assuming Ψ