The Rodin Platform for Incremental Modelling in Event-B Stefan - PowerPoint PPT Presentation

The Rodin Platform for Incremental Modelling in Event-B Stefan Hallerstede University of Southampton FMCO 2008, 22/10/2008 www.deploy‐project.eu

Outline • Complex Systems Modelling in Event-B • Interplay of proof and modelling • Worked example: Access to secure building • Tool Animation • Conclusion 2

Design of complex systems • Need for rigorous modelling • The main purpose of modelling is reasoning – to improve our understanding of the system – to clarify assumptions about the system – to increase quality of system model • Need for refinement – Too many details to address final system directly 3

Reasoning about complex systems • Requires rigorous reasoning – Formal notation – Formal reasoning • This is offered by formal proof – Why prove? • To incrementally improve a model • To take advantage of failing proofs – What to prove? • Proof obligations associated with each model 4

List of core Event-B proof obligations • Feasibility of events • Invariant preservation by events • Refinement of events • Introduction of new events • Convergence of events • Enabledness of events 5

Outline • Complex Systems Modelling in Event-B • Interplay of proof and modelling • Worked example: Access to secure building • Tool Animation • Conclusion 6

Example of an Event-B machine Invariant properties: • inv1 : A user is authorised to be in certain rooms parameters • inv2 : A user can be guards at most in one room ac3ons • inv3 : A user can only be in rooms where he is authorised to be 7

Preservation of in ⊆ auth by event enter • Proof obligation: invariant in ⊆ auth guards u / ∈ dom( in ) u �→ r ∈ auth modified invariant ⊢ in ∪ { u �→ r } ⊆ auth 8

Use of proof obligations for modelling • Modelling is an incremental activity Modelling Proof Obligations Proving • Proof obligations are automatically generated 9

Creating a model incrementally • What does this mean? • We do not demonstrate the actual tool “Rodin” – But focus on essential features – Removed everything that could distract • Aim: – To illustrate method and tool – Not to get distracted by features of the Rodin tool • By way of an example – Access to a secure building 10

Outline • Complex Systems Modelling in Event-B • Interplay of proof and modelling • Worked example: Access to secure building • Tool Animation • Conclusion 11

Description of the secure access model • Abstract model – Users , Rooms – Entering/leaving rooms; adding/removing authorisations • Refined model – Tokens – Data-refinement of abstract model • The model itself is not of importance – But the way we create it is important 12

Focus on three modelling scenarios • Adding events 1. Reasoning about guards and invariants • Refining an event 2. Reasoning about parameters 3. Reasoning about guards and invariants 13

Layout of the modelling canvas Model Proof ☐ ☐ � ☐ Mode ☐ Proof ☐ Obliga3ons ☐ ☐ ☐ proof obliga3on: ☐ ☐ proof succeeded: � ☐ proof failed:  ☐ ☐ ☐ 14

Colouring conventions for formulas Model Proof ☐ ☐ � constants are blue‐green parameters are red ☐ ☐ ☐ ☐ utok ( t ) �→ rtok ( t ) ∈ auth ☐ ☐ ☐ ☐ ☐ variables are blue ☐ ☐ 15

Creation of the abstract model Model Proof Summary: ☐ ☐ � ☐ • Variables: in , auth ☐ ☐ • Events: ☐ ☐ – enter – enter building ☐ ☐ – leave – leave building ☐ ☐ – addAuth – add authorisation ☐ ☐ – remAuth – remove authorisation 16

Location and authorisation of users Model Proof ☐ invariants ☐ � inv 1 : auth ∈ User ↔ Room ☐ inv 2 : in ∈ User � → Room ☐ inv 3 : in ⊆ auth ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ 17

Location and authorisation of users Model Proof ☐ invariants ☐ � inv 1 : auth ∈ User ↔ Room ☐ inv 2 : in ∈ User � → Room ☐ inv 3 : in ⊆ auth ☐ ☐ ☐ initialisation ☐ act 1 : in := ∅ ☐ act 2 : auth := ∅ ☐ ☐ ☐ ☐ 18

Location and authorisation of users Model Proof ☐ invariants ☐ � inv 1 : auth ∈ User ↔ Room ☐ inv 2 : in ∈ User � → Room ☐ inv 3 : in ⊆ auth ☐ ☐ ☐ initialisation ☐ act 1 : in := ∅ ☐ act 2 : auth := ∅ ☐ ☐ ☐ ☐ 19

Location and authorisation of users Model Proof  invariants � inv 1 : auth ∈ User ↔ Room  inv 2 : in ∈ User � → Room ☐ inv 3 : in ⊆ auth ☐ ☐ ☐ initialisation ☐ act 1 : in := ∅ ☐ act 2 : auth := ∅ ☐ ☐ ☐ ☐ 20

Entering a room Model Proof  event enter � any  u, r ☐ when ☐ grd 1 : u �∈ dom( in ) ☐ ☐ grd 2 : u �→ r ∈ auth ☐ then ☐ act 1 : in := in ∪ { u �→ r } ☐ end ☐ ☐ ☐ 21

