UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine1 CSE 503 – Software Engineering Lecture 3: An introduction to Alloy Rob DeLine 5 Apr 2004

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine2 Where we are Problem frames let us be methodical about the problem Now we’ll be methodical about the system behavior  Explore system behavior before committing to design details  Ensure that the system has desired properties System properties have different flavors  Safety property: “The system does not do something bad.”  Liveness property: “The system (eventually) does something good.”  Functional property: “The system computes what we want.” To explore properties, we formally model the system  A model abstracts some aspect of the system and its environment  Different languages emphasize different types of behavior  Different languages come with different theorems and tools

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine3 Different languages for different properties Explore the structure of the system’s state  Model system state as sets and relations in Alloy  Use Alloy to see if possible state configurations uphold properties Explore states the system can reach through operations  Model system as a state transition system  Use a model checker to see if possible traces uphold properties Explore communication patterns in concurrent systems  Model system as processes exchanging messages  Use a process calculus to prove refinements Explore functional properties of algorithms  Model system state as predicates  Use Hoare logic to prove algorithm’s effect on the system state

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine4 Class schedule For the next four weeks  Monday: the syntax/semantics of the notation, use of the tool  Wednesday: case studies, practice modeling together  Assignments will give you individual practice at modeling Tools  May 5/7: Alloy  May 12/14: Promela/SPIN  May 19/21: CCS and Pi  May 26/28: Hoare logic, plus ESC/Java or Boogie/Spec#

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine5 Alloy is based on relations Basic concepts  Atoms are indivisible, immutable, uninterpreted  Relations are sets of tuples of one or more atoms { (a,x), (b,x), (c,y) } Alloy treats all values uniformly as relations  There’s no syntax in the language for atoms or sets  An “set” is a relation with tuples of size 1: { (a), (b), (c) }  An “atom” or scalar is a relation with one tuple of size 1: { (a) }  You don’t need to worry about undefined values or special cases a b c x y ax bx cy

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine6 Equality of relations { (a), (b) } { (a), (a) } { (a,b) } { (a,b), (c,d) } { (a,b), (a,b) } { (a,a) } { (b), (a) } { (a) } { (b,a) } { (c,d), (a,b) } { (a,b) } { (a) } = = != = =

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine7 “Set” operations { (a), (b) } + { (c), (d) } = { (a,b) } + { (a,b), (c,d) } = { (a), (b) } & { (b), (c) } = { (a,b), (b,b) } & { (a,a), (a,b) } = { (a), (b) } – { (b) } = { (a,b), (b,c) } – { (b,c), (c,d) } = { (a), (b), (c), (d) } { (a,b), (c,d) } { (b) } { (a,b) } { (a) } { (a,b) } Union (+), intersection (&), and difference (-)

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine8 Join: Relational composition General pattern:  Find left tuple that ends in atom that begins right tuple  Concatenate the two tuples, eliminating common atom { (a 1,…,a n ) }. { (a n,…,a m ) } = { (a 1,…,a n-1,a n+1,…,a m ) } Join mimics fields access in languages with records  Let X be an object with an f field X = { (o 1 ) }  Let F be a relation mapping an object to the contents of its f field F = { (o 1,x 1 ), (o 2,x 2 ), (o 3,x 2 ) }  X.F = { (o 1 ) }. { (o 1,x 1 ), (o 2,x 2 ), (o 3,x 2 ) } = { (x 1 ) }  Uniformly lets you get the fields of multiple objects X = { (o 1 ), (o 2 ) } X.F = { (x 1 ), (x 2 ) }

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine9 Join practice { (a) }. { (a,b) } = { (a,b) }. { (b,c) } = { (a) }. { (c,d) } = { (a),(b) }. { (a,c),(b,d),(a,e) } = { (b) } { (a,c) } { } { (c),(d),(e) }

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine10 Cross product { (a) } -> { (b) } = { (a) } -> { (b,c) } = { (a,b) } -> { (c) } = { (a),(b) } -> { (c),(d) } = { (a,b) } { (a,b,c) } { (a,c), (a,d), (b,c), (b,d) } Product R -> S: Concatenate every x in R to every y in S

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine11 Relational operators Transpose (~) reverses the tuples in the set ~ { (a,b), (b,c) } = { (b,a), (c,b) } Transitive closure (^): ^R = limit of R + R.R + R.R.R + … ^ { (a,b), (b,c) } = { (a,b), (b,c), (a,c) } Useful constants  Empty relation:none [e]  Universal relation:univ [e]  Identity relation:iden [e](e is a scalar or set)  Type of the result determined by the type of e Reflexive transitive closure (*): *(S->S) = ^(S->S) + iden [S] * { (a,b), (b,c) } = { (a,a), (a,b), (b,b), (b,c), (c,c), (a,c) }

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine12 Logical operators Negation! Fnot F ConjunctionF && GF and G DisjunctionF || GF or G ImplicationF => GF implies G(! F || G) If then elseF => G,HF implies G else HF=>G && !F=>H Bi-implicationF GF iff GF=>G && G=>F

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine13 Quantifiers all x:e | Funiversal; F is true for every x in e some x:e | Fexistential; F is true for at least one x in e no x:e | F F is true for no x in e sole x:e | F F is true for at most one (and possibly no) x in e one x:e | F F is true for exactly one x in e Several variables can be quantified over at once. E.g., one x:e, y: f | F exactly one way to pick x and y that makes F true If you want the variables to be distinct, use disj: one disj x, y : e | F

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine14 Set comprehensions Set comprehensions construct sets and relations directly from properties. { x:e | F } — the set of atoms x from e for which F holds { x : Person | no x.spouse } is the set of unmarried people Can also use comprehensions to construct relations, by declaring more than one variable { x:e, y: f | F} creates a binary relation.

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine15 Toplevel declarations Alloy provides declarations to organize your specification  module – break your specification into manageable pieces  sig – declare new sets and relations  fact – record axioms about your sets and relations (not checked)  fun – name and abbreviate expressions  assert – write conditions that you want to check Alloy provides commands to invoke its constraint engine  check – try to find a counterexample for an assertion  run – try to find an instance of a function

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine16 Signatures Signatures introduce sets and relations sig Name { /* the set of name atoms */ } sig Person { // new set of person atoms name : Name,// new relation Person -> Name spouse : Person, parents: Person, childWith : Person -> Person } Multiplicity markers add contraints on relations  S m->n T where m and n can be ?zero or one !exactly one +one or more option Person, set Person,

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine17 Facts Facts add axioms about your sets and relations fact { all p : Person | p.spouse.spouse = p } It’s handy to add these as part of a sig sig Person { // new set of person atoms name : Name,// new relation Person -> Name spouse : option Person, parents: set Person, childWith : Person -> Person } { // extra block adds facts about “this” this !in spouse }