# An Equational Calculus for Alloy.

**ABSTRACT** In this paper we show that, by translating Alloy formulas to formulas in the language of fork algebras, we obtain a complete, equa- tional, and purely relational calculus for Alloy.

**0**Bookmarks

**·**

**54**Views

- [Show abstract] [Hide abstract]

**ABSTRACT:**Alloy is an increasingly popular lightweight specification language based on relational logic. Alloy models can be automatically verified within a bounded scope using off-the-shelf SAT solvers. Since false assertions can usually be disproved using small counter-examples, this approach suffices for most applications. Unfortunately, it can sometimes lead to a false sense of security, and in critical applications a more traditional unbounded proof may be required. The automatic theorem prover Prover9 has been shown to be particularly effective for proving theorems of relation algebras [7], a quantifier-free (or point-free) axiomatization of a fragment of relational logic. In this paper we propose a translation from Alloy specifications to fork algebras (an extension of relation algebras with the same expressive power as relational logic) which enables their unbounded verification in Prover9. This translation covers not only logic assertions, but also the structural aspects (namely type declarations), and was successfully implemented and applied to several examples.09/2012; - SourceAvailable from: Marcelo F. FriasACM Transactions on Software Engineering and Methodology 01/2007; 17. · 1.55 Impact Factor
- SourceAvailable from: Tiago Massoni[Show abstract] [Hide abstract]

**ABSTRACT:**Refactorings are usually proposed in an ad hoc way because it is difficult to prove that they are sound with respect to a formal semantics, not guaranteeing the absence of type errors or semantic changes. Consequently, developers using refactoring tools must rely on compilation and tests to ensure type-correctness and semantics preservation, respectively, which may not be satisfactory to critical software development. In this paper, we formalize a static semantics for Alloy, which is a formal object-oriented modeling language, and encode it in Prototype Verification System (PVS). The static semantics' formalization can be useful for specifying and proving that transformations in general (not only refactorings) do not introduce type errors, for instance, as we show here.Electronic Notes in Theoretical Computer Science. 01/2007;

Page 1

An Equational Calculus for Alloy

Marcelo F. Frias?,1, Carlos G. L´ opez Pombo2, and Nazareno M. Aguirre3

1Department of Computer Science, School of Exact and Natural Sciences,

University of Buenos Aires, Argentina, and CONICET

{mfrias,clpombo}@dc.uba.ar

2Department of Computer Science, School of Exact and Natural Sciences,

University of Buenos Aires, Argentina

3Department of Computer Science, FCEFQyN,

Universidad Nacional de R´ ıo Cuarto, Argentina

aguirre@dc.exa.unrc.edu.ar

Abstract. In this paper we show that, by translating Alloy formulas to

formulas in the language of fork algebras, we obtain a complete, equa-

tional, and purely relational calculus for Alloy.

1Introduction

Alloy [10] is a formal modeling language that is gaining acceptance within the

formal methods community. Its main feature is its tool support. The Alloy An-

alyzer [8] performs a kind of bounded model checking that allows one to find

counterexamples of supplied assertions within a model description written in

Alloy. Another important feature of Alloy is its amenable language, which in-

corporates constructs ubiquitous in object modeling notations. Also, its easy to

understand semantics, based on relations, makes the language appealing.

Contributions of This Paper: At the same time a vast research has been carried

on about the analysis of Alloy specifications using SAT solving [9,10], not much

research has been done so far on the analysis of Alloy specifications using theorem

proving. In order to prove Alloy assertions from Alloy specifications, in this paper

we propose the following procedure:

1. Translate both the assertions and the specification to equations in the lan-

guage of fork algebras [4].

2. Verify equationally whether the translated assertions can be derived from

the translation of the specification.

The language of fork algebras is quite similar to Alloy in that it predicates

exclusively about relations (binary in this case). The advantage of moving to fork

algebras comes from the fact there is a complete (equational) calculus for rea-

soning about this class of algebras. Therefore, proving an Alloy formula reduces

to proving its translation in this complete equational calculus.

?Research partially funded by Antorchas foundation and project UBACYT X094.

J. Davies et al. (Eds.): ICFEM 2004, LNCS 3308, pp. 162–175, 2004.

c ?Springer-Verlag Berlin Heidelberg 2004

Page 2

An Equational Calculus for Alloy163

