Difference between pages "D23 General Platform Maintenance" and "D32 Mathematical Extensions"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Pascal
 
imported>Im06r
 
Line 1: Line 1:
= Overview =
+
=== Overview ===
The purpose of the platform corrective and evolutive maintenance is to address bugs and feature requests reported either by mail or through the appropriate trackers on SourceForge.
 
  
The noticeable new features in the main platform for the past year are listed below:
+
Mathematical extensions have been co-developed by Systerel (for the Core Rodin Platform) and Southampton (for the Theory plug-in). The main purpose of this new feature was to provide the Rodin user with a way to extend the standard Event-B mathematical language, by defining his own mathematical operators, basic predicates and algebraic types. Along with these additional notations, the user can also define new proof rules (prover extensions).
* Mathematical Language V2 (releases 1.0 and upper)
 
: The new version of the mathematical language is supported.
 
: See [http://wiki.event-b.org/index.php/Event-B_Mathematical_Language Event-B Mathematical Language].
 
* Theorems everywhere (releases 1.0 and upper)
 
: It is possible to mix theorems and regular predicates in axioms, invariants and guards.
 
* Auto-completion (releases 1.0 and upper)
 
: When entering a predicate or expression in the Event-B machine / context editor, it is possible to type <tt>C-Space</tt> to see a list of possible identifiers that could be entered at the cursor position.
 
* Entering mathematical symbols (releases 1.1 and upper)
 
: The Rodin platform provides many more ways to enter mathematical symbols:
 
: - either type the ASCII shortcut (as in previous releases),
 
: - or type the LaTeX command (as defined in style <tt>bsymb</tt>),
 
: - or click in the ''Symbol Table'' view which displays the symbols graphically,
 
: - or directly enter the Unicode value of the symbol (for advanced users).
 
: See [http://wiki.event-b.org/index.php/Rodin_Keyboard Rodin Keyboard].
 
  
See the [http://wiki.event-b.org/index.php/D23_General_Platform_Maintenance#Available_Documentation Release Notes] and the [http://wiki.event-b.org/index.php/D23_General_Platform_Maintenance#Available_Documentation SourceForge] databases (bugs and feature requests) for details about the previous and upcoming releases of the Rodin platform.
+
A theory is a file that can be used to define new algebraic types, new operators/predicates and new proof rules. Theories are developed in the Rodin workspace, and proof obligations are generated to validate prover and mathematical extensions. When a theory is completed and (optionally) validated, the user can make it available for use in models (this action is called the deployment of a theory). Theories are deployed to the current workspace (i.e., Workspace Scope), and the user can use any defined extensions in any project within the workspace.
  
= Motivations =
+
Records Plug-in has been developed by University of Southampton before the mathematical extensions as a new feature to provide structured types in Event-B. The plug-in extends Rodin standard context editor with a new modelling construct to provide support for structured types, which can be defined in terms of two new clauses: record declarations and record extensions. Both enable users to define their custom reusable types, that are treated underline by Rodin as Event-B constant sets and relations, supported by additional axioms, which the plug-in generates to simplify the proofs.
The main evolutions of the Rodin platform are driven by the description of work for the DEPLOY project and the requirements expressed by industrial WP1 to WP5 partners or by consultants during the lifecycle of the project.
 
  
Beyond that, any user registered on SourceForge may record any encountered bug on the Rodin platform or request a new feature, using the dedicated [http://wiki.event-b.org/index.php/D23_General_Platform_Maintenance#Available_Documentation trackers]. Depending on the category, the bug / feature is assigned to the WP9 partner who is in charge of its treatment:
+
=== Motivations ===
{{SimpleHeader}}
 
|-
 
! scope=col | Category || Partner
 
|-
 
|AnimB || Christophe METAYER
 
|-
 
|B2LaTeX || University of Southampton
 
|-
 
|Decomposition || Systerel
 
|-
 
|Event-B core || Systerel
 
|-
 
|Event-B interface || Systerel
 
|-
 
|Event-B POG || Systerel
 
|-
 
|Event-B provers || Systerel
 
|-
 
|Event-B static checker || Systerel
 
|-
 
|PRO-B || Dusseldorf
 
|-
 
|Renaming || University of Southampton
 
|-
 
|Requirements || Dusseldorf
 
|-
 
|Rodin platform || Systerel
 
|-
 
|Text editor || Dusseldorf
 
|-
 
|U2B || Southampton
 
|}
 
  
The priorities are discussed during the WP9 meetings (a management conference call is planned every two weeks, and the WP9 meetings are organised during the DEPLOY workshops).
+
Main reasons for implementing mathematical extensions are:
 +
* increased readability (<math>a \; \operatorname{OR} \; b</math> rather than <math>\operatorname{bool}(a=TRUE \or b=TRUE)</math>)
 +
* polymorphism (<math>l \in List(S \cprod T)</math>)
 +
* decreased proving effort, thanks to extension specific proof rules instead of general purpose ones
  
= Choices / Decisions =
+
The Theory plug-in superseded the Rule-based Prover v0.3 plug-in, and is the placeholder for mathematical and prover extensions. It provides a high-level interface to the Rodin Core capabilities with regards to mathematical extensions. The Rule-based Prover was originally devised to provide an usable mechanism for user-defined rewrite rules through theories. Theories were, then, deemed a natural choice for defining mathematical extensions as well as proof rules to reason about such extensions. In essence, the Theory plug-in provides a systematic platform for defining and validating extensions through a familiar technique: proof obligations.
The WP9 partners have agreed on a release policy (see the [http://wiki.event-b.org/index.php/D23_General_Platform_Maintenance#Available_Documentation Rodin Platform Releases] wiki page). In particular:
 
* A new version of the Rodin platform is released every 3 months.
 
* The code is frozen during the 2 weeks preceding each release.
 
* The Eclipse versioning policy is enforced (See [http://wiki.eclipse.org/index.php/Version_Numbering Version Numbering]).
 
* A wiki page is dedicated to each release.
 
  
The main advantages, for both developers and end-users, are summarized below:
+
The motivation for development of Records plug-in was to fill the gap in Event-B language - a missing support of a syntax for the direct definition of structured types. Some of the industrial partners expressed a desire to have this missing feature in Event-B, that would allow them to define their own structured types such as records or classes. Theoretically these structures could be modelled with existing Event-B capabilities via projection functions. Backed up by a refined theoretical proposal Records plug-in was developed to extend the standard Event-B notation with requested capability.
* Information. The wiki page dedicated to each release provides instant information on the new features and improvements, which may be discussed if necessary.
 
* Validation. The period of code freeze is more especially devoted to bug fixes, and the frequency of the stable releases is ensured.
 
* Integration. A synchronization between the optional plug-ins and other plug-ins is now possible.
 
  
= Available Documentation =
+
=== Choices / Decisions ===
The following pages give useful information about the Rodin platform releases:
 
* Release notes.
 
: See [http://wiki.event-b.org/index.php/Rodin_Platform_Releases Rodin Platform Releases].
 
: More details are provided in the notes distributed with each release (eg. [http://sourceforge.net/project/shownotes.php?release_id=693928]).
 
* Bugs.
 
: See [http://sourceforge.net/tracker/?atid=651669&group_id=108850].
 
* Feature requests.
 
: See [http://sourceforge.net/tracker/?group_id=108850&atid=651672].
 
  
= Planning =
+
On the Core Rodin Platform side, implementing mathematical extensions required to make some parts of the code extensible, that were not designed to be so, namely the lexer and the parser. We were using tools that automatically generated them from a fixed grammar description, so we had to change to other technologies. A [http://wiki.event-b.org/index.php/Constrained_Dynamic_Parser study] has been made on available technologies. The Pratt algorithm was selected for its adequation with the purpose and it did not have the drawbacks of other technologies:
The [http://wiki.event-b.org/index.php/D23_General_Platform_Maintenance#Available_Documentation Rodin Platform Releases] wiki page lists in particular the upcoming releases and give the scheduled release dates.
+
* foreign language integration
 +
* overhead due to over generality
  
Special efforts will be made on the following topics:
+
After a mocking up phase to verify feasibility, the Pratt algorithm has been confirmed as the chosen option and implemented in the Rodin Platform.
* Team-based development.
 
: The purpose is to perform simultaneous developments.
 
: In order to understand the problem properly, some usage scenarios (see [http://wiki.event-b.org/index.php/Scenarios_for_Team-based_Development Scenarios for Team-based Development]) for team-based Development have already been written, and a page has also been started to express merging proofs scenarios (see [http://wiki.event-b.org/index.php/Scenarios_for_Merging_Proofs Scenarios for Merging Proofs]).
 
: A prototype plug-in is available, which enables the use of the EMF compare editor for machines and contexts. The DEPLOY partners will try out this plug-in and gather requirements for the teamwork plug-in.
 
: See [http://wiki.event-b.org/index.php/EMF_Compare_Editor_Investigation EMF Compare Editor Investigation] (Implementation issues).
 
: See [http://wiki.event-b.org/index.php/EMF_Compare_Editor_installation EMF Compare Editor installation] (How to install the EMF Compare editor).
 
: See [http://wiki.event-b.org/index.php/Teamwork_Requirements Teamwork Requirements] (Feedback page / Requirements).
 
  
* Documentation.
+
Besides, we wanted to set up a way to publish and share theories for Rodin users, in order to constitute a database of pre-built theories for everyone to use and contribute. This has been realised by adding a new tracker on SourceForge site ([http://sourceforge.net/tracker/?group_id=108850&atid=1558661]).
: The purpose is to continuously increase the available documentation on the Wiki. It may contains requirements, pre-studies (states of the art, proposals, discussions), technical details (specifications), teaching materials (tutorials), user's guides, etc. The intended audience may be the developers or the end-users.
 
  
[[Category:D23 Deliverable]]
+
The Theory plug-in contributes a theory construct to the Rodin database. Theories were used in the Rule-based Prover (before it was discontinued) as a placeholder for rewrite rules. Given the usability advantages of the theory component, it was decided to use it to define mathematical extensions (new operators and new datatypes). Another advantage of using the theory construct is the possibility of using proof obligations to ensure that the soundness of the formalism is not compromised. Proof obligations are generated to validate any properties of new operators (e.g., associativity). With regards to prover extensions, it was decided that the Theory plug-in inherits the capabilities to define and validate rewrite rules from the Rule-based Prover. Furthermore, support for a simple yet powerful subset of inference rules is added, and polymorphic theorems can be defined within the same setting. Proof obligations are, again, used as a filter against potentially unsound proof rules.
 +
 
 +
Records plug-in required the extension of the Rodin database with the new constructs to support structured types. On the other hand the Event-B language itself did not support extension at that time. For that reason the decision was made to address extensibility problem at the lowest level possible, which was Rodin database, but to model structured types using standard Event-B notation at the level below. The translation from extended to standard syntax has been entrusted to the static checker, that was also extended for this purpose. Thus the plug-in provides the users with notation for record declarations and extensions in unchecked models, but the checked versions operate with standard Event-B constructs.
 +
 
 +
=== Available Documentation ===
 +
 +
* Pre-studies (states of the art, proposals, discussions).
 +
** [http://deploy-eprints.ecs.soton.ac.uk/216/ ''Proposals for Mathematical Extensions for Event-B'']
 +
** [http://deploy-eprints.ecs.soton.ac.uk/251/ ''Mathematical Extension in Event-B through the Rodin Theory Component'']
 +
** [http://wiki.event-b.org/index.php/Constrained_Dynamic_Parser#Design_Alternatives]
 +
** [http://wiki.event-b.org/index.php/Structured_Types ''Theoretical Description of Structured Types'']
 +
* Technical details (specifications).
 +
** [http://wiki.event-b.org/index.php/Mathematical_Extensions]
 +
** [http://wiki.event-b.org/index.php/Constrained_Dynamic_Lexer]
 +
** [http://wiki.event-b.org/index.php/Constrained_Dynamic_Parser]
 +
** [http://wiki.event-b.org/index.php/Theory_Plug-in]
 +
** [http://wiki.event-b.org/index.php/Records_Extension ''Records Extension Documentation'']
 +
* Teaching materials (tutorials).
 +
* User's guides.
 +
** [http://wiki.event-b.org/images/Theory_UM.pdf]
 +
 
 +
=== Planning ===
 +
This paragraph shall give a timeline and current status (as of 28 Jan 2011).
 +
 
 +
{{TODO|What will remain to do after Rodin 2.1 ?}}
 +
 
 +
[[Category:D32 Deliverable]]

Revision as of 21:17, 28 November 2010

Overview

Mathematical extensions have been co-developed by Systerel (for the Core Rodin Platform) and Southampton (for the Theory plug-in). The main purpose of this new feature was to provide the Rodin user with a way to extend the standard Event-B mathematical language, by defining his own mathematical operators, basic predicates and algebraic types. Along with these additional notations, the user can also define new proof rules (prover extensions).

A theory is a file that can be used to define new algebraic types, new operators/predicates and new proof rules. Theories are developed in the Rodin workspace, and proof obligations are generated to validate prover and mathematical extensions. When a theory is completed and (optionally) validated, the user can make it available for use in models (this action is called the deployment of a theory). Theories are deployed to the current workspace (i.e., Workspace Scope), and the user can use any defined extensions in any project within the workspace.

Records Plug-in has been developed by University of Southampton before the mathematical extensions as a new feature to provide structured types in Event-B. The plug-in extends Rodin standard context editor with a new modelling construct to provide support for structured types, which can be defined in terms of two new clauses: record declarations and record extensions. Both enable users to define their custom reusable types, that are treated underline by Rodin as Event-B constant sets and relations, supported by additional axioms, which the plug-in generates to simplify the proofs.

Motivations

Main reasons for implementing mathematical extensions are:

  • increased readability (a \; \operatorname{OR} \; b rather than \operatorname{bool}(a=TRUE \or b=TRUE))
  • polymorphism (l \in List(S \cprod T))
  • decreased proving effort, thanks to extension specific proof rules instead of general purpose ones

The Theory plug-in superseded the Rule-based Prover v0.3 plug-in, and is the placeholder for mathematical and prover extensions. It provides a high-level interface to the Rodin Core capabilities with regards to mathematical extensions. The Rule-based Prover was originally devised to provide an usable mechanism for user-defined rewrite rules through theories. Theories were, then, deemed a natural choice for defining mathematical extensions as well as proof rules to reason about such extensions. In essence, the Theory plug-in provides a systematic platform for defining and validating extensions through a familiar technique: proof obligations.

The motivation for development of Records plug-in was to fill the gap in Event-B language - a missing support of a syntax for the direct definition of structured types. Some of the industrial partners expressed a desire to have this missing feature in Event-B, that would allow them to define their own structured types such as records or classes. Theoretically these structures could be modelled with existing Event-B capabilities via projection functions. Backed up by a refined theoretical proposal Records plug-in was developed to extend the standard Event-B notation with requested capability.

Choices / Decisions

On the Core Rodin Platform side, implementing mathematical extensions required to make some parts of the code extensible, that were not designed to be so, namely the lexer and the parser. We were using tools that automatically generated them from a fixed grammar description, so we had to change to other technologies. A study has been made on available technologies. The Pratt algorithm was selected for its adequation with the purpose and it did not have the drawbacks of other technologies:

  • foreign language integration
  • overhead due to over generality

After a mocking up phase to verify feasibility, the Pratt algorithm has been confirmed as the chosen option and implemented in the Rodin Platform.

Besides, we wanted to set up a way to publish and share theories for Rodin users, in order to constitute a database of pre-built theories for everyone to use and contribute. This has been realised by adding a new tracker on SourceForge site ([1]).

The Theory plug-in contributes a theory construct to the Rodin database. Theories were used in the Rule-based Prover (before it was discontinued) as a placeholder for rewrite rules. Given the usability advantages of the theory component, it was decided to use it to define mathematical extensions (new operators and new datatypes). Another advantage of using the theory construct is the possibility of using proof obligations to ensure that the soundness of the formalism is not compromised. Proof obligations are generated to validate any properties of new operators (e.g., associativity). With regards to prover extensions, it was decided that the Theory plug-in inherits the capabilities to define and validate rewrite rules from the Rule-based Prover. Furthermore, support for a simple yet powerful subset of inference rules is added, and polymorphic theorems can be defined within the same setting. Proof obligations are, again, used as a filter against potentially unsound proof rules.

Records plug-in required the extension of the Rodin database with the new constructs to support structured types. On the other hand the Event-B language itself did not support extension at that time. For that reason the decision was made to address extensibility problem at the lowest level possible, which was Rodin database, but to model structured types using standard Event-B notation at the level below. The translation from extended to standard syntax has been entrusted to the static checker, that was also extended for this purpose. Thus the plug-in provides the users with notation for record declarations and extensions in unchecked models, but the checked versions operate with standard Event-B constructs.

Available Documentation

Planning

This paragraph shall give a timeline and current status (as of 28 Jan 2011).

TODO: What will remain to do after Rodin 2.1 ?