UML-B & U2B

1. UML-B & U2B Colin Snook & Michael Butler University of Southampton

2. Contents • Motivation • Background: B, event systems & event B • Problems translating UML to B • Introduction to UML-B and U2B (in event mode) • Decomposition in UML-B (in event mode) • Subsystem design to code or circuit synthesis • Future Work • Conclusions

3. (Motivation) Formal methods • Formal notations • well-defined, precise • verification • validation • ...but unpopular, textual, cumbersome • not difficult to understand • Experimental comparison of the comprehensibility of a Z specification and its implementation in Java, Snook & Harrison - IST (2001) • good coherent abstraction - difficult • Practitioners’ views on the use of formal methods: an industrial survey by structured interview, Snook & Harrison - IST (2001)

4. (Motivation) • cog dim, uml, diag from paper • UML • popular, graphical, easy to change • ...but loose semantics

5. B • model of a component with an interface • Set based • predicate logic • substitutions (program like) • variables, • operations, • parameterised i/o • = interface • = not refineable • prove invariant preserved by operations • refinement - data, algorithms, refinement relation

6. B - some syntax • Machine <name> • SETS <given sets> • CONSTANTS <list of constants> • PROPERTIES <constraints on constants> • VARIABLES <list of variables> • INVARIANT <constraints on variables> • INITIALISATION <initial values for all variables> • OPERATIONS • <opname> (<list of params>) = • PRE param : <paramType> & ... & <other preconditions> • THEN <substitutions define changes to variables> • END; • <other ops> • END

7. Event systems • Model of an observable system: • state • events (spontaneous) • events may only occur in certain states • deadlocks? • no interface, no parameters • refinements may:- • add new events • combine events into one • split events into many • mustn’t increase deadlock

8. Event B • Events instead of operations • no parameters, • no pre-conditions, • block when guard is false • Additional Proof obligations: • New events in a refinement do not alter the abstraction’s variables(I.e. refine skip) • New events must eventually relinquish control(I.e each new event must decrease a ‘variant’ expression’) • Relative deadlockfreeness is preserved(I.e. I(x) & G(x,y) & OR(abstraction guards) => OR(refinement guards)) • Modalities are refined(I.e.if a condition is eventually reached by a sequence of events in the abstraction, it is also reached in the refinement, albeit, possibly being postponed by new events)

9. Problems translating UML to B • 1) B is not object oriented - no ‘promotion’, no instances • so... • have to model instances explicitly • 2) Restrictions to ensure B components can be independently proved - no write sharing of machines • so... • if class --> machine • then only hierarchical associations • so... • class diag. --> machine • but then no operation calling • (ok for abstract systems - poss. future work)

10. Introduction to UML-B and U2B

11. What are UML-B and U2B? • UML-B is a profile of the UML Class diagrams and State charts Specialisations using stereotypes and tagged values e.g <<machine>>, <<refinement>>,<<constant>> UML-B clauses e.g. INSTANCES {trout,tench,roach} uB - integrated constraint & action language e.g. SELECT waiting=true & other.colour=red THEN colour:=green END

12. What is U2B ? MACHINE broker /*" U2B3.6.4 generated this component from Package broker "*/CONSTANTS POLICY, LOCATION, LOAN, LENDER, INSURER, TRANSACTION, BROKER, USERACCOUNTPROPERTIES POLICY = 1..n & LOCATION = 1..n & LOAN = 1..n & LENDER = 1..n & INSURER = 1..n & TRANSACTION = 1..n VARIABLE amount, assets, capital, price, income, logged_in INVARIANT amount : LOAN --> NATURAL & (borrower=null) or (transactionLn=null) & assets : LENDER --> NATURAL & INITIALISATION amount :: LOAN --> NATURAL || assets :: LENDER --> NATURAL || logged_in :: USERACCOUNT --> {FALSE} OPERATIONS choose (thisTRANSACTION,offer,quote) = PRE thisTRANSACTION : TRANSACTION & offer:LOAN & quote:POLICY THEN SELECT offer:offers & quote:quotes & logged_in(user)=true THEN offer.borrower:=user || quote.holder:=user || delete(thisTRANSACTION) END END ; • U2B translates UML-B models into B • History • PhD work [‘99] • MATISSE [‘00](Åbo Akademi, ClearSy, Qinetiq, Siemens, Gemplus, U.Marseille) • PUSSEE [‘01](Nokia, Volvo, Intracom, ClearSy, KeesDa, U.Paderborn)

