Alloy

1. Alloy 236800 – 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..

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 • filesystemsynchonization • semantic web

5. Example 1. Shopping abstract sig Person {} sig Salesman extends Person {sellsTo: set Customer} sig Customer extends Person {buysFrom: lone Salesman}

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

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

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

13. Relational operators • . : dot (Join) • {(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

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

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

26. Projection

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}

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

33. Characteristics • Based on first order logic (may be thought as subset of Z) • finite scope check • infinite model • declarative • automatic analysis • structured data

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 sig S extends E { F: one T } fact { all s:S | s.F in X } • S is a class • S extends its superclassE • 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 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 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

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

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 predsemaphoreChange[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

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. Questions? References • http://alloy.mit.edu Publications, Courses, Tutorials • http://alloy.mit.edu/kodkod/ : Kodkod • Software Abstractions – Logic, Language and Analysis. Daniel Jackson. The MIT Press 2006