Alloy: A Lightweight and Powerful Object Modelling Language

1. 6894 · workshop in software designlecture 10 · nov 16, 1998 · object modelling language

2. topics • overview of Alloy • a new modelling language • features • lightweight & powerful • precise, analyzable • elements • motivations • target applications • examples • kernel language

3. a new modelling notation should be… • lightweight • small language, small models • natural & easy to use • good for partial modelling • powerful • can express complex aspects succinctly • mechanically analyzable • many previous attempts • formal specification languages (Larch, VDM, Z) • require mathematical mindset • tend to be heavyweight • not tractable • informal languages (OMs, DFDs, MDDs, etc) • end up being complex • not precise, so not analyzable

4. target applications • problem domains • correct working of s/w relies on environmental assumptions • getting them wrong may be catastrophic (Warsaw Airbus) • without domain model, requirements impenetrable • example: airspace structure, identification of aircraft • architectural configs • constraints on individual architectures • or characterize ‘styles’ • example: event systems • complex state spaces • many dimensions of organization • hard to design without making state explicit • example: mobile IP, style sheet • object structures • patterns encourage dynamic configuration • depends on invariants being maintained • example: subject/observer relationship

5. Alloy • what it is • a new object modelling language • designed hand-in-hand with tools • Womble: extracts object models from bytecode • Fox: automatic analysis of object models • status • syntax and formal semantics complete • some details still in flux • reference manual and release of tools in next few months

6. aspects of alloy • structuring mechanisms • follows recent work in description techniques • new checking opportunities • graphical subset • can express some but not all constraints • simple but formal • kernel language • any constraint can be translated into the kernel language • basis for semantics and checking • checking engine • exploits new technology for boolean sat • fast, fully automatic analysis • even though language is undecidable…

7. example: message handler type CLIENT CLITYPE for creates type MSG MSGTYPE HANTYPE handle-out[CLITYPE] type INMSG OUTMSG HANDLER (handler) hanstate HANSTATE

8. example, in text • model MESSAGES { • domain {MSG, CLIENT, HANDLER, HANSTATE, MSGTYP, CLITYPE, HANTYPE} • state { • partitionsticky INMSG, OUTMSG : MSG • type : MSG -> sticky MSGTYPE ! • type : CLIENT -> sticky CLITYPE ! • type : HANDLER -> sticky HANTYPE ! • hanstate : HANDLER -> HANSTATE ! • for : MSG -> sticky CLIENT ! • creates : HANTYPE -> sticky MSGTYPE • handle-out [CLITYPE] , handle-in [CLITYPE] : MSGTYPE -> HANDLER ? • (handler) : MSG -> HANDLER • } • def handler {…} • inv noDoubleSend {…} • … • }

9. constraints • for definition • def handler { • all m : INMSG | m.handler = m.type.handler-in [m.for.type] • all m : OUTMSG | m.handler = m.type.handler-out [m.for.type] • } • for invariant • // handler for outgoing message can’t create a message • inv noDoubleSend { • all m : OUTMSG | no m.handler.type.creates • } • for operation • // register handler • op registerOut (h : HANDLER ! , ct : CLITYPE, mt : MSGTYPE) { • mt.handler-out [ct] := h • }

10. assertions • how to find bugs in a model • simulate it and look at examples • assert some redundant properties • kinds of assertion • implications: one invariant implies another • INVa -> INVb • preservation: if an invariant holds before an operation, it always holds after • OP && INV -> INV’ • encoding operations • the operation • a.r := e • is translated into the formula • all x | x = a -> x.r’ = e • all x | x != a -> x.r’ = x.r

11. kernel language • types • declarations for two kinds of component • c : D c is a set of elements of type D • c : D1 -> D2 c is a set of pairs of elements of type (D1, D2) • expressions • set operations • s1 + s2 union of s1 and s2 • s1 - s2 difference: elements in s1 but not s2 • s1 & s2 intersection of s1 and s2 • qualifiers • r relation component • r* transitive closure of r • ~r transpose of r (ie, r backwards) • image expressions • s.q image of set s under qualifier q • set comprehension • {v : D | f} set of all v drawn from domain D satisfying formula f

12. kernel language, ctd • formulas • elementary formulas • e1 in e2 e1 is a subset of e2 • e1 = e2 e1 and e2 contain same elements • logical operators • && and • || or • -> implies • not negation • quantifiers • all v : D | f universal quantification • some v : D | f existential quantification • and that’s it!

13. examples of kernel exprs and formulas • me : PERSON • men : PERSON • parents, spouse, siblings: PERSON -> PERSON • // don’t usually have to write this • all a : PERSON | all b : PERSON | (a + b) in me -> a = b • some a : PERSON | a in me • // who are these people? • (me.parents.~parents) - me • // a definition • all p : PERSON | p.siblings = p.parents.~parents - p • // a true fact about my family • exists p : PERSON | p in me.spouse.siblings & me.siblings.spouse • // a question • exists a : PERSON | all p : PERSON - a | a in p.parents*

14. exercises • express the following constraints • no incest • all p | no p.siblings & p.spouse • no bigamy • all p | sole p.spouse • nobody is their own ancestor • no p | p in p.parents*

15. what Alloy adds to kernel • structuring mechanisms • def, inv, op, etc • implicit typing • domains • types are implicitly associated with set components declared as ‘domains’ • inference • types of remaining components and variables are inferred • quantifier shorthands • some e short for (some v | v in e) some me.~parents • no v | f short for (not some v | f) no p | some p.parents & p.spouse.parents • overloaded component names • can use same name, so long as types are different • for relation, left type must differ • declaration shorthands • p : PERSON ! says p is a scalar • … etc

16. what’s missing from Alloy (by design) • relational operators • in NP, Z, etc, can write formulas like • ancestors = parents* • in Alloy, must write • all p : PERSON | p.ancestors = p.parent* • constants • traditional set and relation constants not used • to say “I have no step brothers” • no p | (some p.parents & me.parents) && (some p.parents - me.parents) • scalars • scalars are treated as sets • avoids burdensome set/element casts • in Z, me.parents is written • parents [( { me } )] • avoids partial function problem • what does (me.parents != me) mean?