Relevance to Formal Engineering Methods: The Alloy modeling language and

the Alloy Analyzer are being applied in domains such as air traffic control [3]

or verification of medical software [12]. While the kind of analysis provided by

Alloy is extremely useful, it does not substitute analysis techniques such as

theorem proving. There has been a growing interest in combining the SAT-

solving approach of Alloy with theorem proving (we will elaborate on this in the

next paragraph), and our hope is that new tools developed in this direction take

into account the limitations pointed out here, as well as the possible solutions

we offer.

Comparison with Previous Work: Since a broad comparison with other formal

methods that combine model checking and theorem proving might make us loose

focus, we will compare with the specific work that has already been done on the-

orem proving from Alloy specifications. Prioni [2] is a tool that combines the

model checking capabilities offered by Alloy with the theorem proving capa-

bilities provided by the (semi-automatic) theorem prover Athena [1]. Athena’s

characterisation of Alloy allows one to reason about specifications, using (semi

automatic) theorem proving. However, the proposed characterisation does not

capture well some features of Alloy and its relational logic, such as, for instance,

the uniform treatment for scalars, singletons and relations. Quoting the authors,

“Recall that all values in Alloy are relations. In particular, Alloy

blurs the type distinction between scalars and singletons. In our Athena

formalization, however, this distinction is explicitly present and can be

onerous for the Alloy user.” (cf. [2, p. 6])

Prioni has also a number of further shortcomings, such as the, in our opinion,

awkward representations of Alloy’s composition operation ‘.’ and of ordered pairs

[2, p. 4]. This tool, however, manages to integrate the use of theorem proving with

the SAT solving based analysis of the Alloy Analyzer, cleverly assisting theorem

proving with SAT solving and vice versa. The mechanisms used to combine SAT

solving and theorem proving are independent of the theorem prover used and

the axiomatic characterisation of Alloy. Thus, they could also be employed to

combine the Alloy Analyzer with other approaches to reasoning about Alloy

specifications, such as, for instance, the one presented in this paper.

In a previous paper [6] we presented a semantics for Alloy based on fork

algebras. In that paper, the way in which we assigned semantics to quantification

followed Alloy’s definition, which is not equational. In this paper we present a

complete and equational calculus for reasoning about Alloy assertions, in the

context of Alloy specifications. Moreover, the language of fork algebras is closer

to Alloy than the language used in Prioni because fork algebras talk about

relations at the same level of abstraction that Alloy does.

Structure of the Paper: In Section 2 we present the syntax and semantics of

Alloy, as well as a sample of Alloy specification that will be used in Section 3.4.

In Section 3 we present the main results of the paper. It contains a descrip-

tion of fork algebras, including ways to deal with relations that are not binary.

Page 3

164M.F. Frias, C.G. L´ opez Pombo, and N.M. Aguirre

It presents the translation of Alloy formulas to fork algebra equations, and a

theorem that shows that the translation indeed captures the meaning of Alloy

formulas. The section finishes with an example. Finally, in Section 4, we state

our conclusions about the presented work.

2 Syntax and Semantics of Alloy

In this section we present the syntax and semantics of Alloy’s relational logic as

extracted from [10]. The relational logic is the kernel of Alloy. The language is

then defined by means of extensions of the kernel that can be reduced to rela-

tional logic formulas. Constructs such as ‘Functions’ allow one to define abbrevi-

ations for formulas. ‘Facts’ are axioms constraining the model, and ‘Assertions’

are properties intended to hold that are subject to analysis within the model.

For a careful description of these concepts, the reader is directed to [10]. A good

source of information on Alloy is the paper [9], but the semantics is given in

terms of binary relations unlike the latest version of Alloy [10], where relations

have arbitrary finite ranks. In Fig. 1, we present the grammar and semantics

of Alloy’s relational logic. Composition of binary relations is well understood;

but for relations of higher rank, the following definition for the composition of

relations has to be considered:

R;S = {?a1,...,ai−1,b2,...,bj? :

∃b(?a1,...,ai−1,b? ∈ R ∧ ?b,b2,...,bj? ∈ S)} .

Example 1. Let us consider the following fragment of Alloy specification for

memories, extracted from [10].

sig Addr { }

sig Data { }

These are basic signatures. We do not assume any special properties regarding

the structures of data and addresses.