13. UML-B flavours • Model style: Event OR Action OR Conventional Procedural • Instance modelling options: Variable, Fixed (deferred, enumerated, numbered), Single object, None (implicit or class utility) • Machine per: Class OR Package (class diagram) State chart semantics options: State variable OR Petri style

14. UML-B Benefits • Visualise abstractions • Exploratory design tool • Automates B infrastructure • Quick to change model • Increases visibility of important details • Easier to review work within team • Accessible to others

15. Classes and Attributes SYSTEM Bank /*" U2B3.7.7 generated this component from Package Bank "*/ SETS ACCOUNT DEFINITIONS type_invariant == ( Balance : ACCOUNT --> NAT & Overdraft : ACCOUNT --> NAT ) ; invariant = type_invariant VARIABLES Balance, Overdraft INVARIANT invariant INITIALISATION Balance, Overdraft :(invariant & Balance = ACCOUNT * {0} & Overdraft = ACCOUNT * {500} ) END

16. Associations SYSTEM Bank /*" U2B3.7.2 generated this component from Package Bank "*/ SETS ACCOUNT; CUSTOMER DEFINITIONS type_invariant == ( Balance : ACCOUNT --> NAT & Overdraft : ACCOUNT --> NAT & owner : ACCOUNT --> CUSTOMER & Name : CUSTOMER --> NAME ) VARIABLES Balance, Overdraft, owner, Name INVARIANT type_invariant INITIALISATION Balance, Overdraft, owner, Name :(invariant & Balance = ACCOUNT * {0} & Overdraft = ACCOUNT * {500} ) END

17. Operations (Events) Operations are referred to as « events » in EventB terminology EVENTS deposit = ANY thisACCOUNT,cc,nn WHERE thisACCOUNT:ACCOUNT & cc:CUSTOMER & nn:NAT THEN skip END ; withdraw = ANY thisACCOUNT,cc,nn WHERE thisACCOUNT:ACCOUNT & cc:CUSTOMER & nn:NAT THEN skip END

