# An Equational Calculus for Alloy

Conference Paper (PDF Available) · November 2004with8 Reads
DOI: 10.1007/978-3-540-30482-1_19 · Source: DBLP
Conference: Formal Methods and Software Engineering, 6th International Conference on Formal Engineering Methods, ICFEM 2004, Seattle, WA, USA, November 8-12, 2004, Proceedings
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-
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
i1
,b
2
,...,b
j
:
b (a
1
,...,a
i1
,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 {
}
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 (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 {
}
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 RS, and its deﬁnition is given
by:
RS = {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:
RS = {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 :
xy =(x;(Id1)) (y ;(1Id)) ,
(xy);(wz = (xw) (y z) ,
(Id1)˘(1Id 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 [ab]e = Y [a]eY [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)˘=(11
,
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
π = {ab,a : a, b B } ,
ρ = {ab,b : a, b B } .
From the deﬁnitions of fork, π and ρ, operation is deﬁnable as follows:
RS =(π ;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

n1
.(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

n1
.(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
mn+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
=
ρ
;(i1)
;π if 1 i<k,
ρ
;(i1)
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
) xy 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
i1
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
) ab,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., 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.
• ##### Automatic Production of Transformation Chains Using Structural Constraints on Output Models
• "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.
Full-text · Conference Paper · Aug 2014 · ACM Transactions on Software Engineering and Methodology
+1more author...[...]
• ##### Dynamite: A Tool for the Verification of Alloy Models Based on PVS
• "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.
Full-text · Article · Mar 2014
• ##### HeteroGenius: A Framework for Hybrid Analysis of Heterogeneous Software Specifications
• "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.
Full-text · Article · Jan 2014