Model Finder. Lawrence Chung 1
|
|
|
- Tracey Francis
- 5 years ago
- Views:
Transcription
1 Model Finder Lawrence Chung 1
2 Comparison with Model Checking Model Checking Model (System Requirements) STM Specification (System Property) Temporal Logic Model Checker M φ Model Finder ( Answer: Yes, if model satisfies specification Counterexample, otherwise For increasing our confidence in the correctness of the model: Verification: The model satisfies important system properties Debugging: Study counter-examples, pinpoint the source of the error, correct the model, and try again Model (System Requirements, Specification, etc.) Model Finder M true M φ Answer: An instance, if model is consistent Counterexample, if model does satisfy assertion Lawrence Chung 2
3 Characteristics of Alloy finite scope check analysis of the model needs a scope (size). The analysis is sound (it never returns false positives) but incomplete (since it only checks things up to a certain scope). However, it is complete up to scope; it never misses a counterexample which is smaller than the specified scope. Small scope checks are still extremely valuable for finding errors. infinite model - The models in Alloy do not reflect the fact that the analysis is finite. That is, you describe the components of a system and how they interact, but do not specify how many components there can be (as is done in traditional "model checking"). declarative - a declarative modeler answers the question "how would I recognize that X has happened", as opposed to an "operational" or "imperative" modeler who asks "how can I accomplish X". automatic analysis - unlike some other declarative specification languages (such as Z and OCL, the object language of UML), Alloy can be automatically analyzed. You can automatically generate examples of your system and counterexamples to claims made about that system. structured data - Alloy supports complex data structures, such as trees, and thus is a rich way to describe state Lawrence Chung 3
4 A Walkthrough a simple model of a file system. It has a notion of a "file system object" which can be either a file or a directory. Every file system object knows its parent, and directories also know their contents. We will also create the notion of a "root directory", which resides at the top of the file system. Define files, directories, and file system objects, and make sure that they have the appropriate fields (parent, contents, etc.). Write simple facts to constrain the file system and to impose simple sanity constraints. For instance: every file system object must be either a file or a directory (not both, not neither); the file system is connected, the root has no parent; and so on. Make assertions about properties you think (or hope) are true as a result of the sanity constraints you wrote. Check these assertions, and handle when they fail to hold. For instance, verify that a file system is acyclic, even though we do not explicitly force it to be so. The file system will have some shortcomings; most prominently, it will be static. Later, dynamic operations, such as move and delete, will be introduced later. Lawrence Chung 4
5 A Walkthrough: A file System I module models/examples/tutorial/filesystem // A set representing the set of all file system objects in the file system; A parent relation with the set as its domain. sig FSObject { parent: lone Dir } // lone = 0 or 1 // A directory in the file system; extends = a disjoint partition; cf. in = a subset but not a disjoint partition sig Dir extends FSObject { contents: set FSObject } Any issues? // A directory is the parent of its contents fact definecontents { all d: Dir, o: d.contents o.parent = d } Quantifiers: all x:x formula no x:x formula Lawrence Chung one x:x formula lone x:x formula 5
6 A Walkthrough: A File System I module models/examples/tutorial/filesystem // A set representing the set of all file system objects in the file system; A parent relation with the set as its domain. sig FSObject { parent: lone Dir } // lone = 0 or 1 sig Dir extends FSObject { contents: set FSObject } // A directory in the file system fact definecontents { all d: Dir, o: d.contents o.parent = d } // A directory is the parent of its contents.. = relation composition sig File extends FSObject {} // A file in the file system: extends = 1) subset; 2) disjoint from other subsets // All file system objects are either files or directories; + = set union; Without this, a FSObject can be neither a Dir nor a File. fact filedirpartition { File + Dir = FSObject } // == abstract sig FSObject {...} one sig Root extends Dir { }{ no parent } // There exists a root; one = There will always be exactly one instance. // File system is connected; in = subset of (among other things);.* = reflexive transitive closure fact filesystemconnected { FSObject in Root.*contents } // A fact forces something to be true of the model. An assert claims that something must be true due to the behaviour of the model. assert acyclic { no d: Dir d in d.^contents } // The contents path is acyclic;.^ = transitive closure check acyclic for 5 // "for 5 = examine all examples whose top level signatures (those that don't extend other signatures) have up to 5 instances. assert oneroot { one d: Dir no d.parent } // File system has one root check oneroot for 5 assert onelocation { all o: FSObject lone d: Dir o in d.contents } // Every fsobject is in at most one directory check onelocation for 5 // check : 1) no solution found : no counterexamples to the assertion; 2) solution found : a counterexample // Ordering among signature declarations is irrelevant union (+): t is in p+q if and only if t is in p or t is in q. intersection (&): t is in p&q if and only if t is in p and t is in q. set subtraction (-): t is in p-q if and only if t is in p but t is not in q. set Lawrence membership/subset Chung (in): Set membership and subsets are both denoted 6 in. The same symbol is used, since Alloy does not distinguish between atoms and singleton sets.
7 A Walkthrough: A File System I Checking Assertions assert acyclic { no d: Dir d in d.^contents } // The contents path is acyclic;.^ = transitive closure check acyclic for 5 // "for 5 = examine all examples whose top level signatures (those that don't extend other signatures) have up to 5 instances. "no counterexamples found: acyclic may be valid.(00:05) assert oneroot { one d: Dir no d.parent } // File system has one root check oneroot for 5 "no counterexamples found: oneroot may be valid.(00:05) assert onelocation { all o: FSObject lone d: Dir o in d.contents } // Every fsobject is in at most one directory check onelocation for 5 "no counterexamples found: onelocation may be valid.(00:05) Lawrence Chung 7
8 A Walkthrough: A File System I Checking Assertions // an assertion with a counterexample // any two non-root file system objects have the same parent. assert Wrong { all o, p: (FSObject - Root) (o.parent = p.parent) } check Wrong for 3 check Wrong for 2 "no counterexamples found: Wrong may be valid.(00:02)", a cleaner customization Lawrence Chung 8
9 A Walkthrough: A File System I Checking Assertions // an assertion with a counterexample // any two non-root file system objects have the same parent. assert Wrong { all o, p: (FSObject - Root) (o.parent = p.parent) } check Wrong for 15 Lawrence Chung a cleaner customization 9
10 An Alloy Model: 3 Levels OO paradigm Set theory Atoms & relations Example: sig S extends E { F:T } fact { all s:s s.f in X } OO paradigm S is a class S extends its superclass E F is a field of S pointing to a T s is an instance of S. accesses a field s.f returns something of type T Atoms & relations Set theory S is a set (and so is E) S is a subset of E F is a relation which maps each S to some T s is an element of S. composes relations s.f composes the unary relation s with the binary relations F, returning a unary relation of type T S is an atom (and so is E) the containment relation maps E to S (among other things it does) F is a relation from S to T the containment relation maps S to s (among other things). composes relations s.f composes the unary relation s with the Lawrence binary relations Chung F, resulting in a unary relation t, such 10 that the containment relation maps T to t
11 An Alloy Model: Logical Operations!F // negations: not F F && G // conjunction: F and G F G // disjunction: F or G F => G // implication: same as!f G G <=> G // bi-implication: same as (F => G) && (G => F) F => G,H // conditionsl: if F then G else H; same as (F => G) && (!F=> H) Operator precedence: not (!) and (&&) or ( ) implication/conditional (=>) bi-implication (<=>) Lawrence Chung 11
12 A Walkthrough: A File System II module models/examples/tutorial/filesystem abstract sig FSObject {} // A file system object in the file system // File system objects must be either directories or files. sig File, Dir extends FSObject {} sig FileSystem { // A File System root: Dir, objects: set FSObject, sig name { //fields of the signature } { //appended fact constraints } contents: Dir lone-> FSObject, // ternary relations; relational product operator ("->"). parent: FSObject ->lone Dir } // multiplicity markings: lone {no root.parent // root has no parent objects in root.*contents // objects are those reachable from the root parent = ~contents // parent is the inverse of contents } pred example() {} // an empty predicate // A run command, not a check command, generates solutions that are not // counterexamples -- no claim has been made so there's nothing to disprove! run example for exactly 1 FileSystem, 4 FSObject // use run to detect overconstrained (over-specialized) Lawrence Chung or underconstrained (over-generalized) 12 models
13 A Walkthrough: A File System II - Problematic module models/examples/tutorial/filesystem abstract sig FSObject {} // A file system object in the file system // File system objects must be either directories or files. sig File, Dir extends FSObject {} // A File System sig FileSystem { root: Dir, objects: set FSObject, contents: Dir lone-> FSObject, // ternary relations; relational product operator ("->"). parent: FSObject ->lone Dir } // multiplicity markings: lone {no root.parent // root has no parent objects in root.*contents // objects are those reachable from the root parent = ~contents // parent is the inverse of contents } pred example() {} // an empty predicate run example for exactly 1 FileSystem, 4 FSObject The problem with this instance is that the bottom-right Dir is reachable from the root which is not considered to be a object in the file system (it is not labeled 'objects'). That directory is reachable from the file system, but is not part of it! objects in root.*contents ensures that all objects in the file system are reachable from the root, but fails to Lawrence guarantee Chung that 13 all objects reachable from the root are in the file system.
14 A Walkthrough: A File System II Modified But Still Problematic module models/examples/tutorial/filesystem abstract sig FSObject {} // A file system object in the file system // File system objects must be either directories or files. sig File, Dir extends FSObject {} // A File System sig FileSystem { root: Dir, objects: set FSObject, contents: Dir lone-> FSObject, // ternary relations; relational product operator ("->"). parent: FSObject ->lone Dir } // multiplicity markings: lone {no root.parent // root has no parent // objects are those reachable from the root AND // all objects reachable from the root are in the file system. objects = root.*contents parent = ~contents // parent is the inverse of contents } pred example() {} // an empty predicate run example for exactly 1 FileSystem, 4 FSObject Our previous problem is gone, but now there are stray tuples in the contents relation. That is, the contents relation is defining relationships between file system objects which are not in any file system. We can fix this by constraining all the tuples in the contents relation to be between objects that are in its file system. Adding the following Lawrence constraint Chung to the appended fact achieves 14 this contents in objects->objects
15 A Walkthrough: A File System II III module models/examples/tutorial/filesystem abstract sig FSObject {} // A file system object in the file system // File system objects must be either directories or files. sig File, Dir extends FSObject {} sig FileSystem {// A File System root: Dir, objects: set FSObject, contents: Dir lone-> FSObject, parent: FSObject ->lone Dir } { no root.parent // root has no parent objects = root.*contents // objects are those reachable from the root contents in objects->objects // contents only defined on objects parent = ~contents // parent is the inverse of contents } pred example() {} run example for exactly 1 FileSystem, exactly 4 FSObject Lawrence Chung 15
16 A Walkthrough: A File System II III Enforcing some degree of non-triviality module models/examples/tutorial/filesystem abstract sig FSObject {} // A file system object in the file system sig File, Dir extends FSObject {} // File system objects must be either directories or files. sig FileSystem {// A File System root: Dir, objects: set FSObject, contents: Dir lone-> FSObject, parent: FSObject ->lone Dir } { no root.parent // root has no parent objects = root.*contents // objects are those reachable from the root contents in objects->objects // contents only defined on objects parent = ~contents // parent is the inverse of contents } pred example() {} // run example for exactly 1 FileSystem, exactly 4 FSObject run example for all f: FSObject some fs: FileSystem f in fs.objects Lawrence Chung 16
17 A Walkthrough: A File System IV semantically equivalent to File System III, but a bit more concise and arguably clearer. module models/examples/tutorial/filesystem abstract sig FSObject {} // A file system object in the file system // File system objects must be either directories or files. sig File, Dir extends FSObject {} // A File System sig FileSystem { objects: set FSObject, pred example() {} root: Dir & objects, contents: (Dir & objects) one-> (objects - root), // one = exactly 1 parent: (objects - root) ->one (Dir & objects) } {objects in root.*contents // objects are reachable from the root parent = ~contents // parent is the inverse of contents } run example for exactly 1 FileSystem, exactly 4 FSObject Lawrence Chung 17
18 A Walkthrough: A File System V - 1 module models/examples/tutorial/filesystem abstract sig FSObject {} // File system objects sig File, Dir extends FSObject {} sig FileSystem {// A File System root: Dir, objects: set FSObject, contents: Dir lone-> FSObject, parent: FSObject ->lone Dir } {no root.parent // root has no parent objects = root.*contents // objects are those reachable from the root contents in objects->objects // contents only defined on objects parent = ~contents // parent is the inverse of contents } Lawrence Chung 18
19 A Walkthrough: A File System V - 2 // Move FSObject f to Directory d pred mv (fs, fs': FileSystem, f: FSObject, d: Dir) { (f + d) in fs.objects fs'.contents = fs.contents - f.(fs.parent)->f + d->f } // Delete the file f pred rm (fs, fs': FileSystem, f: File) { f in fs.objects fs'.contents = fs.contents - f.(fs.parent)->f } // Delete the directory d pred rmdir(fs, fs': FileSystem, d: Dir) { d in fs.(objects - root) no d.(fs.contents) //d is empty fs'.contents = fs.contents - d.(fs.parent)->d } // Recursively delete the file system object f pred rm_r(fs, fs': FileSystem, f: FSObject) { f in fs.(objects - root) let subtree = f.*(fs.contents) fs'.contents = fs.contents - subtree.(fs.parent)->subtree } run mv for 2 FileSystem, 4 FSObject run rm for 2 FileSystem, 4 FSObject run rmdir for 2 FileSystem, 4 FSObject run rm_r for 2 FileSystem, 4 FSObject Lawrence Chung 19
20 A Walkthrough: A File System V - 3 // Moving doesn't add or delete any file system objects assert moveaddsremovesnone { all fs, fs': FileSystem, f: FSObject, d:dir mv(fs, fs', f, d) => fs.objects = fs'.objects } // rm removes exactly the specified file assert rmremovesonefile { all fs, fs': FileSystem, f: File rm(fs, fs', f) => fs.objects - f = fs'.objects } // rmdir removes exactly the specified directory assert rmdirremovesonedir { all fs, fs': FileSystem, d: Dir rmdir(fs, fs', d) => fs.objects - d = fs'.objects } // rm_r removes exactly the specified subtree assert rm_rremovessubtree { all fs, fs': FileSystem, f: FSObject rm_r(fs, fs', f) => fs.objects - f.*(fs.contents) = fs'.objects } // rm and rm_r same effect on files assert rmandrm_rsameforfiles { all fs, fs1, fs2: FileSystem, f: File rm(fs, fs1, f) && rm_r(fs, fs2, f) => fs1.contents = fs2.contents } check moveaddsremovesnone for 5 //passes check rmremovesonefile for 5 //passes check rmdirremovesonedir for 5 //counterexample! check rm_rremovessubtree for 5 //counterexample! check rmandrm_rsameforfiles for 5 //passes pred example() {} run example for exactly 1 FileSystem, exactly 4 FSObject Lawrence Chung 20
21 module models/examples/tutorial/filesystem abstract sig FSObject {} // File system objects sig File, Dir extends FSObject {} A Walkthrough: A File System V - All sig FileSystem {// A File System root: Dir, objects: set FSObject, contents: Dir lone-> FSObject, parent: FSObject ->lone Dir } {no root.parent // root has no parent objects = root.*contents // objects are those reachable from the root contents in objects->objects // contents only defined on objects parent = ~contents // parent is the inverse of contents } // Move FSObject f to Directory d pred mv (fs, fs': FileSystem, f: FSObject, d: Dir) { (f + d) in fs.objects fs'.contents = fs.contents - f.(fs.parent)->f + d->f } // Delete the file f pred rm (fs, fs': FileSystem, f: File) { f in fs.objects fs'.contents = fs.contents - f.(fs.parent)->f } // Delete the directory d pred rmdir(fs, fs': FileSystem, d: Dir) { d in fs.(objects - root) no d.(fs.contents) //d is empty fs'.contents = fs.contents - d.(fs.parent)->d } // Recursively delete the file system object f pred rm_r(fs, fs': FileSystem, f: FSObject) { f in fs.(objects - root) let subtree = f.*(fs.contents) fs'.contents = fs.contents - subtree.(fs.parent)->subtree } run mv for 2 FileSystem, 4 FSObject run rm for 2 FileSystem, 4 FSObject run rmdir for 2 FileSystem, 4 FSObject run rm_r for 2 FileSystem, 4 FSObject // Moving doesn't add or delete any file system objects assert moveaddsremovesnone { all fs, fs': FileSystem, f: FSObject, d:dir mv(fs, fs', f, d) => fs.objects = fs'.objects } // rm removes exactly the specified file assert rmremovesonefile { all fs, fs': FileSystem, f: File rm(fs, fs', f) => fs.objects - f = fs'.objects } // rmdir removes exactly the specified directory assert rmdirremovesonedir { all fs, fs': FileSystem, d: Dir rmdir(fs, fs', d) => fs.objects - d = fs'.objects } // rm_r removes exactly the specified subtree assert rm_rremovessubtree { all fs, fs': FileSystem, f: FSObject rm_r(fs, fs', f) => fs.objects - f.*(fs.contents) = fs'.objects } // rm and rm_r same effect on files assert rmandrm_rsameforfiles { all fs, fs1, fs2: FileSystem, f: File rm(fs, fs1, f) && rm_r(fs, fs2, f) => fs1.contents = fs2.contents } check moveaddsremovesnone for 5 //passes check rmremovesonefile for 5 //passes check rmdirremovesonedir for 5 //counterexample! check rm_rremovessubtree for 5 //counterexample! check rmandrm_rsameforfiles for 5 //passes pred example() {} Lawrence Chung 21 run example for exactly 1 FileSystem, exactly 4 FSObject
22 A Walkthrough: A File System VI Lawrence Chung 22
23 UML And Alloy Prepared by Weimin Ma Class Diagram (a) Class Diagram (b) context Class1 inv aresame : Class1.allInstances -> forall ( cl1 : Class1 cl1.c2.c1 = cl1 ) context Class3 inv bidirectional : Class3.allInstances -> forall ( cl3 : Class3 cl3.c4.c3 = cl3 ) UML Class Diagram with OCL Constrains Class Diagram (a) Execution Result Any Issues? Translated Alloy Model Class Diagram (b) Execution Result Alloy Execution Result Translating UML to Alloy using UML2Alloy
24 UML And Alloy OCL now part of model class diagram (a) Class Diagram (a) Class Diagram (b) context Class1 inv aresame : Class1.allInstances -> forall ( cl1 : Class1 cl1.c2.c1 = cl1 ) context Class3 inv bidirectional : Class3.allInstances -> forall ( cl3 : Class3 cl3.c4.c3 = cl3 ) UML Class Diagram with OCL Constrains Class Diagram (a) Execution Result aresame is part of UML model Modified Alloy Model aresame is part of UML model Class Diagram (b) Execution Result Alloy Execution Result Translating UML to Alloy using UML2Alloy
25 More on Run and Check Run predicates OCL constrains translated into predicates without being part of UML class Run ~predicates OCL constrains translated into negative predicates without being part of UML class Run predicates OCL constrains translated into facts (&=predicates) being part of UML class Check assertions OCL constrains translated into assertions without being part of UML class Check assertions OCL constrains translated into facts (&=predicates) being part of UML class and assertions Run ~predicates OCL constrains translated into negative predicates being part of UML class Check ~assertions OCL constrains translated into negative assertions without being part of UML class Check ~assertions OCL constrains translated into facts (&=predicates) being part of UML class and negative assertions Lawrence Chung 25
26 UML To Alloy Predicate constrains are NOT part of class diagrams Class Diagram (a) Class Diagram (b) context Class1 inv aresame : Class1.allInstances -> forall ( cl1 : Class1 cl1.c2.c1 = cl1 ) context Class3 inv bidirectional : Class3.allInstances -> forall ( cl3 : Class3 cl3.c4.c3 = cl3 ) UML Class Diagram with OCL Constrains Class Diagram (a) Execution Result Translating UML to Alloy using UML2Alloy Translated Alloy Model Constrains are NOT part of Alloy model as predicates Class Diagram (b) Execution Result Alloy Execution Result
27 UML To Alloy Predicate constrains are part of class diagrams Class Diagram (a) Execution Result Translated Alloy Model Constrains are part of Alloy model as predicates Class Diagram (b) Execution Result Alloy Execution Result
28 UML To Alloy Assertion constrains are NOT part of class diagrams Translated Alloy Model Constrains are NOT part of Alloy model as assertions Class Diagram (a) Execution Result Class Diagram (b) Execution Result Alloy Execution Result
29 UML To Alloy Assertion constrains are part of class diagrams Class Diagram (a) Execution Result Class Diagram (b) Execution Result Alloy Execution Result Translated Alloy Model Constrains are part of Alloy model as assertions
30 UML To Alloy Predicate constrains are NOT part of class diagrams Class Diagram (a) Execution Result Translated Alloy Model Predicates to be checked are negation of predicate constrains Class Diagram (b) Execution Result Alloy Execution Result
31 UML To Alloy Predicate constrains are part of class diagrams Class Diagram (a) Execution Result Class Diagram (b) Execution Result Alloy Execution Result Translated Alloy Model Predicate to check are negation of predicate constrains
32 UML To Alloy Assertion constrains are NOT part of class diagrams Class Diagram (a) Execution Result Class Diagram (b) Execution Result Translated Alloy Model Assertions are negation of intended constrains Alloy Execution Result
33 UML To Alloy Assertion constrains are part of class diagrams Class Diagram (a) Execution Result Class Diagram (b) Execution Result Translated Alloy Model Assertions are negation of constrains Alloy Execution Result
Alloy: A Lightweight Object Modelling Notation
Alloy: A Lightweight Object Modelling Notation Daniel Jackson, ACM Transactions on Software Engineering, 2002 Presented By: Steven Stewart, 2012-January-23 1 Alloy: 2002 to present Software is built on
From: FM 2006 Alloy Intro and Logic. Greg Dennis and Rob Seater Software Design Group, MIT
From: FM 2006 Alloy Intro and Logic Greg Dennis and Rob Seater Software Design Group, MIT agenda Intro & Logic Language & Analysis Dynamic Modeling M.C. Escher Observations Software is built on abstractions
SWEN-220 Mathematical Models of Software
SWEN-220 Mathematical Models of Software Introduction to Alloy Signatures, Fields, Facts, Predicates, and Assertions 2017 - Thomas Reichlmayr & Michael Lutz 1 Topics What is Alloy? Atoms, Sets, Relations
CS:5810 Formal Methods in Software Engineering
CS:5810 Formal Methods in Software Engineering Introduction to Alloy Part 2 Copyright 2001-17, Matt Dwyer, John Hatcliff, Rod Howell, Laurence Pilard, and Cesare Tinelli. Created by Cesare Tinelli and
B.6 Types and Overloading
266 appendix b: alloy language reference B.6 Types and Overloading Alloy s type system was designed with a different aim from that of a programming language. There is no notion in a modeling language of
Conceptual modeling of entities and relationships using Alloy
Conceptual modeling of entities and relationships using Alloy K. V. Raghavan Indian Institute of Science, Bangalore Conceptual modeling What is it? Capture requirements, other essential aspects of software
αrby An Embedding of Alloy in Ruby
αrby An Embedding of Alloy in Ruby September 20, 2013 Aleksandar Milicevic Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology {aleks@csail.mit.edu Abstract. A
An Overview of the Alloy Language & Analyzer. What is Alloy?
An Overview of the Alloy Language & Analyzer Slides contain some modified content from the Alloy Tutorial by G. Dennis & R. Seater (see alloy.mit.edu) Alloy Lecture 1 1 What is Alloy? A formal language
CS:5810 Formal Methods in Software Engineering
CS:5810 Formal Methods in Software Engineering Introduction to Alloy Part 1 Copyright 2001-17, Matt Dwyer, John Hatcliff, Rod Howell, Laurence Pilard, and Cesare Tinelli. Created by Cesare Tinelli and
Specifications and Assertions
Specifications and Assertions Jan van Eijck Master SE, 29 September 2010 Abstract As a start, we give further examples of Alloy specifications. Next we turn to specification of imperative programs. Assertions
A set with only one member is called a SINGLETON. A set with no members is called the EMPTY SET or 2 N
Mathematical Preliminaries Read pages 529-540 1. Set Theory 1.1 What is a set? A set is a collection of entities of any kind. It can be finite or infinite. A = {a, b, c} N = {1, 2, 3, } An entity is an
Appendix 1. Description Logic Terminology
Appendix 1 Description Logic Terminology Franz Baader Abstract The purpose of this appendix is to introduce (in a compact manner) the syntax and semantics of the most prominent DLs occurring in this handbook.
Appendix 1. Description Logic Terminology
Appendix 1 Description Logic Terminology Franz Baader Abstract The purpose of this appendix is to introduce (in a compact manner) the syntax and semantics of the most prominent DLs occurring in this handbook.
Chapter 3: Propositional Languages
Chapter 3: Propositional Languages We define here a general notion of a propositional language. We show how to obtain, as specific cases, various languages for propositional classical logic and some non-classical
SOFTWARE ENGINEERING DESIGN I
2 SOFTWARE ENGINEERING DESIGN I 3. Schemas and Theories The aim of this course is to learn how to write formal specifications of computer systems, using classical logic. The key descriptional technique
Transitive Closure A binary relation is transitive if, whenever it contains the tuples
logic 63 Some useful facts about transpose: s.~r is equal to r.s, and is the image of the set s navigating backward through the relation r; r.~r is the relation that associates two atoms in the domain
EXAMINATIONS 2009 MID-TERM TEST. COMP 202 / SWEN 202 Formal Methods of Computer Science / Formal Foundations of Software Engineering WITH ANSWERS
T E W H A R E W Ā N A N G A O T E Ū P O K O O T E I K A A M Ā U I VUW V I C T O R I A UNIVERSITY OF WELLINGTON Time Allowed: 90 minutes EXAMINATIONS 2009 MID-TERM TEST COMP 202 / SWEN 202 Formal Methods
CSC 501 Semantics of Programming Languages
CSC 501 Semantics of Programming Languages Subtitle: An Introduction to Formal Methods. Instructor: Dr. Lutz Hamel Email: hamel@cs.uri.edu Office: Tyler, Rm 251 Books There are no required books in this
MITOCW watch?v=kz7jjltq9r4
MITOCW watch?v=kz7jjltq9r4 PROFESSOR: We're going to look at the most fundamental of all mathematical data types, namely sets, and let's begin with the definitions. So informally, a set is a collection
Topic Maps Reference Model, version 6.0
Topic Maps Reference Model, 13250-5 version 6.0 Patrick Durusau Steven R. Newcomb July 13, 2005 This is a working draft of the Topic Maps Reference Model. It focuses on the integration of Robert Barta
Foundations of Computer Science Spring Mathematical Preliminaries
Foundations of Computer Science Spring 2017 Equivalence Relation, Recursive Definition, and Mathematical Induction Mathematical Preliminaries Mohammad Ashiqur Rahman Department of Computer Science College
CS Bootcamp Boolean Logic Autumn 2015 A B A B T T T T F F F T F F F F T T T T F T F T T F F F
1 Logical Operations 1.1 And The and operator is a binary operator, denoted as, &,, or sometimes by just concatenating symbols, is true only if both parameters are true. A B A B F T F F F F The expression
22c:181 / 55:181 Formal Methods in Software Engineering. Introduction to Alloy
22c:181 / 55:181 Formal Methods in Software Engineering Introduction to Alloy Copyright 2001-11, Matt Dwyer, John Hatcliff, Rod Howell, Laurence Pilard, and Cesare Tinelli. Created by Cesare Tinelli and
Alloy Language and Analysis based on slides from. Greg Dennis and Rob Seater Software Design Group, MIT
Alloy Language and Analysis based on slides from Greg Dennis and Rob Seater Software Design Group, MIT alloy language & analysis language = syntax for structuring specifications in logic shorthands, puns,
This is already grossly inconvenient in present formalisms. Why do we want to make this convenient? GENERAL GOALS
1 THE FORMALIZATION OF MATHEMATICS by Harvey M. Friedman Ohio State University Department of Mathematics friedman@math.ohio-state.edu www.math.ohio-state.edu/~friedman/ May 21, 1997 Can mathematics be
Appendix B: Alloy Language Reference B.1 Lexical Issues
Appendix B: Alloy Language Reference B.1 Lexical Issues The permitted characters are the printing characters of the ASCII character set, with the exception of backslash \ backquote ` and, of the ASCII
Sets. Sets. Subset, universe. Specifying sets, membership. Examples: Specifying a set using a predicate. Examples
Sets 2/36 We will not give a precise definition of what is a set, but we will say precisely what you can do with it. Sets Lectures 7 and 8 (hapter 16) (Think of a set as a collection of things of which
logic & language Daniel Jackson Lipari Summer School July 18-22, 2005
logic & language Daniel Jackson Lipari Summer School July 18-22, 2005 handshaking solution what this lecture s about a relational logic first-order logic + relational operators Alloy language signatures
Static Program Checking
Bounded Verification Jalloy Automated Software Analysis Group, Institute of Theoretical Informatics Jun.-prof. Mana Taghdiri June 5, 2014 KIT University of the State of Baden-Wuerttemberg and National
Semantic Characterizations of XPath
Semantic Characterizations of XPath Maarten Marx Informatics Institute, University of Amsterdam, The Netherlands CWI, April, 2004 1 Overview Navigational XPath is a language to specify sets and paths in
Alloy Language & Analysis
Alloy Language & Analysis Excerpted (mostly), adapted (a bit) from: SAIL Tutorial at http://alloy.mit.edu/alloy/tutorials/daycourse/ by Greg Dennis and Rob Seater 1 Alloy = logic + language + analysis
CSE 20 DISCRETE MATH. Fall
CSE 20 DISCRETE MATH Fall 2017 http://cseweb.ucsd.edu/classes/fa17/cse20-ab/ Final exam The final exam is Saturday December 16 11:30am-2:30pm. Lecture A will take the exam in Lecture B will take the exam
Module 6. Knowledge Representation and Logic (First Order Logic) Version 2 CSE IIT, Kharagpur
Module 6 Knowledge Representation and Logic (First Order Logic) 6.1 Instructional Objective Students should understand the advantages of first order logic as a knowledge representation language Students
( ) Software Abstractions. With Alloy Analyzer
Software Abstractions With Alloy Analyzer Formal methods In software engineering,formal methods are a particular kind of mathematically-based techniques for the specification,development and verification
Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Chapter 6 Outline. Unary Relational Operations: SELECT and
Chapter 6 The Relational Algebra and Relational Calculus Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 6 Outline Unary Relational Operations: SELECT and PROJECT Relational
CS 512, Spring 2017: Take-Home End-of-Term Examination
CS 512, Spring 2017: Take-Home End-of-Term Examination Out: Tuesday, 9 May 2017, 12:00 noon Due: Wednesday, 10 May 2017, by 11:59 am Turn in your solutions electronically, as a single PDF file, by placing
CSC Discrete Math I, Spring Sets
CSC 125 - Discrete Math I, Spring 2017 Sets Sets A set is well-defined, unordered collection of objects The objects in a set are called the elements, or members, of the set A set is said to contain its
Summary of Course Coverage
CS-227, Discrete Structures I Spring 2006 Semester Summary of Course Coverage 1) Propositional Calculus a) Negation (logical NOT) b) Conjunction (logical AND) c) Disjunction (logical inclusive-or) d) Inequalities
lecture 4: the Alloy language
micromodels of software declarative modelling and analysis with Alloy lecture 4: the Alloy language Daniel Jackson MIT Lab for Computer Science Marktoberdorf, August 2002 the Alloy language syntactic constructs
Propositional Calculus: Boolean Algebra and Simplification. CS 270: Mathematical Foundations of Computer Science Jeremy Johnson
Propositional Calculus: Boolean Algebra and Simplification CS 270: Mathematical Foundations of Computer Science Jeremy Johnson Propositional Calculus Topics Motivation: Simplifying Conditional Expressions
Functional Alloy Modules
Functional Alloy Modules Loïc Gammaitoni and Pierre Kelsen Laboratory for Advanced Software Systems University of Luxembourg 6, rue R. Coudenhove-Kalergi L-1359 Luxembourg TR-LASSY-14-02 Abstract. The
Shared Variables and Interference
Solved Shared Variables and Interference CS 536: Science of Programming, Fall 2018 A. Why Parallel programs can coordinate their work using shared variables, but it s important for threads to not interfere
Finite State Verification. CSCE Lecture 14-02/25/2016
Finite State Verification CSCE 747 - Lecture 14-02/25/2016 So, You Want to Perform Verification... You have a property that you want your program to obey. Great! Let s write some tests! Does testing guarantee
CS 267: Automated Verification. Lecture 13: Bounded Model Checking. Instructor: Tevfik Bultan
CS 267: Automated Verification Lecture 13: Bounded Model Checking Instructor: Tevfik Bultan Remember Symbolic Model Checking Represent sets of states and the transition relation as Boolean logic formulas
Introduction to Sets and Logic (MATH 1190)
Introduction to Sets and Logic () Instructor: Email: shenlili@yorku.ca Department of Mathematics and Statistics York University Dec 4, 2014 Outline 1 2 3 4 Definition A relation R from a set A to a set
Shared Variables and Interference
Illinois Institute of Technology Lecture 24 Shared Variables and Interference CS 536: Science of Programming, Spring 2018 A. Why Parallel programs can coordinate their work using shared variables, but
Formal Verification Methods 2: Symbolic Simulation
Formal Verification Methods 2: Symbolic Simulation John Harrison Intel Corporation Marktoberdorf 2003 Thu 3st July 2003 (:25 2:0) 0 Summary Simulation Symbolic and ternary simulation BDDs Quaternary lattice
Relations and Graphs
s and are Pictures of (Binary) s E. Wenderholm Department of Computer Science SUNY Oswego c 2016 Elaine Wenderholm All rights Reserved Outline 1 A Function that returns a boolean Special Properties of
Alloy: A Lightweight Object Modelling Notation
Alloy: A Lightweight Object Modelling Notation Daniel Jackson Laboratory for Computer Science Massachusetts Institute of Technology July 28, 2000 Abstract Alloy is a little language for describing structural
Evaluating State Modeling Techniques in Alloy
16 Evaluating State Modeling Techniques in Alloy ALLISON SULLIVAN, KAIYUAN WANG, and SARFRAZ KHURSHID, The University of Texas at Austin, USA DARKO MARINOV, University of Illinois at Urbana-Champaign,
Finite State Verification. CSCE Lecture 21-03/28/2017
Finite State Verification CSCE 747 - Lecture 21-03/28/2017 So, You Want to Perform Verification... You have a property that you want your program to obey. Great! Let s write some tests! Does testing guarantee
1 of 7 7/15/2009 3:40 PM Virtual Laboratories > 1. Foundations > 1 2 3 4 5 6 7 8 9 1. Sets Poincaré's quote, on the title page of this chapter could not be more wrong (what was he thinking?). Set theory
Denotational Semantics. Domain Theory
Denotational Semantics and Domain Theory 1 / 51 Outline Denotational Semantics Basic Domain Theory Introduction and history Primitive and lifted domains Sum and product domains Function domains Meaning
Automated Test Generation and Mutation Testing for Alloy
10th IEEE International Conference on Software Testing, Verification and Validation Automated Test Generation and Mutation Testing for Alloy Allison Sullivan, Kaiyuan Wang, Razieh Nokhbeh Zaeem, and Sarfraz
Principles of Programming Languages
Principles of Programming Languages www.cs.bgu.ac.il/~ppl172 Lesson 6 - Defining a Programming Language Bottom Up Collaboration and Management - Elements of Programming Dana Fisman 1 What we accomplished
CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Chapter p. 1/27
CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Chapter 2.1-2.7 p. 1/27 CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer
Mathematical Logic Prof. Arindama Singh Department of Mathematics Indian Institute of Technology, Madras. Lecture - 37 Resolution Rules
Mathematical Logic Prof. Arindama Singh Department of Mathematics Indian Institute of Technology, Madras Lecture - 37 Resolution Rules If some literals can be unified, the same algorithm should be able
CSE 20 DISCRETE MATH. Winter
CSE 20 DISCRETE MATH Winter 2017 http://cseweb.ucsd.edu/classes/wi17/cse20-ab/ Final exam The final exam is Saturday March 18 8am-11am. Lecture A will take the exam in GH 242 Lecture B will take the exam
Metamodeling. Janos Sztipanovits ISIS, Vanderbilt University
Metamodeling Janos ISIS, Vanderbilt University janos.sztipanovits@vanderbilt.edusztipanovits@vanderbilt edu Content Overview of Metamodeling Abstract Syntax Metamodeling Concepts Metamodeling languages
CS 341 Homework 1 Basic Techniques
CS 341 Homework 1 Basic Techniques 1. What are these sets? Write them using braces, commas, numerals, (for infinite sets), and only. (a) ({1, 3, 5} {3, 1}) {3, 5, 7} (b) {{3}, {3, 5}, {{5, 7}, {7, 9}}}
Complete Instantiation of Quantified Formulas in Satisfiability Modulo Theories. ACSys Seminar
Complete Instantiation of Quantified Formulas in Satisfiability Modulo Theories Yeting Ge Leonardo de Moura ACSys Seminar 2008.12 Motivation SMT solvers have been successful Quantified smt formulas are
DISCRETE MATHEMATICS
DISCRETE MATHEMATICS WITH APPLICATIONS THIRD EDITION SUSANNA S. EPP DePaul University THOIVISON * BROOKS/COLE Australia Canada Mexico Singapore Spain United Kingdom United States CONTENTS Chapter 1 The
EXAMINATIONS 2009 END-OF-YEAR. COMP 202 / SWEN 202 Formal Methods of Computer Science / Formal Foundations of Software Engineering
T E W H A R E W Ā N A N G A O T E Ū P O K O O T E I K A A M Ā U I VUW V I C T O R I A UNIVERSITY OF WELLINGTON EXAMINATIONS 2009 END-OF-YEAR COMP 202 / SWEN 202 Formal Methods of Computer Science / Formal
Formal Methods of Software Design, Eric Hehner, segment 24 page 1 out of 5
Formal Methods of Software Design, Eric Hehner, segment 24 page 1 out of 5 [talking head] This lecture we study theory design and implementation. Programmers have two roles to play here. In one role, they
Module 6. Knowledge Representation and Logic (First Order Logic) Version 2 CSE IIT, Kharagpur
Module 6 Knowledge Representation and Logic (First Order Logic) Lesson 15 Inference in FOL - I 6.2.8 Resolution We have introduced the inference rule Modus Ponens. Now we introduce another inference rule
AXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop
AXIOMS OF AN IMPERATIVE LANGUAGE We will use the same language, with the same abstract syntax that we used for operational semantics. However, we will only be concerned with the commands, since the language
Foundations of AI. 9. Predicate Logic. Syntax and Semantics, Normal Forms, Herbrand Expansion, Resolution
Foundations of AI 9. Predicate Logic Syntax and Semantics, Normal Forms, Herbrand Expansion, Resolution Wolfram Burgard, Andreas Karwath, Bernhard Nebel, and Martin Riedmiller 09/1 Contents Motivation
LOGIC AND DISCRETE MATHEMATICS
LOGIC AND DISCRETE MATHEMATICS A Computer Science Perspective WINFRIED KARL GRASSMANN Department of Computer Science University of Saskatchewan JEAN-PAUL TREMBLAY Department of Computer Science University
Slides for Faculty Oxford University Press All rights reserved.
Oxford University Press 2013 Slides for Faculty Assistance Preliminaries Author: Vivek Kulkarni vivek_kulkarni@yahoo.com Outline Following topics are covered in the slides: Basic concepts, namely, symbols,
BDDC v2 A basic bdd-based logical calculator
BDDC v2 A basic bdd-based logical calculator Pascal RAYMOND http://www-verimag.imag.fr/people/pascal.raymond November 24, 2008 BDDC is a tool for manipulating logical formula. It is based on a Binary Decision
Algebraic Properties of CSP Model Operators? Y.C. Law and J.H.M. Lee. The Chinese University of Hong Kong.
Algebraic Properties of CSP Model Operators? Y.C. Law and J.H.M. Lee Department of Computer Science and Engineering The Chinese University of Hong Kong Shatin, N.T., Hong Kong SAR, China fyclaw,jleeg@cse.cuhk.edu.hk
Set and Set Operations
Set and Set Operations Introduction A set is a collection of objects. The objects in a set are called elements of the set. A well defined set is a set in which we know for sure if an element belongs to
Alloy 3.0 Reference Manual
Alloy 3.0 Reference Manual Daniel Jackson May 10, 2004 2004 Daniel Jackson Contributors to the design of the Alloy language include: Daniel Jackson, Manu Sridharan, Ilya Shlyakhter, Emina Torlak, Jonathan
The Inverse of a Schema Mapping
The Inverse of a Schema Mapping Jorge Pérez Department of Computer Science, Universidad de Chile Blanco Encalada 2120, Santiago, Chile jperez@dcc.uchile.cl Abstract The inversion of schema mappings has
Trees. 3. (Minimally Connected) G is connected and deleting any of its edges gives rise to a disconnected graph.
Trees 1 Introduction Trees are very special kind of (undirected) graphs. Formally speaking, a tree is a connected graph that is acyclic. 1 This definition has some drawbacks: given a graph it is not trivial
Chapter 3. Set Theory. 3.1 What is a Set?
Chapter 3 Set Theory 3.1 What is a Set? A set is a well-defined collection of objects called elements or members of the set. Here, well-defined means accurately and unambiguously stated or described. Any
Range Restriction for General Formulas
Range Restriction for General Formulas 1 Range Restriction for General Formulas Stefan Brass Martin-Luther-Universität Halle-Wittenberg Germany Range Restriction for General Formulas 2 Motivation Deductive
Decision Procedures for Recursive Data Structures with Integer Constraints
Decision Procedures for Recursive Data Structures with Ting Zhang, Henny B Sipma, Zohar Manna Stanford University tingz,sipma,zm@csstanfordedu STeP Group, June 29, 2004 IJCAR 2004 - p 1/31 Outline Outline
Distributed Systems Programming (F21DS1) SPIN: Formal Analysis II
Distributed Systems Programming (F21DS1) SPIN: Formal Analysis II Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh Overview Introduce
Comparison of the Modeling Languages Alloy and UML
Comparison of the Modeling Languages Alloy and UML Yujing He Department of Computer Science Portland State University Portland, Oregon, USA Abstract - Alloy is a new modeling language for software design,
Power Set of a set and Relations
Power Set of a set and Relations 1 Power Set (1) Definition: The power set of a set S, denoted P(S), is the set of all subsets of S. Examples Let A={a,b,c}, P(A)={,{a},{b},{c},{a,b},{b,c},{a,c},{a,b,c}}
BDDC v2 A basic bdd-based logical calculator
BDDC v2 A basic bdd-based logical calculator Pascal RAYMOND November 24, 2008, (rev. September 28, 2015) BDDC is a tool for manipulating logical formula. It is based on a Binary Decision Diagram library,
Relational Databases
Relational Databases Jan Chomicki University at Buffalo Jan Chomicki () Relational databases 1 / 49 Plan of the course 1 Relational databases 2 Relational database design 3 Conceptual database design 4
Verifying Java Programs Verifying Java Programs with KeY
Verifying Java Programs Verifying Java Programs with KeY Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at
Data Integration: Logic Query Languages
Data Integration: Logic Query Languages Jan Chomicki University at Buffalo Datalog Datalog A logic language Datalog programs consist of logical facts and rules Datalog is a subset of Prolog (no data structures)
Discrete Mathematics Lecture 4. Harper Langston New York University
Discrete Mathematics Lecture 4 Harper Langston New York University Sequences Sequence is a set of (usually infinite number of) ordered elements: a 1, a 2,, a n, Each individual element a k is called a
Propositional Logic. Part I
Part I Propositional Logic 1 Classical Logic and the Material Conditional 1.1 Introduction 1.1.1 The first purpose of this chapter is to review classical propositional logic, including semantic tableaux.
Reasoning About Imperative Programs. COS 441 Slides 10
Reasoning About Imperative Programs COS 441 Slides 10 The last few weeks Agenda reasoning about functional programming It s very simple and very uniform: substitution of equal expressions for equal expressions
Small Formulas for Large Programs: On-line Constraint Simplification In Scalable Static Analysis
Small Formulas for Large Programs: On-line Constraint Simplification In Scalable Static Analysis Isil Dillig, Thomas Dillig, Alex Aiken Stanford University Scalability and Formula Size Many program analysis
Conjunctive queries. Many computational problems are much easier for conjunctive queries than for general first-order queries.
Conjunctive queries Relational calculus queries without negation and disjunction. Conjunctive queries have a normal form: ( y 1 ) ( y n )(p 1 (x 1,..., x m, y 1,..., y n ) p k (x 1,..., x m, y 1,..., y
SERGEI OBIEDKOV LEARNING HORN FORMULAS WITH QUERIES
SERGEI OBIEDKOV LEARNING HORN FORMULAS WITH QUERIES SUPERVISED LEARNING Input: a training set divided into (for example) two classes w.r.t. a certain target property. positive examples negative examples
No model may be available. Software Abstractions. Recap on Model Checking. Model Checking for SW Verif. More on the big picture. Abst -> MC -> Refine
No model may be available Programmer Software Abstractions Tests Coverage Code Abhik Roychoudhury CS 5219 National University of Singapore Testing Debug Today s lecture Abstract model (Boolean pgm.) Desirable
CS 671, Automated Reasoning
CS 671, Automated Reasoning Lesson 20: Type Constructs based on Intersection (II): dependent records, abstract data types, basic algebra April 3, 2001 Last time we discussed record types and their representation
2.1 Sets 2.2 Set Operations
CSC2510 Theoretical Foundations of Computer Science 2.1 Sets 2.2 Set Operations Introduction to Set Theory A set is a structure, representing an unordered collection (group, plurality) of zero or more
Propositional Logic. Application of Propositional logic
DISCRETE STRUCTURE Propositional Logic Application of Propositional logic Propositional logic is the study of propositions (true or false statements) and ways of combining them (logical operators) to
Software Engineering Lecture Notes
Software Engineering Lecture Notes Paul C. Attie August 30, 2013 c Paul C. Attie. All rights reserved. 2 Contents I Hoare Logic 11 1 Propositional Logic 13 1.1 Introduction and Overview..............................
lecture 1: introduction
micromodels of software declarative modelling and analysis with Alloy lecture 1: introduction Daniel Jackson MIT Lab for Computer Science Marktoberdorf, August 2002 lightweight models a foundation for
15-819M: Data, Code, Decisions
15-819M: Data, Code, Decisions 08: First-Order Logic André Platzer aplatzer@cs.cmu.edu Carnegie Mellon University, Pittsburgh, PA André Platzer (CMU) 15-819M/08: Data, Code, Decisions 1 / 40 Outline 1
Ontological Modeling: Part 8
Ontological Modeling: Part 8 Terry Halpin LogicBlox and INTI International University This is the eighth in a series of articles on ontology-based approaches to modeling. The main focus is on popular ontology
Negations in Refinement Type Systems
Negations in Refinement Type Systems T. Tsukada (U. Tokyo) 14th March 2016 Shonan, JAPAN This Talk About refinement intersection type systems that refute judgements of other type systems. Background Refinement