A possible way of defining memories is by saying that a memory consists of

set of addresses, and a (total) mapping from these addresses to data values:

sig Memory {

addrs: set Addr

map: addrs ->! Data

}

The symbol “!” in the above definition indicates that “map” is functional and

total (for each element a of addrs, there exists exactly one element d in Data

such that map(a) = d).

Alloy allows for the definition of signatures as subsets of the set denoted by

other “parent” signature. This is done via what is called signature extension. For

the example, one could define other (perhaps more complex) kinds of memories

as extensions of the Memory signature:

Page 4

An Equational Calculus for Alloy165

problem ::= decl∗form

decl ::= var : typexpr

typexpr ::=

type

| type → type

| type ⇒ typexpr

form ::=

expr in expr (subset)

|!form (neg)

| form && form (conj)

| form || form (disj)

| all v : type/form (univ)

| some v : type/form (exist)

expr ::=

expr + expr (union)

| expr & expr (intersection)

| expr − expr (difference)

|∼ expr (transpose)

| expr.expr (navigation)

| +expr (closure)

| {v : t/form} (set former)

| V ar

V ar ::=

var (variable)

| V ar[var] (application)

M : form → env → Boolean

X : expr → env → value

env = (var + type) → value

value = (atom × ··· × atom)+

(atom → value)

M[a in b]e = X[a]e ⊆ X[b]e

M[!F]e = ¬M[F]e

M[F&&G]e = M[F]e ∧ M[G]e

M[F || G]e = M[F]e ∨ M[G]e

M[all v : t/F] =

?{M[F](e ⊕ v→{x})/x ∈ e(t)}

M[some v : t/F] =

?{M[F](e ⊕ v→{x})/x ∈ e(t)}

X[a + b]e = X[a]e ∪ X[b]e

X[a&b]e = X[a]e ∩ X[b]e

X[a − b]e = X[a]e \ X[b]e

X[∼ a]e = (X[a]e)˘

X[a.b]e = X[a]e;X[b]e

X[+a]e = the smallest r such that

r;r ⊆ r and X[a]e ⊆ r

X[{v : t/F}]e =

{x ∈ e(t)/M[F](e ⊕ v→{x})}

X[v]e = e(v)

X[a[v]]e = {?y1,...,yn?/

∃x.?x,y1,...,yn? ∈ e(a) ∧ ?x? ∈ e(v)}

Fig.1. Grammar and semantics of Alloy

sig MainMemory extends Memory {}

sig Cache extends Memory {

dirty: set addrs

}

With these definitions, MainMemory and Cache are special kinds of memo-

ries. In caches, a subset of addrs is recognised as dirty.

A system might now be defined to be composed of a main memory and a

cache:

sig System {

cache: Cache

main: MainMemory

}

Page 5

166M.F. Frias, C.G. L´ opez Pombo, and N.M. Aguirre

3A Complete Equational Calculus for Alloy, Based on

Fork Algebras

We begin this section by introducing in Section 3.1 the class of fork algebras.

Fork algebras are closely related to Alloy’s semantics because they provide a

formalism for dealing with (binary) relations. Actually, fork algebras are even

closer to NP [7], a specification language also developed by Jackson and that

later evolved to Alloy. Since fork algebras allow us to deal with binary relations

and Alloy handles relations of arbitrary arity, in Sections 3.2 and 3.3 we show

how to emulate these kinds of relation in fork algebras. Finally, in Section 3.4 we

present the mapping and present a theorem connecting Alloy terms with their

translation. Finally, we present an example illustrating the way the translation

works.

3.1

Fork algebras [4] are described through few equational axioms. The intended

models of these axioms are structures called proper fork algebras, in which the

domain is a set of binary relations (on some base set, let us say B), closed under

the following operations for sets:

– union of two binary relations, denoted by ∪,

– intersection of two binary relations, denoted by ∩,

– complement of a binary relation, denoted, for a binary relation r, by r,

– the empty binary relation, which does not relate any pair of objects, and is

denoted by ∅,

– the universal binary relation, usually B × B, that will be denoted by 1.

Besides the previous operations for sets, the domain has to be closed under

the following operations for binary relations:

– transposition of a binary relation. This operation swaps elements in the pairs

of a binary relation. Given a binary relation r, its transposition is denoted

by ˘ r,

