Alloy Analyzer 4 Tutorial Session 2: Language and Analysis Greg Dennis and Rob Seater Software Design Group, MIT.

Slides:



Advertisements
Similar presentations
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 2.
Advertisements

Design by Contract.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2013 Lecture 4.
DSE using Alloy Reading part. 1 Introduction Alloy -DSL -DSE Framework Use of Alloy.
– Seminar in Software Engineering Cynthia Disenfeld
Micromodels of Software
2005conjunctive-ii1 Query languages II: equivalence & containment (Motivation: rewriting queries using views)  conjunctive queries – CQ’s  Extensions.
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.
1 Web Developer & Design Foundations with XHTML Chapter 9 Key Concepts.
Knowledge Representation
Kanban Task Manager for Outlook ‒ Introduction
Discrete Mathematics Lecture 5 Alexander Bukharovich New York University.
1 Relational Algebra & Calculus. 2 Relational Query Languages  Query languages: Allow manipulation and retrieval of data from a database.  Relational.
CSE 1302 Lecture 8 Inheritance Richard Gesick Figures from Deitel, “Visual C#”, Pearson.
1 A UML Class Diagram Analyzer Tiago Massoni Rohit Gheyi Paulo Borba Software Productivity Group Informatics Center – UFPE October 2004.
CS 290C: Formal Models for Web Software Lectures 7 and 8: Alloy, Alloy Analyzer, Data Modeling and Analysis with Alloy Instructor: Tevfik Bultan.
Modelling Conceptual Knowledge using Logic - Week 6 Lee McCluskey Department of Computing and Mathematical Sciences University of Huddersfield.
01 Introduction1June Introduction CE : Fundamental Programming Techniques.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 10.
1 Introduction to OBIEE: Learning to Access, Navigate, and Find Data in the SWIFT Data Warehouse Lesson 5: Navigation in OBIEE – Touring the Catalog Page.
1 Relational Algebra and Calculus Yanlei Diao UMass Amherst Feb 1, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
LSU 06/04/2007BASIC Stamp Editor1 The BASIC Stamp Editor Programming Unit, Lecture 3.
A First Program Using C#
272: Software Engineering Fall 2008 Instructor: Tevfik Bultan Lectures 5, 6, and 7: Alloy and Alloy Analyzer.
Lecture 8 Inheritance Richard Gesick. 2 OBJECTIVES How inheritance promotes software reusability. The concepts of base classes and derived classes. To.
T U T O R I A L  2009 Pearson Education, Inc. All rights reserved. 1 2 Welcome Application Introducing the Visual Basic 2008 Express Edition IDE.
Tutorial 111 The Visual Studio.NET Environment The major differences between Visual Basic 6.0 and Visual Basic.NET are the latter’s support for true object-oriented.
Alloy Daniel Jackson MIT Lab for Computer Science 6898: Advanced Topics in Software Design February 11, 2002.
Office Management Tools II Ms Saima Gul. Office Management Tools II Ms Saima Gul.
Microsoft Office XP Illustrated Introductory, Enhanced Reports Using.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 03. Classes,
1 Relational Algebra & Calculus Chapter 4, Part A (Relational Algebra)
1 Relational Algebra and Calculas Chapter 4, Part A.
Relational Algebra.
An Object-Oriented Approach to Programming Logic and Design Chapter 3 Using Methods and Parameters.
Semantic Nets, Frames, World Representation CS – W February, 2004.
Arjav Dave Jitendra Gupta Nishit Shah. Agenda  Overview  Alloy Architecture  Alloy Specification Language  Alloy Analyzer Demo  Comparisons  Conclusion.
An Introduction to Forms. The Major Steps of a MicroSoft Access Database  Tables  Queries  Forms  Macros  Reports  Modules On our road map, we are.
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine1 CSE 503 – Software Engineering Lecture 3: An introduction to Alloy Rob DeLine 5 Apr 2004.
ALLOY: A Formal Methods Tool Glenn Gordon Indiana University of Pennsylvania COSC 481- Formal Methods Dr. W. Oblitey 26 April 2005.
On Combining Multi-formalism Knowledge to Select Models for Model Transformation Testing Sagar Sen (1 st year PhD student), Benoit Baudry, Jean-Marie Mottu.
11 Making Decisions in a Program Session 2.3. Session Overview  Introduce the idea of an algorithm  Show how a program can make logical decisions based.
Alloy Analyzer 4 Tutorial Session 3: Static Modeling Greg Dennis and Rob Seater Software Design Group, MIT.
A Gentle Introduction to Software Modeling & Analysis
Using Alloy to Design a Safe Traffic Light System
Names and Attributes Names are a key programming language feature
Session 4: Dynamic Modeling
Microsoft Office Access 2010 Lab 2
Using Alloy to model the self-selection of a leader in a decentralized set of communicating processes I’m the leader! time … Roger L. Costello December.
SEAA 2014 Automatic Production of Transformation Chains Using Structural Constraints on Output Models Cuauhtémoc Castellanos Etienne Borde Thomas Vergnaud.
ece 720 intelligent web: ontology and beyond
Gephi Gephi is a tool for exploring and understanding graphs. Like Photoshop (but for graphs), the user interacts with the representation, manipulate the.
Saving, Modifying page, grammar & spell checking, and printing
Database Applications – Microsoft Access
Compiler Design 18. Object Oriented Semantic Analysis (Symbol Tables, Type Checking) Kanat Bolazar March 30, 2010.
Tutorial 19 - Microwave Oven Application Building Your Own Classes and Objects Outline Test-Driving the Microwave Oven Application Designing.
Lecture 22 Inheritance Richard Gesick.
Alloy Daniel Jackson MIT Lab for Computer Science 6898: Advanced Topics in Software Design February 11, 2002.
Model the non-negative even integers
Each hotel guest has a set of keys and no two guests have the same key
Modeling Inference Rules
Use Alloy to model and find a solution to the Farmer, Goat, Cabbage, and Wolf problem Roger L. Costello July 14, 2018.
Multiple Inheritance Roger L. Costello March 24, 2018.
Object-Oriented Programming: Inheritance and Polymorphism
Encapsulation in Alloy
Desktop model Roger L. Costello March 24, 2018 Desktop0 Desktop1
Rigorous Software Engineering
Handout-2(b) Dr. R. Z. Khan AMU. Aligarh (INDIA).
ICOM 5016 – Introduction to Database Systems
Presentation transcript:

