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

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.

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).”

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

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

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

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

Model:

Correcting the specification fact {sellsTo = ~buysFrom}

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

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

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

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

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

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

Example: Stock

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

Sets

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

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

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

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

Predicates

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

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

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

Projection

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

Themes

Themes

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 +…

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

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

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

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

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

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

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

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.

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.

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.

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

Modules - Example

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']

Modules - Example

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

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

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.

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 Questions?