– composition of two binary relations, which, for binary relations r and s is

denoted by r;s,

– reflexive–transitive closure, which, for a binary relation r, is denoted by r∗,

– the identity relation (on B), denoted by Id.

Finally, a binary operation called fork is included, which requires the base set

B to be closed under an injective function ?. This means that there are elements

x in B that are the result of applying the function ? to elements y and z. Since

? is injective, x can be seen as an encoding of the pair ?y,z?. The application of

fork to binary relations R and S is denoted by R∇S, and its definition is given

by:

R∇S = {?a,b ? c? : ?a,b? ∈ R and ?a,c? ∈ S } .

The operation cross (denoted by ⊗) performs a kind of parallel product. Its

set-theoretical definition is given by:

Fork Algebras

R⊗S = {?a ? c,b ? d? : ?a,b? ∈ R ∧ ?c,d? ∈ S } .

Page 6

An Equational Calculus for Alloy167

Once the class of proper fork algebras has been presented, the class of fork

algebras is axiomatized with the following formulas:

1. Your favorite set of equations axiomatizing Boolean algebras. These axioms

define the meaning of union, intersection, complement, the empty set and

the universal relation.

2. Formulas defining composition of binary relations, transposition, reflexive–

transitive closure and the identity relation:

x; (y;z) = (x;y) ;z,

x;Id = Id;x = x,

(x;y) ∩ z = ∅ iff (z;˘ y) ∩ x = ∅ iff (˘ x;z) ∩ y = ∅,

x∗= Id ∪ (x;x∗),

x∗;y;1 ≤ (y;1) ∪?x∗;(y;1 ∩ (x;y;1))?.

3. Formulas defining the operator ∇:

x∇y = (x; (Id∇1)) ∩ (y; (1∇Id)),

(x∇y) ;(w∇z)˘= (x; ˘ w) ∩ (y;˘ z),

(Id∇1)˘∇(1∇Id)˘≤ Id.

The axioms given above define a class of models. Proper fork algebras satisfy

the axioms [5], and therefore belong to this class. It could be the case that there

are models for the axioms that are not proper fork algebras. Fortunately, as was

proved in [5], [4, Thm. 4.2], if a model is not a proper fork algebra then it is

isomorphic to one.

In Section 3.4 we will need to handle fork terms involving variables denoting

relations. Following the definition of the semantics of Alloy, we define a mapping

Y that, given an environment in which these variables get values, homomorphi-

cally allows to calculate the values of terms. The definition is given in Fig. 2.

The set U is the domain of a fork algebra, and therefore a set of binary relations.

Y : expr → env → U

env = (var + type) → U.

Y [∅]e = smallest element in U

Y [1]e = largest element in U

Y [a]e = Y [a]e

Y [a ∪ b]e = Y [a]e ∪ Y [b]e

Y [a ∩ b]e = Y [a]e ∩ Y [b]e

Y [˘ a]e = (Y [a]e)˘

Y [Id]e = Id

Y [a;b]e = Y [a]e;Y [b]e

Y [a∇b]e = Y [a]e∇Y [b]e

Y [a∗]e = (Y [a]e)∗

Y [v]e = e(v)

Fig.2. Semantics of fork terms involving variables

Page 7

168M.F. Frias, C.G. L´ opez Pombo, and N.M. Aguirre

3.2

We will represent sets by binary relations contained in the identity relation.

Thus, for an arbitrary type t and an environment env, env(t) ⊆ Id must

hold. That is, for a given type t, its meaning in an environment env is a binary

relation contained in the identity binary relation. Similarly, for an arbitrary

variable v of type t, env(v) must be a relation of the form {?x,x?}, with

?x,x?

on env(v)1:

Representing Objects and Sets

∈

env(t). This is obtained by imposing the following conditions

env(v) ⊆ env(t),

env(v);1;env(v) = env(v),

env(v) ?= ∅ .

Actually, given binary relations x and y satisfying the properties:

y ⊆ Id,x ⊆ y,x;1;x = x,x ?= ∅,

(1)

it is easy to show that x must be of the form {?a,a?} for some object a. Thus,

given an object a, by a we will also denote the binary relation {?a,a?}. Since y

represents a set, by x : y we assert the fact that x is an object of type y, which

implies that x and y satisfy the formulas in (1).

3.3Representing and Navigating Relations of Higher Rank in

