Slide 1

Alloy236800 Seminar in Software EngineeringCynthia DisenfeldAlloyIt 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 dont wont to be represented.Underconstrained, allows more systems than what we want to modelOverconstrained, there are restrictions that are not necessary.

2Alloy in the IndustryDaniel Jackson: Alloy is being used in a bunch of companies, but most ofthem are rather secretive about it. I do know that it's beenused by Navteq (who make navigation systems), ITASoftware (for understanding invariants in their flightreservation database), AT&T (for specifying and analyzingnovel switch architectures), Northrop Grumman (some largemilitary avionics models), Telcordia (who've delivered aprototype network configuration tool to the DoD based onAlloy).Alloy in the IndustryAlloy was used for specification and modelling of name serversnetwork configuration protocolsaccess controlTelephonySchedulingdocument structuringkey managementCryptographyinstant messagingrailway switchingfilesystem synchonizationsemantic webExample 1. Shoppingabstract sig Person {}sig Salesman extends Person {sellsTo: set Customer}sig Customer extends Person {buysFrom: lone Salesman}

Declarative: data structures, first order relational logic

Abstract definitionLone definitionExtends imply disjoint

Explain how father, mother are actually relations5Set multipliersset : any number.one: exactly one.lone: zero or one.some: one or more.

Example 1. Shoppingabstract sig Person {}sig Salesman extends Person {sellsTo: set Customer}sig Customer extends Person {buysFrom: lone Salesman}

pred show{}run show for 47Model:

8Correcting the specificationfact {sellsTo = ~buysFrom}

Check the specification is now correctassert factOk{all s:Salesman, c:Customer | c in s.sellsTo s in c.buysFrom }check factOk for 5

Difference between fact and assert10Quantifiersall x: e | Fsome x: e | Fno x: e | Flone x: e | Fone x: e | FOperators+ : union& : intersection- : differencein : subset= : equalityRelational operators. : dot (Join){(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: Stocksig 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 relation15Example: Stock

Setsuniv: the set of all the elements in the current domainnone: the empty setiden: the identity relation

Sets

PredicatesWe 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).PredicatesA customer buys from a certain salesman a certain product. This causes the stock of the product to be reduced by one.Predicatespred 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 union21Predicatespred 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

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

Predicates

Is it necessary to add that theres at least one product in stock to be able to execute the predicate buy?25Projection

Explain why before appear from the stock to the amount and now from the product26Projection

Functionsfun 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.sellsTost'.amount = st.amount ++ newAmount[p, st] }run buy2 for 2 Stock, 2 Person, 1 Product

Themes

Themes

Transitive ClosureGiven the following model specification of a Tree:sig Tree {children: set Tree}To be able to say that a tree doesnt appear later in its children:fact {all t:Tree | t not in t.^children}

t.children+t.children.children+

t.*children = t + t.children + t.children.children +31Alloy AnalyzerTo run it:java -jar /usr/local/cs236800/alloy/alloy4.jar

CharacteristicsBased on first order logic (may be thought as subset of Z)finite scope checkinfinite modeldeclarative automatic analysisstructured datafinite 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

33ModelsThere are three basic levels of abstraction at which an Alloy model can be readOO paradigmset theoryatoms and relationssig S extends E { F: one T }

fact { all s:S | s.F in X } 34OOS 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 Tsig S extends E { F: one T }

fact { all s:S | s.F in X } Set TheoryS 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 Tsig S extends E { F: one T }

fact { all s:S | s.F in X } Atoms and relationsS 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 tsig S extends E { F: one T }

fact { all s:S | s.F in X } Everything is a Relation (or an Atom) in AlloyThe 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 formulax.f = yconstrains 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

37Underlying methodRelations 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 matrixO1O2O110O210relations 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)38Underlying methodGiven the boolean representation of the relations, every operator on the relations can be represented as an operator on the matricesFor example, the conjunction of R and S is conjuction of each cell i,j in R with i,j in SAlso 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 methodThe 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.ModulesIt 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 - Exampleopen util/ordering[State]module TrafficLightabstract sig Color {}one sig Red, RedYellow, Green, Yellow extends Color {}sig State {color: Color}fact { first.color = Red }pred example {}run example for 542Modules - Example

43Modules - Examplepred 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 IssuesHard to express recursion, have to find ways by means of transitive closure for instance.Kodkod solves several problems of Alloy:Interface to other toolsPartial evaluation (e.g. Sudoku)Sharing common subformulasExplain what is kodkod46SummaryWidely usedDeclarative languageIterative processInstances and counterexamples help find the correct model specificationPossible reuse of modulesSummaryTranslation to CNF formulas (by using finite scope) allows automatic verificationIt is possible to interpret models in different waysThere still are limitations in the expression power of the languageThere are other limitations that Kodkod deals with them.

48Questions?http://alloy.mit.edu Publications, Courses, Tutorialshttp://alloy.mit.edu/kodkod/ : KodkodSoftware Abstractions Logic, Language and Analysis. Daniel Jackson. The MIT Press 2006References49