Alloy Vatche Ishakian Boston University- CS511 March/24/2008 Contributors: Andrei Lapets, Michalis Potamias, Mark Reynolds.

Slides:



Advertisements
Similar presentations
Chapter 2 Revision of Mathematical Notations and Techniques
Advertisements

Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 2.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2013 Lecture 4.
CS848: Topics in Databases: Foundations of Query Optimization Topics covered  Introduction to description logic: Single column QL  The ALC family of.
– Seminar in Software Engineering Cynthia Disenfeld
Micromodels of Software
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.
Semantics (Representing Meaning)
1 DTD (Document Type Definition) Imposing Structure on XML Documents (W3Schools on DTDs)W3Schools on DTDs.
Answer Set Programming Overview Dr. Rogelio Dávila Pérez Profesor-Investigador División de Posgrado Universidad Autónoma de Guadalajara
1 A Description Logic with Concrete Domains CS848 presentation Presenter: Yongjuan Zou.
Of 27 lecture 7: owl - introduction. of 27 ece 627, winter ‘132 OWL a glimpse OWL – Web Ontology Language describes classes, properties and relations.
The Engineering Design of Systems: Models and Methods
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
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.
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.
1 Relational Algebra and Calculus Yanlei Diao UMass Amherst Feb 1, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
CS 267: Automated Verification Lecture 13: Bounded Model Checking Instructor: Tevfik Bultan.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Predicates and Quantifiers
22 March 2009Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Formal.
CS355 - Theory of Computation Lecture 2: Mathematical Preliminaries.
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.
THE RELATIONAL DATA MODEL CHAPTER 3 (6/E) CHAPTER 5 (5/E) 1.
Week 15 - Wednesday.  What did we talk about last time?  Review first third of course.
An Algebra for Composing Access Control Policies (2002) Author: PIERO BONATTI, SABRINA DE CAPITANI DI, PIERANGELA SAMARATI Presenter: Siqing Du Date:
INM175 Topic 7 1 Module INM175 Discrete Mathematics Topic 7 Set Theoretic Models.
ARTIFICIAL INTELLIGENCE Lecture 3 Predicate Calculus.
1 Relational Algebra and Calculas Chapter 4, Part A.
Formal Specification of Intrusion Signatures and Detection Rules By Jean-Philippe Pouzol and Mireille Ducassé 15 th IEEE Computer Security Foundations.
© D. Wong Ch. 2 Entity-Relationship Data Model (continue)  Data models  Entity-Relationship diagrams  Design Principles  Modeling of constraints.
Lecture 4: Predicates and Quantifiers; Sets.
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.
1 Formal Methods in SE Abstract Model Specification Lecture # 19.
Formal Methods in SE Lecture 16 Formal Methods in SE Qaisar Javaid Assistant Professor.
Conceptualization Relational Model Incomplete Relations Indirect Concept Reflection Entity-Relationship Model Incomplete Relations Two Ways of Concept.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 9: Test Generation from Models.
1 Abstract Model Specification. 2 Explicitly describes behavior in terms of a model using well-defined types (viz. set, sequences, relations, functions)
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.
Based on slides by Patrice Belleville and Steve Wolfman CPSC 121: Models of Computation Unit 11: Sets.
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.
LDK R Logics for Data and Knowledge Representation Description Logics: family of languages.
Week 15 - Wednesday.  What did we talk about last time?  Review first third of course.
ALLOY: A Formal Methods Tool Glenn Gordon Indiana University of Pennsylvania COSC 481- Formal Methods Dr. W. Oblitey 26 April 2005.
Week 8 - Wednesday.  What did we talk about last time?  Relations  Properties of relations  Reflexive  Symmetric  Transitive.
English for Economic Informatics I Tomáš Foltýnek Theoretical Foundations of Informatics.
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.
Using Alloy to Design a Safe Traffic Light System
ece 720 intelligent web: ontology and beyond
EKT472: Object Oriented Programming
Formal Modeling Concepts
UML Class Diagrams: Basic Concepts
Propositional Logic Defining Propositional Logic
Model the non-negative even integers
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.
Foundations of TIL; method of analysis
ICOM 5016 – Introduction to Database Systems
Logic Logic is a discipline that studies the principles and methods used to construct valid arguments. An argument is a related sequence of statements.
Presentation transcript:

