CSE 503 – Software Engineering Lecture 3: An introduction to Alloy Rob DeLine 5 Apr 2004 - PowerPoint PPT Presentation

CSE 503 – Software Engineering
Download
1 / 17

  • 64 Views
  • Uploaded on
  • Presentation posted in: General

CSE 503 – Software Engineering Lecture 3: An introduction to Alloy Rob DeLine 5 Apr 2004. 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Cse 503 software engineering lecture 3 an introduction to alloy rob deline 5 apr 2004

  • CSE 503 – Software Engineering

  • Lecture 3: An introduction to Alloy

  • Rob DeLine

  • 5 Apr 2004


Where we are

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


Different languages for different properties

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


Class schedule

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#


Alloy is based on relations

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

x

b

y

c


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) }

Equality of relations

=

=

!=

=

=

!=


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) }

“Set” operations

Union (+), intersection (&), and difference (-)


Join relational composition

Join: Relational composition

  • General pattern:

    • Find left tuple that ends in atom that begins right tuple

    • Concatenate the two tuples, eliminating common atom

      • { (a1,…,an) } . { (an,…,am) } = { (a1,…,an-1,an+1,…,am) }

  • Join mimics fields access in languages with records

    • Let X be an object with an f field X = { (o1) }

    • Let F be a relation mapping an object to the contents of its f field

      • F = { (o1,x1), (o2,x2), (o3,x2) }

    • X.F = { (o1) } . { (o1,x1), (o2,x2), (o3,x2) } = { (x1) }

    • Uniformly lets you get the fields of multiple objects

      • X = { (o1), (o2) }

      • X.F = { (x1), (x2) }


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) }

Join practice


Cross product

{ (a) } -> { (b) } =

{ (a) } -> { (b,c) } =

{ (a,b) } -> { (c) } =

{ (a),(b) } -> { (c),(d) } =

{ (a,b) }

{ (a,b,c) }

{ (a,b,c) }

{ (a,c), (a,d), (b,c), (b,d) }

Cross product

Product R -> S: Concatenate every x in R to every y in S


Relational operators

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) }


  • Logical operators

    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


    Quantifiers

    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


    Set comprehensions

    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.


  • Toplevel declarations

    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


    Signatures

    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,


    Facts

    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

    • }


  • Login