Software Verification and Testing. Lecture Notes: Temporal Logics



Similar documents
Formal Verification and Linear-time Model Checking

Formal Verification of Software

Software Modeling and Verification

Model Checking: An Introduction

Temporal Logics. Computation Tree Logic

Semantics and Verification of Software

Introduction to Software Verification

Model Checking II Temporal Logic Model Checking

logic language, static/dynamic models SAT solvers Verified Software Systems 1 How can we model check of a program or system?

Fixed-Point Logics and Computation

Algorithmic Software Verification

Rigorous Software Development CSCI-GA

Testing LTL Formula Translation into Büchi Automata

Static Program Transformations for Efficient Software Model Checking

Model checking test models. Author: Kevin de Berk Supervisors: Prof. dr. Wan Fokkink, dr. ir. Machiel van der Bijl

Development of dynamically evolving and self-adaptive software. 1. Background

Fundamentals of Software Engineering

Today s Agenda. Automata and Logic. Quiz 4 Temporal Logic. Introduction Buchi Automata Linear Time Logic Summary

CISC422/853: Formal Methods

Software Model Checking: Theory and Practice

Specification and Analysis of Contracts Lecture 1 Introduction

A Propositional Dynamic Logic for CCS Programs

Feature Specification and Automated Conflict Detection

Path Querying on Graph Databases

Formal Verification Coverage: Computing the Coverage Gap between Temporal Specifications

Software Model Checking. Equivalence Hierarchy

Software Model Checking: Theory and Practice

Low upper bound of ideals, coding into rich Π 0 1 classes

CHAPTER 7 GENERAL PROOF SYSTEMS

From Workflow Design Patterns to Logical Specifications

A computational model for MapReduce job flow

Runtime Verification - Monitor-oriented Programming - Monitor-based Runtime Reflection

T Reactive Systems: Introduction and Finite State Automata

Formal Verification by Model Checking

The Model Checker SPIN

Using Patterns and Composite Propositions to Automate the Generation of Complex LTL

Summary Last Lecture. Automated Reasoning. Outline of the Lecture. Definition sequent calculus. Theorem (Normalisation and Strong Normalisation)

Journal of Mathematics Volume 1, Number 1, Summer 2006 pp

The Course.

Automata-based Verification - I

CS Master Level Courses and Areas COURSE DESCRIPTIONS. CSCI 521 Real-Time Systems. CSCI 522 High Performance Computing

Software Engineering using Formal Methods

Formal Verification of Computer Systems - (INFO-F-412)

UML TUTORIALS THE USE CASE MODEL

A Distributed Calculus for Role-Based Access Control

On the Modeling and Verification of Security-Aware and Process-Aware Information Systems

Introducing Formal Methods. Software Engineering and Formal Methods

Iterated Dynamic Belief Revision. Sonja Smets, University of Groningen. website:

Validated Templates for Specification of Complex LTL Formulas

6.852: Distributed Algorithms Fall, Class 2

StaRVOOrS: A Tool for Combined Static and Runtime Verification of Java

Reading 13 : Finite State Automata and Regular Expressions

! " # The Logic of Descriptions. Logics for Data and Knowledge Representation. Terminology. Overview. Three Basic Features. Some History on DLs

Schedule. Logic (master program) Literature & Online Material. gic. Time and Place. Literature. Exercises & Exam. Online Material

System modeling. Budapest University of Technology and Economics Department of Measurement and Information Systems

CS510 Software Engineering

Lecture 10: Regression Trees

Mathematics for Computer Science/Software Engineering. Notes for the course MSM1F3 Dr. R. A. Wilson

Verification of hybrid dynamical systems

MetaGame: An Animation Tool for Model-Checking Games

INTRODUCTORY SET THEORY

DNA Data and Program Representation. Alexandre David

On strong fairness in UNITY

A Framework for the Semantics of Behavioral Contracts

Model Checking based Software Verification

Formal Engineering for Industrial Software Development

Automated Theorem Proving - summary of lecture 1

INF5140: Specification and Verification of Parallel Systems

Vector storage and access; algorithms in GIS. This is lecture 6

3 Extending the Refinement Calculus

Loop Invariants and Binary Search

Model Checking of Software

A first step towards modeling semistructured data in hybrid multimodal logic

The University of Jordan

Automated Route Planning for Milk-Run Transport Logistics with the NuSMV Model Checker

Research Note. Bi-intuitionistic Boolean Bunched Logic

Regression Verification: Status Report

