Extending Alloy with Partial Instances.

Extending Alloy with Partial Instances

Vajih Montaghami

Derek Rayside

iFM & ABZ 2012

Extending Alloy with Partial Instances V. Montaghami; D. Rayside;

MotivationAlloy’s main deficiency as a general-purpose problem description language is its lack of support for partial instances.

2

E. Torlak & D. Jackson 2007Kodkod: A relational model finder

• Torlak & Jackson added partial instance capability to the Alloy backend (Kodkod)

• But they did not extend the Alloy surface syntax to support this new feature


Linked List Example

3

sig Node{ next: lone Node, val: one Int}

inst simple { −− introduce three atomsNode = head + middle + tail, −− exact bound for next relationnext = head→middle + middle→tail, −− exact bound for val relationval = head→0 + middle→1 + tail→2 }Pa

rtia

l Ins

tanc

e Bl

ock


Linked List Example

4

sig Node{ next: lone Node, val: one Int}

inst single{ Node=n, no next, val=n→0}

inst cyclic{ Node=a+b, next=a→b+b→a, val=a→0+b→1}


Syntax by Exampleinst i { 4, Node = n + m, next includes n→m, val in n→0 + m→1}{

not m.next = m}

run {} for i

5

-- default sig size-- exact bound for sig-- lower bound for relation-- upper bound for relation-- appended fact-- access to atoms


Syntax

6

Clafer [1] is a language that is designed to support combined modelling andmeta-modelling.

3 Language Extension

We propose to add an inst block to the Alloy language, allowing the user tospecify a partial instance, as illustrated above in Figures 1, 2, 3, and 4. Thepartial instances in those examples only use exact bounds; Kodkod and oursyntax also support lower and upper bounds as well, using the in and includeskeywords, respectively. Lower bound is a set of tuples that a relation must have,and upper bound is the one that realation might have [9].

These inst blocks are given names and used in Alloy commands. Whereasnow a user might write run p for 3, they will now write run p for i, indicatingthat predicate p is to be simulated in the context of partial instance i.

An inst block, like a sig block, may have an appended fact. For inst blocks,the appended fact is only expected to be true when that inst block is part ofthe command being executed. The purpose of this appended fact is to givethe specifier an opportunity to write constraints that mention the atom namesintroduced in the inst block — these names are not available elsewhere in themodel.

Fig. 5 Grammar and preliminary type definitions(a) Grammar

⌅iBlk⇧ := ‘inst’ id (‘extends’ id)? ‘{’ ⌅iSt⇧[,⌅iSt⇧]* ‘}’(‘{’ ⌅frml⇧ ‘}’)?

⌅iSt⇧ := ⌅n⇧| ‘exactly’ ⌅n⇧ ⌅var⇧| ⌅var⇧ ‘=’ ⌅iXpr⇧| ⌅var⇧ ‘in’ ⌅iXpr⇧| ⌅var⇧ ‘include’ ⌅iXpr⇧| ⌅var⇧ ‘include’ ⌅iXpr⇧ ‘moreover’ ⌅iXpr⇧| ‘no’ ⌅var⇧

⌅iXpr⇧ := ⌅iXpr⇧ ‘->’ ⌅iXpr⇧| ⌅iXpr⇧ ‘+’ ⌅iXpr⇧| ‘(’ ⌅iXpr⇧ ‘)’| ⌅atm⇧

(b) Preliminary type definitions

⌅prb⇧ := ⌅univ⇧ ⌅iSt⇧* ⌅frml⇧*⌅univ⇧ := {⌅atm⇧[,⌅atm⇧]*}⌅tpl⇧ := ⌅atm[,atm]* ⇧⌅cnst⇧ := {tpl[,tpl]*} | {} [�{}]*⌅var⇧ := id

⌅atm⇧ := id

⌅sig⇧ := ⌅var⇧⌅sigs⇧ := ⌅sig⇧*⌅n⇧ := int

Figure 5a lists the grammar for our proposed extension to the Alloy languageto support partial instances. An iBk has a name, a list of iSts and optionally anappended fact. Each iSt alternative that contains a var bounds either a signatureor a field (whichever is named by the var). The one iSt alternative that does notname a var provides the default number of atoms for each signature. A relation(signature or field) name can only appear on the left-hand side of at most oneiSt in each iBk.

An iSt that names a signature on its left-hand side introduces atom names onits right-hand side. These atom names can then be used to describe the boundson fields. An iXpr is an expression that describes a set of tuples using the normal