Fork Algebras

In a proper fork algebra the relations π and ρ defined by

π = (1,∇1)˘,

behave as projections with respect to the encoding of pairs induced by the injec-

tive function ?. Their semantics in a proper fork algebra A whose binary relations

range over a set B, is given by

ρ = (1∇1,)˘

π = {?a ? b,a? : a,b ∈ B },

ρ = {?a ? b,b? : a,b ∈ B } .

From the definitions of fork, π and ρ, operation ⊗ is definable as follows:

R⊗S = (π;R)∇(ρ;S) .

Given a n-ary relation R ⊆ A1× ··· × An, we will represent it by the binary

relation

{?a1,a2? ··· ? an? : ?a1,...,an? ∈ R} .

1The proof requires relation 1 to be of the form B × B for some nonempty set B.

Page 8

An Equational Calculus for Alloy169

This will be an invariant in the representation of n-ary relations by binary

ones.

For instance, given an Alloy ternary relation

map ⊆ Memory × addrs × Data,

in our framework it is encoded as a binary relation map whose elements are pairs

of the form ?m,a ? d? for m : Memory, a : Addr and d : Data. We will in general

denote the encoding of a relation C as a binary relation, by C. Given an object

(in the relational sense — cf. 3.2) m : Memory, the navigation of the relation

map through m should result in a binary relation contained in Addr × Data.

Given a relational object a : t and a binary relation R encoding a relation of

rank higher than 2, we define the navigation operation • by

a • R = ˘ π;Ran(a;R) ;ρ .

Operation Ran in (2) returns the range of a relation as a partial identity. It

is defined by

Ran(x) = (x;1) ·1,.

Its semantics in terms of binary relations is given by

(2)

Ran(R) = {?a,a? : ∃b s.t.?b,a? ∈ R} .

If we denote by xRy the fact that x and y are related via the relation R,

then Fig. 3 gives a graphical explanation of operation •.

y

? ?

@ @

˘ π

y

?

z

Ran(xaxR

z

?

y)

z

?

y

? ?

@ @ρ

z

Fig.3. Semantics of •

For a binary relation R representing a relation of rank 2, navigation is easier.

Given a relational object a : t, we define

a • R = Ran(a;R) .

Going back to our example about memories, it is easy to check that for a

relational object m?: Memory such that m?= {?m,m?},

m?• map = {?a,d? : a ∈ Addr,d ∈ Data and ?m,a ? d? ∈ map} .

3.4

It is well known [13, p. 26] that Boolean combinations of relation algebraic

equations can be translated into a single equation of the form R = 1. Since

Translating Alloy Formulas to Fork Algebra Equations

Page 9

170M.F. Frias, C.G. L´ opez Pombo, and N.M. Aguirre

Alloy terms are typed, the translation must be modified slightly. We denote by 1

the untyped universal relation. By 1kwe will denote the universal k-ary relation,

and by Idkwe denote the k-ary identity relation. The transformation, for n-ary

Alloy terms a and b, is:

a in b ? 1n− (a − b) = 1n

For a formula of the form !(a = 1n), we reason as follows:

!(a = 1n) ⇐⇒ !(1n− a = 0) .

Now, from a nonempty n-ary relation, we must generate a universal n-ary

relation. Notice that if 1n− a is nonempty, then 11.(1n− a) is nonempty, and

has arity n − 1. Thus, the term

11.(··· .(11

?

yields a nonempty 1-ary relation. If we post compose it with 12, we obtain

the universal 1-ary relation. If the resulting relation is then composed with the

(n+1)-ary universal relation, we obtain the desired n-ary universal relation. We

then have

???

n−1

.(1n− a))···)

!(a = 1n) ? (11.(··· .(11

? ???

n−1

.(1n− a))···).12).1n+1= 1n.

If we are given a formula of the form

a = 1n&& b = 1m,

with n = m, then the translation is trivial:

a = 1n&& b = 1m? a&b = 1n.

If m > n, we will convert a into a m-ary relation a?such that a?= 1mif and

only if a = 1n. Let a?be defined as

a.Id3.1m−n+1.

Then,

a = 1n&& b = 1m? a?&b = 1m.

Therefore, we will assume that whenever a quantifier occurs in a formula,

it appears being applied to an equation of the form R = 1n, for some n. Since

