Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 2.

Slides:



Advertisements
Similar presentations
Knowledge Representation using First-Order Logic
Advertisements

First-Order Logic Chapter 8.
Chapter 2 Revision of Mathematical Notations and Techniques
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 1.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 12.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2013 Lecture 4.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 3.
From Handbook of Temporal Reasoning in Artificial Intelligence By Jan Chomicki & David Toman Temporal Databases Presented by Leila Jalali CS224 presentation.
CS848: Topics in Databases: Foundations of Query Optimization Topics covered  Introduction to description logic: Single column QL  The ALC family of.
Biointelligence Lab School of Computer Sci. & Eng.
– Seminar in Software Engineering Cynthia Disenfeld
1 Programming Languages (CS 550) Mini Language Interpreter Jeremy R. Johnson.
Synthesis, Analysis, and Verification Lecture 04c Lectures: Viktor Kuncak VC Generation for Programs with Data Structures “Beyond Integers”
Micromodels of Software
Semantics Static semantics Dynamic semantics attribute grammars
10 October 2006 Foundations of Logic and Constraint Programming 1 Unification ­An overview Need for Unification Ranked alfabeths and terms. Substitutions.
Alan Shaffer, Mikhail Auguston, Cynthia Irvine, Tim Levin The 7th OOPSLA Workshop on Domain-Specific Modeling October 21-22, 2007 Toward a Security Domain.
Alloy Vatche Ishakian Boston University- CS511 March/24/2008 Contributors: Andrei Lapets, Michalis Potamias, Mark Reynolds.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
The Engineering Design of Systems: Models and Methods
Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 3 The Basic (Flat) Relational Model.
CS 290C: Formal Models for Web Software Lectures 7 and 8: Alloy, Alloy Analyzer, Data Modeling and Analysis with Alloy Instructor: Tevfik Bultan.
Module #1 - Logic 1 Based on Rosen, Discrete Mathematics & Its Applications. Prepared by (c) , Michael P. Frank and Modified By Mingwu Chen Relations.
1 Relational Algebra and Calculus Yanlei Diao UMass Amherst Feb 1, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Chapter 10 Functional Dependencies and Normalization for Relational Databases.
Chapter 4 The Relational Model.
272: Software Engineering Fall 2008 Instructor: Tevfik Bultan Lectures 5, 6, and 7: Alloy and Alloy Analyzer.
Math 3121 Abstract Algebra I Section 0: Sets. The axiomatic approach to Mathematics The notion of definition - from the text: "It is impossible to define.
A Z Approach in Validating ORA-SS Data Models Scott Uk-Jin Lee Jing Sun Gillian Dobbie Yuan Fang Li.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Mathematical Preliminaries (Hein 1.1 and 1.2) Sets are collections in which order of elements and duplication of elements do not matter. – {1,a,1,1} =
CSE314 Database Systems The Relational Algebra and Relational Calculus Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson Ed Slide Set.
ARTIFICIAL INTELLIGENCE Lecture 3 Predicate Calculus.
Semantics. Semantics is a precise definition of the meaning of a syntactically and type-wise correct program. Ideas of meaning: –Operational Semantics.
Sets Define sets in 2 ways  Enumeration  Set comprehension (predicate on membership), e.g., {n | n  N   k  k  N  n = 10  k  0  n  50} the set.
Formal Specification of Intrusion Signatures and Detection Rules By Jean-Philippe Pouzol and Mireille Ducassé 15 th IEEE Computer Security Foundations.
Analyzing relational logic Daniel Jackson, MIT WG 2.3 · Newcastle April 2000.
Formal Methods in Software Engineering 1
Language: Set of Strings
Arjav Dave Jitendra Gupta Nishit Shah. Agenda  Overview  Alloy Architecture  Alloy Specification Language  Alloy Analyzer Demo  Comparisons  Conclusion.
CSE314 Database Systems Lecture 3 The Relational Data Model and Relational Database Constraints Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson.
Formal Methods in SE Lecture 16 Formal Methods in SE Qaisar Javaid Assistant Professor.
LDK R Logics for Data and Knowledge Representation ClassL (Propositional Description Logic with Individuals) 1.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 9: Test Generation from Models.
ece 627 intelligent web: ontology and beyond
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine1 CSE 503 – Software Engineering Lecture 3: An introduction to Alloy Rob DeLine 5 Apr 2004.
Set Theory Concepts Set – A collection of “elements” (objects, members) denoted by upper case letters A, B, etc. elements are lower case brackets are used.
Of 29 lecture 15: description logic - introduction.
CSCI 6315 Applied Database Systems Review for Midterm Exam I Xiang Lian The University of Texas Rio Grande Valley Edinburg, TX 78539
LDK R Logics for Data and Knowledge Representation Description Logics: family of languages.
1 Section 7.1 First-Order Predicate Calculus Predicate calculus studies the internal structure of sentences where subjects are applied to predicates existentially.
ALLOY: A Formal Methods Tool Glenn Gordon Indiana University of Pennsylvania COSC 481- Formal Methods Dr. W. Oblitey 26 April 2005.
Week 8 - Monday.  What did we talk about last time?  Properties of functions  One-to-one  Onto  Inverses  Cardinality.
Week 8 - Wednesday.  What did we talk about last time?  Relations  Properties of relations  Reflexive  Symmetric  Transitive.
Alloy Analyzer 4 Tutorial Session 1: Intro and Logic Greg Dennis and Rob Seater Software Design Group, MIT.
Alloy Analyzer 4 Tutorial Session 2: Language and Analysis Greg Dennis and Rob Seater Software Design Group, MIT.
Alloy Analyzer 4 Tutorial Session 3: Static Modeling Greg Dennis and Rob Seater Software Design Group, MIT.
Chapter 3: Modeling Data in the Organization
Session 4: Dynamic Modeling
Navigating through Alloy relations
Model the non-negative even integers
Chapter 20 Object-Oriented Analysis and Design
Logics for Data and Knowledge Representation
Event-Based Architecture Definition Language
Use Alloy to model and find a solution to the Farmer, Goat, Cabbage, and Wolf problem Roger L. Costello July 14, 2018.
Logics for Data and Knowledge Representation
Foundations of TIL; method of analysis
Presentation transcript:

Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 2

