Difference between pages "Event-B Examples" and "Event-B Indexers"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>WikiSysop
 
imported>Laurent
 
Line 1: Line 1:
{{TOCright}}
+
==Purpose==
This page is for listing available example Event-B/Rodin projects.
 
  
== Year 2011 ==
+
Event-B indexers populate the index repository. Currently, indexers are implemented for the following files :
=== [[Development of a Heating Controller System]]===
+
* machine (.bum)
By Abdolbaghi Rezazadeh.
+
* context (.buc)
  
This material describes an Event-B development of a simple heating controller. This is a first case study that covers the entire development process; starting from a system specification and ending up in an implementation in the Ada programing language. The overall aim of this case study is to put in practice the recommended methodological aspects of Event-B, particularly those aspects of modelling concerned with decomposition and code generation. We begin the tutorial with an overview of the [http://wiki.event-b.org/index.php/Development_of_a_Heating_Controller_System abstract development] that forms the basis for subsequent Tasking Event-B modelling. In the [http://wiki.event-b.org/index.php?title=Tasking_Event-B_Tutorial Tasking Event-B tutorial] the developer is guided, step-by-step, through the final construction stages of a partially completed model. The tutorial provides an introduction to some of the main constructs used when modelling with Tasking Event-B.
 
  
===[http://deploy-eprints.ecs.soton.ac.uk/316/ Vehicle On-Board Controller for Trains]===
+
==Event-B Occurrence Kinds==
  
This material describes an Event-B development of a Vehicle On-Board Controller for trains.  
+
So far, the following occurrence kinds have been defined :
The purpose of the system under study is to detect the driving mode wished by the train
+
* DECLARATION : when a variable, a carrier set, ..., is declared
driver (he has some buttons at his disposal to do that) and decide accordingly whether
+
* REFERENCE : when a variable, a carrier set, ..., is referenced (but not modified)
this mode is feasible so that the current mode of the train could be (or not be) that
+
* MODIFICATION : when a variable is modified (e.g., occurs in the left-hand side of an event action)
wished by the driver. A paper describing the modelling methodology and a Rodin archive
+
* REDECLARATION : when a variable, parameter or event is redeclared (refined).
are available here:
+
Please notice the distinction between the index repository notion of declaration ({{class|IDeclaration}}) and the Event-B occurrence kind DECLARATION.
http://deploy-eprints.ecs.soton.ac.uk/316/
 
  
== Year 2010 ==
+
==What Is Indexed==
  
===[http://deploy-eprints.ecs.soton.ac.uk/227/ Modularisation Training]===
+
Currently, indexed elements are :
By Alexei Iliasov.
+
* carrier sets
 +
* constants
 +
* variables
 +
* events
 +
* parameters
  
This is teaching material for those wishing to learn about the Modularisation plugin. It includes a development and detailed explanatory slides.  
+
Formulas which cannot be parsed are ignored.
  
 +
In the descriptions below, the following notation will be used to specify locations :
 +
* [element] : internal location
 +
* [element/attribute] : attribute location
 +
* [element/attribute/begin..end] : attribute substring location
  
== Year 2009 ==
+
===Context Indexer===
  
===[http://deploy-eprints.ecs.soton.ac.uk/150/ Code Generation - Shared Buffer Example]===
+
====Dependencies====
By Andrew Edmunds and Michael Butler
+
* extended contexts
  
The document describes an example Event-B development of a shared buffer and reading/writing processes. An implementation is then specified using the OCB notation; and a description of the implementation refinement and Java source is shown. An archive file contains the abstract Event-B development, however the implementation refinement proof is ongoing.
+
====Declarations====
 +
* carrier sets
 +
* constants
  
=== [http://deploy-eprints.ecs.soton.ac.uk/138/ Well-ordering theorem]===  
+
====Occurrences====
By Jean-Raymond Abrial.
 
  
The slides outline the use of Rodin in the proof of Well-ordering theorem. The archive contains the
+
* DECLARATION of carrier sets [CarrierSet/Identifier]
Rodin development.
+
* DECLARATION of constants [Constant/Identifier]
 +
* REFERENCE of elements in axioms [Axiom/Predicate/b..e]
 +
* REFERENCE of elements in theorems [Theorem/Predicate/b..e]
  
 +
Example:
  
=== [[Development of a flash-based filestore]]===
+
  Ctx
By Kriangsak Damchom and Michael Butler.
+
  Sets
 +
    S
 +
  Constants
 +
    C
 +
  Axioms
 +
    axm1 : C ∈ S
  
The paper outlines the use of Event-B in the development of a flash-based filestore.  The archive contains the
+
We will end up with the following occurrences :
Event-B development.
 
  
=== [http://deploy-eprints.ecs.soton.ac.uk/107/ Real-time controller for a water tank]===
+
  S :
By Michael Butler.
+
    DECLARATION in [S/Identifier]
 +
    REFERENCE in [axm1/Predicate/4..5]
 +
  C :
 +
    DECLARATION in [C/Identifer]
 +
    REFERENCE in [axm1/Predicate/0..1]
  
The draft paper outlines an approach to treating continuous behaviour in Event-B by a discrete approximation.
+
====Exports====
An example of a water tank system is used to illustrate the proposed approach.  The archive contains the
+
* imported and declared carrier sets
Event-B development for the water tank system.
+
* imported and declared constants
  
=== [http://deploy-eprints.ecs.soton.ac.uk/95/ UML-B Development of an ATM]===  
+
===Machine Indexer===
By Mar Yah Said,  Michael Butler and Colin Snook.
 
  
This paper outlines support for refinement of classes and statemachines in UML-B and issustrates these
+
====Dependencies====
with an Automated Teller Machine (ATM) example.  The ATM development is contained in a Rodin
+
* refined machines
archive.  It consists of an abstract model focusing on bank account updates.  The ATM, pin cards and
+
* seen contexts
messaging between ATMs and a bank server are introduced in successive refinements.
 
  
=== [http://deploy-eprints.ecs.soton.ac.uk/84/ MIDAS: A Formally Constructed Virtual Machine]===  
+
====Declarations====
By [[User:Steve|Steve]].
+
* variables
 +
* events
 +
* parameters
  
MIDAS (Microprocessor Instruction and Data Abstraction System) is a specification of an Instruction Set Architecture (ISA). It is refined to a usable Virtual Machine (VM) capable of executing binary images compiled from the C language. It was developed to demonstrate a methodology for formal construction of various ISAs in Event-B via a generic model. There are two variants: a stack-based machine and a randomly accessible register array machine. The two variants employ the same instruction codes, the differences being limited to register file behavior.
+
====Occurrences====
 +
* DECLARATION of (local) variables [Root]
 +
* DECLARATION of (local) events [Root]
 +
* DECLARATION of (local) parameters [Event]
 +
* REDECLARATION of abstract variables in the local variables that redeclare them [Variable/Identifier]
 +
* REDECLARATION of abstract events in the local events that refine them [Event/RefinesEvent/Target]
 +
* REDECLARATION of abstract parameters in the local parameters that redeclare them [Parameter/Identifier]
 +
* REFERENCE of abstract parameters or variables in witnesses [Witness/Label]
 +
* REFERENCE of elements in invariants [Invariant/Predicate/b..e]
 +
* REFERENCE of elements in theorems [Theorem/Predicate/b..e]
 +
* REFERENCE of elements in variants [Variant/Expression/b..e]
 +
* REFERENCE of elements in guards [Guard/Predicate/b..e]
 +
* REFERENCE of elements in witnesses [Witness/Predicate/b..e]
 +
* REFERENCE of non assigned elements in actions [Action/Assignment/b..e]
 +
* MODIFICATION of assigned elements in actions [Action/Assignment/b..e]
  
The archive supplied at [http://deploy-eprints.ecs.soton.ac.uk/84/ Deploy repository] contains: C-coded prototypes of the MIDAS VMs, an Event-B model refinement constructing the same VMs, the B2C Event-B to C auto-generation tool, C compiler/assembler/linkers for the VMs, an example C test suite, and execution environments for running compiled C on the machines.
+
Example :
  
MIDAS is described in detail in [http://deploy-eprints.ecs.soton.ac.uk/163/ Formal Construction of Instruction Set Architectures (PhD Thesis)].
+
  M1
 +
  VARIABLES
 +
    var1
 +
  INVARIANTS
 +
    inv1 : var1 > 0
 +
  EVENTS
 +
    INITIALISATION
 +
      THEN
 +
        act1 : var1 := 1
  
=== [http://deploy-eprints.ecs.soton.ac.uk/82/ Development of a Network Topology Discovery Algorithm]===
+
After indexing M1, we will have the following occurrences:
By ''Hoang, Thai Son and Basin, David and Kuruma, Hironobu and Abrial, Jean-Raymond''.
 
  
This paper and this Rodin development is another version of the [[#Link State Routing Development|Link State Routing Development]] presented in 2008.
+
  M1.var1 :
 +
    DECLARATION in [M1.Root]
 +
    REFERENCE in [M1.inv1/Predicate/0..4]
 +
    MODIFICATION in [M1.act1/Assignment/0..4]
 +
  M1.INITIALISATION :
 +
    DECLARATION in [M1.Root]
  
== Year 2008 ==
+
Then, if we add another machine
=== [http://deploy-eprints.ecs.soton.ac.uk/31/ Link State Routing Development]===
 
By ''Hoang, Thai Son and Basin, David and Kuruma, Hironobu and Abrial, Jean-Raymond''.
 
  
We present a formal development in Event-B of a distributed topology discovery algorithm. Distributed topology discovery is at the core several routing algorithms and is the problem of each node in a network discovering and maintaining information on the network topology. One of the key challenges in developing this algorithm is specifying the problem itself.We provide a specification that includes both safety properties, formalizing invariants that should hold in all system states, and liveness properties that characterize when the system reaches stable states. We specify these by appropriately combining invariants, event refinement, and proofs of event convergence and deadlock freedom. The combination of these features is novel and should be useful for formalizing and developing other kinds of semi-reactive systems, which are systems that react to, but do not modify, their environment.
+
  M2
 +
  REFINES
 +
    M1
 +
  VARIABLES
 +
    var1
 +
  EVENTS
 +
    INITIALISATION
 +
      THEN
 +
        act1 : var1 := 1
  
=== [http://deploy-eprints.ecs.soton.ac.uk/22/ Modelling and proof of a Tree-structured File System] ===
+
we will add the following occurrences :
By ''Damchoom, Kriangsak and Butler, Michael and Abrial, Jean-Raymond''.
 
  
We present a verified model of a tree-structured file system which was carried out using Event-B and the Rodin platform. The model is focused on basic functionalities affecting the tree structure including create, copy, delete and move. This work is aimed at constructing a clear and accurate model with all proof obligations discharged. While constructing the model of a file system, we begin with an abstract model of a file system and subsequently refine it by adding more details through refinement steps. We have found that careful formulation of invariants and useful theorems that can be reused for discharging similar proof obligations make models simpler and easier to prove.
+
  M1.var1 :
 +
    REDECLARATION in [M2.var1/Identifier]
 +
  M2.var1 :
 +
    DECLARATION in [M2.Root]
 +
    MODIFICATION in [M2.act1/Assignment/0..4]
 +
  M2.INITIALISATION :
 +
    DECLARATION in [M2.Root]
  
=== [http://deploy-eprints.ecs.soton.ac.uk/56/ Deliverable D8 D10.1 "Teaching Materials"] ===
+
====Exports====
By ''Abrial, Jean-Raymond and Hoang, Thai Son and Schmalz, Matthias''.
+
* imported carrier sets
 +
* imported constants
 +
* local variables
 +
* local events
 +
* local parameters
  
==Year 2007==
+
==Propagation==
=== [http://deploy-eprints.ecs.soton.ac.uk/9/ Redevelopment of an Industrial Case Study Using Event-B and Rodin]===
 
From ''Rezazadeh, Abdolbaghi and Butler, Michael and Evans, Neil''.
 
  
CDIS is a commercial air traffic information system that was developed using formal methods 15 years ago by Praxis, and it is still in operation today. This system is an example of an industrial scale system that has been developed using formal methods. In particular, the functional requirements of the system were specified using VVSL -- a variant of VDM. A subset of the original specification has been chosen to be reconstructed on the Rodin platform based on the new Event-B formalism. The goal of our reconstruction was to overcome three key difficulties of the original formalisation, namely the difficulty of comprehending the original specification, the lack of any mechanical proof of the consistency of the specification and the difficulty of dealing with distribution and atomicity refinement. In this paper we elucidate how a new formal notation and tool can help to overcome these difficulties.
+
Propagators are defined for :
 +
* events ({{class|EventPropagator}}) to propagate through refines
 +
* parameters ({{class|IdentifierPropagator}}) to propagate through redeclaration
 +
* variables ({{class|IdentifierPropagator}} as well) to propagate through redeclaration
  
[[Category:Examples]]
+
In the above example with machines M1 and M2, after both files have been indexed, we can query occurrences of M1.var1.
 +
 
 +
With no propagator, the result would be :
 +
 
 +
  M1.var1 :
 +
    DECLARATION in [M1.Root]
 +
    REFERENCE in [M1.inv1/Predicate/0..4]
 +
    MODIFICATION in [M1.act1/Assignment/0..4]
 +
    REDECLARATION in [M2.var1/Identifier]
 +
 
 +
Using the {{class|IdentifierPropagator}}, the result becomes :
 +
 
 +
  M1.var1 (propagated) :
 +
    DECLARATION in [M1.Root]
 +
    REFERENCE in [M1.inv1/Predicate/0..4]
 +
    MODIFICATION in [M1.act1/Assignment/0..4]
 +
    REDECLARATION in [M2.var1/Identifier]
 +
    DECLARATION in [M2.Root]
 +
    MODIFICATION in [M2.act1/Assignment/0..4]
 +
 
 +
[[Category:Developer documentation]]

Revision as of 09:40, 10 March 2009

Purpose

Event-B indexers populate the index repository. Currently, indexers are implemented for the following files :

  • machine (.bum)
  • context (.buc)


Event-B Occurrence Kinds

So far, the following occurrence kinds have been defined :

  • DECLARATION : when a variable, a carrier set, ..., is declared
  • REFERENCE : when a variable, a carrier set, ..., is referenced (but not modified)
  • MODIFICATION : when a variable is modified (e.g., occurs in the left-hand side of an event action)
  • REDECLARATION : when a variable, parameter or event is redeclared (refined).

Please notice the distinction between the index repository notion of declaration (IDeclaration) and the Event-B occurrence kind DECLARATION.

What Is Indexed

Currently, indexed elements are :

  • carrier sets
  • constants
  • variables
  • events
  • parameters

Formulas which cannot be parsed are ignored.

In the descriptions below, the following notation will be used to specify locations :

  • [element] : internal location
  • [element/attribute] : attribute location
  • [element/attribute/begin..end] : attribute substring location

Context Indexer

Dependencies

  • extended contexts

Declarations

  • carrier sets
  • constants

Occurrences

  • DECLARATION of carrier sets [CarrierSet/Identifier]
  • DECLARATION of constants [Constant/Identifier]
  • REFERENCE of elements in axioms [Axiom/Predicate/b..e]
  • REFERENCE of elements in theorems [Theorem/Predicate/b..e]

Example:

 Ctx
 Sets
   S
 Constants
   C
 Axioms
   axm1 : C ∈ S

We will end up with the following occurrences :

 S :
   DECLARATION in [S/Identifier]
   REFERENCE in [axm1/Predicate/4..5]
 C :
   DECLARATION in [C/Identifer]
   REFERENCE in [axm1/Predicate/0..1]

Exports

  • imported and declared carrier sets
  • imported and declared constants

Machine Indexer

Dependencies

  • refined machines
  • seen contexts

Declarations

  • variables
  • events
  • parameters

Occurrences

  • DECLARATION of (local) variables [Root]
  • DECLARATION of (local) events [Root]
  • DECLARATION of (local) parameters [Event]
  • REDECLARATION of abstract variables in the local variables that redeclare them [Variable/Identifier]
  • REDECLARATION of abstract events in the local events that refine them [Event/RefinesEvent/Target]
  • REDECLARATION of abstract parameters in the local parameters that redeclare them [Parameter/Identifier]
  • REFERENCE of abstract parameters or variables in witnesses [Witness/Label]
  • REFERENCE of elements in invariants [Invariant/Predicate/b..e]
  • REFERENCE of elements in theorems [Theorem/Predicate/b..e]
  • REFERENCE of elements in variants [Variant/Expression/b..e]
  • REFERENCE of elements in guards [Guard/Predicate/b..e]
  • REFERENCE of elements in witnesses [Witness/Predicate/b..e]
  • REFERENCE of non assigned elements in actions [Action/Assignment/b..e]
  • MODIFICATION of assigned elements in actions [Action/Assignment/b..e]

Example :

 M1
 VARIABLES
   var1
 INVARIANTS
   inv1 : var1 > 0
 EVENTS
   INITIALISATION
     THEN
       act1 : var1 := 1

After indexing M1, we will have the following occurrences:

 M1.var1 :
   DECLARATION in [M1.Root]
   REFERENCE in [M1.inv1/Predicate/0..4]
   MODIFICATION in [M1.act1/Assignment/0..4]
 M1.INITIALISATION :
   DECLARATION in [M1.Root]

Then, if we add another machine

 M2
 REFINES
   M1
 VARIABLES
   var1
 EVENTS
   INITIALISATION
     THEN
       act1 : var1 := 1

we will add the following occurrences :

 M1.var1 :
   REDECLARATION in [M2.var1/Identifier]
 M2.var1 :
   DECLARATION in [M2.Root]
   MODIFICATION in [M2.act1/Assignment/0..4]
 M2.INITIALISATION :
   DECLARATION in [M2.Root]

Exports

  • imported carrier sets
  • imported constants
  • local variables
  • local events
  • local parameters

Propagation

Propagators are defined for :

  • events (EventPropagator) to propagate through refines
  • parameters (IdentifierPropagator) to propagate through redeclaration
  • variables (IdentifierPropagator as well) to propagate through redeclaration

In the above example with machines M1 and M2, after both files have been indexed, we can query occurrences of M1.var1.

With no propagator, the result would be :

 M1.var1 :
   DECLARATION in [M1.Root]
   REFERENCE in [M1.inv1/Predicate/0..4]
   MODIFICATION in [M1.act1/Assignment/0..4]
   REDECLARATION in [M2.var1/Identifier]

Using the IdentifierPropagator, the result becomes :

 M1.var1 (propagated) :
   DECLARATION in [M1.Root]
   REFERENCE in [M1.inv1/Predicate/0..4]
   MODIFICATION in [M1.act1/Assignment/0..4]
   REDECLARATION in [M2.var1/Identifier]
   DECLARATION in [M2.Root]
   MODIFICATION in [M2.act1/Assignment/0..4]