Loading in 5 sec....

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

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

- 86 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about ' CSE 503 – Software Engineering Lecture 3: An introduction to Alloy Rob DeLine 5 Apr 2004' - eliora

**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

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

- 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

- 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

- 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

{ (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=

=

!=

=

=

!=

{ (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” operationsUnion (+), intersection (&), and difference (-)

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

{ (a,b) } . { (b,c) } =

{ (a) } . { (c,d) } =

{ (a),(b) } . { (a,c),(b,d),(a,e) } =

{ (b) }

{ (a,c) }

{ }

{ (c),(d),(e) }

Join practice{ (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 productProduct R -> S: Concatenate every x in R to every y in S

Relational operators Transitive closure (^): ^R = limit of R + R.R + R.R.R + … Useful constants Reflexive transitive closure (*): *(S->S) = ^(S->S) + iden [S]

- Transpose (~) reverses the tuples in the set
- ~ { (a,b), (b,c) } = { (b,a), (c,b) }

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

- 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

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

Logical operators

- Negation ! F not F
- Conjunction F && G F and G
- Disjunction F || G F or G
- Implication F => G F implies G (! F || G)
- If then else F => G,H F implies G else H F=>G && !F=>H
- Bi-implication F <=> G F iff G F=>G && G=>F

Quantifiers

- all x:e | F universal; F is true for every x in e
- some x:e | F existential; 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 Can also use comprehensions to construct relations, by declaring more than one variable

- 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

- { x:e, y: f | F} creates a binary relation.

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 Multiplicity markers add contraints on relations

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

- S m->n T where m and n can be
- ? zero or one
- ! exactly one
- + one or more

option Person,

set Person,

Facts It’s handy to add these as part of a sig

- Facts add axioms about your sets and relations
- fact { all p : Person | p.spouse.spouse = p }

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

Download Presentation

Connecting to Server..