1. 236800 – Seminar in Software Engineering Cynthia Disenfeld
Alloy
– Seminar in Software Engineering
Cynthia Disenfeld

2. Alloy
It was developed at MIT by the Software Design Group under the guidance of Daniel Jackson.
Alloy is a modelling language for software design.
Find instances and counterexamples to define a correct model, find errors..
Represents the abstraction, i.e. without errors, and not models we don’t won’t to be represented.
Underconstrained, allows more systems than what we want to model
Overconstrained, there are restrictions that are not necessary.

3. Alloy in the Industry
Daniel Jackson: – “Alloy is being used in a bunch of companies, but most of them are rather secretive about it. I do know that it's been used by Navteq (who make navigation systems), ITA Software (for understanding invariants in their flight reservation database), AT&T (for specifying and analyzing novel switch architectures), Northrop Grumman (some large military avionics models), Telcordia (who've delivered a prototype network configuration tool to the DoD based on Alloy).”

4. Alloy in the Industry
Alloy was used for specification and modelling of
name servers
network configuration protocols
access control
Telephony
Scheduling
document structuring
key management
Cryptography
instant messaging
railway switching
filesystem synchonization
semantic web

5. Example 1. Shopping
abstract sig Person {} sig Salesman extends Person {sellsTo: set Customer} sig Customer extends Person {buysFrom: lone Salesman}
Declarative: data structures, first order relational logic
Abstract definition
Lone definition
Extends imply disjoint
Explain how father, mother are actually relations

6. Set multipliers set : any number. one: exactly one. lone: zero or one.
some: one or more.

7. Example 1. Shopping
abstract sig Person {} sig Salesman extends Person {sellsTo: set Customer} sig Customer extends Person {buysFrom: lone Salesman} pred show{} run show for 4

8. Model:

9. Correcting the specification
fact {sellsTo = ~buysFrom}

10. Check the specification is now correct
assert factOk{all s:Salesman, c:Customer | c in s.sellsTo <=> s in c.buysFrom } check factOk for 5
Difference between fact and assert

11. Quantifiers all x: e | F some x: e | F no x: e | F lone x: e | F

12. Operators + : union & : intersection - : difference in : subset
= : equality

13. Relational operators . : dot (Join) -> : arrow (product)
{(N0), (A0)} . {(A0), (D0)} = {(N0), (D0)}
-> : arrow (product)
s -> t is their cartesian product
^ : transitive closure
* : reflexive-transitive closure
~ : transpose

14. Logical Operators ! : negation && : conjunction (and)
|| : disjunction (OR)
=> : implication
<=> : if and only if

15. Example: Stock sig Product {} sig Stock {
amount: Product -> one Int }{
all p: Product | p.amount >= 0 }
run show for 3 but 1 Stock
run show for 3 Person, 3 Product, 1 Stock
Explication of the relation

16. Example: Stock

17. Sets univ: the set of all the elements in the current domain
none: the empty set
iden: the identity relation

18. Sets

19. Predicates We can find models that are instances of the predicates.
As well, we can specify operations, by describing what changes in the state of the system (like in a Z specification we have preconditions on the previous state of the system and post conditions on the result).

20. Predicates
A customer buys from a certain salesman a certain product. This causes the stock of the product to be reduced by one.