18. State Charts DEFINITIONS type_invariant == ( exceeded : POW(ACCOUNT) & ok : POW(ACCOUNT) & Balance : ACCOUNT --> NAT & Overdraft : ACCOUNT --> NAT & owner : ACCOUNT --> CUSTOMER & Name : CUSTOMER --> NAME ) ; .... VARIABLES exceeded, ok, .... INITIALISATION exceeded, ok, ... :(invariant &exceeded = {} & ok = ACCOUNT & .... END

19. State Charts in EventB EVENTS deposit = ANY thisACCOUNT,cc,nn WHERE thisACCOUNT:ACCOUNT & cc:CUSTOMER & nn:NAT THEN SELECT thisACCOUNT : exceeded THEN skip WHEN thisACCOUNT : exceeded THEN exceeded:=exceeded-{thisACCOUNT} || ok:=ok\/{thisACCOUNT} WHEN thisACCOUNT : ok THEN skip END END

20. Transition Guards SELECT thisACCOUNT : exceeded & nn+Balance(thisACCOUNT)< -Overdraft(thisACCOUNT) THEN skip WHEN thisACCOUNT : exceeded & nn+Balance(thisACCOUNT)>= -Overdraft(thisACCOUNT) THEN exceeded:=exceeded-{thisACCOUNT}|| ok:=ok\/{thisACCOUNT} ...

21. Operation Guards and Semantics withdraw = [cc=owner] ==>Balance:=Balance-nn withdraw = ... SELECT cc=owner(thisACCOUNT) THEN <select from state chart> || Balance(thisACCOUNT):=Balance(thisACCOUNT)-nn END END

22. Invariants Invariants can be associated with states (as well as with classes)

23. Invariants ACCOUNT_invariant == ( !(thisACCOUNT).(thisACCOUNT:ACCOUNT => ( ( thisACCOUNT : exceeded => ( Balance(thisACCOUNT)<-Overdraft(thisACCOUNT) )) )) & !(thisACCOUNT).(thisACCOUNT:ACCOUNT => ( ( thisACCOUNT : ok => ( Balance(thisACCOUNT)>=-Overdraft(thisACCOUNT) )) )) )

24. Changing a UML-B Model e.g. add new events to make changes to the overdraft limit increaseLimit =[ol>Overdraft] ==> overdraft:=ol reduceLimit =[ol<Overdraft] ==> overdraft:=ol increaseLimit = ANY thisACCOUNT,ol WHERE thisACCOUNT:ACCOUNT & ol:NAT THEN SELECT ol>Overdraft(thisACCOUNT) THEN SELECT thisACCOUNT : exceeded & Balance(thisACCOUNT)>=-ol THEN exceeded:=exceeded-{thisACCOUNT} || ok:=ok\/{thisACCOUNT} WHEN thisACCOUNT : exceeded & Balance(thisACCOUNT)<-ol THEN skip WHEN thisACCOUNT : ok THEN skip END || Overdraft(thisACCOUNT):=ol END END

25. ‘Advanced’ Instance Modelling CARDINALITY clause n => fixed (deferred or enumerated), SETS CC 3..3 => fixed numbered CONSTANTS C = 0..3 0..n => varying VARIABLES C : POW(possibleC) = {} constructors and destructors <<create>>, <<destroy>> INSTANCES clause {lille,paris,nantes} SETS CC = {lille,paris,nantes} Association classes CONSTANTS CC : POW(BB*AA) Inheritance CONSTANTS CC : POW1(SUPERC)

26. Decomposition of Event systems • As refinement adds detail systems get bigger...need to decompose into subsystems to cope • Event systems have no I/O...so subsystems cannot communicate • Instead, abstract away all details of events in other subsystems and model inputs as nondeterministic changes • ...but must not refine variables representing the interfaces !!

27. Architecture Packages represent models i.e. systems and their refinements, and after decomposition subsystems and their refinements Each package is translated into a separate B component Some subsystems may be implemented in hardware and some in software <---- refines

28. Decomposition of Event systems registerUser =[uu/:registered] ==>registered:=registered\/{uu} addCopy =[bb/:UNION(ll).(ll:LIBRARY | ll.collection)] ==>collection:=collection \/ {bb} ||IF bb.title /: catalog THEN catalog:=catalog\/{bb.title}END loan =[uu:ll.registered & self:ll.collection &self/:UNION(uu).(uu:USER | uu.borrows)]==>uu.borrows:=uu.borrows \/ {self} return = [self:uu.borrows] ==> uu.borrows:=uu.borrows-{self} • allocate events to subsystems to minimise shared data (data coupling).. • e.g. addCopy in one subsystem, registerUser,loan,return in another

29. Decomposition of Event systems • Maintenance subsystem is derived as follows: • 1) Identify data accessed by events of subsystem • 2) Remove unused data • 3) for each event not in subsystem, • a) add <<static>> stereotype, • b) delete any parameters, • c) delete any guards, • d) abstract away semantics by replacing any writes to variables of this subsystem with v1,v2,...vn:(invariant) OR if there are none, replace with skip. 1) addCopy refers to associations, collection, title and catalog and classes LIBRARY and BOOK. It also needs to know about the class TITLE in order to obtain the type for title and catalog. 2) the USER class and its associations can be deleted. 3) registerUser, loan and return all become skip

30. Decomposition of Event systems • registerUser = skip • addCopy =[bb/:UNION(ll).(ll:LIBRARY | ll.collection)]==>collection:=collection \/ {bb} ||IF bb.title /: catalog THEN catalog:=catalog\/{bb.title}END • loan = skip • return = skip

31. Decomposition of Event systems • registerUser =[uu/:registered] ==>registered:=registered\/{uu} • addCopy =$collection:(invariant) • loan =[uu:ll.registered & self:ll.collection &self/:UNION(uu).(uu:USER | uu.borrows)] ==>uu.borrows:=uu.borrows \/ {self} • return = [self:uu.borrows] ==>uu.borrows:=uu.borrows-{self}

32. UML 2.0 Components Subsystem1 Subsystem2 • UML1.x had no decomposition mechanism • Currently UML-B has no way of modelling the interface between subsystems • UML 2 components may provide an answer • Ports and channels will define the abstraction of ‘other subsystems’ events and/or shared interface variables

33. Subsystem design to code • recompose events into a single event • use imports to decompose into B modules • specify single event in terms of calls to operations in the imported modules

34. Subsystem design to circuit • design circuit in event B • add refinements to describe circuit events • when sufficient detail • use BHDL to VHDL converter

35. Future plans • RODIN • EC IST Strep project Starts 1st June 2004 (3 years) • Nokia, Praxis, VTEngControl, ClearSy, • U.Newcastle, U.Zurich, Åbo Akademi • Develop UML-B features (inheritance, Components, other UML notations?) • Integrate U2B with B# - new language - improved genericity features Click’nProve - new proof tools ProB - B model checker ProTest - model based test • Open source tool set running under Elipse