Alloy Analyzer Analyzes micro models of software Helps to – identify key properties of a software design – find conceptual errors (not implementation errors) Small scope hypothesis: many properties that do not hold have small counterexamples Exhaustively search for errors in all instances of bounded size

Example Applications Security protocols Train controllers File systems Databases Network protocols Software design/testing/repair/sketching Many examples are shipped with Alloy. More can be found on the Alloy website.

Today: The Alloy Language Chapters 3 and 4 of Daniel Jacksons book

Atoms, Relations, Structures, and Models An Alloy model defines a set of structures (instances) A structure is built from atoms and relations An atom is a primitive entity that is – indivisible: it cant be broken down into smaller parts – immutable: its properties do not change over time – uninterpreted: it does not have any build-in properties, unlike, e.g. integer numbers A relation is a mathematical object that relates atoms. It consists of a set of tuples, each tuple being a sequence of atoms.

Atoms and Relations: Examples Three unary relations: Name = {(N 0 ), (N 1 ), (N 2 )} Addr = {(A 0 ), (A 1 ), (A 3 )} Book = {(B 0 ), (B 1 )} A ternary relation: addr = {(B 0, N 0, A 1 ), (B 0, N 0, A 2 ), (B 1, N 2, A 0 )} atoms tuples

Size and Arity of Relations The size (also cardinality) of a relation is the number of tuples in the relation. The arity of a relation is the number of atoms in each tuple of the relation. Examples: – A unary relation of size 3: Name = {(N 0 ), (N 1 ), (N 2 )} – A ternary relation of size 2: addr = {(B 0, N 0, A 1 ), (B 0, N 1, A 2 )}

Visualizing Structures: Snapshots Name = {(N 0 ), (N 1 ), (N 2 )} Addr = {(A 0 ), (A 1 )} address = {(N 0, A 0 ), (N 1, A 0 ), (N 1, A 1 )} N0N0 N0N0 N1N1 N1N1 A0A0 A0A0 A1A1 A1A1 N2N2 N2N2 address

Visualizing Structures: Snapshots Name = {(N 0 ), (N 1 ), (N 2 )} Addr = {(A 0 ), (A 1 ), (A 3 )} Book = {(B 0 ), (B 1 )} addr = {(B 0, N 0, A 1 ), (B 0, N 0, A 2 ), (B 1, N 2, A 0 )} B0B0 B0B0 B1B1 B1B1 A1A1 A1A1 A0A0 A0A0 N0N0 N0N0 addr[N 0 ] addr[N 2 ] A2A2 A2A2 N1N1 N1N1 N2N2 N2N2

