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

An Equational Calculus for Alloy

Marcelo F. Frias

,1

, Carlos G. L´opez Pombo

2

, and Nazareno M. Aguirre

3

1

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

University of Buenos Aires, Argentina, and CONICET

{mfrias,clpombo}@dc.uba.ar

2

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

University of Buenos Aires, Argentina

3

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

1 Introduction

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 ﬁnd

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 speciﬁcations using SAT solving [9, 10], not much

research has been done so far on the analysis of Alloy speciﬁcations using theorem

proving. In order to prove Alloy assertions from Alloy speciﬁcations, in this paper

we propose the following procedure:

1. Translate both the assertions and the speciﬁcation 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 speciﬁcation.

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

An Equational Calculus for Alloy 163

Relevance to Formal Engineering Methods: The Alloy modeling language and

the Alloy Analyzer are being applied in domains such as air traﬃc control [3]

or veriﬁcation 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 oﬀer.

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 speciﬁc work that has already been done on the-

orem proving from Alloy speciﬁcations. Prioni [2] is a tool that combines the

model checking capabilities oﬀered 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 speciﬁcations, 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

speciﬁcations, 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 quantiﬁcation

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

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

context of Alloy speciﬁcations. 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 speciﬁcation 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.

164 M.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 ﬁnishes 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 deﬁned by means of extensions of the kernel that can be reduced to rela-

tional logic formulas. Constructs such as ‘Functions’ allow one to deﬁne 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 ﬁnite 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 deﬁnition for the composition of

relations has to be considered:

R;S = {a

1

,...,a

i−1

,b

2

,...,b

j

:

∃b (a

1

,...,a

i−1

,b∈R ∧b, b

2

,...,b

j

∈S)} .

Example 1. Let us consider the following fragment of Alloy speciﬁcation 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 deﬁning 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 deﬁnition 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 deﬁnition 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 deﬁne other (perhaps more complex) kinds of memories

as extensions of the Memory signature:

An Equational Calculus for Alloy 165

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 (diﬀerence)

|∼ expr (transpose)

| expr.expr (navigation)

| +expr (closure)

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

| Var

Var::=

var (variable)

| Var[var] (application)

M : form → env → Boolean

X :expr→ env → value

env =(var + type) → value

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

(atom → value

)

