Modeling Software Systems Lecture 2 Book: Chapter 4.

Slides:



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

Model Checking Lecture 1.
Modeling Software Systems Lecture 2 Book: Chapter 4.
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Models of Concurrency Manna, Pnueli.
Part 3: Safety and liveness
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.
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
Lecture 8: Three-Level Architectures CS 344R: Robotics Benjamin Kuipers.
CS6133 Software Specification and Verification
1 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Lecture 10: Formal Verification Formal Methods Basics of Logic first order.
卜磊 Transition System. Part I: Introduction  Chapter 0: Preliminaries  Chapter 1: Language and Computation Part II: Models  Chapter.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture 05.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Lecture 2: Reasoning with Distributed Programs Anish Arora CSE 6333.
Concurrency.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of.
Chapter 11: Distributed Processing Parallel programming Principles of parallel programming languages Concurrent execution –Programming constructs –Guarded.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
Review of the automata-theoretic approach to model-checking.
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.
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.
15-820A 1 LTL to Büchi Automata Flavio Lerda A 2 LTL to Büchi Automata LTL Formulas Subset of CTL* –Distinct from CTL AFG p  LTL  f  CTL. f.
Linear and Branching Time Safety, Liveness, and Fairness
1 Introduction to SMV and Model Checking Mostly by: Ken McMillan Cadence Berkeley Labs Small parts by: Brandon Eames ISIS/Vanderbilt.
Representing distributed algorithms Why do we need these? Don’t we already know a lot about programming? Well, you need to capture the notions of atomicity,
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
1 Formal Semantics of Programming Languages “Program testing can be used to show the presence of bugs, but never to show their absence!” --Dijkstra.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 3 (26/01/2006) Instructor: Haifeng YU.
CS6133 Software Specification and Verification
Lecture #5 Properties of hybrid systems João P. Hespanha University of California at Santa Barbara Hybrid Control and Switched Systems.
Defining Programs, Specifications, fault-tolerance, etc.
Advanced Topics in Software Engineering Marjan Sirjani Tehran University Faculty of Engineering ECE Department Tehran,
6.852: Distributed Algorithms Spring, 2008 Class 13.
卜磊 Transition System. Definitions and notations Reactive System The intuition is that a transition system consists of a set of possible.
2015 Concurrency: logical properties 1 ©Magee/Kramer 2 nd Edition Chapter 14 Logical Properties Satisfied? Not satisfied?
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
Ordering of Events in Distributed Systems UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department CS 739 Distributed Systems Andrea C. Arpaci-Dusseau.
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.
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 8 Introduction to Modelling Concurrency John Gurd, Graham Riley Centre for.
Formal methods: Lecture
CIS 842: Specification and Verification of Reactive Systems
Automatic Verification
Axiomatic semantics Points to discuss: The assignment statement
CSCI1600: Embedded and Real Time Software
ITEC452 Distributed Computing Lecture 5 Program Correctness
CSCI1600: Embedded and Real Time Software
Translating Linear Temporal Logic into Büchi Automata
COMP60621 Designing for Parallelism
Introduction to verification
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.,  0≤i≤n A[i]≥0, A[i] integer. Have some final assertion, e.g.,  0≤i≤n-1 A[i] · A[i+1]. is supposed to terminate.

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

Problems in modeling concurrent systems 1. Granularity of transitions (‘atomic transitions’). 2. Representing and specifying concurrency: - Allow one transition at a time. - Allow parallel transitions. - Allow a partial order between events. 3. Assumptions about ‘normal behavior’ of concurrent systems (e.g. ‘fairness’).

1. Granularity & Atomic Transitions Question: Is the statement c:=a+a; equal to c:= 2a; ?

Execute the following when a=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 Granularity & Atomic Transitions

2. Modeling V={v 0,v 1,v 2, …} - a set of variables, over some domain. A state is an assignment of values to the program variables. For example: s= h v 0 =1,v 2 =3,v 3 =7,…,v 18 =2 i The state space of a program is the set of all possible states for it.

2. Modeling p(v 0, v 1, …, v n ) - a parametrized predicate, e.g., (v 0 =v 1 +v 2 ) Æ (v 3 >v 4 ). p(s) is p under the assignment s. Example: modeling the initial condition: A parametrized predicate I. The program can start from states s such that I(s) holds. For example: I(s)=a>b Æ b>c.

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.

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