Scalars, Sets, and Relations In Alloy, everything is a relation, including scalars and sets Sets of atoms are unary relations Name = {(N 0 ),(N 1 ),(N 2 )} Scalars are singleton sets n = {(N 0 )} The following objects are treated as identical: x (x) {x} {(x)}

Domain and Range The domain of a relation is the set of atoms in the first position of its tuples The range of a relation is the set of atoms in the last position of its tuples Example: address = {(N 0, A 0 ), (N 1, A 1 ), (N 2, A 1 )} domain(address) = {(N 0 ), (N 1 ), (N 2 )} range(address) = {(A 0 ), (A 1 )}

Alloy Specifications Signatures and Fields sets and relations defining the model Predicates and Functions operations and test predicates Facts assumptions about the model Assertions properties and conjectures Commands simulation, testing, and verification

Signatures and Fields Signatures – define the entities of your model Fields – define relations between signatures Signature constraints – multiplicity constraints on relations/signatures – signature facts

Signatures A signature introduces a set of atoms The declaration sig A {} introduces a set named A A set can be introduced as a subset of another set sig A1 extends A {}

Signatures Signatures declared independently of each other define disjoint sets sig A {} sig B {} sig A1 extends A {} sig A2 extends A {} A A1 A2 B

Signatures An abstract set only contains the elements of its extensions abstract sig A {} sig B {} sig A1 extends A {} sig A2 extends A {} A A1 A2 B

Signatures Signatures can also be declared as subsets of other signatures without being disjoint abstract sig A {} sig B {} sig A1 extends A {} sig A2 extends A {} sig A3 in A {} A A1 A2 B A3

Fields Relations are declared as fields of signatures – The declaration sig A {f: e} introduces a relation f whose domain is A and whose range is defined by the expression e. Examples: – A binary relation f: A £ A sig A {f: A} – A ternary relation g: B £ A £ A sig B {g: A -> A}

Multiplicities Multiplicities constrain the sizes of sets and relations A multiplicity keyword placed before a signature declaration constraints the number of element in the signatures set m sig A {} We can also make multiplicities constraints on fields: sig A {f: m e} sig A {f: e1 m -> n e2} There are four multiplicities – set : any number – some : one or more – lone : zero or one – one : exactly one

Multiplicities Examples – RecentlyUsed: set Name – senderName: lone Name – addr: Alias ->lone Addr – f: A ->one B – f: A lone->one B The default multiplicity keyword for unary relations is one r: e is equivalent to r: one e //addr is partial function // f is total function // f is total and injective function

Predefined Sets and Relations There are three predefined constants – none : empty set – univ : universal set – iden : identity Example: in the structure Name = {(N 0 ), (N 1 ), (N 2 )} Addr = {(A 0 ), (A 1 )} these constants are interpreted as none = {} univ = {(N 0 ), (N 1 ), (N 2 ), (A 0 ), (A 1 )} iden = {(N 0, N 0 ), (N 1, N 1 ), (N 2, N 2 ), (A 0, A 0 ), (A 1, A 1 )}

Set Operators Alloys set operators are + union & intersection - difference in (subset) inclusion = equality Examples: {(A 0 ),(A 1 ),(A 3 )} + {(A 1 ),(A 2 )} = {(A 0 ),(A 1 ),(A 2 ),(A 3 )} {(N 0,A 1 ),(N 1,A 2 )} & {(N 1,A 2 ),(N 2,A 1 )} = {(N 1,A 2 )}

Relational Operators Alloys relational operators are -> arrow (product). dot (join) [] box (join) ~ transpose ^ transitive closure * reflexive transitive closure <: domain restriction :> range restriction ++ override