6

upper and lower bounds


Universe Construction

1. Default number for all sigs

2. Exactly number for specified sigs

3. Upper (in), lower (includes), and exact (=) bounds for specified sigs

7

Note: each entity name may occur on the LHS of at most one statement in an inst block.


File System Examplesig File{}sig Dir{contents: set (Dir+File)}

pred fileSystem[root:Dir]{ (File+Dir) in root.*contents --isReachable all d: Dir | not (d in d.^contents) --isAcyclic all d: (Dir+File) | #(d.~contents)<2 --One parent}

inst i{ File in f0+f1+f2, --upperbound Dir = root+d0+d1, --exactbound contents include root→d0 --lowerbound}{ some d:Dir | d=root and fileSystem[d]}run {} for i

8


Partial Instances in A4.2By Fact• If inference succeeds:

• Kodkod bounds• performs well

• If inference fails:• SAT constraints• performs poorly

• Non-modular

9

By Constant Function

• Inlined as a constant expression

• Performs well

• Exact bounds only

• Non-modular

Only possible to express one partial instance


Explicit Partial Instances

1. Expressive

• exact, upper, and lower bounds

2. Modular

• different instances for different analyses

3. Performant

• translated as Kodkod bounds

10


Performance Evaluation

• New syntax improves performance.

• Experiments:

• Micro-benchmark

• Refactored a working model

11


Micro-benchmarking

12

one sig S0,S1 extends S{}fact {r=S0→S1+S1→S0}pred f[]{all s:S|S in s.^r}run f

By fact

sig S {r:S}


Micro-benchmarking

13

one sig S0,S1 extends S{}fact {r=S0→S1+S1→S0}pred f[]{all s:S|S in s.^r}run f

By fact

By const-Funsig S {r:S}

sig S {/* r:S*/}one sig S0,S1 extends S{}fun r[]:S→S {S0→S1+S1→S0}pred f[]{all s:S|S in s.^r}run f


Micro-benchmarkingone sig S0,S1 extends S{}fact {r=S0→S1+S1→S0}pred f[]{all s:S|S in s.^r}run f

one sig S0,S1 extends S{}fun r[]:S→S {S0→S1+S1→S0}pred f[]{all s:S|S in s.^r}run f

inst i {S=S0+S1,r=S0→S1+S1→S0}

pred f[]{all s:S|S in s.^r}run f

By fact

By inst-Block

By const-Fun

14

sig S {r:S}

sig S {/* r:S*/}


No SAT Variables

S0,..,S74 extends S{}r=S0->S1+...+S73->S74

15

0

2

4

6

8

10

10 20 30 40 50 60 70

Gen

erat

ed V

aria

bles

By

SAT-

solv

er

Number of Sigs

factfuninst

All approaches produce CNFs with zero variables. This is expected in the function and inst block cases. It occurs in the fact case because Alloy’s bound inference succeeded.


Time Comparison

Kodkod Translation Time

SAT Solving Time

16

0

100

200

300

400

500

600

700

800

10 20 30 40 50 60 70

Tran

slat

ion

Tim

e (m

s) B

y Ko

dkod

Number of Sigs

factfuninst

0

200

400

600

800

1000

1200

1400

10 20 30 40 50 60 70

Solv

ing

Tim

e (m

s) B

y SA

T-so

lver

Number of Sigs

factfuninst

fact fun inst


Refactoring a real model

1.1x slower

4x faster

17

Model based on Z spec by Y. Cai & K. Sullivan

A4.2’fact

A4.2iinst

SAT Variables 59,953 59,664

SAT Clauses 162,417 162,642

KK Translation Time (ms) 11,188 12,742

SAT Solving Time (ms) 27,730 6,744 as expected


Conclusion

The Beta Version: https://ece.uwaterloo.ca/~vmontagh/alloy/

18

1. Expressive

• Exact, upper, and lower bounds

2. Modular

• Instances × analyses

3. Performant

• Translated as Kodkod bounds

4. Use-cases (in paper):

• Test-Driven Development

• Regression Testing

• Modelling by Example

• Combined Modelling and Meta-Modelling

Explicit partial instances

https://ece.uwaterloo.ca/~vmontagh/alloy/

https://ece.uwaterloo.ca/~vmontagh/alloy/

Extending Alloy with Partial Instances.

Software

Transcript of Extending Alloy with Partial Instances.