tractable object models Daniel Jackson Software Design Group MIT Laboratory for Computer Science WG 2.9 · Flims · February 7, 2000

2 lightweight formal methods focus high risk issues structural aspect light notation minimal syntax, pure ascii simple semantics integrated graphical/textual light analysis fully automatic, interactive speed concrete output (instances & counters) declarative style incrementality & views essential properties

3 progress nitpick (1996) sets & binary relations Z-like schema calculus sequential composition alcoa (1999) first-order quantifiers object model declarations mutability constraints more nimble schema calculus alcoa’ (2000) structures (hierarchy) sequential composition numbers, sequences & orders #relations scope

4 semantic minimalism for simple semantics, no undefined or unknown implicit coercions or flattenings special treatment of attributes relation attributes aggregation for conceptual modelling, no classes, types, packages methods navigability

5 relational structure database viewpoint [Codd, Chen, etc] relations are tables with named columns can have 3-way relationships constraints use lots of quantifiers relational calculus viewpoint [Tarski, Abrial, etc] relations are binary constraints use set & relation operators my work based on relational calculus constraints more succinct, diagrams simpler? but database view more familiar? thanks to Emmanuel Letier

6 example nobody has the same name as her parent database view all x, y, m, n | Parent (x, y) && Named (x, m) && Named (y, n) -> m != n relational view no p | p.name in p.parents.name pure relational view name & (parent ; name) = {}

7 modelling implication example worst case stopping distance depends on train and segment database view relation on from Train to Segment on has attribute wcsd relational view introduce new object Occupancy segment : Occupancy -> Segment! train : Occupancy -> Train! wcsd : Occupancy -> Distance! or use a function (indexed relation) wcsd : Segment => (Train -> Dist!)

8 partial function problem problem f(x) = g(y) when x outside the domain of f? other options special undefined value (KAOS?, UML) undef appears in specs what is (x.f + y.g).h when x.f = undef ? special logic (VDM, UML) formulas can be half true special semantics (Z, UML) not all terms have a meaning some p | p.name = daniel is meaningless undefined applications are false (Parnas, Nitpick) x.f != x.f true if short for !(x.f = x.f)

9 my approach idea scalar represented as singleton set examples some p | p.name = daniel all p | no (p.wife & p.siblings) all e : Employee | e.boss in e.company.employees nice properties no guards no flattenings or promotions all terms have meaning use multiplicities for sets no free lunch no p | p.wife in p.siblings false if somebody’s unmarried! no p | p.wife /in p.siblings

10 an example domain BART railway system problem specify topology of railway investigate placement of gates caveats structural aspect only I haven’t even read the 15pp started at midnight last night …

11 basic notions segments capability to use track in one direction a connector at each end seg1.from = con1 seg3.from = seg4.from overlap model crossings etc by overlap seg5 in seg6.overlaps gates some segments have gates at the end gates are open or closed trains occupy segments; ignore position seg1 seg2 con2con1 junction crossover seg6 seg5 seg4 seg3

12 object model diagram

