Difference between pages "Current Developments" and "Event-B Indexers"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Pascal
 
imported>Nicolas
 
Line 1: Line 1:
−
{{TOCright}}
+
==Purpose==
−
This page sum up the known developments that are being done around or for the [[Rodin Platform]]. ''Please contributes informations about your own development to keep the community informed''
 
  
−
You may also have a look at [[Past Developments|past developments]].
+
Event-B indexers populate the index repository. Currently, indexers are implemented for the following files :
 +
* machine (.bum)
 +
* context (.buc)
  
−
== Deploy Tasks ==
 
−
The following tasks were planned at some stage of the [[Deploy]] project.
 
−
=== Core Platform ===
 
  
−
====Better event-B Editor====
+
==Event-B Occurrence Kinds==
  
−
Feedback from users indicates strongly that the current layout used in the default event-B editor (edit tab) is sub-optimal and severely hinders usability of the Rodin platform. Ideas for improving this are collected on page: [[Layout improvements in the event-B editor]].
+
So far, the following occurrence kinds have been defined :
 +
* DECLARATION : when a variable, a carrier set, ..., is declared
 +
* REFERENCE : when a variable, ..., is referenced (but not modified); also applies when an abstract element is redeclared in a refinement
 +
* MODIFICATION : when a variable is modified
  
−
==== Mathematical Language ====
+
Please notice the distinction between the index repository notion of declaration ({{class|IDeclaration}}) and the Event-B occurrence kind DECLARATION.
  
−
[[Mathematical_extensions|Proposals for mathematical extensions]]
+
==What Indexers Index==
  