Entering a room Model Proof  event enter � any  u, r ☐ when ☐ grd 1 : u �∈ dom( in ) ☐ ☐ grd 2 : u �→ r ∈ auth ☐ Proof obliga3on: then ☐ act 1 : in := in ∪ { u �→ r } ☐ Preserva3on of end invariant inv3 ☐ ☐ ☐ 22

Entering a room Model Proof Preservation of invariant inv3  in ⊆ auth �  u / ∈ dom( in ) ☐ u �→ r ∈ auth ☐ ☐ ⊢ ☐ ☐ Proof obliga3on: in ∪ { u �→ r } ⊆ auth ☐ ☐ Preserva3on of invariant inv3 ☐ ☐ ☐ 23

Entering a room Model Proof Preservation of invariant inv3  in ⊆ auth �  u / ∈ dom( in ) ☐ u �→ r ∈ auth  ☐ ⊢ ☐ ☐ Proof obliga3on: in ∪ { u �→ r } ⊆ auth ☐ ☐ Preserva3on of invariant inv3 ☐ ☐ ☐ 24

Entering a room Model Proof  event enter � any  u, r ☐ when  grd 1 : u �∈ dom( in ) ☐ ☐ grd 2 : u �→ r ∈ auth ☐ then ☐ act 1 : in := in ∪ { u �→ r } ☐ end ☐ ☐ ☐ 25

Entering a room Model Proof  event enter � any  u, r � when  grd 1 : u �∈ dom( in ) ☐ ☐ grd 2 : u �→ r ∈ auth ☐ then ☐ act 1 : in := in ∪ { u �→ r } ☐ end ☐ ☐ ☐ 26

Leaving a room Model Proof  event leave � any  u � when  grd 1 : u ∈ dom( in ) ☐ ☐ then ☐ act 1 : in := { u } ⊳ − in ☐ end ☐ ☐ ☐ ☐ 27

Leaving a room Model Proof  event leave � any  u � when  grd 1 : u ∈ dom( in ) ☐ ☐ then ☐ act 1 : in := { u } ⊳ − in ☐ end ☐ ☐ ☐ ☐ 28

Leaving a room Model Proof  event leave � any  u � when  � grd 1 : u ∈ dom( in )  then ☐ act 1 : in := { u } ⊳ − in ☐ end ☐ ☐ ☐ ☐ 29

Adding an authorisation Model Proof  event addAuth � any  u, r � when  � grd 1 : u ∈ User  grd 2 : r ∈ Room ☐ then ☐ act 1 : auth := auth ∪ { u �→ r } ☐ end ☐ ☐ ☐ 30

Adding an authorisation Model Proof  event addAuth � any  u, r � when  � grd 1 : u ∈ User  grd 2 : r ∈ Room ☐ then ☐ act 1 : auth := auth ∪ { u �→ r } ☐ end ☐ ☐ ☐ 31

Adding an authorisation Model Proof  event addAuth � any  u, r � when  � grd 1 : u ∈ User  grd 2 : r ∈ Room  then  act 1 : auth := auth ∪ { u �→ r } ☐ end ☐ ☐ ☐ 32

Removing an authorisation Model Proof  event remAuth � any  u, r � when  � grd 1 : u ∈ User  grd 2 : r ∈ Room  then  act 1 : auth := auth \ { u �→ r } ☐ end ☐ ☐ ☐ 33

Removing an authorisation Model Proof  event remAuth � any  u, r � when  � grd 1 : u ∈ User  grd 2 : r ∈ Room  then  act 1 : auth := auth \ { u �→ r } ☐ end ☐ ☐ ☐ 34

Removing an authorisation Model Proof  event remAuth � any  u, r � when  Proof obliga3on: � grd 1 : u ∈ User  grd 2 : r ∈ Room Preserva3on of  then invariant inv3  act 1 : auth := auth \ { u �→ r }  end  ☐ ☐ 35

Removing an authorisation Model Proof Preservation of invariant inv3  in ⊆ auth �  u ∈ User Possible remedies: � r ∈ Room • Modify ac3on:  ➞ Remove user u from building � ⊢  • Modify guard:  in ⊆ auth \ { u �→ r } ➞ Require user u not in building   • Modify guard:  ➞ Require user u not in room r ☐ u �→ r �∈ in ☐ 36

Removing an authorisation Model Proof  event remAuth � any  u, r � when  � grd 1 : u ∈ User  grd 2 : r ∈ Room  then  act 1 : auth := auth \ { u �→ r }  end  ☐ ☐ 37

Removing an authorisation Model Proof  event remAuth � any  u, r � when  � grd 1 : u ∈ User  grd 2 : u �→ r �∈ in  then  act 1 : auth := auth \ { u �→ r }  end  ☐ ☐ 38

Removing an authorisation Model Proof Preservation of invariant inv3  in ⊆ auth �  u ∈ User � u �→ r / ∈ in  � ⊢   in ⊆ auth \ { u �→ r }    ☐ ☐ 39