Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Sliced Alloy

Course work for Static Analysis course

  • Loggen Sie sich ein, um Kommentare anzuzeigen.

  • Gehören Sie zu den Ersten, denen das gefällt!

Sliced Alloy

  1. 1. Towards Sliced Alloy Vajih Montaghami University of Waterloo
  2. 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. 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. 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. 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. 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. 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. 8. Approach • Which part of possible instances should be generated first? • Which part of a model can be solved first? 9
  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. 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. 11. Example of Dependency Graph 12 The most independent class The most dependent class
  12. 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. 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. 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. 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. 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. 17. Conclusion • Alloy is not imperative, but we still need Static Analyzer • Typed-system • Optimizer Execution • Slicing does always improve performance • More benchmarking 20

×