Alloy Vatche Ishakian Boston University- CS511 March/24/2008 Contributors: Andrei Lapets, Michalis Potamias, Mark Reynolds

Why write a Model To describe formally the components of a system and relationships between them Check properties about the model Exclude ill-formed examples of Models. Two kind of problems might arise – Bugs (in the logic of the model) – Errors (in the subject that you are modeling)

Why Alloy Conceptual simplicity and minimalism – Very little to learn – WYSIWYG: no special semantics high-level notation – Constraints -- can build up incrementally – Relations flexible and powerful – Much more succinct than most model checking notations Ref: Alloy in 90 minutes.

Alloy Case Studies In Industry – Animating requirements (Venkatesh, Tata) – Military simulation (Hashii, Northtrop Grumman) – Role-based access control (Zao, BBN) – Generating network configurations (Narain, Telcordia) In Research – security features (Pincus, MSR) – exploring design of switching systems (Zave, AT&T) Ref: Alloy in 90 minutes.

Alloy Characteristics Finite scope check: – The analysis is sound, but incomplete Infinite model: – Finite checking does not get reflected in your model Declarative: first-order relational logic Automatic analysis: – visualization a big help Structured data:

Bad Things Sequences are awkward Recursive functions hard to express

Alloy model structures Structures are expressed as a set of tuples (vectors of atoms) – individual elements are treated as singleton sets Atoms are Alloy's primitive entities – Indivisible: can’t be broken down into smaller parts – Immutable: it does not change. Relations – Associate atoms with one another. – Consists of a set of tuples eache tuple being a sequence of atoms.

Relations The "arity" of the relation is the number of atoms in each tuple A relation with no tuples is empty

Alloy declarations First line module declaration – module chapter4/filesystem sig Object {} – Defines a set named Object represents all objects – abstract sig Object{} abstract sig has no elements except those belonging to its extensions. sig File extends Object {} – A set can be introduced as a subset of another set

Signatures Ref: Alloy in 90 minutes. sig A {} sig B extends A {} sig C extends A {} Means – B in A – C in A – no B & C

Signatures abstract sig A {} sig B extends A {} sig C extends A {} B in A C in A no B & C A = (B + C)

Declaring relations Relations are declared as fields of signatures sig Object{} sig Dir extends Object { entries: set Object, parent: lone Dir }

Fields sig A {f: set X} sig B extends A {g: set Y} means – B in A – f: A -> X – g: B -> Y

Set Multiplicities set : any number. one: exactly one. lone: zero or one. some: one or more. – sig Man extends Person { Wife: lone Woman} – sig Woman extends Person {Husband: lone Man} – sig Object{} sig Dir extends Object { entries: set Object, parent: lone Dir }

Facts and Assertions fact: – Constraints that are assumed always to hold (used to restrict space of possible counterexamples) – A Model can have any number of facts sig A {} fact { all z: A | F } assert: – Constraints that are intended to follow from the facts of the model – Can be checked using the check command

assert, check fact F {…} assert A {…} check A means – fact: assume constraint F holds – assert: believe that A follows from F – check: find an instance that satisfies F and not A Ref: Alloy in 90 minutes.

