Using Alloy in Process Modelling

Chris Wallace

UWE

Plan

• Alloy

• Case Studies

• Alloy limitations

• Alloy benefits

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)

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

Alloy - operators

• ‘Set’ operators applied to relations– intersection +– union &– difference -– membership e in S

• Logical operators– and &&– or ||– implication =>, => else– not !

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 ..

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}

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>

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

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

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?

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

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}

Constraints// departments and employees cant share a namefact { all d: Dept | no e : Emp | e.name = d.name }

// employee names are uniquefact { all disj e1,e2 : Emp | e1.name not = e2.name }

// employees cant manage themselvesfact { no e : Emp | e.mgr = e }

// all departments have employees

fact {all d : Dept | some dept.d }

// departments ahave unique locationfact { 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 bossfact { one e: Emp | no e.mgr }

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

Defining states and transitionssig 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}

The statechartfun 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

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}

Constraintsfact { 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 }}

Who owns the Zebra?

• module cw/zebra• /* who owns the Zebra

• http://www.blakjak.demon.co.uk/zebra.htm

• */

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

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]

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

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