variables in RL stand for single objects, we will first convert term R into a term

of the form

(IdS1⊗ ··· ⊗IdSk) ⊗R .

Page 10

An Equational Calculus for Alloy171

Intuitively, the term IdS1⊗ ··· ⊗IdSkallows us to pass on the value of the

free variables occurring in R so that the values can be retrieved at any time. If

we define relations Xi(1 ≤ i ≤ k) by

?

ρ;(i−1)

Xi=

ρ;(i−1);π

if 1 ≤ i < k,

if i = k ,

an input a1?···?akis related through term Xito ai. Notice then that the term

Dom(π;Xi ∩ ρ) filters those inputs (a1? ··· ? ak) ? b in which ai?= b (i.e., the

value b is bound to be ai). The translation is defined as follows:

T(C)

T(xi)

T(r+s) = T(r) ∪ T(s),

T(r&s) = T(r) ∩ T(s),

T(r − s) = T(r) ∩ T(s) ∩ ((IdS1⊗ ··· ⊗IdSk) ⊗1),

T(∼ r)

T(+r)= T(r);T(r)∗.

= (IdS1⊗ ··· ⊗IdSk) ⊗C,

= Dom(π;Xi ∩ ρ),

= T(r)˘,

In order to define the translation for navigation r.s and application s[v], we

need to distinguish whether s is a binary relation, or if it has greater arity. The

definition is as follows:

?

T(r) • (T(s); ((Id⊗π)∇(Id⊗ρ)))

?

T(v) • (T(s); ((Id⊗π)∇(Id⊗ρ)))

In case there are no quantified variables, there is no need to carry the values

on, and the translation becomes:

T(r.s) =

T(r) • T(s)if s is binary,

otherwise.

T(s[v]) =

T(v) • T(s)if s is binary,

otherwise.

T(C)

T(r+s) = T(r) ∪ T(s),

T(r&s) = T(r) ∩ T(s),

T(r − s) = T(r) ∩ T(s),

T(∼ r)

T(+r)= T(r);T(r)∗,

T(r.s)= T(r) • T(s),

T(s[r])= T(r) • T(s) .

= C,

= T(r)˘,

It is now easy to prove a theorem establishing the relationship between Alloy

terms and the corresponding translation. Notice that:

– Given a type T, e(T) is a nonempty set.

– Given a variable v, e(v) is a n-ary relation for some n ∈ IN.

Page 11

172M.F. Frias, C.G. L´ opez Pombo, and N.M. Aguirre

We define the environment e?by:

– Given a type T, e?(T) = {?a,a? : a ∈ e(T)}.

– Given a variable v such that e(v) is a n-ary relation,

?

{?a1,a2? ··· ? an? : ?a1,a2,...,an? ∈ e(v)}

Theorem 1 establishes the relationship between the semantics of Alloy terms

and their translation, and allows us to assess that the translation is sound in the

sense that it captures the semantics of Alloy terms. For the theorem we assume

that whenever the transpose operation or the transitive closure occur in a term,

they affect a binary relation. Notice that this is the assumption in [10]. We also

assume that whenever the navigation operation is applied, the argument on the

left-hand side is a unary relation (set). This is because our representation of

relations of arity greater than two makes defining the generalized composition

more complicated than desirable. At the same time, use of navigation in object-

oriented settings usually falls in the situation modeled by us. In order to simplify

notation, we will denote by b?the element b1? ··· ? bm.

Theorem 1. For every Alloy term t such that:

e?(v) =

{?a,a? : a ∈ e(v)}

if n = 1,

otherwise.

1. X[t]e defines a n-ary relation,

2. there are m free variables x1,...,xmin t,

Y [T(t)]e?=

⎧

⎪

⎪

⎪

⎪

⎪

⎪

⎩

⎨