Alloy Analyzer 4 Tutorial Session 2: Language and Analysis Greg Dennis and Rob Seater Software Design Group, MIT

alloy language & analysis ● language = syntax for structuring specifications in logic – shorthands, puns, sugar ● analysis = tool for finding solutions to logical formulas – searches for and visualizes counterexamples

“I'm My Own Grandpa” Song ● popular radio skit originally written in the 1930's ● expanded into hit song by “Lonzo and Oscar” in 1948

module grandpa abstract sig Person { father: lone Man, mother: lone Woman } sig Man extends Person { wife: lone Woman } sig Woman extends Person { husband: lone Man } fact { no p: Person | p in p.^(mother + father) wife = ~husband } assert noSelfFather { no m: Man | m = m.father } check noSelfFather fun grandpas[p: Person] : set Person { p.(mother + father).father } pred ownGrandpa[p: Person] { p in grandpas[p] } run ownGrandpa for 4 Person “I'm My Own Grandpa” in Alloy

language: module header module grandpa ● first non-comment of an Alloy model

language: signatures sig A {} set of atoms A sig A {} sig B {} disjoint sets A and B (no A & B) sig A, B {} same as above sig B extends A {} set B is a subset of A (B in A) sig B extends A {} sig C extends A {} B and C are disjoint subsets of A (B in A && C in A && no B & C) sig B, C extends A {} same as above abstract sig A {} sig B extends A {} sig C extends A {} A partitioned by disjoint subsets B and C (no B & C && A = (B + C)) sig B in A {} B is a subset of A – not necessarily disjoint from any other set sig C in A + B {} C is a subset of the union of A and B one sig A {} lone sig B {} some sig C {} A is a singleton set B is a singleton or empty C is a non-empty set

grandpa: signatures ● all men and women are persons ● no person is both a man and a woman ● all persons are either men or women abstract sig Person {... } sig Man extends Person {... } sig Woman extends Person {... }

language: fields sig A {f: e} f is a binary relation with domain A and range given by expression e f is constrained to be a function (f: A -> one e) or (all a: A | a.f: e) sig A { f1: one e1, f2: lone e2, f3: some e3, f4: set e4 } (all a: A | a.fn : m e) sig A {f, g: e} two fields with same constraints sig A {f: e1 m -> n e2} (f: A -> (e1 m -> n e2)) or (all a: A | a.f : e1 m -> n e2) sig Book { names: set Name, addrs: names -> Addr } dependent fields (all b: Book | b.addrs: b.names -> Addr)

grandpa: fields ● fathers are men and everyone has at most one ● mothers are women and everyone has at most one ● wives are women and every man has at most one ● husbands are men and every woman has at most one abstract sig Person { father: lone Man, mother: lone Woman } sig Man extends Person { wife: lone Woman } sig Woman extends Person { husband: lone Man }

language: facts fact { F } fact f { F } sig S {... }{ F } sig Host {} sig Link {from, to: Host} fact {all x: Link | x.from != x.to} no links from a host to itself fact noSelfLinks {all x: Link | x.from != x.to} same as above sig Link {from, to: Host} {from != to} same as above, with implicit 'this.' facts introduce constraints that are assumed to always hold