Quantifiers all x: e | F some x: e | F no x: e | F lone x: e | F one x: e | F – fact EntriesSameName {all e1, e2 : entries | e1.name = e2.name => e1 = e2} – fact nametoaddress { all n:Name| lone d: Address| d in n.address} – fact {no p: Person | p in p.^(mother + father) } – fact FourPassengersPerCar { all c:Car | #{c.contents } <= 4 } – fact OneVehiclePerPassenger { all p:Passenger | one v:Vehicle | p in v.contents }

Examples of Asserts assert NoSelfFather {no m: Man | m = m.father} check NoSelfFather assert FileInDir {all f: File | some d: Dir | f in d.contents} check FileInDir assert RootTop {no o: Object | Root in o.contents} check RootTop

Constants and Operators The language of relations has its own constants and operators Constants – none = empty set – univ = universal set – iden = identity

Constants and Operators Name = {(N0), (N1)} Addr = {(D0), (D1)} none={} univ = {(N0), (N1), (D0), (D1)} iden = {(N0,N0), (N1,N1), (D0,D0), (D1,D1)} Operators fall into Two Categories – Set – Relational

Set Operators + : union – sig Vehicle {} {Vehicle = Car + Truck} & : intersection – fact DisjSubtrees { all t1, t2:Tree | (t1.^children) & (t2.^children) = none } - : difference – fact dirinothers { all d: Directory - Root | some contents.d } in : subset – Sibling = (brother + sister) – sister in sibling = : equality

Relational operators. : dot (Join) – {(N0), (A0)}. {(A0), (D0)} = {(N0), (D0)} -> : arrow (product) – s -> t is their cartesian product – r: s -> t says r maps atoms in s to atoms in t ^ : transitive closure – fact DisjSubtrees { all t1, t2:Tree | (t1.^children) & (t2.^children) = none } – fact {no p: Person | p in p.^(mother + father) } * : reflexive-transitive closure – fact {Object in Root.*contents} ~ : transpose – Takes its mirror image s.~r = r.s (image of s navigating backwards through rel r)

Relational Operators ~ : transpose (continued) – fact dirinothers{ all d: Directory - Root | some d.~contents } – fact dirinothers { all d: Directory - Root | some contents.d } [] : box (join) – Semantically identical to join, takes arguments in different order. Expressions: e1[e2] = e2.e1 <: :domain restriction – Contains those tuples of r that start with an element in s. :> : range restriction – Contains the tuples of r that end with an element in s ++: Override – Override p ++ q (just like union), except that tuples of q can replace tuples of p rather than augmenting them.

Relational Operators Alias = {(N0), (N1)} Addr = {(A0)} address = {(N0, N1), (N1, N2), (N2, A0)} Domain restriction Alias <: address = {(N0, N1), (N1, N2)} Range restriction: address :> Addr = {(N2, A0)} workAddress = {(N0, N1), (N1, A0)} address ++ workAddress = {(N0, N1), (N1, A0), (N2, A0)}

Logical operators ! : negation && : conjunction (and) || : disjunction (OR) => : implication else : alternative : bi-implication (IFF)

Logic Cardinalities = equals < less than > greater than =< less than or equal to >= greater than or equal to #r number of tuples in r 0,1,... integer literal + plus - minus all b: Bag | #b.marbles =< 3 all bags have 3 or less marbles fact FourPassengersPerCar { all c:Car | #{c.contents} <= 4 }

Functions and Predicates A function is a named expression Zero or more declarations for arguments fun grandpas [p: Person]: set Person { p.(mother + father).father } fun colorSequence: Color -> Color { Color Green + Green->Yellow + Yellow->Red }

Predicates and functions A predicate is a named constraint Zero or more declarations for arguments Can be used to represent an operation Only holds when invoked (unlike fact) – sig Name, Addr {} sig Book { addr: Name -> Addr } pred add (b, b': Book, n: Name, a: Addr) { b'.addr = b.addr + n->a } – pred Above(m, n: Man) {m.floor = n.ceiling} Man m is “above” Man n if m's floor is n's ceiling

fact, pred, run fact F {…} pred P () {…} run P means – fact: assume constraint F holds – pred: define constraint P – run: find an instance that satisfies P and F Ref: Alloy in 90 minutes.

Analyzing the model Write a command to analyze a model A run command searches for an instance of a predicate – run ownGrandpa A check command searches for a counter example of an assertion – check NoSelfFather You may give a scope that bounds the size of instances. – run solve for 5 State

Demo The File System.