Example V = {a, b, c, d, e}. I = c=a Æ d=b Æ e=0 T = {c>0  (c,e):=(c-1,e+1), d>0  (d,e):=(d-1,e+1)} 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.., I(s 0 ). Moving from one state s i to s i+1 is by executing one 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 = h a=2, b=1, c=2, d=1, e=0 i (satisfies the initial condition) S 1 = h a=2, b=1, c=1, d=1, e=1 i (first transition executed) S 2 = h a=2, b=1, c=1, d=0, e=2 i (second transition executed) S 3 = h a=2, b=1,c=0, d=0, e=3 i (first transition executed again)

L 0 :While True do NC 0 :wait (Turn=0); CR 0 :Turn=1; endwhile Initially: PC 0 =L 0 Æ PC 1 =L 1 A long example … (Mutual Exclusion) L 1 :While True do NC 1 :wait (Turn=1); CR 1 :Turn=0; endwhile ||

L 0 :While True do NC 0 :wait (Turn=0); CR 0 :Turn=1 endwhile || L 1 :While True do NC 1 :wait (Turn=1); CR 1 :Turn=0 endwhile T 0 : PC 0 =L 0  PC 0 :=NC 0 T 1 : PC 0 =NC 0 Æ Turn=0  PC 0 :=CR 0 T 2 : PC 0 =CR 0  (PC 0,Turn) :=(L 0,1) T 3 : PC 1 =L 1  PC 1 =NC 1 T 4 : PC 1 =NC 1 Æ Turn=1  PC 1 :=CR 1 T 5 : PC 1 =CR 1  (PC 1,Turn) :=(L 1,0) I: PC 0 =L 0 Æ PC 1 =L 1 And here is the transition system… V={PC 0,PC 1,Turn…}

The state space Turn=0 CR 0,NC 1 Turn=0 NC 0,NC 1 Turn=0 CR 0,L 1 Turn=1 L 0,CR 1 Turn=1 NC 0,CR 1 Turn=1 NC 0,NC 1 Turn=0 L 0,L 1 Turn=0 L 0,NC 1 Turn=0 NC 0,L 1 Turn=1 L 0,NC 1 Turn=1 NC 0,L 1 Turn=1 L 0,L 1

Specification with Temporal Logic (informal) First order logic or propositional assertions describe a state. Some temporal operators: } 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. } 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.

Turn=0 CR 0,NC 1 Turn=0 NC 0,NC 1 Turn=0 CR 0,L 1 Turn=1 L 0,CR 1 Turn=1 NC 0,CR 1 Turn=1 NC 0,NC 1 Turn=0 L 0,L 1 Turn=0 L 0,NC 1 Turn=0 NC 0,L 1 Turn=1 L 0,NC 1 Turn=1 NC 0,L 1 Turn=1 L 0,L 1 “Mutual exclusion is preserved” (Safety) ð ¬(PC 0 =CR 0 Æ PC 1 =CR 1 )

Turn=0 CR 0,NC 1 Turn=0 NC 0,NC 1 Turn=0 CR 0,L 1 Turn=1 L 0,CR 1 Turn=1 NC 0,CR 1 Turn=1 NC 0,NC 1 Turn=0 L 0,L 1 Turn=0 L 0,NC 1 Turn=0 NC 0,L 1 Turn=1 L 0,NC 1 Turn=1 NC 0,L 1 Turn=1 L 0,L 1 “The processes switch turns” (Liveness) ð ((Turn=0 ) } Turn=1) Æ (Turn=1 ) } Turn = 0))

Turn=0 CR 0,NC 1 Turn=0 NC 0,NC 1 Turn=1 L 0,CR 1 Turn=0 L 0,L 1 Turn=0 L 0,NC 1 Turn=1 L 0,NC 1 In the interleaving semantics we consider all possible traces…

Turn=0 L 0,L 1 Turn=0 L 0,NC 1 Turn=0 CR 0,NC 1 Turn=0 NC 0,NC 1 Turn=1 L 0,CR 1 Turn=1 L 0,NC 1 Turn=0 L 0,L 1 Turn=0 L 0,NC 1 … In this case this the computation is:

An infinite unfolding of the automaton represents all interleavings Turn=0 L 0,L 1 Turn=0 L 0,NC 1 Turn=0 NC 0,L 1 Turn=0 CR 0,NC 1 Turn=0 NC 0,NC 1 Turn=0 CR 0,L 1 Turn=1 L 0,NC 1 Turn=0 NC 0,NC 1 Turn=0 CR 0,NC 1 Turn=0 CR 0,NC 1

Alternative: Partial Order Semantics Sometimes called “real concurrency”. There is no total order between events. More intuitive. Closer to the actual behavior of the system. May make verification easier Partial order: (S, <), where < is Transitive: 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 n0 m1 PC 1 =m0,x=0 PC 1 =m0,x=2 PC 1 =m0,x=1 PC 1 =m1,x=1 PC 1 =m1,x=2 PC 2 =n0,y=0,z=0 PC 2 =n0,y=1,z=1 PC 2 =n1,y=0,z=1 PC 2 =n1,y=1,z=2 Initially: x=0 Local variables frequently do not affect properties- disregard their order !

