Event-B and Rodin Overview

Slides:



Advertisements
Similar presentations
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Advertisements

25 February 2009Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department.
Specification, Partitioning, and Composition Techniques for Web Applications in the Context of Event-B Abdolbaghi Rezazadeh Michael Butler University of.
An Integration of Program Analysis and Automated Theorem Proving Bill J. Ellis & Andrew Ireland School of Mathematical & Computer Sciences Heriot-Watt.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
Describing Syntax and Semantics
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
End-to-End Design of Embedded Real-Time Systems Kang G. Shin Real-Time Computing Laboratory EECS Department The University of Michigan Ann Arbor, MI
6 Feb 08 Deploying Rodin Michael Butler Dependable Systems and Software Engineering University of Southampton.
Process Modeling SYSTEMS ANALYSIS AND DESIGN, 6 TH EDITION DENNIS, WIXOM, AND ROTH © 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 1 Roberta M. Roth.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
Structured Event Refinement Michael Butler University of Southampton users.ecs.soton.ac.uk/mjb.
The Software Development Life Cycle: An Overview
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
Chapter 7 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 Introduction to Software Engineering Lecture 1.
© Gudmund Grov & Andrew Ireland Dependable Systems Group Planning for System Development Gudmund Grov & Andrew Ireland Dependable Systems Group School.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Formal Methods.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
UML - Development Process 1 Software Development Process Using UML.
Formal Methods in Software Engineering1 Today’s Agenda  Mailing list  Syllabus  Introduction.
Requirement Specification SRS document is a contract between the development team and the customer How do we communicate the Requirements to others? Firm.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Principles of Programming & Software Engineering
Requirements Specification
Interface Concepts Modeling Core Team
UNIT-IV Designing Classes – Access Layer ‐ Object Storage ‐ Object Interoperability.
Formal Specification.
Programming paradigms
Chapter 1: Introduction to Systems Analysis and Design
Systems Analysis and Design in a Changing World, Fourth Edition
Definition CASE tools are software systems that are intended to provide automated support for routine activities in the software process such as editing.
SysML 2.0 Formalism: Requirement Benefits, Use Cases, and Potential Language Architectures Formalism WG December 6, 2016.
What is UML? What is UP? [Arlow and Neustadt, 2005] October 5, 2017
Principles of Programming and Software Engineering
Software Processes (a)
System Modeling Chapter 4
Abstract descriptions of systems whose requirements are being analysed
Daniel Amyot and Jun Biao Yan
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
Software Processes.
Component-Level Design
Informatics 121 Software Design I
Design and Programming
Evaluating Compuware OptimalJ as an MDA tool
Chapter 20 Object-Oriented Analysis and Design
BPMN - Business Process Modeling Notations
Chapter 5 Architectural Design.
Analysis models and design models
An Introduction to Software Architecture
Chapter 1: Introduction to Systems Analysis and Design
Department of Computer Science Abdul Wali Khan University Mardan
Chapter 5 Architectural Design.
Design Yaodong Bi.
Human Computer Interaction Lecture 14 HCI in Software Process
Chapter 1: Introduction to Systems Analysis and Design
Software Development Process Using UML Recap
Presentation transcript:

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

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

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

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

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 ACTIVITY authorised location takeplace ROOM

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 ]

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

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?

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

Counterexample from model checking with ProB plug-in for Rodin

Failing proof with Rodin

Strengthen guard of RemAuth

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

Failing refinement proof

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) ]

Invariant enables PO discharge

But get new failing PO

Source of failing PO

Strengthen guard of refined RemAuth

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? 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) ]

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

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

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 ProB 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) 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

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) StartWrite(f) PageWrite(f,p) EndWrite(f) all(b) StartPage(f,p) ByteWrite(f,p,b) EndPage(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 Partition the variables E2b v2 E3 E1 E2a v1

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

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_M0 to Railway_M2 Decompose Railway_M2 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 ProB model checker: animation, consistency and refinement checking Graphical model animation Requirements management Team-based development Decomposition Code generation …

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

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 REDO this diagram

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

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