Bounded LTL Model Checking with Stable Models

x < y iff x < y, or x and y are incomparable and x χ(x,y) < y χ(x,y).

A Classification of Model Checking-based Verification Approaches for Software Models

Goal-Driven Adaptable Software Architecture for UAVs

Fabio Patrizi DIS Sapienza - University of Rome

Automata-Based Verification of Temporal Properties on Running Programs Dimitra Giannakopoulou Klaus Havelund

Ensuring Consistency in Long Running Transactions

Transcription:

Software Verification and Testing Lecture Notes: Temporal Logics

Motivation traditional programs (whether terminating or non-terminating) can be modelled as relations are analysed wrt their input/output behaviour (pre/postconditions) invariants are also considered correctness properties: partial correctness (of postcondition wrt precondition): if the precondition holds then the postcondition will hold whenever the program terminates. total correctness (of postcondition wrt precondition): if the precondition holds then the postcondition will hold and the program will terminate. 1

Motivation reactive systems: yield no final output i/o-relations are not appropriate for their analysis partial/total correctness are not relevant invariants are much more important correctness properties: are properties of the execution run/trace of the system have a dynamical/temporal flavour can be formalised/analysed using temporal logics 2

Time question: what is time? Augustinus: If nobody asks me for it, I know it; if I want to explain it to someone, I do not know it. science/engineering: time is used and modelled without asking what it is selection of model is application-driven question: then how to model time? remark: still a difficult question... 3

Time questions: is time discrete/continuous? instant/interval-based? linear/branching?... question: do we describe time by past, present, future? earlier, later? question: is our model exogenous/endogenous? exogenous: compare different systems endogenous: focus on trace of one single system 4

Time in FOL example: modelling time as relational structure (T, <) in FOL possible properties of binary precedence relation < irreflexivity: x. x < x transitivity: x, y, z.(x < y y < z x < z) linearity: x, y.(x = y x < y y < x) (forward) discreteness: x y.(x < y z.(x < z w.(x < w z < w))) density: x, y.(x < y z.(x < z z < y)) no end: x y.x < y problems: many interesting properties cannot be expressed, e.g., every descending sequence of instants of time must be finite. formalism may be difficult to manipulate 5

Alternative Model framework: we make the following assumptions instant-based model with initial state, infinite into future time is discrete (there are time-steps) we model temporal properties by propositional logics we add temporal operators (next-time, always, eventually,... ) to model temporal system behaviour remarks: temporal operators are examples of modal operators; temporal logics are examples of modal logics we will see logics for linear and branching time 6

Alternative Model temporal logics and transition systems reactive system modelled by LTS formulae of propositional logics describe what holds in a state temporal operators describe what holds in the next state, in some future state, in all future states, etc. these descriptions can be understood as observer processes consequence: satisfiability relation should be relativised to states or paths: A, s = φ A, c = φ where A = (S, T, α, β, λ) is a LTS, s S, c is a path over T and φ is a formula of temporal logic 7

Temporal Logics and Transition Systems example: consider a mutex algorithm (with two processes) we have seen how to model this as an LTS properties of interest might be there never is a global state with both processes in the critical section (a safety property) there never is a global state without any transition (deadlock-free) traces from a global state are always infinite (deadlock-free) every process that tries to enter the critical section from a global state will eventually enter it (a liveness property) there is an infinite path where in each transition the two processes try to reach the critical section and never succeed (livelock) 8

Linear Temporal Logic idea: linear temporal logic (LTL) expresses path properties of a LTS syntax: the language of LTL is built from a set P of propositional variables, the constant 0, the logical connective, the temporal operators X ( next ) and U ( until ) the formulae of LTL are defined (inductively) by the rules φ ::= p 0 φ ψ X φ φu ψ 9

Linear Temporal Logic syntax: other logical connectives can be defined as usual (question: how to define p?) 1 = 0 further temporal operators: F φ = 1U φ ( eventually, finally ) Gφ = F φ ( always, globally ) 10

Linear Temporal Logic intuitive semantics: X φ φuψ F φ G φ 11

Linear Temporal Logic semantics: Let A = (S, T α, β, λ τ ) be a LTS and c a path label states with the propositional variables that hold there λ σ : S 2 P we then inductively define A, c = φ for every LTL formula φ: A, c = 1 and not A, c = 0 A, c = p iff p P and p λ σ (α(c)) A, c = φ ψ iff A, c = φ implies A, c = ψ A, c = X φ iff c = t c and A, c = φ A, c = φu ψ iff A, c = ψ, or c = t 1... t n c with A, c = ψ and 1 i n. A, t i... t n c = φ 12