21. Predicates
pred buy[s:Salesman, c:Customer, p:Product, st, st': Stock] {
st'.amount = st.amount + {p->(p.(st.amount)-1)} }
run buy for 2 Stock, 2 Person, 1 Product
Explain + is union

22. Predicates
pred buy[s:Salesman, c:Customer, p:Product, st, st': Stock] {
st'.amount = st.amount ++{p->(p.(st.amount)-1)} }
run buy for 2 Stock, 2 Person, 1 Product

23. Predicates

24. Predicates
pred buy[s:Salesman, c:Customer, p:Product, st, st': Stock] {
c in s.sellsTo
st'.amount = st.amount ++{p->(p.(st.amount)-1)} }
run buy for 2 Stock, 2 Person, 1 Product

25. Predicates
Is it necessary to add that there’s at least one product in stock to be able to execute the predicate buy?

26. Projection
Explain why before appear from the stock to the amount and now from the product

27. Projection

28. Functions fun newAmount[p:Product, st: Stock]: Product->Int{
p->(p.(st.amount)-1) }
pred buy2[s:Salesman, c:Customer, p:Product, st, st': Stock] {
c in s.sellsTo
st'.amount = st.amount ++ newAmount[p, st]
run buy2 for 2 Stock, 2 Person, 1 Product

29. Themes

30. Themes

31. Transitive Closure Given the following model specification of a Tree:
sig Tree {
children: set Tree }
To be able to say that a tree doesn’t appear later in it’s children:
fact {all t:Tree | t not in t.^children}
t.children+t.children.children+…
t.*children = t + t.children + t.children.children +…

32. Alloy Analyzer To run it:
java -jar /usr/local/cs236800/alloy/alloy4.jar

33. Characteristics
Based on first order logic (may be thought as subset of Z)
finite scope check
infinite model
declarative
automatic analysis
structured data
finite scope check - once you go to actually analyze the model, you must specify a scope (size) for your model. The analysis is sound (it never returns false positives) but incomplete (since it only checks things up to a certain scope). However, it is complete up to scope; it never misses a counterexample which is smaller than the specified scope. Small scope checks are still extremely valuable for finding errors.
infinite model - The models you write in Alloy do not reflect the fact that the analysis is finite. That is, you describe the compontents of a system and how they interact, but do not specify how many components there can be (as is done in traditional "model checking").
declarative - a declarative modeler answers the question "how would I recognize that X has happened", as opposed to an "operational" or "imperative" modeler who asks "how can I accomplish X".
automatic analysis - unlike some other declarative specification languages (such as Z and OCL, the object language of UML), Alloy can be automatically analyzed. You can automatically generate examples of your system and counterexamples to claims made about that system.
structured data - Alloy supports complex data structures, such as trees, and thus is a rich way to describe state

34. Models
There are three basic levels of abstraction at which an Alloy model can be read
OO paradigm
set theory
atoms and relations
sig S extends E {
F: one T }
fact {
all s:S | s.F in X

35. OO S is a class S extends its superclass E
sig S extends E {
F: one T }
fact {
all s:S | s.F in X
S is a class
S extends its superclass E
F is a field of S pointing to a T
s is an instance of S
. accesses a field s.F returns something of type T

36. Set Theory S is a set (and so is E) S is a subset of E
sig S extends E {
F: one T }
fact {
all s:S | s.F in X
S is a set (and so is E)
S is a subset of E
F is a relation which maps each S to exactly one T
s is an element of S
. composes relations s.F composes the unary relation s with the binary relations F, returning a unary relation of type T

37. Atoms and relations S is an atom (and so is E)
sig S extends E {
F: one T }
fact {
all s:S | s.F in X
S is an atom (and so is E)
the containment relation maps E to S (among other things it does)
F is a relation from S to T
the containment relation maps S to s (among other things)
. composes relations s.F composes the unary relation s with the binary relations F, resulting in a unary relation t, such that the containment relation maps T to t
Everything is a Relation (or an Atom) in Alloy
The Alloy universe consists of atoms and relations, although everything that you can get your hands on and describe in the language is a relation. Atoms only exist behind the scenes.
An atom is a primary entity which is
indivisible: it cannot be broken down into smaller parts,
immutable: it's properties don't change over time, and
uninterpreted: it doesn't have any built-in properties (the way objects can in the OO paradigm).
A relation is a structure which relates atoms. Each relation is a set of ordered tuples (vectors of atoms). Each tuple indicates that those atoms are related in a certain way (as dictated by the relation itself). The "arity" of the relation is the number of atoms in each tuple.
Alloy has no explicit notion of sets, scalars or tuples. A set is simply a unary relation; a scalar is a singleton, unary relation; and a tuple is a singleton relation. The type system distinguishes sets from relations because they have different arity, but does not distinguish tuples and scalars from more general relations.
There is no function application operator. Relational join is used in its place, and is syntactically cleaner that it would be in a language that distinguished sets and scalars. For example, given a relation f that is functional, and x and y constrained to be scalars, the formula
x.f = y
constrains the image of x under the relation f to be the set y. So long as x is in the domain of f, this formula will have the same meaning as it would if the dot were interpreted as function application, f as a function, and x and y as scalar-typed variables. But if x is out of the domain of f, the expression x.f will evaluate to the empty set, and since y is constrained to be a scalar (that is, a singleton set), the formula as a whole will be false

38. Underlying method
Relations may be expressed as boolean matrices, and operators between relations are operators on the matrices.
Example: In the domain {o1, o2}, the relation {(o1, o1)(o2, o1)} may be represented by the matrix
relations as boolean matrices, operations between them, optimizations(disjuctions, search of isomorphisms, variable renamings) the idea on behind is use sat solver, uses some libraries called sat4j. More precisely, the check command or run specify the amount of atoms, and all possible combinations of values with that amount of atoms are assigned to the relations, and given an assert search a model that contradicts it (but holds all the facts) O1 O2 1

39. Underlying method
Given the boolean representation of the relations, every operator on the relations can be represented as an operator on the matrices
For example, the conjunction of R and S is conjuction of each cell i,j in R with i,j in S
Also sets and scalars can be represented as relations:
Sets are unidimensional relations (1 for each element that is in the set, 0 otherwise)
Scalars are singleton sets.

40. Underlying method The scope determines the size of the matrices.
Given a model, an assertion and a scope, all the possible combinations within the scope, that satisfy the model are evaluated to see whether they contradict the assertion.
This is done by representing the model and the assertion both in terms of boolean variables (turns out to be a big CNF formula) which is used as the input for a SAT solver.

41. Modules It is possible to define and use other modules.
For example: Linear Ordering
open util/ordering[State]
first returns the first State atom in the linear ordering.
last returns the last State atom in the linear ordering.
next maps each State atom (except the last atom) to the next State atom.

42. Modules - Example
open util/ordering[State] module TrafficLight abstract sig Color {} one sig Red, RedYellow, Green, Yellow extends Color {} sig State {color: Color} fact { first.color = Red } pred example {} run example for 5

43. Modules - Example

44. Modules - Example pred semaphoreChange[s,s': State] {
s.color = Red => s'.color = RedYellow
else s.color = RedYellow => s'.color = Green
else s.color = Green => s'.color = Yellow
else s'.color = Red }
fact{ all s:State, s': s.next | semaphoreChange[s,s']

45. Modules - Example

46. Some Issues
Hard to express recursion, have to find ways by means of transitive closure for instance.
Kodkod solves several problems of Alloy:
Interface to other tools
Partial evaluation (e.g. Sudoku)
Sharing common subformulas
Explain what is kodkod

47. Summary Widely used Declarative language Iterative process
Instances and counterexamples help find the correct model specification
Possible reuse of modules

48. Summary
Translation to CNF formulas (by using finite scope) allows automatic verification
It is possible to interpret models in different ways
There still are limitations in the expression power of the language
There are other limitations that Kodkod deals with them.

49. References
Publications, Courses, Tutorials
: Kodkod
Software Abstractions – Logic, Language and Analysis. Daniel Jackson. The MIT Press 2006
Questions?