Linearizations n0 m1 PC 1 =m0,x=0 PC 1 =m0,x=2 PC 1 =m0,x=1 PC 1 =m1,x=1 PC 1 =m1,x=2 PC 2 =n0,y=0,z=0 PC 2 =n0,y=1,z=1 PC 2 =n1,y=0,z=1 PC 2 =n1,y=1,z=2 pc 1 xpc 2 yz s0s0 m0m0 0n0n0 00 s1s1 m1m1 1n0n0 00 s2s2 m0m0 1n1n1 01 s3s3 m1m1 2n1n1 01 s4s4 m1m1 2n0n0 11 s5s5 m0m0 2n1n1 12 …

Linearizations pc 1 xpc 2 yz s0s0 m0m0 0n0n0 00 s1s1 m1m1 1n0n0 00 s2s2 m0m0 1n1n1 01 s3s3 m0m0 1n0n0 11 s4s4 m1m1 2n0n0 11 s5s5 m0m0 2n1n1 12 … n0 m1 PC 1 =m0,x=0 PC 1 =m0,x=2 PC 1 =m0,x=1 PC 1 =m1,x=1 PC 1 =m1,x=2 PC 2 =n0,y=0,z=0 PC 2 =n0,y=1,z=1 PC 2 =n1,y=0,z=1 PC 2 =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

3. Modeling assumptions on concurrency Restriction on the set of ‘legal’ sequences. if some transition is enabled infinitely often, then it will be executed (in other words, the program is ‘fair’).

P1 L 0 :x:=1 P2 R 0 :while y=0 do [:: z:=z+1 :: if x=1 then y:=1] end while I: x=0 Æ y=0 Æ z=0 Æ PC 1 =L 0 Æ PC 2 =R 0 Termination? Termination of P1? Both of these are enabled No fairness? Nothing guaranteed With fairness? P1 and P2 terminate.

L 0 :While True do NC 0 :wait (Turn=0); CR 0 :Turn=1 endwhile || L 1 :While True do NC 1 :wait (Turn=1); CR 1 :Turn=0 endwhile T 0 : PC 0 =L 0  PC 0 :=NC 0 T 1 : PC 0 =NC 0 Æ Turn=0  PC 0 :=CR 0 T1’:PC 0 =NC 0 Æ Turn=1  PC 0 :=NC 0 T 2 : PC 0 =CR 0  (PC 0,Turn) :=(L 0,1) T 3 : PC 1 =L 1  PC 1 =NC 1 T 4 : PC 1 =NC 1 Æ Turn=1  PC 1 :=CR 1 T4’:PC 1 =NC 1 Æ Turn=0  PC 1 :=N1 T 5 : PC 1 =CR 1  (PC 1,Turn) :=(L 1,0) I: PC 0 =L 0 Æ PC 1 =L 1 V={PC 0,PC 1,Turn…} 3. Assumptions (fairness)

L 0 :While True do NC 0 :wait(Turn=0); CR 0 :Turn=1 endwhile || L 1 :While True do NC 1 :wait(Turn=1); CR 1 :Turn=0 endwhile T0:PC 0 =L 0  PC 0 :=NC 0 T1:PC 0 =NC 0 Æ Turn=0  PC 0 :=CR 0 T1’:PC 0 =NC 0 Æ Turn=1  PC 0 :=NC 0 T2:PC 0 =CR 0  (PC 0,Turn) :=(L 0,1) T3:PC 1 ==L 1  PC 1 =NC 1 T4:PC 1 =NC 1 Æ Turn=1  PC 1 :=CR 1 T4’:PC 1 =NC 1 Æ Turn=0  PC 1 :=N1 T5:PC 1 =CR 1  (PC 1,Turn) :=(L 1,0) Initially: PC 0 =L 0 Æ PC 1 =L 1 3. Assumptions (fairness)

ð (Turn=0 )} Turn=1) Turn=0 CR 0,NC 1 Turn=0 NC 0,NC 1 Turn=0 CR 0,L 1 Turn=1 L 0,CR 1 Turn=1 NC 0,CR 1 Turn=1 NC 0,NC 1 Turn=0 L 0,L 1 Turn=0 L 0,NC 1 Turn=0 NC 0,L 1 Turn=1 L 0,NC 1 Turn=1 NC 0,L 1 Turn=1 L 0,L 1

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 Ψ