tractable object models

Daniel JacksonSoftware Design GroupMIT Laboratory for Computer Science

WG 2.9 · Flims · February 7, 2000

2

lightweight formal methods

focushigh risk issuesstructural aspect

light notationminimal syntax, pure asciisimple semanticsintegrated graphical/textual

light analysisfully automatic, interactive speedconcrete output (instances & counters)

declarative styleincrementality & viewsessential properties

3

progress

nitpick (1996)sets & binary relationsZ-like schema calculussequential composition

alcoa (1999)first-order quantifiersobject model declarationsmutability constraintsmore nimble schema calculus

alcoa’ (2000)structures (hierarchy)sequential compositionnumbers, sequences & orders #relations

scope

5 10 15 20

3

6

9

12

4

semantic minimalism

for simple semantics, noundefined or unknownimplicit coercions or flatteningsspecial treatment of attributesrelation attributesaggregation

for conceptual modelling, noclasses, types, packagesmethodsnavigability

5

relational structure

database viewpoint [Codd, Chen, etc]relations are tables with named columnscan have 3-way relationshipsconstraints use lots of quantifiers

relational calculus viewpoint [Tarski, Abrial, etc]relations are binaryconstraints use set & relation operators

my workbased on relational calculusconstraints more succinct, diagrams simpler?but database view more familiar?

thanks to Emmanuel Letier

6

example

nobody has the same name as her parent

database viewall x, y, m, n | Parent (x, y) && Named (x, m) && Named (y, n) -> m != n

relational viewno p | p.name in p.parents.name

pure relational viewname & (parent ; name) = {}

7

modelling implication

exampleworst case stopping distancedepends on train and segment

database viewrelation on from Train to Segmenton has attribute wcsd

relational viewintroduce 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

problemf(x) = g(y) when x outside the domain of f?

other optionsspecial undefined value (KAOS?, UML)

undef appears in specswhat 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 meaningsome 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

ideascalar represented as singleton set

examplessome p | p.name = danielall p | no (p.wife & p.siblings)all e : Employee | e.boss in e.company.employees

nice propertiesno guardsno flattenings or promotionsall terms have meaninguse multiplicities for sets

no free lunchno p | p.wife in p.siblings false if somebody’s unmarried!no p | p.wife /in p.siblings

10

an example

domainBART railway system

problemspecify topology of railwayinvestigate placement of gates

caveatsstructural aspect onlyI haven’t even read the 15ppstarted at midnight last night …

11

basic notions

segmentscapability to use track in one directiona connector at each endseg1.from = con1seg3.from = seg4.from

overlapmodel crossings etc by overlapseg5 in seg6.overlaps

gatessome segments have gates at the endgates are open or closed

trainsoccupy segments; ignore position

seg1

seg2

con2con1

junction

crossover

seg6

seg5

seg4

seg3

12

object model diagram

Segment Connectorfrom

to

Train

on

overlaps

Gategate

Open Closed

!

!!

?

!

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 segmentscond 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 overlapdef 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 consistencyask for instances of states and transitionsspecify conditions to get good cases

check consequencesassert implications of invariantsassert properties of operations

eg, preservation of invariant

20

bug example, inconsistency

I asked Alcoa to show me a statenone found in scope of 3realized I had made from and to surjective

the condition I executed cond Acyclic {some Segment && no s | s in s.+succ}

Alcoa’s outputAnalyzing Acyclic ...Scopes: Gate(3), Connector(3), Segment(3), Train(3)Total conversion time: 0 secondsTotal solver time: 0 secondsNo instances exist in this scope

the fix: drop the plus from, to : Segment + -> Connector!

21

bug example, implication

I asserted that conflicts is symmetricAlcoa generated a counterexamplerealized overlaps should be symmetric too

the assertion I checkedassert ConflictsSym { all s, t | s in t.conflicts -> t in s.conflicts }

Alcoa’s outputnext slide

the fix: add the constraint all s, t | s in t.overlaps -> t in s.overlaps

22

output

Alcoa’s outputAnalyzing 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 produced how I responded

ex nihilo train creation add Trains = Trains’ to operationtrain enters backlooping segment constrained assertion to ignore thistrain hits train in succ segment added separation to policyfunky overlap scenario went to sleep

24

funky overlap

s0

s1 s2

overlap!

25

why it’s hard (1)

what we’d like Alcoa to dogiven a formula

find a solutionor 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 anyonly consider instances in scopenow a finite search: decidable

ALCOA

FORMULA

SOLUTION NONE

26

small scope hypothesis

% bugscaught

scope

90

4

most bugs can be caught by considering only small instances

27

why it’s hard (2)

even in finite scopehuge space of configurationsadd a relation in scope of k

increase by 2^(k^2)for transition, 2x components

why search is neededlanguage is declarativeno recipe for after-states

example: BART6 relationsfor transition, 12 rels

scope of 32^ 144 ~ 10^40 casesat 10G/sec, 10^20 centuries (1 nanocentury = secs)

28

translating to SAT

what you learned in CS 1013-SAT: first NP-c problemto show a problem is hard

reduce SAT to it

what we know nowSAT is usually easyto show a problem is easy

reduce it to SAT

reducemapback

MAPPING

SAT PROBLEM SAT SOLUTIONSAT

solver

DESIGNPROBLEM

DESIGNANALYSIS

schemegiven a design problem Dconstruct

SAT problem S, mapping MS has solution s D has solution M(s)

29

research status

case studiesmobile IPv6Sullivan’s COM analysis, Jini, intensional namingwith NASA: air-traffic controlwith IBM: K42 operating system

tool developmentnew symmetry schemeopen interfacesvisualization

application to codeshape analysisdesign conformance

30

conclusion

key ideasabstract -> not tractable?small scope hypothesisfocus on existence, not absence

acknowledgmentslanguage: M. Jackson, Liskov, Halltool: Schechter, ShlyakhterSAT solvers: Nelson, Selman, Kautz, ZhangMoore: 1980-2000, 3 hrs -> 1 sec

Alcoa! Free while supplies last!

http://sdg.lcs.mit.edu/alcoa