−
==== Text Editor ====
+
Currently, indexed elements are :
−
The efforts in [[Düsseldorf]] ([[User:Fabian|Fabian]]) and [[Newcastle]] ([[User:Alexei|Alexei]]) have been joined to create a single text editor which will be part of the [[#EMF framework for Event-B|EMF framework for Event-B]] (see that [[#EMF framework for Event-B|section]] for details).
+
* carrier sets
 +
* constants
 +
* variables
 +
* events
 +
* parameters
  
−
The first version of the TextEditor will be released in a few weeks (following the Rodin 1.0 release). Until then we are going to release a few testing releases (beta) for interested users. Find detailed information on the page [[Text Editor|TextEditor]].
+
Formulas which cannot be parsed are ignored.
  
−
==== EMF framework for Event-B ====
+
In the descriptions below, the following notation will be used to specify locations :
−
Newcastle, Southampton and Düsseldorf have begun to develop an EMF framework to support Rodin modelling tools based on EMF. The framework includes an EMF representation of Event-B, a synchronising persistence interface for loading and saving models via the Rodin API and facilities to support text editing and parsing. Examples of tools that will be based on the EMF framework for Rodin are, a Text editor, a compare/merge editor (which can be used for team based development), pattern/composition tools, Diagram Editors.
+
* [element] : internal location
 +
* [element/attribute] : attribute location
 +
* [element/attribute/begin..end] : attribute substring location
  
−
More details can be found here: [[EMF framework for Event-B]]
+
===Context Indexer===
  
−
==== Event Model Decomposition (A-style) ====
+
====Dependencies====
−
[[Systerel]] ([[User:Carine|Carine]]) is in charge of this task.
+
* extended contexts
−
{{details|Event Model Decomposition|Event Model Decomposition}}
 
  
−
The purpose of (A-style) event model decomposition is to cut a heavy event system into smaller pieces which can be handled more comfortably than the whole. More precisely, each piece can then be refined independently of the others.
+
====Declarations====
 +
* carrier sets
 +
* constants
  
−
==== Preferences for the automatic tactics ====
+
====Occurrences====
−
[[Systerel]] is in charge of this task.
 
−
{{details|Preferences for the automatic tactics|Preferences for the automatic tactics}}
 
  
−
The purpose is to give more detailed preferences to the user to build his own automated tactics.
+
* DECLARATION of carrier sets [Root]
 +
* DECLARATION of constants [Root]
 +
* REFERENCE of elements in axioms [Axiom/Predicate/b..e]
 +
* REFERENCE of elements in theorems [Theorem/Predicate/b..e]
  
−
=== Plug-ins ===
+
Example:
  
 +
  Ctx
 +
  Sets
 +
    S
 +
  Constants
 +
    C
 +
  Axioms
 +
    axm1 : C ∈ S
  
−
==== UML-B Improvements ====
+
We will end up with the following occurrences :
−
[[Southampton]] is in charge of [[UML-B]] plug-in.
 
  
−
A new version of UML-B is being developed that will have improved integration with Event-B. The new version will be built as an extension to the EMF framework for Event-B. While this new version is being developed improvements are also being made to the existing version of UML-B. Both topics are covered in more detail on the following page:
+
  S :
−
[[UML-B Integration and Improvements]]
+
    DECLARATION in [Ctx.Root]
 +
    REFERENCE in [axm1/Predicate/4..5]
 +
  C :
 +
    DECLARATION in [Ctx.Root]
 +
    REFERENCE in [axm1/Predicate/0..1]
  
−
==== ProB Plug-in ====
 
−
[[Düsseldorf]] is in charge of [[ProB]].
 
−
<!-- {{details|ProB current developments|ProB current developments}} -->
 
  
−
===== Work already performed =====
+
====Exports====
 +
* imported and declared carrier sets
 +
* imported and declared constants
  
−
We have now ported ProB to work directly on the Rodin AST. Animation is working and the user can now set a limited number of preferences.
+
===Machine Indexer===
−
The model checking feature is now also accessible.
 
−
It is also possible to create CSP and classical B specification files. These files can be edited with BE4 and animated/model checked with ProB.
 
−
On the classical B side we have moved to a new, more robust parser (which is now capable of parsing some of the more complicated AtelierB
 
−
specifications from Siemens).
 
  
−
On the developer side, we have moved to a continuous integration infrastructure using CruiseControl. Rodin is also building from CVS in that infrastructure.
+
====Dependencies====
 +
* refined machines
 +
* seen contexts
  
−
Developers can build tools on top of ProB using the [[ProB API]].
+
====Declarations====
 +
* variables
 +
* events
 +
* parameters
  
−
===== Ongoing and future developments=====
+
====Occurrences====
 +
* DECLARATION of (local) variables [Root]
 +
* DECLARATION of (local) events [Root]
 +
* DECLARATION of (local) parameters [Event]
 +
* REFERENCE of abstract variables in the local variables that redeclare them [Variable/Identifier]
 +
* REFERENCE of abstract events in the local events that refine them [RefinesEvent/Target]
 +
* REFERENCE 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]
  
−
We are currently developing a new, better user interface.
+
Example :
−
We also plan to support multi-level animation with checking of the gluing invariant.
 
  
−
We have prototypes for several extensions working, but they need to be fully tested and integrated into the plugin:
+
  M1
−
* an inspector that allows the user to inspect complex predicates (such as invariants or guards) as well as expressions in a tree-like manner
+
  VARIABLES
−
* a graphical animator based on SWT that allows the user to design his/her own animations easily within the tool
+
    var1
−
* a 2D viewer to inspect the state space of the specification
+
  INVARIANTS
 +
    inv1 : var1 > 0
 +
  EVENTS
 +
    INITIALISATION
 +
      THEN
 +
        act1 : var1 := 1
  
−
==== B2Latex Plug-in ====
+
After indexing M1, we will have the following occurrences:
−
[[Southampton]] is in charge of [[B2Latex]].
 
  
−
Kriangsak Damchoom will update the plug-in to add [[Event Extension|extensions of events]].
+
  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]
  
−
==== Parallel Composition Plug-in ====
+
Then, if we add another machine
−
[[Southampton]] is in charge of the [[Parallel Composition using Event-B]] .
 
  
−
The purpose of the plug-in is to allow the parallel composition of several Event-B machines into a composite machine. The machine composition uses a shared event composition, where separate machines operate on disjoint variables and
+
  M2
−
machines interact by synchronising on events that may share parameters.
+
  REFINES
 +
    M1
 +
  VARIABLES
 +
    var1
 +
  EVENTS
 +
    INITIALISATION
 +
      THEN
 +
        act1 : var1 := 1
  
−
This plug-in allows:
+
we will add the following occurrences :
−
* Selection of machines that will be part of the composition (''Includes'' Section)
 
−
* Possible selection of an abstract machine (''Refines'' Section)
 
−
* Possible inclusion of invariants that relate the included machines (''Invariant'' Section and use of the monotonicity )
 
−
* Invariants of included machines are conjoined.
 