{?b?? a,b?? a? :

a ∈ X[t]e(b ?→ x)?

?a1,...,an? ∈ X[t]e(b ?→ x)?

if n = 1

{?b?? a1,b?? (a2? ··· ? an)? :

if n > 1

Proof. (Sketch of the proof) With the aim of using a shorter notation, the value

(according to the standard semantics) of an Alloy term t in an environment e

will be denoted by e(t) rather than by X[t]e. Similarly, the value of a fork algebra

term t in an environment e?will be denoted by e?(t) rather than by Y [t]e?. The

proof follows by induction on the structure of term t. As a sample we prove it

for the variables, the remaining cases end up being simple applications of the

semantics of the fork algebra operators.

If v is a quantified variable (namely, xi), then e(t) is a unary relation.

e?(T(xi))

= e?(Dom(π;Xi ∩ ρ))

= {?b?? a,b?? a? : a = bi}

= {?b?? a,b?? a? : a ∈ {bi}}

=??b?? a,b?? a? : a ∈?e(b ?→ x)?(xi)?

If v is a variable distinct of x1,...,xm, there are two possibilities.

(by def. T)

(by semantics)

(by set theory)

(by def. e(b ?→ x))

.

Page 12

An Equational Calculus for Alloy173

1. e(v) denotes a unary relation.

2. e(v) denotes a n-ary relation with n > 1.

If e(v) denotes a unary relation,

e?(T(v)) = e?((IdS1⊗ ··· ⊗IdSm) ⊗v)

= (IdS1⊗ ··· ⊗IdSm) ⊗e?(v)

= (IdS1⊗ ··· ⊗IdSm) ⊗ {?a,a? : a ∈ e(v)}

= {?b?? a,b?? a? : a ∈ e(v)}

=??b?? a,b?? a? : a ∈ (e(b ?→ x)))(v)?

If e(v) denotes a n-ary relation (n > 1),

(by def. T)

(by semantics)

(by def. e?)

(by semantics)

(by def. e(b ?→ x))

.

e?(T(v)) = e?((IdS1⊗ ··· ⊗IdSm) ⊗v)

= (IdS1⊗ ··· ⊗IdSm) ⊗e?(v)

= (IdS1⊗ ··· ⊗IdSm) ⊗ {?a1,a2? ··· ? an? : ?a1,...,an? ∈ e(v)}

(by def. T)

(by semantics)

(by def. e?)

= {?b?? a1,b?? (a2? ··· ? an)? : ?a1,...,an? ∈ e(v)} (by semantics)

=??b?? a1,b?? (a2? ··· ? an)? : ?a1,...,an? ∈ (e(b ?→ x)))(v)?

.

(by def. e(b ?→ x))

From the set-theoretical definition of fork and the remaining relational oper-

ators, it follows that2

(x1? ··· ? xn) ? x T(t) (x1? ··· ? xn) ? y

⇐⇒

(x1? ··· ? xn) ? x ? y ∈ ran(Id ∇ T(t);ρ) .

(3)

Now, it only remains to adequately quantify, using relational expressions,

variables x1,...,xn,x,y. We define the relational term ∃xias follows:

∃xi= X1∇ ··· ∇Xi−1∇1S∇Xi+1∇ ··· ∇Xk.

For instance, if k = 3, we have ∃x2= X1∇1S∇X3. This term defines the

binary relation

{?a1? a3,a1? a2? a3? : a2∈ S } .

Notice that the term generates all possible values for variable x2. The term

∃x2;Ran(Id ∇ T(t(x1,x2,x3));ρ) ;1

describes the binary relation

2Given a binary relation R, ran(R) denotes the set {b : ∃a such that ?a,b? ∈ R}.

Page 13

174M.F. Frias, C.G. L´ opez Pombo, and N.M. Aguirre

{?(a1? a3) ? a ? b,c? : (∃a2: S)(?a1? a2? a3) ? a,b? ∈ T(t(x1,x2,x3)) } .

This term allows us to quantify over the right domain. Profiting from the

interdefinability of ∃ and ∀, the term

∃x2;T(t)

allows us to quantify variable x2 universally. We will denote such a term as

∀x2T(t).

Since variables x and y abstract the input and output values for term T(t)

(cf. (3)) and the original equation is of the form T(t) = 1, variables x and y

must be quantified universally.

Example 2. Let us consider the following Alloy assertion, to be understood in

the context of the specification for memories provided in Section 2.

some s : System | s.cache.map in s.main.map .

Once converted to an equation of the form R = 1, assertion (4) becomes

(4)

some s : System | 12− (s.cache.map − s.main.map) = 12.

If we apply translation T to the term on the left-hand side of the equality in

(5), it becomes

(5)

Dom(π;Xs∩ ρ) •

IdS

⊗

cache

•

⎛

⎝

IdS

⊗

map

;

