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