Properties global semantics: A = φ iff A, c = φ for all paths c = φ iff A = φ for all LTS A semantics of always and eventually: A, c = F φ iff c = c c (for some c ) and A, c = φ A, c = Gφ iff A, c = φ for all c with c = c c further interesting operators: F φ = GF φ infinitely often G φ = FGφ almost everywhere 13

Properties remark: many properties of temporal operators can be derived from their semantics = X φ X φ = F (φ ψ) F φ F ψ = (φu ψ) ψ (φ X (φu ψ)) = GGφ Gφ... 14

Properties properties of paths expressed in LTL: A, c = X 1: c is non-empty A, c = FX 0: c is infinite correctness properties: safety properties ( bad things never happen ): G φ liveness properties ( good things eventually happen ): F ψ or G(φ F ψ) fairness properties ( all processes are treated fairly be the scheduler ) (examples later) 15

Properties examples: partial correctness: (a safety property) φ G(terminates ψ) total correctness: (a liveness property) φ F (terminates ψ) 16

Properties examples: it will never be the case that two cars are at the same time at the crossing (a safety property) G (c 1 c 2 atcrossing(c 1 ) atcrossing(c 2 ) I ll be back (a liveness property) Terminator(x) F isback(x) all plagiators will eventually be caught (another liveness property) G(isPlagiator(x) F iscaught(x)) 17

Properties fairness: (there are several other fairness properties) impartiality: every process is executed infinitely often i.f executed i weak fairness: every process enabled almost everywhere is executed infinitely often i.(g enabled i F executed i ) strong fairness: every process enabled infinitely often is executed infinitely often i.(f enabled i F executed i ) 18

Computational Tree Logic idea: for computational tree logic (CTL) instead of paths, consider properties of states of LTS unfolded to tree quantify existentially/universally over transitions from a state language: propositional part as for LTL next-step operators AX and EX until operators E[ U ] and A[ U ] formulae: φ ::= p 0 φ ψ EX φ AX φ E[φU ψ] A[φU ψ] 19

Computational Tree Logic intuitive semantics: EXφ AXφ E[ φu ψ ] A[ φuψ ] 20

Computational Tree Logic definition: a maximal path is a path that is either infinite or ending in a state that is not the source of another transition semantics: inductively define A, s = φ for state s and CTL-formula φ propositional cases similar to LTL (A, s = p iff p λ σ (s)) A, s = EX φ iff A, s = φ for some transition with source s and target s A, s = AX φ iff A, s = φ for all transitions with source s and target s A, s = E[φU ψ] iff there is a maximal path c = t 1... t n... with source s such that either A, s = ψ, or there is a k N such that A, β(t k ) = ψ and 1 i k.a, α(t i ) = φ A, s = A[φU ψ] iff for all maximal paths c = t 1... t n... with source s either A, s = ψ, or there is a k N such that A, β(t k ) = ψ and 1 i k.a, α(t i ) = φ, or c is a finite path and for every i, A, α(t i ) = φ and A, β(t i ) = φ 21

Computational Tree Logic remarks: operators for eventually and globally can again be defined A, s = AX φ holds in particular if s is not the source of any transition again, a rich calculus for CTL follows from the semantics LTL vs CTL: both logics have particular advantages CTL can distinguish some LTS that LTL cannot LTL cannot express possibility properties CTL cannot express fairness conditions (there are no path formulae to express F ) remark: the logic CTL overcomes these restrictions; it subsumes both LTL and CTL and has state and path formulae 22

Model Checking model checking problem: Given a LTS A and a formula φ (in some temporal logic), does the following hold? A, s = φ A, c = φ A = φ model checking and verification: the LTS encodes a reactive system, the correctness properties is described in the temporal logic remark: for finite LTS model checking problems are decidable validity of the temporal logic formulae can be checked by global search on the LTS different logics lead to different search complexities if the formula does not hold, the failure path/run provides information for bug fixing 23

Model Checking algorithmic aspects: intuitively, the temporal logics formula is compiled into an observer process that runs in parallel with the LTS global model checking: recurse on formulae; but evaluate on global LTS local model checking: explore LTS locally; but evaluate entire formulae worst-case complexity is the same, but average behaviour can differ LTL is usually treated locally, CTL globally the performance critically depends on storage space, on efficient data structures (e.g. binary decision diagrams) and on heuristics 24