Id⊗π

∇

Id⊗ρ

⎞

⎠∩

⎛

⎝

IdS

⊗

1

⎞

⎠

•

∪ Dom(π;Xs∩ ρ) •

IdS

⊗

main

⎛

⎝

IdS

⊗

map

;

Id⊗π

∇

Id⊗ρ

⎞

⎠.

(6)

Since s is the only variable, Xs= ρ0= Id, and therefore (6) becomes

Dom(π ∩ ρ) •

IdS

⊗

cache

•

⎛

⎝

IdS

⊗

map

;

Id⊗π

∇

Id⊗ρ

⎞

⎠∩

⎛

⎝

IdS

⊗

1

⎞

⎠

⊗

∪ Dom(π ∩ ρ) •

IdS

main

•

⎛

⎝

IdS

⊗

map

;

Id⊗π

∇

Id⊗ρ

⎞

⎠.

(7)

Certainly (7) is harder to read than the equation in (4). This can probably

be improved by adding adequate syntactic sugar to the language. Let us denote

by E the term in (7). Following our recipe, we arrive to the following equation

∃s;∀x∀y(Ran(Id ∇ E;ρ) ;1) = 1 .

(8)

Page 14

An Equational Calculus for Alloy175

4 Conclusions

Even although theorem proving was not considered a critical issue during the

development of Alloy, it has been lately recognized as a significant problem that

deserves to be addressed. The tool Prioni allows one to prove properties from

Alloy specification but at the expense of requiring the user to learn another

language conceptually different of Alloy in order to understand proof steps. Al-

though the language of fork algebras is not the same as Alloy, from a conceptual

viewpoint the language of fork algebras shares common principles with Alloy, as

for instance the fact that objects are relations. This is one of the cornerstones of

Alloy, and is shared by fork algebras but not by the language used in Athena.

References

1. Arkoudas K., Type-ω DPLs, MIT AI Memo 2001-27, 2001.

2. Arkoudas K., Khurshid S., Marinov D. and Rinard M., Integrating Model Check-

ing and Theorem Proving for Relational Reasoning, to appear in Proceedings of

RelMiCS’03.

3. Gregory Dennis, TSAFE: Building a Trusted Computing Base for Air Traffic Con-

trol Software. MIT Masters Thesis, January 2003.

4. Frias M., Fork Algebras in Algebra, Logic and Computer Science, World Scientific

Publishing Co., Series Advances on Logic, 2002.

5. Frias, M. F., Haeberer, A. M. and Veloso, P. A. S., A Finite Axiomatization for

Fork Algebras, Logic Journal of the IGPL, Vol. 5, No. 3, 311–319, 1997.

6. Frias M., L´ opez Pombo C., Baum G., Aguirre N. and Maibaum T., Taking Alloy to

the Movies, in Proceedings of FME’03, Pisa, Italy, 2003, LNCS 2805, pp. 678–697.

7. Jackson D., Nitpick: A checkable specificacion language, in proceedings of Formal

Methods in Software Practice, January 1996.

8. Jackson D., Micromodels of Software: Lightweight Modelling and Analysis with

Alloy, 2002.

9. Jackson D., Alloy: A Lightweight Object Modelling Notation, ACM Transactions

on Software Engineering and Methodology (TOSEM), Volume 11, Issue 2 (April

2002), pp. 256-290.

10. Jackson, D., Shlyakhter, I., and Sridharan, M., A Micromodularity Mechanism.

Proc. ACM SIGSOFT Conf. Foundations of Software Engineering/European Soft-

ware Engineering Conference (FSE/ESEC ’01), Vienna, September 2001.

11. Maddux R., Pair-Dense Relation Algebras, Transactions of the American Mathe-

matical Society, Vol. 328, N. 1, 1991.

12. Andrew Rae, Prasad Ramanan, Daniel Jackson, and Jay Flanz. Critical feature

analysis of a radiotherapy machine. International Conference of Computer Safety,

Reliability and Security (SAFECOMP 2003), Edinburgh, September 2003.

13. Tarski, A. and Givant, S.,A Formalization of Set Theory without Variables, A.M.S.

Coll. Pub., vol. 41, 1987.

#### View other sources

#### Hide other sources

- Available from Marcelo F. Frias · Jun 3, 2014
- Available from citeseerx.ist.psu.edu