Arrow Product p -> q – p is n-ary relation, q is m-ary relation – p -> q is the (n+m)-ary relation obtained by pairwise concatenating all tuples in p and q p -> q = {(x 1,…,x n,y 1,…,y m ) | (x 1,…,x n ) 2 p, (y 1,…,y m ) 2 q} Examples: n = {(N)}, a = {(A 0 )}, Addr = {(A 0 ),(A 1 ),(A 2 )}, Book = {(B 0 ),(B 1 )} n -> a = {(N, A 0 )} n -> Addr = {(N, A 0 ), (N, A 1 ), (N, A 2 )} Book -> n -> Addr = {(B 0,N, A 0 ), (B 0,N, A 1 ), (B 0,N, A 2 ), (B 1,N, A 0 ), (B 1,N, A 1 ), (B 1,N, A 2 )}

Dot Join on Tuples Join of tuples {(x 1,…,x n )} and {(y 1,…,y m )} is – none if x n y 1 – {(x 1,…,x n-1,y 2,…,y m )} if x n = y 1 Examples: – {(A,B)}.{(A,C)} = {} – {(A,B)}.{(B,C)} = {(A,C)} – {(A)}.{(A,C}) = {(C)} – {(A)}.{(A)} = ? Dot join is undefined if both n=1 and m=1 undefined

Dot Join p.q – p is n-ary relation, q is m-ary relation with n>1 or m>1 – p.q is (n+m-1)-ary relation obtained by taking every combination of a tuple from p and a tuple from q and adding their join, if it exists. p.q = {(x 1,…,x n-1,y 2,…,y m )|(x 1,…,x n ) 2 p, (y 1,…,y m ) 2 q, x n =y 1 }

Dot Join: Example to maps messages to the names of the recipients: to = {(M 0,N 0 ),(M 0,N 2 ), (M 1,N 2 ),(M 2,N 3 )} address maps names to addresses: address = {(N 0,A 0 ),(N 0,A 1 ),(N 1,A 1 ), (N 1,A 2 ),(N 2,A 3 ),(N 4,A 3 )} to.address maps messages to addresses of recipients: to.address = {(M 0,A 0 ),(M 0,A 1 ), (M 0,A 3 ),(M 1,A 3 )} M0M0 M1M1 M2M2 N0N0 N1N1 N2N2 N3N3 N4N4 A0A0 A1A1 A2A2 A3A3 to.address address to

Dot Join: Exercise Given the relations mother and father, how do you express the grandfather relation? grandfather = (mother + father).father

Box Join e1 [e2] – is semantically equivalent to e2.e1 Dot binds stronger than box a.b.c [d] is short for d.(a.b.c) Example: b.addr[n] denotes the addresses associated with name n in book b

Transpose ~ p – denotes the mirror image of relation p ~p = {(x n,…,x 1 ) | (x 1,…,x n ) 2 p } Example: address = {(N 0, A 0 ), (N 1, A 0 ), (N 2, A 1 )} ~ address = {(A 0, N 0 ), (A 0, N 1 ), (A 1, N 2 )} some useful facts: – ~(~p.~q) is equal to q.p – if p is a unary and q binary then p.~q is equal to q.p – p.~p relates atoms in the domain of p that are related to the same element in the range of p – p.~p in iden states that p is injective

(Reflexive) Transitive Closure ^r – r is binary relation – transitive closure ^r is smallest transitive relation containing r ^r = r + r.r + r.r.r +... reflexive transitive closure: *r = ^r + iden

Transitive Closure: Example A relation address representing an address book with multiple levels (including groups of aliases): address = {(G 0,A 0 ),(G 0,G 1 ),(A 0,D 0 ),(G 1,D 0 ),(G 1,A 1 ),(A 1,D 1 ),(A 2,D 2 )} ^address = {(G 0,A 0 ),(G 0,G 1 ),(A 0,D 0 ),(G 1,D 0 ),(G 1,A 1 ),(A 1,D 1 ),(A 2,D 2 ), (G 0,D 0 ),(G 0,A 1 ),(G 1,D 1 ), (G 0,D 1 )} G0G0 A0A0 G1G1 A1A1 D0D0 D1D1 A2A2 D2D2 ^address address

Transitive Closure: Exercise How would you express the ancestor relation in a family tree, given the children relation? ancestor = ^(~children)

Domain and Range Restriction s <: r – s is a set and r a relation – s <: r is the relation obtained by restricting the domain of r to s r :> s – r :> s is the relation obtained by restricting the range of r to s Example: siblings = {(M 0,W 0 ),(W 0,M 0 ),(W 1,W 2 ),(W 2,W 1 )} women = {(W 0 ),(W 1 ),(W 2 )} sisters = siblings :> women

