fun with object modelling

Daniel JacksonSoftware Design GroupMIT Laboratory for Computer Science

Kansas State University · November 8, 1999

2

only code matters

in most developmentsdesign = code sketchprogress = lines of codeproduct = codeno specification

what’s lostclarity of purposeseparation of concernsradical design options

what’s goes wrongthrow code awaychanges are hardreuse is difficult

Plan to throw one away.You will anyhow.

3

how did we get in this mess?

code is realcan’t deliver spec alone

code is easier than spec/designto do, to evaluate, to teach

no other way to talk about softwarespec/design languages

heavy, mathematical, inert

4

lightweight & electric models

object modellingcaptures structural propertiesof domain, behaviour, or implementationglobal viewpoint – not OO!

Alloy: A Lightweight OM Notationdeclarative, partial, abstractsimple and rigorous semanticsgraphical & textual

Alcoa: Alloy Constraint Analyzerfully automatic, interactiveanimates models: sampling & checkingconcrete analysis of abstract model

Plan to throw one away.You will anyhow.

So make it amodel, not code

5

a happier future?

OM extractionLackwitAjaxWomble

OM analysisNitpickAlcoa

CODECODE SPECFRAGMENT

SPECFRAGMENT

ANALYZEANALYZE

ANALYZEANALYZE

DESIGNFRAGMENT

DESIGNFRAGMENT

DESIGNFRAGMENT

DESIGNFRAGMENT

DESIGNFRAGMENT

DESIGNFRAGMENT

EXTRACTEXTRACT

6

rest of talk

CTASa new air-traffic control systemthe aircraft assignment problem

Alloygraphical & textual notationsexamples

Alcoaa demonstrationhow it works

summaryexperience with Alloy & Alcoaresearch challengesrelated work

7

CTAS

what it isCenter/TRACON Automation Systemsuite of tools to manage traffic at big airportsFAA’s choice for terminal area automation (1991)deployed in five US airports (1998)NASA Software of the Year (1998)

what TMA tool doestakes

radar inputflight plansaircraft modelsweather, etc

givesdelay advisories

8

Communications Manager

what it iscentral component of CTASmaintains aircraft databaseacts as message switchabout 80kloc of C

why we chose itCM is a bottleneckCM’s design has degraded

9

aircraft allocation problem

aircraft statesactive: radar tracks receivedassigned: to a route analyzerwaiting: to be assigned

process statesconnected: doing analysis

challengeaircraft arrive, become active/inactiveprocesses fail and come backhow to allocate aircraft to analyzers?

what kind of problem?not algorithmic!

challengessimple, flexible mechanismeasy to argue that it’s right

10

alloy basic concepts (ABC)

state declarationsets of atomssubset relationshipsrelations between sets

multiplicity? zero/one! exactly one+ one or more

S

T

T is a subset of S

S

T U

T, U disjoint subsets of S

S Tm R n

R is relation from S to Teach S maps to n T’s, m S’s map to each T

11

description vs. instance

object modeldescribes set of configurationseach has a value for each

setrelation

an odd instancemy family

tim

daniel

emily

claudiawife

wife

judy judy

mum

mum

mum

mum

Person

Man Woman

wife

mum

??!

Name name!

12

textual constraints

expressionsall exprs denote setse1 + e2 unione1 & e2 intersectione . r navigatione . +r transitive closure

formulase1 in e2 subsete1 = e2 equalityall v: S | F F true when any atom in S

substituted for v

no incestall p: Person |

p.wife.mum != p.mum

nobody’s her own (grand)motherno p: Woman | p in p.+mum

our familysome daniel, tim: Person |

daniel.mum = tim.mum &&

daniel.wife.mum = tim.wife.mum

13

object model: state & invariants

inv NoGhosts {Active in (Waiting + Assigned)}

inv LiveAnalyzers {Assigned.analyzer in (RouteAnalyzer & Connected)}

A c t i v e A i r c r a f t

W a i t i n g A s s i g n e d R o u t eA n a l y z e r

P r o c e s s C o n n e c t e d

a n a l y z e r ( ~ l o a d ) !

14

