1. Event-B and Rodin Overview
Michael Butler
School of Electronics and Computer Science
University of Southampton, UK

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

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

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

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

6. Formal Methods Clear specifications (contract)
Mathematical techniques for 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

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

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

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

10. System level Examples of systems: System level reasoning:
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

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

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

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

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

15. Variables and invariants of Event-B model
Variables of Event-B model
@inv1 authorised ∈ User ↔ Activity // relation
@inv2 takeplace ∈ Room ↔ Activity // relation
@inv3 location ∈ User ⇸ Room // 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
@inv4 ∀u,r . u∈dom(location) ∧ location( u ) = r ⇒
takeplace[ r ] ⊆ authorised[ u ]

16. State snapshot as tables
User
Activity u1 a1 a2 u2
Room
Activity r1 a1 a2 r2
authorised
takeplace
User
Room u1 r1 u2 r2 u3
location

17. Event for entering a room
when
grd1   :    u ∈ User
grd2   :    r ∈ Room
grd3   :    takeplace[ r ] ⊆ authorised[ u ]
then
act1   :    location(u)  :=  r
end
Does this event maintain the security invariant?

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

19. Remove authorisation
RemoveAuth(u,a) ≙ when grd1 : u ∈ User grd2 : a ∈ Activity grd3 : u ↦ a ∈ authorised then act1 : authorised := authorised ∖ { u ↦ a } end Does this event maintain the security invariant?

20. Counterexample from model checking with ProB plug-in for Rodin

21. Failing proof with Rodin

22. Strengthen guard of RemAuth

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

24. Failing refinement proof

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

26. Invariant enables PO discharge

27. But get new failing PO

28. Source of failing PO

29. Strengthen guard of refined RemAuth

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

31. What, how, why written in B
What does it achieve?
inv4: u∈dom(location) ∧ location( u ) = r ⇒
takeplace[ r ] ⊆ authorised[ u ]
How does it work?
grd3b: t ∈ valid ∧ r = room(t) ∧ u = holder(t)
Why does it work?
  inv5: t ∈ valid   ⇒ 
   takeplace [ room(t) ]  ⊆  authorised[ holder(t) ]

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

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

34. 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 refinement step we refine one model M1 to another model M2:
M2 is a refinement of M1
M1 is an abstraction of M2
Don’t throw M1 away

35. Refinement (contined)
We can perform a series of refinement steps to produce a series of models M1, M2, M3, ...
Facilitates abstraction: we can postpone treatment of some system features to later refinement steps
Event-B provides a notion of consistency of a refinement:
We use proof to verify the consistency of a refinement step
Failing proof can help us identify inconsistencies in a refinement step

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

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

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

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

40. Break

41. Part 2 Decomposition Rodin tool overview Provers ProB UML-B
Code generation (under development)

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

43. Atomicity decomposition example
Write(f)
all(p)
StartWrite(f)
PageWrite(f,p)
EndWrite(f)
Refine atomic write of a file into a process that writes individual file pages atomically
Events for different files are interleaved

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

45. Hierarchical refinement
Write(f)
all(p)
StartWrite(f)
PageWrite(f,p)
EndWrite(f)
all(b)
StartPage(f,p)
ByteWrite(f,p,b)
EndPage(f,p)

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

47. Shared Event Decomposition
Partition the variables
E2b v2 E3 E1
E2a v1

48. Shared Variable Decomposition
E1, E2
E3, E4
Partition the events E1 E2
E3’ v1 v2
E2’ E3 v2 v3 E4

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

50. Railway System Decomposition for Railway
3 refinement levels: Railway_M0 to Railway_M2
Decompose Railway_M2
Context decomposition

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

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

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

54. Statistics from Flash-based file development in Event-B

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

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

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

58. Abstract Class Diagram
Refined Class Diagram
REDO this diagram

59. Abstract State Machine
Nested State Machine
Refined State Machine

60. 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 (IL1)
Translation rules from extended Event-B to IL1
Back-end to textual Ada/C via simple rules
Deploy 2nd Review, 24/25 March 2010, Newcastle

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