daniel jackson & sarfraz khurshid lcs retreat ·martha’s vineyard · june 2k

1. unintentionalnaming daniel jackson & sarfraz khurshidlcs retreat ·martha’s vineyard · june 2k

2. elaboratemodel runanalysis interpretresults model & issues alloy project • hypothesis • better software? • base on clear & simple concepts • why models? • smaller & more flexible than code • can analyze exhaustively • alloy • a RISC modelling notation • for structural properties • SAT-based analyzer 2

3. designproblem result mapping translateproblem translatesolution booleanformula booleansolution SATsolver architecture 3

4. intentional naming case study • why INS? • naming vital to infrastructure • INS more powerful than Jini, COM, etc • the Kaashoek challenge … • what? • analyzed lookup operation • based model on SOSP paper & Java code • a few weeks in April • Khurshid did all the work 4

5. intentional naming • attribute/value pairs city: cambridge • hierarchical specs city: cambridge, building: ne43, room: 524 service: camera, resolution: hi service: printer, postscript: level2 • lookup • database maps spec to set of records • query is set of specs • lookup returns records meeting all specs 5

6. query database n0 building service building service ne43 camera ne43 camera printer n0 n1 n0 n0 n1 tree representation 6

7. strategy • model database & queries • characterize by constraints • generate samples • check properties • obvious • no record returned when no attributes match • claims • “wildcards are equivalent to omissions” • essential • additions to DB don’t reduce query results • discuss and refine … 7

8. alloy model: state • model INS {domain {Attribute, Value, Record}state { Root : fixed Value! valQ : Attribute? -> Value? attQ : Value? -> Attribute valDB : Attribute? -> Value attDB : Value? -> Attribute rec : Value + -> Record lookup : Value -> Record } 8

9. alloy model: constraints • // no cycles in queryinv Q4 {no v | v in v.+nextQ} • // if query and DB share a leaf value, lookup returns its recordsinv Lookup1 {all v | no v.attQ || no v.attDB -> v.lookup = v.rec} • // adding a record doesn’t reduce resultsassert LookupOK7 {AddRecord -> Root.lookup in Root.lookup'} 9

10. checking assertions 3 attrs,vals, recs selectscope fixmodel runcheck incrscope counter? Y N N N real? slow? Y Y propfails propholds 10

11. results • 12 assertions checked • when query is subtree, ok • found known bugs in paper • found bugs in fixes too • monotonicity violated 11

12. query database n1 service service printer printer size type size type A4 mono A4 mono n0 n1 counterexample 12

13. time & effort • costs  2 weeks modelling, ~100 lines Alloy • cf. 900 lines testing code  all bugs found in < 10 secs with scope of 4 • 2 records, 2 attrs, 3 values usually enough • cf. a year of use  exhausts scope of 5 in 30 secs max • space of approx 10^20 cases 13

14. lessons •  • quick & easy prototyping • more effective than testing • assertions easily invented • visualization a big help •  • model not modular • algorithm a bit tricky • can’t express paths 14

15. related experiences • case studies • microsoft COM: no encapsulation • collaborative arrival planner: ghost planes • PANS phone: light gets stuck • other users • alloy taught in courses at 5 universities • case studies at: DERA, AT&T, FS, U.Southampton, Imperial, Oxford • typical dimensions • model: 20 – 200 lines • space: 30 – 300 bits 15

16. helping oxygen? • rapid experimentation • articulating essence • simplifying design 16

17. musings • why does Alloy help? lazy specification refining design ideas catching showstopper bugs • modelling on the rise? • tool as trojan horse (SDL, SPIN, SMV) • design patterns phenomenon • shop floor to drafting office, c.1850 17