object model: operation (1)

implicit versiondoesn’t specify how aircraft are reassignedinvariants are included implicitly

op LoseAnalyzer (z: Process) { no z.load' Connected' = Connected - z Active = Active’ Waiting = Waiting’ Assigned = Assigned' }

15

object model: operation (2)

explicit version Aload is moved to another process

op LoseAnalyzerA (z: Process) { LoseAnalyzer (z) ReassignLoadA (z) } op ReassignLoadA (z: Process) { some y: (RouteAnalyzer & Connected) - z | y.load' = y.load + z.load && (all p: RouteAnalyzer - (y + z) | p.load = p.load') }

16

object model: operation (3)

explicit version Bload is spread arbitrarily amongst other processes

op LoseAnalyzerB (z: Process) { LoseAnalyzer (z) ReassignLoadB (z) } op ReassignLoadB (z: Process) { all a: Aircraft - (z.load) | a.analyzer = a.analyzer' z.load.analyzer' in (RouteAnalyzer & Connected') }

17

object model: analyses

questions for Alcoashow me

a sample of the statean execution of each variant of LoseAnalyzeran execution that leaves an analyzer with no loadthe difference between the versions

do both versions preserve the invariant?

notespecifications are declarative

don’t say how state is updatedlets you be partial & abstract

but makes analysis hard!

18

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 transitionfinding a solution = sampling or refuting

theory says no!Alloy is undecidable (because of relations)so no decision procedure exists

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

19

small scope hypothesis

an empirical hypothesismost invalid claims can be refuted by small

counterexamples

smallestrevealing

scope

cumulative invalid assertions

3

90%

misscatch

20

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: allocation problem

7 sets, 1 relation in statefor operation, 14 and 2

scope of 32^ (14 x 3 + 2 x 9) = 2^60at 1M/sec

10^12 secs ~ 300 years *

*1 nanocentury = seconds

21

translating to SAT

what you learned in CS 1013-SAT: 1st problem tshown NP-cto 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

schemegiven a design problem Dconstruct

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

reducemapback

MAPPING

SAT PROBLEM SAT SOLUTIONSAT

solver

DESIGNPROBLEM

DESIGNANALYSIS

22

architecture of Alcoa

front endparse & syntax checktype inferenceinline formulasconvert to kernel

middle endtranslate to boolscope-dependent

backendexploit off-the-shelf solversAlcoa treats as black boxconfigured by generic mechanism

TRANSLATE

TRANSLATE

KERNEL

BOOL

SOLVE

STATE,TRANS

ALLOY MODEL

SCOPE

23

Alcoa performance

works well for problems withmany solutions: eg, samplingfew solutions: eg, finding bug

complexity grows with# state componentssize of formula

rule of thumbsolvers bogged down for

> 2000 boolean variables

> 200 state space bits

example: file systemrelations: naming, dir, linkssets: file, dir, name36 (90) bits for scope of 5

cost

P(solvable)

24

ongoing work

case studiesCTAS: checking design conformance of Java versionCAP: designing CTAS extensionK42: object invariants in new IBM OSAT&T: looking at new conferencing/mobile feature

analyzer performancelarger models & scopes, faster analysis

language developmentsequencing of operationsmore powerful compositions

code analysisextracting Alloy models and analyzing with Alcoa

25

related work

object modelling notationsOCL expression language (Warmer et al)pUML group working on semanticssemantic data models (eg, Hammer & McLeod, 1981)

interacting state machinesextract automata, apply model checkingBandera project (KSU, UMass, Hawaii)focus on concurrency & event sequencing

design patternsfragmentary design idioms for OO programspictorial representation of code

software architectureprotocols connecting componentstopological constraints nicely expressed in Alloy

26

conclusion

what makes it usefuladdresses complexity of structuredeclarative & partialbig code/model ratio

what makes it possiblelightweight, tractable notationsmall scope hypothesisshow existence, not absence

help from othersCraig Damon, Somesh Jha, Ilya Shlyakhter, Ian SchechterSAT solversMoore: 1980-2000, 3 hrs -> 1 sec

Alcoa! Free while supplies last!

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