−
* Selection of events that will be merged. The event(s) must come from different machines. At the moment, events with parameters with same name are merged. If it is a refinement composition, it is possible to choose the abstract event that is being refined.
 
−
* Initialisation event is the parallel composition of all the included machines' initialisations.
 
−
* For a composed event, the guards are conjoined and the all the actions are composed in parallel.
 
  
−
Currently, after the conclusion of the composition machine, a new machine can be generated, resulting from the properties defined on the composition file. This allows proofs to be generated as well as a visualisation of the composition machine file. In the future, the intention is to make the validation directly on the composition machine file directly where proofs would be generated ( and discharged) - the new machine generation would be optional. An event-b model for the validation/generation of proofs in currently being developed. Another functionality which should be quite useful for the composition (but not restricted to that) is '''renaming''':
+
  M1.var1 :
 +
    REFERENCE in [M2.var1/Identifier]
 +
  M2.var1 :
 +
    DECLARATION in [M2.Root]
 +
    MODIFICATION in [M2.act1/Assignment/0..4]
 +
  M2.INITIALISATION :
 +
    DECLARATION in [M2.Root]
  
−
* while composing, two machines may have variables with the same name for instance (which is not allowed for this type of composition). In order to solve this problem, one would have to rename one of the variables in order to avoid the clash, which would mean change the original machine. A possible solution for that would be to rename the variable but just on composition machine file, keeping the original machine intact. A renaming framework designed and developed by Stefan Hallerstede and Sonja Holl exists currently although still on a testing phase. The framework was developed to be used in a general fashion (not constrained to event-b syntax). The idea is to extend the development of this framework and apply to Event-B syntax (current development).
 
  
−
There is a prototype for the composition plug-in available that works for Rodin 0.9.2.1 available from the Rodin Main Update Site soon, under 'Shared Event Composition'.
+
====Exports====
 +
* imported carrier sets
 +
* imported constants
 +
* local variables
 +
* local events
 +
* local parameters
  
−
==== Refactoring Framework Plug-in ====
 
−
[[Southampton]] is in charge of the [[Refactoring Framework]].
 
  
−
The intention of the plug-in is to allow the renaming/refactoring of elements on a file (and possible related files). Although created to be used in a general way, the idea is to embed this framework on the Rodin platform, using Event-B syntax. This plug-in was initially designed and developed by Stefan Hallerstede and Sonja Holl.
+
==Propagation==
  
−
This plug-in allows:
+
Propagators are defined for :
−
* Defining extensions that can be used to select related files.
+
* events ({{class|EventPropagator}}) to propagate through refines
−
* Defining extesions that can be used to rename elements based on the type of file.
+
* parameters ({{class|IdentifierPropagator}}) to propagate through redeclaration
−
* Renaming of elements on a file and possible occurrences on related files.
+
* variables ({{class|IdentifierPropagator}} as well) to propagate through redeclaration
−
* Generating of a report of possible problems (clashes) that can occur while renaming.
 
  
−
==== Measurement Plug-In ====
+
In the above example with machines M1 and M2, after both files have been indexed, we can query occurrences of M1.var1.
  
−
The [[Measurement Plug-In]] to the RODIN platform will provide information both about the model itself and about the process of building the model.
+
With no propagator, the result would be :
−
It has a double purpose:
 
  
−
* provide feedback to the user about the quality of the Event-B model he is building and about potential problems in it or in the way he is building it.
+
  M1.var1 :
−
* automate the data collection process for the measurement and assessment WP. This data collected will be analyzed to identify global transfer (increase in model quality, size, complexity,...), tool shortcomings (usability, prover), modelling issues (to be addressed by training, language, tool evolution,...), etc.
+
    DECLARATION in [M1.Root]
 +
    REFERENCE in [M1.inv1/Predicate/0..4]
 +
    MODIFICATION in [M1.act1/Assignment/0..4]
 +
    REFERENCE in [M2.var1/Identifier]
  
−
==== Machine Instantiation ====
+
Using the {{class|IdentifierPropagator}}, the result becomes :
  
−
The context of a machine can be viewed as defining the parameters of that machine
+
  M1.var1 (propagated) :
−
(carrier sets, constants, axioms).  These parameters make a machine generic.
+
    DECLARATION in [M1.Root]
−
We propose an  approach for  instantiating Event-B  machines by replacing generic sets and constants
+
    REFERENCE in [M1.inv1/Predicate/0..4]