M[ainb]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 = {y

1

,...,y

n

/

∃x. x, y

1

,...,y

n

∈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 deﬁnitions, MainMemory and Cache are special kinds of memo-

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

A system might now be deﬁned to be composed of a main memory and a

cache:

sig System {

cache: Cache

main: MainMemory

}

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

3 A 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 speciﬁcation 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

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,

– reﬂexive–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 deﬁnition 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 deﬁnition is given by:

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

An Equational Calculus for Alloy 167

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

deﬁne the meaning of union, intersection, complement, the empty set and

the universal relation.

2. Formulas deﬁning composition of binary relations, transposition, reﬂexive–

transitive closure and the identity relation:

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

x;Id = Id;x = x,

(x;y) ∩ z = ∅ iﬀ (z ;˘y) ∩ x = ∅ iﬀ (˘x;z) ∩ y = ∅,

x

∗

= Id ∪ (x;x

∗

) ,

x

∗

;y;1 ≤ (y ;1) ∪

x

∗

;(y ;1 ∩ (x;y ;1))

.

3. Formulas deﬁning 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 deﬁne 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 deﬁnition of the semantics of Alloy, we deﬁne a mapping

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

cally allows to calculate the values of terms. The deﬁnition 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

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

3.2 Representing Objects and Sets

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∈env(t). This is obtained by imposing the following conditions

on env(v)

1

:

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,bya 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.3 Representing and Navigating Relations of Higher Rank in

Fork Algebras

In a proper fork algebra the relations π and ρ deﬁned by

π =(1

,

∇1)˘,ρ=(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

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

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

From the deﬁnitions of fork, π and ρ, operation ⊗ is deﬁnable as follows:

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

Given a n-ary relation R ⊆ A

1

×···×A

n

, we will represent it by the binary

relation

{a

1

,a

2

···a

n

: a

1

,...,a

n

∈R } .

1

The proof requires relation 1 to be of the form B × B forsomenonemptysetB.

An Equational Calculus for Alloy 169

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 deﬁne the navigation operation • by

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

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

is deﬁned by

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

,

.

Its semantics in terms of binary relations is given by

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

.

If we denote by x

R

y 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

(

x

a

x

R

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 deﬁne

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 Translating Alloy Formulas to Fork Algebra Equations

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

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

Alloy terms are typed, the translation must be modiﬁed slightly. We denote by 1

the untyped universal relation. By 1

k

we will denote the universal k-ary relation,

and by Id

k

we denote the k-ary identity relation. The transformation, for n-ary

Alloy terms a and b,is:

a in b 1

n

− (a − b)=1

n

For a formula of the form !(a =1

n

), we reason as follows:

!(a =1

n

) ⇐⇒ !(1

n

− a =0).

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

relation. Notice that if 1

n

− a is nonempty, then 1

1

.(1

n

− a) is nonempty, and

has arity n − 1. Thus, the term

1

1

.(··· .(1

1

n−1

.(1

n

− a)) ···)

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

2

, 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

!(a =1

n

) (1

1

.(··· .(1

1

n−1

.(1

n

− a)) ···).1

2

).1

n+1

=1

n

.

If we are given a formula of the form

a =1

n

&& b =1

m

,

with n = m, then the translation is trivial:

a =1

n

&& b =1

m

a&b =1

n

.

If m>n, we will convert a into a m-ary relation a

such that a

=1

m

if and

only if a =1

n

.Leta

be deﬁned as

a.Id

3

.1

m−n+1

.

Then,

a =1

n

&& b =1

m

a

&b =1

m

.

Therefore, we will assume that whenever a quantiﬁer occurs in a formula,

it appears being applied to an equation of the form R =1

n

, for some n. Since

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

of the form

(Id

S

1

⊗···⊗Id

S

k

) ⊗R.

An Equational Calculus for Alloy 171

Intuitively, the term Id

S

1

⊗···⊗Id

S

k

allows 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 deﬁne relations X

i

(1 ≤ i ≤ k)by

X

i

=

ρ

;(i−1)

;π if 1 ≤ i<k,

ρ

;(i−1)

if i = k,

an input a

1

···a

k

is related through term X

i

to a

i

. Notice then that the term

Dom (π ;X

i

∩ ρ) ﬁlters those inputs (a

1

···a

k

) b in which a

i

= b (i.e., the

value b is bound to be a

i

). The translation is deﬁned as follows:

T (C)=(Id

S

1

⊗···⊗Id

S

k

) ⊗C,

T (x

i

)=Dom (π ;X

i

∩ ρ) ,

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

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

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

T (s) ∩ ((Id

S

1

⊗···⊗Id

S

k

) ⊗1) ,

T (∼ r)=T (r)˘,

T (+r)=T (r);T (r)

∗

.

In order to deﬁne 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

deﬁnition is as follows:

T (r.s)=

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

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

T (s[v]) =

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

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

In case there are no quantiﬁed variables, there is no need to carry the values

on, and the translation becomes:

T (C)=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)

∗

,

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

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

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)isan-ary relation for some n ∈ IN .

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

We deﬁne the environment e

by:

– Given a type T , e

(T )={a, a : a ∈ e(T ) }.

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

e

(v)=

{a, a : a ∈ e(v) } if n =1,

{a

1

,a

2

···a

n

: a

1

,a

2

,...,a

n

∈e(v)} otherwise.

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 aﬀect 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 deﬁning 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 b

1

···b

m

.

Theorem 1. For every Alloy term t such that:

1. X[t]e deﬁnes a n-ary relation,

2. there are m free variables x

1

,...,x

m

in t,

Y [T (t)]e

=

⎧

⎪

⎪

⎪

⎨

⎪

⎪

⎪

⎩

{b

a,b

a :

a ∈ X[t]e(

b → x)

if n =1

{b

a

1

,b

(a

2

···a

n

) :

a

1

,...,a

n

∈X[t]e(b → x)

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 quantiﬁed variable (namely, x

i

), then e(t) is a unary relation.

e

(T (x

i

))

= e

(Dom (π ;X

i

∩ ρ)) (by def. T )

= {b

a,b

a : a = b

i

} (by semantics)

= {b

a,b

a : a ∈{b

i

}} (by set theory)

=

b

a,b

a : a ∈

e(b → x)

(x

i

)

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

If v is a variable distinct of x

1

,...,x

m

, there are two possibilities.

An Equational Calculus for Alloy 173

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

((Id

S

1

⊗···⊗Id

S

m

) ⊗v) (by def. T )

=(Id

S

1

⊗···⊗Id

S

m

) ⊗e

(v) (by semantics)

=(Id

S

1

⊗···⊗Id

S

m

) ⊗{a, a : a ∈ e(v) } (by def. e

)

= {b

a,b

a : a ∈ e(v) } (by semantics)

=

b

a,b

a : a ∈ (e(b → x)))(v)

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

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

e

(T (v)) = e

((Id

S

1

⊗···⊗Id

S

m

) ⊗v) (by def. T )

=(Id

S

1

⊗···⊗Id

S

m

) ⊗e

(v) (by semantics)

=(Id

S

1

⊗···⊗Id

S

m

) ⊗{a

1

,a

2

···a

n

: a

1

,...,a

n

∈e(v) }

(by def. e

)

= {b

a

1

,b

(a

2

···a

n

) : a

1

,...,a

n

∈e(v) } (by semantics)

=

b

a

1

,b

(a

2

···a

n

) : a

1

,...,a

n

∈(e(b → x)))(v)

.

(by def. e(

b → x))

From the set-theoretical deﬁnition of fork and the remaining relational oper-

ators, it follows that

2

(x

1

···x

n

) xT(t)(x

1

···x

n

) y ⇐⇒

(x

1

···x

n

) xy∈ ran (Id ∇ T (t);ρ) . (3)

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

variables x

1

,...,x

n

,x,y. We deﬁne the relational term ∃

x

i

as follows:

∃

x

i

= X

1

∇···∇X

i−1

∇1

S

∇X

i+1

∇···∇X

k

.

For instance, if k =3,wehave∃

x

2

= X

1

∇1

S

∇X

3

. This term deﬁnes the

binary relation

{a

1

a

3

,a

1

a

2

a

3

: a

2

∈ S } .

Notice that the term generates all possible values for variable x

2

.Theterm

∃

x

2

;Ran (Id ∇ T (t(x

1

,x

2

,x

3

));ρ);1

describes the binary relation

2

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

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

{(a

1

a

3

) ab,c :(∃a

2

: S)(a

1

a

2

a

3

) a,b∈ T (t(x

1

,x

2

,x

3

)) } .

This term allows us to quantify over the right domain. Proﬁting from the

interdeﬁnability of ∃ and ∀,theterm

∃

x

2

;T (t)

allows us to quantify variable x

2

universally. We will denote such a term as

∀

x

2

T (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 quantiﬁed universally.

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

the context of the speciﬁcation for memories provided in Section 2.

some s : System | s.cache.map in s.main.map . (4)

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

some s : System | 1

2

− (s.cache.map − s.main.map) = 1

2

. (5)

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

(5), it becomes

Dom (π ;X

s

∩ ρ) •

Id

S

⊗

cache

•

⎛

⎝

Id

S

⊗

map

;

Id⊗π

∇

Id⊗ρ

⎞

⎠

∩

⎛

⎝

Id

S

⊗

1

⎞

⎠

∪ Dom (π;X

s

∩ ρ) •

Id

S

⊗

main

•

⎛

⎝

Id

S

⊗

map

;

Id⊗π

∇

Id⊗ρ

⎞

⎠

. (6)

Since s is the only variable, X

s

= ρ

0

= Id, and therefore (6) becomes

Dom (π ∩ ρ) •

Id

S

⊗

cache

•

⎛

⎝

Id

S

⊗

map

;

Id⊗π

∇

Id⊗ρ

⎞

⎠

∩

⎛

⎝

Id

S

⊗

1

⎞

⎠

∪ Dom (π ∩ ρ) •

Id

S

⊗

main

•

⎛

⎝

Id

S

⊗

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)

An Equational Calculus for Alloy 175

4 Conclusions

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

development of Alloy, it has been lately recognized as a signiﬁcant problem that

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

Alloy speciﬁcation but at the expense of requiring the user to learn another

language conceptually diﬀerent 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 Traﬃc Con-

trol Software. MIT Masters Thesis, January 2003.

4. Frias M., Fork Algebras in Algebra, Logic and Computer Science, World Scientiﬁc

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 speciﬁcacion 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.

- CitationsCitations15
- ReferencesReferences19

- "In Alloy, relational algebra relies on relations between signatures (i.e. the atoms of the algebra). To simplify, a signature can be seen as an abstract data type with relations [8] with other signatures. "

[Show abstract] [Hide abstract]**ABSTRACT:**Model transformations are usually difficult to automate as they require to transform graphs into other graphs while the result must respect a set of predefined constraints. In previous works, we described how to compose competing model transformations addressing the same objective with different non-functional results. In this paper, we focus on the composition of complementary transformations addressing different needs. In particular, the order in which model transformations are applied must be determined when they are not commutative. However, preconditions and post conditions must still be valid and the evaluation of chains alternatives can be time consuming. We propose to solve this problem by abstracting models, transformations, and chaining process with a formal logic in order to fasten the discovery of valid transformation chains. Our solution first translates model transformations as Alloy constrained binary relations between input and output models and second exhibits a valid chain of transformations.- "Once the translation of terms has been presented, we introduce the translation from Alloy formulas to PDOCFA formulas. The translation differs from the one presented in [Frias et al. 2004] in that the target of the translation is a first-order language rather than an equational language, and therefore it is no longer necessary to encode quantified variables because they are kept explicit. This will greatly improve the readability of the translated formulas by Alloy users. "

[Show abstract] [Hide abstract]**ABSTRACT:**Automatic analysis of Alloy models is supported by the Alloy Analyzer, a tool that translates an Alloy model to a propositional formula that is then analyzed using off-the-shelf SAT solvers. The translation requires user-provided bounds on the sizes of data domains. The analysis is limited by the bounds and is therefore partial. Thus, the Alloy Analyzer may not be appropriate for the analysis of critical applications where more conclusive results are necessary. Dynamite is an extension of PVS that embeds a complete calculus for Alloy. It also includes extensions to PVS that allow one to improve the proof effort by, for instance, automatically analyzing new hypotheses with the aid of the Alloy Analyzer. Since PVS sequents may get cluttered with unnecessary formulas, we use the Alloy unsat-core extraction feature in order to refine proof sequents. An internalization of Alloy's syntax as an Alloy specification allows us to use the Alloy Analyzer for producing witnesses for proving existentially quantified formulas. Dynamite complements the partial automatic analysis offered by the Alloy Analyzer with semi-automatic verification through theorem proving. It also improves the theorem proving experience by using the Alloy Analyzer for early error detection, sequent refinement, and witness generation.- "The formal background of Dynamite can be found in [4] and [3], where it is proved that there exists a semantic preserving translation of the Alloy specification language to theories in an extension of fork algebras [2] 3 . The class of algebraic structures considered for interpreting Alloy is the class of point-dense omega closure fork algebras (PDOCFA). "

[Show abstract] [Hide abstract]**ABSTRACT:**Nowadays, software artifacts are ubiquitous in our lives being an essential part of home appliances, cars, cell phones, and even in more critical activities like aeronautics and health sciences. In this context software failures may produce enormous losses, either economical or, in the worst case, in human lives. Software analysis is an area in software engineering concerned with the application of diverse techniques in order to prove the absence of errors in software pieces. In many cases different analysis techniques are applied by following specific methodological combinations that ensure better results. These interactions between tools are usually carried out at the user level and it is not supported by the tools. In this work we present HeteroGenius, a framework conceived to develop tools that allow users to perform hybrid analysis of heterogeneous software specifications. HeteroGenius was designed prioritising the possibility of adding new specification languages and analysis tools and enabling a synergic relation of the techniques under a graphical interface satisfying several well-known usability enhancement criteria. As a case-study we implemented the functionality of Dynamite on top of HeteroGenius.

Data provided are for informational purposes only. Although carefully collected, accuracy cannot be guaranteed. The impact factor represents a rough estimation of the journal's impact factor and does not reflect the actual current impact factor. Publisher conditions are provided by RoMEO. Differing provisions from the publisher's actual policy or licence agreement may be applicable.

We could not find any SHERPA/RoMEO information. Please check the publication restrictions.

Learn more