Event-B and Rodin Overview Michael Butler School of

Event-B and Rodin Overview Michael Butler School of Electronics and Computer Science University of Southampton, UK www. event-b. org www. deploy-project. eu

Part 1 • Motivation • Event-B overview • Rational design with Event-B: – abstraction – refinement – proof and mechanical analysis • Proof and use of Rodin tools

What’s wrong with the V model? Validation testing Specification Preliminary design Integration testing Detailed design Unit testing Coding Many errors are introduced early but detected late – such errors are expensive to fix.

Why is it difficult to detect errors? • Lack of precision – ambiguities – inconsistencies • Too much complexity: – complexity of requirements – complexity of operating environment – complexity of designs

Precise models (blueprints) • Precision from early stages with models – Amenable to analysis by tools – Identify and fix ambiguities and inconsistencies as early as possible • Mastering complexity – Encourage abstraction – Incremental analysis and design through refinement and decomposition

Formal Methods • Mathematical techniques formulation and analysis of systems • Formal methods facilitate: – Clear specifications (contract) – Rigorous validation and verification Validation: does the contract specify the right system? – answered informally Verification: does the finished product satisfy the contract? – can be answered formally

Early stage analysis Validation testing Specification Validation Verification Architectural design Validation Verification Detailed design Verification Coding Integration testing Unit testing

Rapid prototying versus modelling • Rapid prototying: provides early stage feedback on system functionality – Plays an important role in getting user feedback – and in understanding some design constraints – But we will see that formal modelling and proof provide a deep understanding that is hard to achieve with rapid prototyping • Advice: use any approach that improves design process!

Event-B (Abrial) • State-transition model (like ASM, B, VDM, Z) – set theory as mathematical language • Refinement (based on action systems by Back) – data refinement – one-to-many event refinement – new events (stuttering steps) • Proof method – Refinement proof obligations (POs) generated from models – Automated and interactive provers for POs

System level • Examples of systems: – Train signalling system – Mechanical press system – Access control system – Air traffic information system – Electronic purse system – Distributed database system – Cruise control system –… • System level reasoning: – Involves abstractions of overall system not just software components

Rational design, by example • Example: access control system • Example intended to give a feeling for: – modelling language – abstraction and refinement – role of verification and Rodin tool

Access control system Users are authorised to engage in activities User authorisation may be added or revoked Activities take place in rooms Users gain access to a room using a one-time token provided they have authority to engage in the room activities • Tokens are issued by a central authority • Tokens are time stamped • A room gateway allows access with a token provided the token is valid • •

Extracting the essence • Access Control Policy: Users may be in a room only if they are authorised to engage in all activities that may take place in that room • To express this we only require Users, Rooms, Activities and relationships between them • Abstraction: focus on key entities in the problem domain

Diagrammatic representation of an abstract model USER authorised location ACTIVITY takeplace ROOM

Variables and invariants of Event-B model Variables of Event-B model @inv 1 authorised ∈ User ↔ Activity @inv 2 takeplace ∈ Room ↔ Activity @inv 3 location ∈ User Room // relation // partial function Access control invariant: if user u is in room r, then u must be authorised to engaged in all activities that can take place in r @inv 4 ∀u, r. u∈dom(location) ∧ location( u ) = r ⇒ takeplace[ r ] ⊆ authorised[ u ]

State snapshot as tables User Activity Room Activity u 1 a 1 r 1 a 1 u 1 a 2 r 1 a 2 u 2 a 2 r 2 a 1 authorised takeplace User Room u 1 r 1 u 2 r 2 u 3 location

Event for entering a room Enter ≙ when grd 1 : grd 2 : grd 3 : then act 1 : end u ∈ User r ∈ Room takeplace[ r ] ⊆ authorised[ u ] location(u) : = r Does this event maintain the security invariant?

Role of invariants and guards • Invariants: specify properties of model variables that should also remain true – violation of invariant is undesirable – use (automated) proof to verify invariant preservation • Guards: specify conditions under which events may occur – should be strong enough to ensure invariants are maintained – but not so strong that they prevent desirable behaviour

Remove authorisation Remove. Auth(u, a) ≙ when grd 1 : u ∈ User grd 2 : a ∈ Activity grd 3 : u ↦ a ∈ authorised then act 1 : authorised : = authorised ∖ { u ↦ a } end Does this event maintain the security invariant?

Counterexample from model checking with Pro. B plug-in for Rodin

Failing proof with Rodin

Strengthen guard of Rem. Auth

