Towards Sliced Alloy

Vajih MontaghamiUniversity of Waterloo

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.

Example for an Imperative Language

for(i=0...9) x++for(i=0..3) y++v=xw=y

for(i=0...9) x++v=xfor(i=0..3) y++w=y

Example for an Imperative Language

for(i=0...9) x++for(i=0..3) y++v=xw=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=xw=y

for(i=0...9) x++v=x

for(i=0..x) y++w=y

Serial

Poker: a motivating example

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 Jokerall c: Card | c.number != Joker

}

There are 56 Possible Cards, but 52 Cards are Valid.

Poker: a motivation example

fact playing_rules{--Nobody plays by himselfall p:Player | p.successor != p--Playing in a circular orderall p:Player | p.^successor = Player--each player have exactly two cardsall p:Player | #p.cards = 2--Pocket cards are not sharedall 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 Jokerall c: Card | c.number != Joker

}

Idea• Preventing exponential growing of the

state space.• Alloy creates an upper bound for

solution• Solve smaller slices such that

Σcost(slicei) ≪cost(whole)cost: Memory+Time

Approach

• Which part of possible instances should be generated first?

• Which part of a model can be solved first?

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.

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

Example of Dependency Graph

The mostindependent class

The mostdependent class

Predicates slicing• Find a predicates such that:• The instances of relations in the

predicate is already in a sig class and its predecessors.

• Example:--No Joker in Deckall c: Card | c.number != Joker

Card.(Card->Number) != Number

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

Alloy type system• 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→Card)

{Player,Card,Round}SigIn(φ) =

φ :

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

Feasibility Study• One model has been tested so far• Simon: Software design modularity

AnalysisTotal

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,174A4.2s1 22 8 25 30 40A4.2sT 20,082 511 37,173 1016 2,214

Conclusion• Alloy is not imperative, but we still need

Static Analyzer• Typed-system• Optimizer Execution

• Slicing does always improve performance• More benchmarking