Override p ++ q – p and q are relations – like union, but any tuple in p that starts with the same element as a tuple in q is dropped Example: homeAddress = {(N 0,A 1 ), (N 1,A 2 ), (N 2,A 3 )} workAddress = {(N 0,A 0 ), (N 1,A 2 )} homeAddress ++ workAddress = {(N 0,A 0 ), (N 1,A 2 ), (N 2,A 3 )} Example: insertion of a key k with value v into a hashmap m: m = m ++ k->v

Logical Operators Alloys logical operators are not ! negation and && conjunction or || disjunction implies => implication else, alternative iff biimplication Examples: F implies G else H (F and G) or ((not F) and H)

Operator Precedence || => && ! = != in & -> <: :> []. ~ * lowest highest

Quantifiers A quantified constraint takes the form Q x: e | F The forms of quantification in Alloy are – all x: S | F F holds for every x in S – some x: S | F F holds for some x in S – no x: S | F F fails for every x in S – lone x: S | F F holds for at most 1 x in S – one x: S | F F holds for exactly 1 x in S

Quantifiers Quantifiers can also be applied to expressions – some e e has some tuple – no e e has no tuples – lone e e has at most one tuple – one e e has exactly one tuple

Let Expressions let x = e | A – let expression can factor out a complicated subexpression e by introducing a short hand x – let expressions cannot be recursive, i.e., x is not allowed to appear in e Example: preferred address of an alias a is the work address, if it exists all a : Alias | let w = a.workAddress | a.address = some w => w else a.homeAddress

Comprehensions {x: e | F} – the set of values x drawn from set e for which F holds – general form {x 1 : e 1, …, x n : e n | F} defines an n-ary relation Example: relation mapping names to addresses in a multilevel address book {n: Name, a: Addr | n->a in ^address}

Facts Facts define additional assumptions about the signatures and fields of a model Alloy will only consider instances that also satisfy all facts Example: fact Biology { no p: Person | p in p.^(mother + father) }

Signature Facts Signature facts express assumptions about each element of a signature The declaration sig A {... } { F } is equivalent to sig A {... } fact {all this: A | F} where F is like F but with all appearances of fields g of A in F replaced by this.g

Signature Facts: Example There are no cycles in the addr relation of an address book: sig Book { addr : Name -> Target } { no n : Name | n in n.^addr }

Assertions An assertion is a constraint that is intended to follow from the facts of the model. Useful to – find flaws in the model – express properties in different ways – act as regression tests The analyzer checks assertions and produces a counterexample instance, if an assertion does not hold. If an assertion does not hold, you typically want to – move that constraint into a fact or – refine your specification until the assertion holds.

Assertions: Example assert addIdempotent { all b,b',b'' : Book, n : Name, a : Addr | add [b, b', n, a] and add [b', b'', n, a] implies b'.addr = b''.addr }

Run Command Used to ask Alloy to generate an instance of the model May include conditions – Used to guide AA to pick model instances with certain characteristics – E.g., force certain sets and relations to be nonempty – In this case, not part of the true specification Alloy only executes the first run command in a file

Scope Limits the size of instances considered to make instance finding feasible Represents the maximum number of tuples in each top-level signature Default scope is 3

Run Command: Examples run {} – no condition – scope is 3 run {} for 5 but exactly 2 Book – no condition – scope is 5 for all signatures except for signature Book, which should be of size exactly 2 run {some Book && some Name} for 2 – condition forces Book and Name to be nonempty – scope is 2

Functions and Predicates Functions and predicates define short hands that package expressions or constraints together. They can be – named and reused in different contexts (facts, assertions and conditions of run) – parameterized – used to factor out common patterns Predicates are good for: – Constraints that you dont want to record as facts – Constraints that you want to reuse in different contexts Functions are good for – Expressions that you want to reuse in different contexts

Functions A function is a named expression with 0 or more arguments. Examples The parent relation fun parent [] : Person->Person {~children} The lookup function fun lookup [b : Book, n : Name] : set Addr { n.^(b.addr) & Addr }

Predicates A predicate is a named constraint with 0 or more arguments. Example: pred ownGrandFather [p: Person] { p in p.grandfather } no person is its own grand father no p: Person | ownGrandFather[p]