Program slicing is a technique to decompose programs into smaller slices based on data and control flow dependencies. The author proposes extending this technique to the Alloy specification language by slicing based on Alloy's type system. Slicing Alloy models could prevent exponential growth in the state space by first generating and solving smaller slices whose signatures are independent of other signatures. This approach aims to solve slices such that the total cost of all slices is less than solving the whole model. An example model called Simon was tested, and slicing reduced the number of variables and clauses, improving solving time. More evaluation is needed, but initial results suggest slicing holds promise for optimizing Alloy model execution.

1. Towards Sliced Alloy
Vajih Montaghami
University of Waterloo

2. Program slicing
• Program Slicing: Automatically decompose
program by analyzing their data flow, control
flow, and graph dependency
• Comprehend slice: debugging, testing
• Comprehend slices: parallelization
• Alloy is a logic specification language
• Slicing based on the Alloy type-system.
2

3. Example for an Imperative
Language
3
for(i=0...9) x++
for(i=0..3) y++
v=x
w=y
for(i=0...9) x++
v=x
for(i=0..3) y++
w=y

4. Example for an Imperative
Language
4
for(i=0...9) x++
for(i=0..3) y++
v=x
w=y
for(i=0...9) x++
v=x
for(i=0..3) y++
w=y
for(i=0...9) x++
for(i=0..x) y++
v=x
w=y
for(i=0...9) x++
v=x
for(i=0..x) y++
w=y
Serial

5. Poker: a motivating example
5
sig Suit{}
sig Number{gt:lone Number}
sig Card{suit: one Suit,
number: one Number}
fact Card_Set{
all disjoint c1,c2:Card|
c1.number!=c2.number and
c1.suit !=c2.suit
--card set does not include Joker
all c: Card | c.number != Joker
}
There are 56 Possible Cards, but 52 Cards are Valid.

6. Poker: a motivation example
6
fact playing_rules{
--Nobody plays by himself
all p:Player | p.successor != p
--Playing in a circular order
all p:Player | p.^successor = Player
--each player have exactly two cards
all p:Player | #p.cards = 2
--Pocket cards are not shared
all disjoint p1,p2:Player | no (p1.cards & p2.cards )
}
sig Player{
cards: set Card,
chips: one Int,
successor: one Player}
sig Suit{}
sig Number{gt:lone Number}
sig Card{suit: one Suit,
number: one Number}
fact Card_Set{
all disjoint c1,c2:Card |
c1.number=c2.number and c1.suit =c2.suit
--card set does not include Joker
all c: Card | c.number != Joker
}

7. Idea
• Preventing exponential growing of the state
space.
• Alloy creates an upper bound for solution
• Solve smaller slices such that
8
Σcost(slicei) ≪cost(whole)
cost: Memory+Time

8. Approach
• Which part of possible instances should be
generated first?
• Which part of a model can be solved first?
9

9. Slicing Signatures
• A sig depends on another sig if:
• declares a relation, e.g.:
• sig A{} sig B{r:A}
• extends another sig, e.g. :
• sig B extends A{}
• sig B in A{}
• If B depends on A, then generating instances
of B requires the existence of instances of A.
10

10. Dependency Graph
• Dependency class: All sigs that does not have
input edge in the dependency graph
• Remove all dependent sigs from the dependency
graph and find other dependent sigs
• A dependency class
• Depends on predecessors
• Not depend on successors
11

11. Example of Dependency Graph
12
The most
independent class
The most
dependent class

12. Predicates slicing
• Find a predicates such that:
• The instances of relations in the predicate is
already in a sig class and its predecessors.
• Example:
13
--No Joker in Deck
all c: Card | c.number != Joker
Card.(Card->Number) != Number

13. Challenge to Slice predicates
• Relation overloading
• Two relation defined in two signatures with the
same name
• Over-approximates the denoted Signatures.
• The resolution depends on the context
14

14. Alloy type system
15
• Relation overloading
• Example
sig Player{
cards: set Card,
chips: one Int,
successor: one Player}
sig Round{
cards: set Card,
dealer: one Player,
blind: one Player}
Player.(cards+cards) = 2
Player.(Player→Card+Round→Ca
rd)
{Player,Card,Round}SigIn(φ) =
φ :

15. Handling overloading
• Reusing Alloy type system
• Runs in two opposite way
• Bottom-up: Approximates the relations that
might belong to expression
• Top-down: Approximates the portion of
relations that are relevant to context
16

16. Feasibility Study
• One model has been tested so far
• Simon: Software design modularity Analysis
19
Total
Variables
Primary
Variables
Clauses
Translation
time (ms)
Solving
time (ms)
A4.2 59,953 768 162,417 11,188 27,730
A4.2p 59,694 773 162,642 12,742 6,744
A4.2s2 20,060 503 37,148 986 2,174
A4.2s1 22 8 25 30 40
A4.2sT 20,082 511 37,173 1016 2,214

17. Conclusion
• Alloy is not imperative, but we still need
Static Analyzer
• Typed-system
• Optimizer Execution
• Slicing does always improve performance
• More benchmarking
20