: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 25.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 26.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 27.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 28.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 29.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 30.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 31.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 32.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 33.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 34.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 25.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 26.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 27.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 28.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 29.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 30.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 31.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 32.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 33.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 34.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 25.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 26.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 27.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 28.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 29.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 30.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 31.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 32.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 33.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 34.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 25.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 26.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 27.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 28.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 29.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 30.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 31.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 32.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 33.
: Function ereg_replace() is deprecated in /afs/csail.mit.edu/proj/alloy/www/data/community/sites/all/themes/Aeon5/advforum/forum-thread.tpl.php on line 34.
Checking Z - Refinements using Alloy RC-10 (Problem with Init)
Checking Z - Refinements using Alloy RC-10 (Problem with Init)
Date: Tue, 24 Jul 2007 20:13:58 -0000
From: Christian Estler
Hello, I'm trying to prove a Downward Simulation for an abstract
and a conrete Z specifiaction using Alloy RC-10.
The idea is to have a "lamp" that can be switch on or off, depending
on the actual status of the lamp.
In the abstract model, the status value is given as "on" or "off". In
the concrete model it is given as a boolean value.
Initially, the lamp is "off" and "false", respectively.
As Init is handled as an operation in Z, I'm also trying to implement
it as one in Alloy. My actual translation is:
--------------------
-- Abstract Model --
--------------------
abstract sig Status {}
one sig ON, OFF extends Status {}
sig Lamp_abs {
status: Status
}
pred Init_abs [l: Lamp_abs] {
l.status in OFF
}
pred Switch_abs [l, l': Lamp_abs] {
l.status in ON => l'.status in OFF
l.status in OFF => l'.status in ON
}
For the concrete model I'm using the moduel boolean which comes with Alloy.
-------------------
-- Conrete Model --
-------------------
open util/boolean as B
sig Lamp_con {
active: B/Bool
}
pred Init_con [l: Lamp_con] {
l.active = B/False
}
pred Switch_con [l, l': Lamp_con] {
l'.active = B/Not[l.active]
}
Furthermore, I have to define a "Retrieve Relation" between the
abstract and the concrete model.
pred R[la: Lamp_abs, lc: Lamp_con] {
(la.status in ON) <=> B/isTrue[lc.active]
(la.status in OFF) <=> B/isFalse[lc.active]
}
To prove that C is a downward simulation of A, I have to prove (among
other things) that: "for all CState' such that CInit => there exists
AState' such that AInit and R'".
Or written in Tex-Notation using the OZ style: "\forall CState' @
CInit \implies \exsits AState' @ AInit \land R'" where @ denotes the
bullet.
Intuitively I worte an Alloy assertion like this one:
assert init {
all c: Lamp_con |
Init_con[c] => (some a: Lamp_abs | Init_abs[a] and R[a, c])
}
Checking the assertion always produces a counterexample which can be
reduced to the situation that Alloy finds an instance such that
Lamp_con.active maps to B/False while Lamp_abs.staus maps to ON.
For my own understandig, I want to know, why Alloy produces such a
counterexample. Am I right that Alloy checks all possible instances of
the model and because there are valid models where (one or more)
Lamp_abs map to ON while Lamp_con maps to B/False the assertion fails?
How do I have to rewirte the assertion to correctly express the Z-formula?
Or maybe my modeling approach is just not adequate?
Date: Tue, 24 Jul 2007 18:15:07 -0400
From: Daniel Jackson
You've hit a subtle issue of Alloy semantics. See Section 5.3 on p. 155 of
my book on "Unbounded universal quantifiers". In short, the problem is that
all quantifiers in Alloy are bounded by definition, and your assertion
requires an unbounded quantifier.
In this case, the fix is straightforward. Since the retrieve relation is a
function, you can write the assertion in this form instead:
all c: C | init_cons [c] => init_abs [ r[c] ]
To rewrite the relation as a function, you could just use a set
comprehension. Try something like this to convert your relation to a
function:
fun r [la: Lamp_abs] : Lamp_con {
{lc: Lamp_con | R[a,c]}
}
Section 6.4 in my book shows examples of refinement checks done in this style.
BTW, you don't need to qualify imported names if they're unambiguous, so you
can write Bool instead of B/Bool, etc.
Date: Sat, 28 Jul 2007 17:10:51 -0000
From: Christian Estler
Thanks to you for your help. I applied your "workaround" to
my model and it works fine. Unfortunatley I wasn't able to read
the chapters in your book yet, but I'll hopefully get it the
next week (so I'm sorry if my question is already covered
in one of those chapters).
Is there also a smooth way to proof the "Init-Condition" of a refinement,
if the Retrieve Relation ist not a function?
It seems to me, in that case, there's no chance to get rid of an
unbounded quantifier. I played around with a small model (appended),
but nothing worked out.
----------------
-- test model --
----------------
open util/boolean as B
abstract sig Value {}
one sig ONE, TWO, THREE extends Value {}
sig AState {
v: Value
}
pred AInit [a: AState] {
a.v in ONE
}
sig CState {
b: Bool
}
pred CInit [c: CState] {
c.b in False
}
pred R [a: AState, c: CState] {
c.b in False <=> a.v in ONE || a.v in TWO
c.b in True <=> a.v in THREE
}
fun Rfun[c: CState]: AState{
{a: AState | R[a, c]}
}
check {
all c: CState | CInit[c] => AInit[Rfun[c]]
} for 4 but exactly 1 CState, exactly 1 AState
Date: Sat, 28 Jul 2007 21:33:37 -0400
From: Daniel Jackson
> Is there also a smooth way to proof the "Init-Condition" of a
> refinement, if the Retrieve Relation ist not a function?
You'll probably need to provide a function that gives the "witness"
producing the appropriate abstract value for the retrieve relation. Tahina
Ramananandro did this in (at least one of the versions of)
his Mondex model; see
From: Daniel Jackson
You've hit a subtle issue of Alloy semantics. See Section 5.3 on p. 155 of
my book on "Unbounded universal quantifiers". In short, the problem is that
all quantifiers in Alloy are bounded by definition, and your assertion
requires an unbounded quantifier.
In this case, the fix is straightforward. Since the retrieve relation is a
function, you can write the assertion in this form instead:
all c: C | init_cons [c] => init_abs [ r[c] ]
To rewrite the relation as a function, you could just use a set
comprehension. Try something like this to convert your relation to a
function:
fun r [la: Lamp_abs] : Lamp_con {
{lc: Lamp_con | R[a,c]}
}
Section 6.4 in my book shows examples of refinement checks done in this style.
BTW, you don't need to qualify imported names if they're unambiguous, so you
can write Bool instead of B/Bool, etc.
From: Christian Estler
Thanks to you for your help. I applied your "workaround" to
my model and it works fine. Unfortunatley I wasn't able to read
the chapters in your book yet, but I'll hopefully get it the
next week (so I'm sorry if my question is already covered
in one of those chapters).
Is there also a smooth way to proof the "Init-Condition" of a refinement,
if the Retrieve Relation ist not a function?
It seems to me, in that case, there's no chance to get rid of an
unbounded quantifier. I played around with a small model (appended),
but nothing worked out.
----------------
-- test model --
----------------
open util/boolean as B
abstract sig Value {}
one sig ONE, TWO, THREE extends Value {}
sig AState {
v: Value
}
pred AInit [a: AState] {
a.v in ONE
}
sig CState {
b: Bool
}
pred CInit [c: CState] {
c.b in False
}
pred R [a: AState, c: CState] {
c.b in False <=> a.v in ONE || a.v in TWO
c.b in True <=> a.v in THREE
}
fun Rfun[c: CState]: AState{
{a: AState | R[a, c]}
}
check {
all c: CState | CInit[c] => AInit[Rfun[c]]
} for 4 but exactly 1 CState, exactly 1 AState
From: Daniel Jackson
> Is there also a smooth way to proof the "Init-Condition" of a
> refinement, if the Retrieve Relation ist not a function?
You'll probably need to provide a function that gives the "witness"
producing the appropriate abstract value for the retrieve relation. Tahina
Ramananandro did this in (at least one of the versions of)
his Mondex model; see
http://www.eleves.ens.fr/home/ramanana/work/mondex/
In general, you don't need the retrieve relation to be non-functional --
you can always do it with a function, by adding history/prophecy variables.