Now we construct a new model (refinement) USER holder authorised location ACTIVITY takeplace ROOM TOKEN room Abstract guard on a user and room for entering grd 3: takeplace[ r ] ⊆ authorised[ u ] is replaced by a guard on a token grd 3 b: t ∈ valid ∧ room(t) = r ∧ holder(t) = u

Failing refinement proof

Gluing invariant USER holder authorised location ACTIVITY takeplace ROOM TOKEN room To ensure consistency of the refinement we need invariant: inv 6: t ∈ valid ⇒ takeplace [ room(t) ] ⊆ authorised[ holder(t) ]

Invariant enables PO discharge

But get new failing PO

Source of failing PO

Strengthen guard of refined Rem. Auth

Rational design – what, how, why • What does it achieve? if user u is in room r, then u must be authorised to engaged in all activities that can take place in r • How does it work? Check that a user has a valid token • Why does it work? For any valid token t, the holder of t must be authorised to engage in all activities that can take place in that room

What, how, why written in B • What does it achieve? inv 4: u∈dom(location) ∧ location( u ) = r ⇒ takeplace[ r ] ⊆ authorised[ u ] • How does it work? grd 3 b: t ∈ valid ∧ r = room(t) ∧ u = holder(t) • Why does it work? inv 5: t ∈ valid ⇒ takeplace [ room(t) ] ⊆ authorised[ holder(t) ]

Abstraction • Abstraction can be viewed as a process of simplifying our understanding of a system. • The simplification should – focus on the intended purpose of the system – ignore details of how that purpose is achieved. • The modeller should make judgements about what they believe to be the key features of the system.

Abstraction (continued) • If the purpose is to provide some service, then – model what a system does from the perspective of the service users – ‘users’ might be computing agents as well as humans. • If the purpose is to control, monitor or protect some phenomenon, then – the abstraction should focus on those phenomenon – in what way should they be controlled or protected? – why should they be monitored?

Refinement • Refinement is a process of enriching or modifying a model in order to – augment the functionality being modelled, or – explain how some purpose is achieved • In a reﬁnement step we reﬁne one model M 1 to another model M 2: – M 2 is a reﬁnement of M 1 – M 1 is an abstraction of M 2 – Don’t throw M 1 away

Refinement (contined) • We can perform a series of refinement steps to produce a series of models M 1, M 2, M 3, . . . • Facilitates abstraction: we can postpone treatment of some system features to later reﬁnement steps • Event-B provides a notion of consistency of a reﬁnement: – We use proof to verify the consistency of a reﬁnement step – Failing proof can help us identify inconsistencies in a reﬁnement step

Proof obligations in Event-B • Well-definedness – e. g, avoid division by zero, out of bounds access • Invariant preservation – each event maintains invariants • Guard strengthening – Refined event only possible when abstract event possible • Simulation – update of abstract variable correctly simulated by update of concrete variable

Proof and model checking • Model checking: force the model to be finite state and explore state space looking for invariant violations – completely automatic – powerful debugging tool (counter-example) • (Semi-)automated proof: based on logical deduction rules – no restrictions on state space – leads to discovery of invariants that deepen understanding – not completely automatic

Event-B is not the full solution • Event-B is a general purpose formalism • Particular domains/paradigms require additional guidelines, patterns and language extensions – some results on this in Deploy • Not tied to any specific requirements engineering approach – possible to link with approaches, e. g. , Problem Frames • Can use alternative syntax such as UML – UML-B (class diagrams, state machine diagrams) – Integration with SAP UML-like language and tool • Not tied to any specific programming language – Classical B has automatic generation of Ada and C – In Deploy working on code generation from Event-B (Ada and C) • No support for continuous or stochastic reasoning in Event-B – some on-going work

Important Messages • Formal modelling can be applied to systems • Role of formal modelling: – increase understanding – decrease errors • Role of refinement: – manage complexity through multiple levels of abstraction • Role of verification: – improve quality of models (consistency, invariants) • Role of tools: – make verification as automatic as possible, pin-pointing errors and even suggesting improvements • Event-B can and should be linked with complementary methods

Break

Part 2 • Decomposition • Rodin tool overview – Provers – Pro. B – UML-B – Code generation (under development)

Decomposition • Beneficial to model systems abstractly with little architectural structure and large atomic steps – e. g. , file transfer, replicated database transaction • Refinement and decomposition are used to add structure and then separate elements of the structure • Atomicity decomposition: Decomposing large atomic steps to more fine-grained steps • Model decomposition: Decomposing refined models to for (semi-)independent refinement of sub-models