13 Alloy model: declarations model Bart { domain {Segment, Connector, Gate, Train} state Segments { from, to : Segment -> Connector! overlaps : Segment -> Segment gate : Segment! -> Gate? partition Open, Closed : Gate on : Train -> Segment ! succ : Segment -> Segment conflicts : Segment -> Segment }

14 an indicative invariant inv Overlaps { all s, t | s.from = t.to && s.to = t.from -> s in t.overlaps all s | s in s.overlaps }

15 a safety condition // no every segment has at most one train on it and its overlapping segments cond Safety { all s | sole (s + s.overlaps).~on }

16 two definitions // the successors of a segment are those that are from the connector it is to def succ { all s | s.succ = {t | t.from = s.to} } // a segment conflicts with another segment if their successors overlap def conflicts { all s | s.conflicts = {t | some (s.succ & t.succ.overlaps)} - s }

17 policy invariants // place a gate wherever there’s a conflict inv GatePlacement { all s | some s.conflicts -> some s.gate } // at most one open gate in a conflicting group inv Policy { all s | sole (s.conflicts + s).gate & Open }

18 an operation // in a step, any number of trains can move // no train goes through a closed gate op TrainsMove (ts : Train) { all t : ts | t.on' in t.on.succ no (ts.on.gate & Closed) all t : Train - ts | t.on = t.on' }

19 analysis strategy check consistency ask for instances of states and transitions specify conditions to get good cases check consequences assert implications of invariants assert properties of operations eg, preservation of invariant

20 bug example, inconsistency I asked Alcoa to show me a state none found in scope of 3 realized I had made from and to surjective the condition I executed cond Acyclic {some Segment && no s | s in s.+succ} Alcoa’s output Analyzing Acyclic... Scopes: Gate(3), Connector(3), Segment(3), Train(3) Total conversion time: 0 seconds Total solver time: 0 seconds No instances exist in this scope the fix: drop the plus from, to : Segment + -> Connector!

21 bug example, implication I asserted that conflicts is symmetric Alcoa generated a counterexample realized overlaps should be symmetric too the assertion I checked assert ConflictsSym { all s, t | s in t.conflicts -> t in s.conflicts } Alcoa’s output next slide the fix: add the constraint all s, t | s in t.overlaps -> t in s.overlaps

22 output Alcoa’s output Analyzing ConflictsSym... Scopes: Gate(3), Connector(3), Segment(3), Train(3) Counterexample found: Domains: Connector = {C1,C2} Segment = {S1,S2} Relations: conflicts = {S2 -> {S1}} from = {S1 -> C2, S2 -> C1} overlaps = {S1 -> {S1,S2}, S2 -> {S2}} succ = {S1 -> {S1}, S2 -> {S2}} to = {S1 -> C2, S2 -> C1} Skolem constants: s = S1 t = S2

23 bug example, preservation of invariant I asserted that the safety condition is preserved assert PolicyWorks { all t | TrainsMove (t) && Safety -> Safety' } scenarios Alcoa producedhow I responded ex nihilo train creationadd Trains = Trains’ to operation train enters backlooping segmentconstrained assertion to ignore this train hits train in succ segmentadded separation to policy funky overlap scenariowent to sleep

24 funky overlap s0 s1s2 overlap!

25 why it’s hard (1) what we’d like Alcoa to do given a formula find a solution or show there aren’t any solution is state or transition theory says no! Alloy is undecidable (because of relations) so no decision procedure practice says yes! more important to find bugs than to show there aren’t any only consider instances in scope now a finite search: decidable ALCOA FORMULA SOLUTIONNONE

26 small scope hypothesis % bugs caught scope 90 4 most bugs can be caught by considering only small instances

27 why it’s hard (2) even in finite scope huge space of configurations add a relation in scope of k increase by 2^(k^2) for transition, 2x components why search is needed language is declarative no recipe for after-states example: BART 6 relations for transition, 12 rels scope of 3 2^ 144 ~ 10^40 cases at 10G/sec, 10^20 centuries (1 nanocentury =  secs)

28 translating to SAT what you learned in CS SAT: first NP-c problem to show a problem is hard reduce SAT to it what we know now SAT is usually easy to show a problem is easy reduce it to SAT reduce map back MAPPING SAT PROBLEMSAT SOLUTION SAT solver DESIGN PROBLEM DESIGN ANALYSIS scheme given a design problem D construct SAT problem S, mapping M S has solution s  D has solution M(s)

29 research status case studies mobile IPv6 Sullivan’s COM analysis, Jini, intensional naming with NASA: air-traffic control with IBM: K42 operating system tool development new symmetry scheme open interfaces visualization application to code shape analysis design conformance

30 conclusion key ideas abstract -> not tractable? small scope hypothesis focus on existence, not absence acknowledgments language: M. Jackson, Liskov, Hall tool: Schechter, Shlyakhter SAT solvers: Nelson, Selman, Kautz, Zhang Moore: , 3 hrs -> 1 sec Alcoa! Free while supplies last!