grandpa: fact ● no person is his or her own ancestor ● a man's wife has that man as a husband ● a woman's husband has that woman as a wife fact { no p: Person | p in p.^(mother + father) wife = ~husband }

language: functions fun f[x1: e1,..., xn: en] : e { E } sig Name, Addr {} sig Book { addr: Name -> Addr } fun lookup[b: Book, n: Name] : set Addr { b.addr[n] } fact everyNameMapped { all b: Book, n: Name | some lookup[b, n] } functions are named expression with declaration parameters and a declaration expression as a result invoked by providing an expression for each parameter

language: predicates pred p[x1: e1,..., xn: en] { F } sig Name, Addr {} sig Book { addr: Name -> Addr } pred contains[b: Book, n: Name, d: Addr] { n->d in b.addr } fact everyNameMapped { all b: Book, n: Name | some d: Addr | contains[b, n, a] } named formula with declaration parameters

grandpa: function and predicate ● a person's grandpas are the fathers of one's own mother and father fun grandpas[p: Person] : set Person { p.(mother + father).father } pred ownGrandpa[p: Person] { p in grandpas[p] }

language: “receiver” syntax fun f[x: X, y: Y,...] : Z {...x...} fun X.f[y:Y,...] : Z {...this...} pred p[x: X, y: Y,...] {...x...} pred X.p[y:Y,...] {...this...} f[x, y,...] x.f[y,...] p[x, y,...] x.p[y,...] fun Person.grandpas : set Person { this.(mother + father).father } pred Person.ownGrandpa { this in this.grandpas }

language: assertions assert a { F } sig Node { children: set Node } one sig Root extends Node {} fact { Node in Root.*children } // invalid assertion: assert someParent { all n: Node | some children.n } // valid assertion: assert someParent { all n: Node – Root | some children.n } constraint intended to follow from facts of the model

language: check command check a top-level sigs bound by 3 check a for default top-level sigs bound by default check a for default but list default overridden by bounds in list check a for list sigs bound in list, invalid if any unbound assert a { F } check a scope instructs analyzer to search for counterexample to assertion within scope abstract sig Person {} sig Man extends Person {} sig Woman extends Person {} sig Grandpa extends Man {} check a check a for 4 check a for 4 but 3 Woman check a for 4 but 3 Man, 5 Woman check a for 4 Person check a for 4 Person, 3 Woman check a for 3 Man, 4 Woman check a for 3 Man, 4 Woman, 2 Grandpa // invalid: check a for 3 Man check a for 5 Woman, 2 Grandpa if model has facts M finds solution to M && !F

grandpa: assertion check ● sanity check ● command instructs analyzer to search for counterexample to noSelfFather within a scope of at most 3 Persons ● noSelfFather assertion follows from fact fact { no p: Person | p in p.^(mother + father) wife = ~husband } assert noSelfFather { no m: Man | m = m.father } check noSelfFather

language: run command pred p[x: X, y: Y,...] { F } run p scope instructs analyzer to search for instance of predicate within scope if model has facts M, finds solution to M && (some x: X, y: Y,... | F) fun f[x: X, y: Y,...] : R { E } run f scope instructs analyzer to search for instance of function within scope if model has facts M, finds solution to M && (some x: X, y: Y,..., result: R | result = E)

grandpa: predicate simulation ● command instructs analyzer to search for configuration with at most 4 people in which a man is his own grandfather fun grandpas[p: Person] : set Person { p.(mother + father).father } pred ownGrandpa[p: Person] { p in grandpas[p] } run ownGrandpa for 4 Person

exercise: barber paradox ➢ download barber.als from the tutorial website ➢ follow the instructions ➢ don't hesitate to ask questions sig Man {shaves: set Man} one sig Barber extends Man {} fact { Barber.shaves = {m: Man | m not in m.shaves} }

introduction to visualization ➢ Download grandpa.als from the tutorial website ➢ Click “Execute” ➢ Click “Show” ➢ Click “Theme”

superficial ● types and sets – default color → gray – Apply – man color → blue – woman color → red – Apply ● also notice: – hide unconnected nodes – orientation – layout backwards

types & sets ● types: from signatures – person shape → trapezoid – notice it carries down to man, woman – woman: align by type – Apply

types & sets

● sets: from existentials, runs, checks – somewhat intelligently named – $ownGrandpa_m label → self-grandpa – Apply – pitfall: don't show vs. don't show as label (vs. don't show in customizer...)

relations ● relations – mother: show as attribute → check (still shown as arc) – gray = inherited (vs. overridden) – Apply

relations ● relations – mother: show as attribute → uncheck – father, mother, husband, wife: label → “ ” – father, mother: color → green – husband, wife: color → yellow – Apply

relations

finishing up ● save theme ● close theme ➢ create your own visualization for the barber exercise!