Atomicity decomposition example Write(f) all(p) Start. Write(f) Page. Write(f, p) End. Write(f) • Refine atomic write of a file into a process that writes individual file pages atomically • Events for different files are interleaved

Event refinement diagrams • Based on diagrammatic notation of Jackson System Development • Graphical representation of how abstract atomic events are decomposed in refinement • Useful for sketching designs before committing to models • Provide additional traceability information over and above that provided by Event-B refinement • We can exploit the hierarchical nature of diagrams to represent event refinement

Hierarchical refinement Write(f) all(p) Start. Write(f) Page. Write(f, p) End. Write(f) all(b) Start. Page(f, p) Byte. Write(f, p, b) End. Page(f, p)

Machine Decomposition styles • Shared Event • Components interact by synchronising over shared events – no shared variables • Shared events may have common parameters (message-passing synchronisation) • Shared Variable • Components interact through shared variables • Both are forms of Jigsaw decomposition (Jackson)

Shared Event Decomposition E 1 v 1 M v 1 E 1 M 1 E 2 a v 1 E 2 E 3 v 2 Partition the variables E 2 b M 2 E 3 v 2

Shared Variable Decomposition E 1 E 2 v 1 M E 3 v 2 v 3 E 1, E 2 E 1 M 1 E 2 v 1 E 3, E 4 M 2 Partition the events E 2’ E 3’ v 2 E 4 E 3 v 2 E 4 v 3

Refinement after decomposition • Shared event: can refine sub-model provided • Common parameters of shared events are maintained • Shared variable: can refine sub-model provided • External events are not refined (rely condition) • Invariants used in refinement are preserved by external events

Railway System • Decomposition for Railway • 3 refinement levels: Railway_M 0 to Railway_M 2 • Decompose Railway_M 2 • Context decomposition

Rodin Open Tool Platform • Extension of Eclipse IDE • Repository of structured modelling elements • Rodin Eclipse Builder manages: – Well-formedness + type checker – Consistency/refinement Proof Obligation generator – Proof manager – Propagation of changes • Extension points www. event-b. org

Differential proving in Rodin • Models are constantly being changed • When a model changes, proof impact of changes should be minimised as much as possible: • Sufficiency comparison of POs – In case of success, provers return list of used hypotheses – Proof valid provided the used hypothesis are in the new version of a PO • Model refactoring: – Identifier renaming applied to models (avoiding name clash) – Corresponding POs and proofs automatically renamed

Rodin Proof Manager (PM) • • PM constructs proof tree for each PO Automatic and interactive modes PM manages used hypotheses PM calls reasoners to – discharge goal, or – split goal into subgoals • Collection of reasoners: – simplifier, rule-based, decision procedures, … • Basic tactic language to define PM and reasoners

Statistics from Flash-based file development in Event-B

Rodin Plug-ins • • Linking UML and Event-B Pro. B model checker: animation, consistency and refinement checking Graphical model animation Requirements management Team-based development Decomposition Code generation …

Pro. B • Animator and model checker – searches for invariant violations – searches for proof obligation violations (under development) • Implementation uses constraint logic programming – makes all types finite – exploits symmetries in B types

UML-B • UML-like language • Package, Class, State diagrams – Package used to structure a refinement chain – Class represents a set – Attributes and associations represent relations – State machine diagrams determine event execution • Event-B as constraint and action language – Guards, invariants, actions • UML-B plug-in for Rodin – Generates Event-B from UML-B

Abstract Class Diagram Refined Class Diagram 58

Abstract State Machine Nested State Machine Refined State Machine

Code generation (on-going) • Extending Event-B with process syntax – Add structured control flow to machine: ; / If / While – Multiple parallel processes, sharing data • Data types: – Support for basic types (integers, arrays) – Additional data types defined in theory components (math extension) • Generation: – Intermediate language based on Ada subset (IL 1) – Translation rules from extended Event-B to IL 1 – Back-end to textual Ada/C via simple rules Deploy 2 nd Review, 24/25 March 2010, Newcastle 60

Contributors to Rodin Jean-Raymond Abrial Stefan Hallerstede Farhad Mehta Thierry Lecomte Mathieu Clabaut Alexei Iliasov Jens Bendisposto Dominique Cansell Renato Silva Michael Jastram Issam Maamria Abdolbaghi Rezazadeh Carine Pascal Vitaly Savicks. . . Laurent Voisin Thai Son Hoang Christophe Metayer Michael Leuschel Colin Snook Nicolas Beauger Kriangsak Damchoom Cliff Jones Francois Terrier Fabian Fritz Andy Edmunds Mar Yah Said Andreas Furst Thomas Muller