Using Alloy in Process Modelling

1. Using Alloy in Process Modelling Chris Wallace UWE

2. Plan • Alloy • Case Studies • Alloy limitations • Alloy benefits

3. Alloy • Developed by Daniel Jackson and his group at MIT • based on Z, relational algebra, Syntropy, ... • Principles • declarative, hence compositional • textural, readable • analysable using SAT solver • 1st order predicate calculus over relations • competitor to OCL but complete ( like USE/OCL)

4. Alloy - domain • Entity sets • sig Level{} • Relations • sig Module { level : Level} • defines relation <Module, Level> - a functional dependency (many-one) • Relations subsume • sets - relation of arity 1 • scalars - set of cardinality 1 • Integers • + - = #S cardinality of S

5. Alloy - operators • ‘Set’ operators applied to relations • intersection + • union & • difference - • membership e in S • Logical operators • and && • or || • implication =>, => else • not !

6. Alloy - relational operators • Join . • a.b • a, b relations => join on rightmost field of a with leftmost field of b • a or b is scalar => de-referencing I.e. a’s bs • Product -> • a->b • a, b relations => a->b is the cartesian product • a, b scalars => a->b is the tuple <a,b> • Transpose ~ r • Transitive closure ^r = r + r.r + r.r.r ..

7. Alloy - predicate calculus • Quantifiers • some, no, all, sole, one, two • e.g all m:Module | one m.level • Comprehensions • {all m : Module | no m.prereq}

8. Alloy - relational algebra • Relational constants • none[t] • univ[t] • iden[e] • Relational algebra • if a is <T,S> , b is <S,R> • T.a , a.S - Projections of a • all a | p(a) - Restrict • a.b - Natural Join, giving <T,R>

9. Developing a model(1) • Construct initial model • declarations - sig .. • constraints - fact { ..} • functions (parameterised formula) - fun f () {…} • assertions - assert g {.} • examples - run f for 4 • counter-examples - check g • compile

10. Developing a model (2) • Model space is converted to a boolean expression in Conjunctive Normal Form • CNF formula sent to SAT solver • If instance found, it is displayed • in tree form • in graphical form using GraphViz’s dot • Correct model, recompile and re-execute

11. Case studies in Process Modelling • Data modelling • The old Emp Dept example again • Fowlers Patterns • Organisational structure • Process Modelling • State-based - Student progression • Declarative • Puzzles • Who owns the zebra?

12. ER Modelling • Straightforward expression of ER models with additional structural constraints • Modelling process is • start small • generate instances • if instances wrong, add constraints till the instances look right • if no instances, weaken constraints • assert properties which should be true • alter constraints if counter-examples

13. module lecture/empdept sig String {} sig Job {} sig Location {} sig Dept { name : String, loc : Location } sig Emp { name : String, dept : Dept, role : Job, mgr : option Emp }

14. Constraints // departments and employees cant share a name fact { all d: Dept | no e : Emp | e.name = d.name } // employee names are unique fact { all disj e1,e2 : Emp | e1.name not = e2.name } // employees cant manage themselves fact { no e : Emp | e.mgr = e } // all departments have employees fact {all d : Dept | some dept.d } // departments ahave unique location fact { all disj d1,d2 : Dept | d1.loc not = d2.loc } // management hierarchy - no employee can manage themselves or their managers manager etc fact { all e : Emp { e !in e.^mgr // ^ is the relational closure operator } } // only one boss fact { one e: Emp | no e.mgr }

15. State Transition Modelling • Base model provides invariants • Define set of transitions that change state of student • Define guards on transitions • Define generalised transition between states • Constrain sequence of transitions

16. Defining states and transitions sig Level {} sig Module { disj prereq, coreq, excluded : set Module, level : Level } sig Student { taking, passed : set Module, level : Level, mode : Mode } sig Mode {} part disj sig Initial, Active, Suspended, Graduate extends Mode {} fact {all s :Student | no s.taking & s.passed } fun canTake (m : Module, s: Student) { m !in (s.passed + s.taking) && m !in (s.passed + s.taking).excluded && m.prereq in s.passed && m.level = s.level } fun doTake (m : Module, s, s' : Student) { s'.taking = s.taking + m&& s'.passed = s.passed && s'.level = s.level }

17. The statechart fun doStep (s,s' : Student) { some a : Event | some m : Module | s.mode = Initial && a in Enrol => (doEnrol(s,s') && s'.mode = Active) else s.mode= Active && a in Take && canTake(m,s) => (doTake(m,s,s') && s'.mode= Active ) else s.mode= Active && a in Pass && canSit(m,s) => (doPass(m,s,s') && s'.mode= Active) else s.mode= Active && a in Fail && canSit(m,s)=> (doFail(m,s,s') && s'.mode= Active) else s.mode= Active && canProgress(s) => (doProgress(s,s') && s'.mode= Active) else

18. Declarative approach sig Review {} disj part sig OKReview, FailReview extends Review {} sig ExamModeration { request : option Request, draftPaper : option Paper, internalReview : set Review, revisedPaper : option Paper, internalSignature : option Signature, externalReview : set Review, externalSignature : option Signature }

19. Constraints fact { all e : ExamModeration { one e.draftPaper => one e.request some e.internalReview => one e.draftPaper sole e.internalReview & OKReview one e.internalSignature => one r: e.internalReview | r in OKReview one e.internalSignature and some e.internalReview & FailReview => one e.revisedPaper one e.revisedPaper => some e.internalReview & FailReview e.revisedPaper not = e.draftPaper sole e.externalReview & OKReview some e.externalReview => one e.internalSignature one e.externalSignature => one r: e.externalReview | r in OKReview no e.internalSignature & e.externalSignature no e.internalReview & e.externalReview } }

20. Who owns the Zebra? • module cw/zebra • /* who owns the Zebra • http://www.blakjak.demon.co.uk/zebra.htm • */

21. sig House{ colour: Colour, nation: Nation, pet: Pet, drink: Drink, smoke: Smoke } sig Colour {} // each house has its own unique colour { one colour.this } static disj sig Red, Green,Yellow, Blue, White extends Colour {} … fact { // there are five houses #House=5 // the englishman lives in a red house one h: House | h.nation in English and h.colour in Red // The swede has a dog one h: House | h.nation in Swedish and h.pet in Dog // the dane drinks tea one h: House | h.nation in Danish and h.drink in Tea

22. Alloy limitations • discrete - so no real numbers • state space explosion • 4 Module, 4 Level sig {Module • level : Level -- 4 * 4 =16 • level : option Level -- 4 * 4 * 2 = 32 • level : set Level -- 4 * 2^4 = 64 • not OO - single type, so single namespace, no overriding etc [but work underway to fix]

23. Alloy benefits • Proven worth in uncovering problems in published systems • Makes models testable • Works with quite sizeable models • Great for teaching - will replace Z • Can be used to explore tricky structures and algorithms • Interplay between the general and the particular is great step forward

24. Future of Analytic Modelling? • The developer centric methods (open-source, extreme programming) don’t use models - • ‘all models are lies’ - Kent Beck • The traditional methods use models only informally • ‘Bubbles don’t crash’ - Bertrand Meyer • Alloy can appeal to both camps • responsive enough for the developers • learnable enough for the analysts