−
with more specific sets and constants.  The axioms of a context represent assumptions on the
+
    MODIFICATION in [M1.act1/Assignment/0..4]
−
sets and constants that need to be satisfied whenever the machine is instantiated.
+
    REFERENCE in [M2.var1/Identifier]
−
The instantiation leads to proof obligations
+
    DECLARATION in [M2.Root]
−
to ensure that the generic axioms are satisfied by the instantiation.  For more details see
+
    MODIFICATION in [M2.act1/Assignment/0..4]
−
[[Image:Proposal_generic_instantiation_rodin.pdf | Proposal for generic instantiation of machines]].
 
−
 
 
−
==== Rule-based Extensible Prover ====
 
−
[[Southampton]] is in charge of devising an extensible rule-based prover.
 
−
 
 
−
In order to extend the prover with new rewrite and inference rules, it is necessary to write Java code
 
−
adding to the appropriate extension points. That way, it becomes very difficult to verify the soundness of the
 
−
implemented rules. We propose a mechanism by which the prover can be extended with new rewrite rules
 
−
and inference rules without compromising its soundness. Our proposal follows a similar
 
−
approach employed by Event-B: generating proof obligations. We, initially, focus on adding the facility to specify
 
−
rewrite rules. We envisage the mechanism to evolve to cover inference rules as well as the many mathematical extensions
 
−
proposed in [[Mathematical_extensions]]. For more details, we refer to [[Image:Rule-based_Prover_Proposal.pdf | Proposal for a rule-based extensible prover]].
 
−
 
 
−
== Exploratory Tasks ==
 
−
=== Template Base Exporter ===
 
−
Some prototyping work is done in python, to explore how to use template engines to export rodin models to text, Latex, docbook, mediawiki,...
 
−
The [http://www.mercurial.org mercurial] repository is available [https://bitbucket.org/matclab/rodin_exporter/ here]. You can cloned it by installing mercurial on your computer and doing <code>hg clone https://bitbucket.org/matclab/rodin_exporter/</code>.
 
−
 
 
−
Be warn that, for now, it bypass the rodin database API and does parse the .bum and .buc files directly. It is also highly experimental, so do not rely to much on the produced output.
 
−
 
 
−
(This work is done by [[User:Mathieu|Mathieu]] on its spare time...)
 
−
 
 
−
== Others ==
 
−
 
 
−
=== AnimB ===
 
−
[[User:Christophe|Christophe]] devotes some of its spare time for this plug-in.
 
−
{{details|AnimB Current Developments|AnimB Current Developments}}
 
−
The current developments around the [[AnimB]] plug-in encompass the following topics:
 
−
;Live animation update
 
−
:where the modification of the animated event-B model is instantaneously taken into account by the animator, without the need to restart the animation.
 
−
;Collecting history
 
−
:The history of the animation will be collected.
 
−
 
 
−
=== Team-Based Development ===
 
−
 
 
−
; Usage Scenarios
 
−
: In order to understand the problem properly, [http://www.stups.uni-duesseldorf.de/ Düsseldorf] created a number of usage [[Scenarios for Team-based Development]].
 
−
: A page as also been opened for [[Scenarios for Merging Proofs|merging proofs scenarios]].
 
−
[[Category:Work in progress]]
 
−
 
 
−
 
 
−
=== New Proof Rules ===
 
−
 
 
−
[[New Proof Rules|This document]] describes the set of newly added reasoners for improving the usability of the prover within Rodin Platform.
 

Revision as of 10:55, 3 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, ..., is referenced (but not modified); also applies when an abstract element is redeclared in a refinement
  • MODIFICATION : when a variable is modified

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

What Indexers Index

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 [Root]
  • DECLARATION of constants [Root]
  • 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 [Ctx.Root]
   REFERENCE in [axm1/Predicate/4..5]
 C :
   DECLARATION in [Ctx.Root]
   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]
  • REFERENCE of abstract variables in the local variables that redeclare them [Variable/Identifier]
  • REFERENCE of abstract events in the local events that refine them [RefinesEvent/Target]
  • REFERENCE 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 :
   REFERENCE 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]
   REFERENCE 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]
   REFERENCE in [M2.var1/Identifier]
   DECLARATION in [M2.Root]
   MODIFICATION in [M2.act1/Assignment/0..4]
Retrieved from ‘https://wiki.event-b.org/index.php?title=Current_Developments&oldid=4106’