Rigorous Software Development CSCI-GA 3033-009 Instructor: Thomas Wies Spring 2013 Lecture 4.

Slides:



Advertisements
Similar presentations
Model Checking Lecture 4. Outline 1 Specifications: logic vs. automata, linear vs. branching, safety vs. liveness 2 Graph algorithms for model checking.
Advertisements

Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 1 Summer school on Formal Models.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 1.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 2.
1 First order theories (Chapter 1, Sections 1.4 – 1.5)
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 12.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 10.
Modal Logic with Variable Modalities & its Applications to Querying Knowledge Bases Evgeny Zolin The University of Manchester
Query Answering for OWL-DL with Rules Boris Motik Ulrike Sattler Rudi Studer.
– Seminar in Software Engineering Cynthia Disenfeld
Abstraction of Source Code (from Bandera lectures and talks)
Semantics Static semantics Dynamic semantics attribute grammars
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
Logic.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
Symmetry-Aware Predicate Abstraction for Shared-Variable Concurrent Programs Alastair Donaldson, Alexander Kaiser, Daniel Kroening, and Thomas Wahl Computer.
CS 355 – Programming Languages
Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.
Logical Agents Chapter 7. Why Do We Need Logic? Problem-solving agents were very inflexible: hard code every possible state. Search is almost always exponential.
Logical Agents Chapter 7. Why Do We Need Logic? Problem-solving agents were very inflexible: hard code every possible state. Search is almost always exponential.
Search in the semantic domain. Some definitions atomic formula: smallest formula possible (no sub- formulas) literal: atomic formula or negation of an.
Last time Proof-system search ( ` ) Interpretation search ( ² ) Quantifiers Equality Decision procedures Induction Cross-cutting aspectsMain search strategy.
CS 4700: Foundations of Artificial Intelligence
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Describing Syntax and Semantics
CS 267: Automated Verification Lecture 13: Bounded Model Checking Instructor: Tevfik Bultan.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
SAT Solver Math Foundations of Computer Science. 2 Boolean Expressions  A Boolean expression is a Boolean function  Any Boolean function can be written.
Boolean Satisfiability and SAT Solvers
CS6133 Software Specification and Verification
Pattern-directed inference systems
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
CS 363 Comparative Programming Languages Semantics.
Analyzing relational logic Daniel Jackson, MIT WG 2.3 · Newcastle April 2000.
Propositional Calculus CS 270: Mathematical Foundations of Computer Science Jeremy Johnson.
Formal Methods in Software Engineering 1
Chapter 3 Part II Describing Syntax and Semantics.
Extra slides for Chapter 3: Propositional Calculus & Normal Forms Based on Prof. Lila Kari’s slides For CS2209A, 2009 By Dr. Charles Ling;
CS6133 Software Specification and Verification
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.
© Copyright 2008 STI INNSBRUCK Intelligent Systems Propositional Logic.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 9: Test Generation from Models.
Semantics of Predicate Calculus For the propositional calculus, an interpretation was simply an assignment of truth values to the proposition letters of.
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine1 CSE 503 – Software Engineering Lecture 3: An introduction to Alloy Rob DeLine 5 Apr 2004.
Albert Gatt LIN3021 Formal Semantics Lecture 3. Aims This lecture is divided into two parts: 1. We make our first attempts at formalising the notion of.
Propositional Logic Rather than jumping right into FOL, we begin with propositional logic A logic involves: §Language (with a syntax) §Semantics §Proof.
Daniel Kroening and Ofer Strichman 1 Decision Procedures An Algorithmic Point of View Basic Concepts and Background.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
PREDICATES AND QUANTIFIERS COSC-1321 Discrete Structures 1.
Propositional Logic. Assignment Write any five rules each from two games which you like by using propositional logic notations.
ALLOY: A Formal Methods Tool Glenn Gordon Indiana University of Pennsylvania COSC 481- Formal Methods Dr. W. Oblitey 26 April 2005.
CS.462 Artificial Intelligence SOMCHAI THANGSATHITYANGKUL Lecture 04 : Logic.
Logical Agents. Outline Knowledge-based agents Logic in general - models and entailment Propositional (Boolean) logic Equivalence, validity, satisfiability.
SS 2017 Software Verification Bounded Model Checking, Outlook
ARTIFICIAL INTELLIGENCE
Semantics In propositional logic, we associate atoms with propositions about the world. We specify the semantics of our logic, giving it a “meaning”. Such.
Propositional Calculus: Boolean Algebra and Simplification
Logical Agents Chapter 7.
Back to “Serious” Topics…
Logics for Data and Knowledge Representation
This Lecture Substitution model
Program correctness Axiomatic semantics
Dichotomies in CSP Karl Lieberherr inspired by the paper:
Instructor: Aaron Roth
Presentation transcript:

Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2013 Lecture 4

Todays Topics The Alloy Analyzer (Ch. 5 of Jackson Book) – From Alloy models to Analysis Constraints – Propositional Logic (Ch. 1 of Huth/Ryan Book) – From Analysis Constraints to Propositional Logic – Quantifier Elimination – Alleviating State Space Explosion

Alloy Analyzer (AA) Small scope hypothesis: violations of assertions are witnessed by small counterexamples – AA exhaustively searches for instances of small scope AA can falsify a model but not verify it – It can prove that an assertion does not hold for all instances of a model by finding a counterexample. – It cannot prove that an assertion holds in all instances of a model, – it can only prove that an assertion holds for all instances up to a certain size (bounded verification).

Alloy Analyzer (AA) Small scope hypothesis: violations of assertions are witnessed by small counterexamples – AA exhaustively searches for instances of small scope Can we automatically verify Alloy models? – The answer is no because the verification problem for Alloy models is undecidable – i.e., there is no general algorithm to solve this problem.

From Alloy Models to SAT and Back AA is actually a compiler – First, the alloy model is translated to a single Alloy constraint, which is called the analysis constraint. – Given the scope of the command to execute, the analysis constraint is translated into a propositional constraint. – AA then uses an off-the-shelf SAT solver to find a satisfying assignment for the propositional constraint. – If a satisfying assignment exists, it is translated back into an instance of the original Alloy model. AA reduces the problem of finding instances of Alloy models to a well-understood problem: SAT

Analysis Constraints First, the Alloy model is translated into a single Alloy constraint: the analysis constraint. The analysis constraint is a conjunction of – fact constraints facts that are explicitly declared in the model facts that are implicit in the signature declarations – and a predicate constraint: for a run command: the constraint of the predicate that is run for a check command: the negation of the assertion that is checked

Analysis Constraints: Example module addressBook abstract sig Target {} sig Addr, Name extends Target {} sig Book {addr: Name->Target} fact Acyclic {all b: Book | no ^(b.addr) & iden} pred add [b, b: Book, n: Name, t: Target] { b.addr = b.addr + n->t } run add for 3 but 2 Book

Implicit Fact Constraint The implicit fact constraint is the conjunction of the constraints implicit in the signature declarations: Example: from the signature declarations abstract sig Target {} sig Addr, Name extends Target {} sig Book {addr: Name->Target} AA generates the implicit fact constraint: Name in Target Addr in Target no Name & Addr Target in Name + Addr no Book & Target

Explicit Fact Constraint The explicit fact constraint is the conjunction of all bodies of the declared facts Example: the fact fact Acyclic {all b: Book | no ^(b.addr) & iden} generates the explicit fact constraint: all b: Book | no ^(b.addr) & iden

Predicate Constraint The predicate constraint is – the conjunction of the body of the predicate that is run and the multiplicity and type constraints of its parameters – or the negation of the body of the assertion that is checked. Example: running the predicate pred add [b, b: Book, n: Name, t: Target] { b.addr = b.addr + n->t } generates the predicate constraint: b: Book and b: Book and n: Name and t: Target b.addr = b.addr + n->t t in Target and one t

Analysis Constraint for addressBook Name in Target Addr in Target no Name & Addr Target in Name + Addr no Book & Target all b: Book | no ^(b.addr) & iden b: Book and b: Book n: Name and t: Target b.addr = b.addr + n->t Implicit fact constraint Explicit fact constraint Predicate constraint

Satisfying Assignment for Analysis Constraint Target = {(A 0 ), (N 0 )} Addr = {(A 0 )} Name = {(N 0 )} Book = {(B 0 ), (B 1 )} addr = {(B 0,N 0,A 0 ), (B 1,N 0,A 0 )} b = {(B 0 )} b = {(B 1 )} n = {(N 0 )} t = {(A 0 )} B 0 {b} B 0 {b} A 0 {t} A 0 {t} N 0 {n} N 0 {n} B 1 {b} B 1 {b} addr [N 0 ] Satisfying assignment is mapping from constraint vars to relations of atoms that evaluate the constraint to true.

From Analysis Constraints to Propositional Logic Given the scope of the command to execute, the analysis constraint is translated into a constraint in propositional logic. The translation guarantees a one-to-one correspondence between satisfying assignments of the propositional constraint and the analysis constraint. AA then uses an off-the-shelf SAT solver to find a satisfying assignment for the propositional constraint. If a satisfying assignment is found, it is translated back into an assignment of the analysis constraint which in turn represents the instance of the original Alloy model.

What is Logic? Like a programming language, a logic is defined by its syntax and semantics. Syntax: – An alphabet is a set of symbols. – A finite sequence of symbols is called an expression. – A set of rules defines the well-formed expressions. Semantics: – Gives meaning to well-formed expressions. – Formal notions of induction and recursion can be used to give rigorous semantics.

Syntax of Propositional Logic Each expression is made of – propositional variables: a, b,..., p, q,... – logical constants:, – logical connectives: Æ, Ç, ),... Every propositional variable stands for a basic fact – Examples: Im hungry, Apples are red, Joe and Jill are married

Syntax of Propositional Logic Well-formed expressions are called formulas Each propositional variable (a, b,..., p, q,...) is a formula Each logical constant (, ) is a formula If Á and à are formulas, all of the following are also formulas ¬ Á Á Æ Ã Á ) à ( Á ) Á Ç Ã Á, à Nothing else is a formula

Semantics of Propositional Logic The meaning (value) of is always True. The meaning of is always False. The meaning of the other formulas depends on the meaning of the propositional variables. – Base cases: Truth Tables – Non-base cases: Given by reduction to the base cases Example: the meaning of (p Ç q) Æ r is the same as the meaning of a Æ r where a has the same meaning as p Ç q. PQ : PP Æ QP Ç QP ) QP, Q False TrueFalse True FalseTrue FalseTrue False TrueFalse TrueFalse True FalseTrue

Semantics of Propositional Logic An assignment of Boolean values to the propositional variables of a formula is an interpretation of the formula. Interpretations: {P False, Q False}, {P False, Q True},... The semantics of Propositional logic is compositional: the meaning of a formula is dened recursively in terms of the meaning of the formulas components. PQP Ç Q(P Ç Q) Æ : Q(P Ç Q) Æ : Q ) P False True FalseTrue FalseTrue FalseTrue FalseTrue

Semantics of Propositional Logic Typically, the meaning of a formula depends on its interpretation. Some formulas always have the same meaning. A formula is – (un)satisable if it is true in some (no) interpretation, – valid if it is true in every possible interpretation. A formula that is valid or unsatisfiable is called a tautology. PQP Ç Q(P Ç Q) Æ : Q(P Ç Q) Æ : Q ) P False True FalseTrue FalseTrue FalseTrue FalseTrue

The SAT Problem The satisfiability problem for propositional logic (SAT) asks whether a given formula Á is satisfiable. SAT is decidable. Hence, so is validity of propositional formulas. However, SAT is NP-complete Hence, checking validity is co-NP-complete.

The SAT Problem Many problems in formal verication can be reduced to checking the satisability of a formula in some logic. In practice, NP-completeness means the time needed to solve a SAT problem grows exponentially with the number of propositional variables in the formula. Despite NP-completeness, many realistic instances (in the order of 100,000 variables) can be checked very efciently by state-of-the-art SAT solvers.

Translating the Analysis Constraint Name in Target Addr in Target no Name & Addr Target in Name + Addr no Book & Target all b: Book | no ^(b.addr) & iden b: Book and b: Book n: Name and t: Target b.addr = b.addr + n->t

Characteristic Function of a Relation Name = {(N 0 ),(N 1 ),(N 2 )} Addr = {(A 0 ),(A 1 ),(A 2 )} address = {(N 0,A 0 ), (N 1,A 1 ), (N 2,A 1 )} Characteristic function of the relation address: Â address : Name £ Addr ! {0,1} Â address (N i,A j ) = 1 iff (N i,A j ) 2 address

Characteristic Function of a Relation Name = {(N 0 ),(N 1 ),(N 2 )} Addr = {(A 0 ),(A 1 ),(A 2 )} address = {(N 0,A 0 ), (N 1,A 1 ), (N 2,A 1 )} Characteristic function of the relation address: Â address N0N0 N1N1 N2N2 A0A0 100 A1A1 011 A2A2 000

Propositional Encoding of Relations Introduce a propositional variable X ij for every A i and N j : Â address N0N0 N1N1 N2N2 A0A0 100 A1A1 011 A2A2 000 N0N0 N1N1 N2N2 A0A0 X 00 X 01 X 02 A1A1 X 10 X 11 X 12 A2A2 X 20 X 21 X 22

Propositional Encoding of Relations Introduce a propositional variable X ij for every A i and N j :  address N0N0 N1N1 N2N2 A0A0 100 A1A1 011 A2A2 000 N0N0 N1N1 N2N2 A0A0 X 00 X 01 X 02 A1A1 X 10 X 11 X 12 A2A2 X 20 X 21 X 22 Each assignment to the propositional variables X ij corresponds to one possible function  address and thus one possible interpretation of the relation address. Each assignment to the propositional variables X ij corresponds to one possible function  address and thus one possible interpretation of the relation address.

Translating Relational Operations All relational operations in an Alloy constraint are encoded as propositional formulas. The propositional variables in the formulas describe the characteristic functions of the relational variables in the Alloy constraint. Â addr N0N0 N1N1 N2N2 A0A0 X 00 X 01 X 02 A1A1 X 10 X 11 X 12 A2A2 X 20 X 21 X 22

Propositional Translation: Example Analysis constraint (scope 3): Addr in Target Propositional variables for characteristic functions: Addr : A 0, A 1, A 2 Target : T 0, T 1, T 2 Propositional encoding of analysis constraint: A 0 ) T 0 Æ A 1 ) T 1 Æ A 2 ) T 2

Propositional Translation: Example Analysis constraint (scope 3): address = address + n->t Flatten analysis constraint by introducing fresh variables for non-trivial subexpressions. Flattened analysis constraint: address = address + e e = n->t

Propositional Translation: Example Flattened analysis constraint (scope 3): address = address + e e = n->t Propositional variables for characteristic functions: address: A 00, A 01, A 02, A 10, A 11, A 12, A 20, A 21, A 22 e : E 00, E 01, E 02, E 10, E 11, E 12, E 20, E 21, E 22 n : N 0, N 1, N 2 t : T 0, T 1, T 2

Propositional Translation: Example Flattened analysis constraint (scope 3): e = n->t Propositional variables for characteristic functions: e : E 00, E 01, E 02, E 10, E 11, E 12, E 20, E 21, E 22 n : N 0, N 1, N 2 t : T 0, T 1, T 2 Propositional encoding of analysis constraint: Æ E ij, N i Æ T j 0 · i,j · 2

Propositional Translation: Example Flattened analysis constraint (scope 3): addr = addr + e Propositional variables for characteristic functions: address: A 00, A 01, A 02, A 10, A 11, A 12, A 20, A 21, A 22 e : E 00, E 01, E 02, E 10, E 11, E 12, E 20, E 21, E 22 Propositional encoding of analysis constraint: Æ A ij, A ij Ç E ij 0 · i,j · 2

Quantifier Elimination Universal and existential quantification over finite sets can be eliminated using finite conjunctions, respectively, disjunctions. Example: Replace universal quantifier all x: S | F where S = {s 0,..., s n } with conjunction F[s 0 /x] and... and F[s n /x]

Quantifier Elimination Quantifier elimination can be encoded directly in the propositional constraint. Example: The universal quantifier all x: Alias | x.addr in Addr can be encoded by the propositional formula Æ A i Æ R ij ) D j assuming the scope is n and the propositional variables are A i for Alias, D i for Addr, and R ij for addr. 0 · i,j < n

Skolemization Existential quantifiers can be treated more effectively using Skolemization – Replace top-level existential quantifiers of the form some x: S | F with (xs: S) and F[xs/x] where xs is a fresh variable Advantage: witness for x is made explicit in generated instances

Skolemization Skolemization also works for existential quantifiers that appear below universal quantifiers: – replace all x: S | some y: T | F with (sy: S->one T) and all x: S | F[x.sy/y] where sy is a fresh analysis variable

Symmetries in Satisfying Assignments Permuting the names of the propositional variables for each characteristic function in a satisfying assignment yields again a satisfying assigment.

Symmetries in Satisfying Assignments Target = {(A 0 ), (N 0 )} Addr = {(A 0 )} Name = {(N 0 )} Book = {(B 0 ), (B 1 )} addr = {(B 0,N 0,A 0 ), (B 1,N 0,A 0 )} b = {(B 0 )} b = {(B 1 )} n = {(N 0 )} t = {(A 0 )} B 0 {b} B 0 {b} A 0 {t} A 0 {t} N 0 {n} N 0 {n} B 1 {b} B 1 {b} addr [N 0 ] Exchanging the roles of B 0 and B 1 gives a symmetric satisfying assignment.

Symmetries can lead to an exponential blow-up in the number of possible instances. This state space explosion problem makes it hard for the SAT solver to solve the propositional constraints. Ideally, the SAT solver only has to consider one assignment per equivalence class of symmetric assignments. State Space Explosion Problem

Symmetry Reduction To reduce the number of symmetries, Alloy adds symmetry breaking constraints to the propositional constraint. Example: util/ordering [Data] – all orderings on Data atoms Data0, Data1, Data2, … are symmetric. – util/ordering enforces one particular ordering on Data, namely the lexicographic ordering on atom names: Data0 < Data1 < Data2 < …

Alleviating State Space Explosion Often careful modeling can help to reduce symmetries Example: use partial instances when possible instead of left right null rightleft null right left right left and right are partial functions instead of total functions

Next Week: Design by Contract Alloy provides a means for expressing properties of designs – Early design refinement saves time – Ultimately, we want this effort to impact the quality of implementations How can we transition design information to the code? – State information (multiplicities, invariants, …) – Operations info (pre, post, frame conditions, …)