Difference between pages "D45 General Platform Maintenance" and "D45 Prover Enhancement"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Ladenberger
 
imported>Tommy
 
Line 1: Line 1:
 
= Overview =
 
= Overview =
The Rodin platform versions concerned by this deliverable are:
+
* Two tasks concerned the prover performance from the core platform: the addition of rewriting and inference rules, and the addition of a mechanism to allow the customization and the parametrization or combination of tactics. While the addition of rewriting and inference rules has always been a regular task to enhance the Rodin integrated prover during DEPLOY lifetime, a new way to manage tactics has been implemented. In fact, the user is now able to define various types of tactics called 'profiles' which could be customized and parameterized tactics to discharge some specific proof obligations.
* 2.1(08.02.2011),
+
* {{TODO}} An overview of the contribution about the ProB Disprover (Daniel Plagge, Jens Bendiposto)  
* 2.2(01.06.2011),
+
* The SMT Solvers plug-in allowing to use the SMT solvers within Rodin is an effective alternative to the Atelier-B provers, particularly when reasoning on linear arithmetic. {{TODO}} (Laurent Voisin, Yoann Guyot)
* 2.2.2(01.08.2011),
 
* 2.3(04.10.2011),
 
* 2.4(31.01.2011),
 
* 2.5(30.04.2011).
 
This year, the maintenance carried on fixing identified bugs, although an emphasis was put on correcting usability issues. Indeed, during the annual meeting in Nice, the WP9 members agreed to refocus on the needed tasks to address some specific bugs and issues reported by DEPLOY partners, and wished resolved by the end of DEPLOY. Thus, no new features were implemented but those appearing in the description of work. The tasks to be performed by the WP9 members were then scheduled, prioritized and regularly updated during the WP9 bi-weekly meetings. The updates allowed to capture and integrate rapidly some minor changes to enhance the usability of the platform which were required by the DEPLOY partners. The following paragraphs will give an overview of the the work that has been performed concerning maintenance on the existing platform components (i.e. core platform and plug-ins).
 
 
 
See the Release Notes<ref name="documentation">http://wiki.event-b.org/index.php/D32_General_Platform_Maintenance#Available_Documentation</ref> and the SourceForge<ref name=documentation>http://wiki.event-b.org/index.php/D45_General_Platform_Maintenance#Available_Documentation</ref> databases (bugs and feature requests) for details about the previous and upcoming releases of the Rodin platform.
 
 
 
* General platform maintenance
 
The maintenance done to overcome Rodin scalability weaknesses and enhance the proving experience will be detailed in a separate chapter. However, some features initially planned and some other which were later added and prioritized are worth to mention:
 
:*Possibility to highlight patterns in the ProverUI,
 
:*A better output providing warnings and errors in case of wrong or missing building configurations,
 
:*The switch to Eclipse 3.7,
 
:*A Handbook to complete and enhance the existing documentation.
 
 
 
* {{TODO}} An overview of the contribution about Mathematical extensions / Theory Plug-in (Issam Maamria)
 
 
 
* {{TODO}} An overview of the contribution about Plug-in Incompatibilities (All partners)
 
 
 
* {{TODO}} An overview of the contribution about Modularisation (Alexei Illiasov)
 
 
 
* {{TODO}} An overview of the contribution about Decomposition (Renato Silva)
 
 
 
* {{TODO}} An overview of the contribution about Team-based Development (Colin Snook, Vitaly Savicks)
 
 
 
* {{TODO}} An overview of the contribution about UML-B (Colin Snook, Vitaly Savicks)
 
 
 
== An overview of the contribution about ProR (Michael Jastram) ==
 
 
 
ProR is a replacement of the original requirements plug-in, which got discontinued in 2010.  It is based on the OMG ReqIF standard (<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref>), which provides interoperability with industry tools.  It evolved into the Eclipse Foundation project "Requirements Modeling Framework" (RMF, <ref name="rmf">http://eclipse.org/rmf</ref>), resulting in significant visibility.  ProR is independent from Rodin.  Integration is achieved with a separate plug-in that provides support for traceability and model integration.
 
 
 
== An overview of the contribution about BMotion Studio (Lukas Ladenberger) ==
 
 
 
BMotion Studio is a visual editor which enables the developer of a formal model to set-up easily a domain specific visualisation for discussing it with the domain expert. BMotion Studio comes with a graphical editor that allows to create a visualisation within the modeling environment. Also, it does not require to use a different notation for gluing the state and its visualisation. BMotion Studio is based on the ProB animator and is integrated into the RODIN tool. However, BMotion Studio is independent from Rodin. Integration is achieved with a separate plug-in.
 
 
 
The main advantages of BMotion Studio are:
 
 
 
* The modeler stays within a single notation. BMotion Studio uses Event-B predicates and expressions as gluing code.
 
* An easy to use graphical editor, that allows to create visualisations with a few mouse clicks.
 
* BMotion Studio comes with a number of default observers and controls that are sufficient for most visualisations.
 
* It can be extended for specific domains.
 
  
 
= Motivations =
 
= Motivations =
The tasks to solve the issues faced by the DEPLOY partners have been listed and have been assigned to groups according to their priority. A high priority means a high need in the outcome of a given task. The group 1 has the highest priority, the group 2 has an intermediate priority, and the group 3 has the lowest priority. The group 4 concerns topics that could not be resourced during the lifetime of DEPLOY.The prover integrity item, although not being directly covered, has been partially addressed thanks to Isabelle and SMT integration. Unfortunately, the originally planned export of full proofs and integrity check was too ambitious to be fully achieved in the scope of DEPLOY.
+
== New rewriting and inference rules ==
 +
In an Event-B development, more than 60% of the time is spent on proofs. It has been a continuous aim to increase the number of automatically discharged proof obligations (POs) by improving the capabilities of the integrated sequent prover through the addition of rewriting and inference rules. These rules were provided through tactics, or existing or newly created. These tactics were automatic, or manual, or sometimes both. Providing new proving rules, even if it sometimes does not increase directly the number of automatically discharged POs aims to help the user to interactively discharge them and spare his time.
  
{{SimpleHeader}}
+
== Advanced Preferences for Auto-tactics ==
|-
+
{{TODO}} ''To be completed by Nicolas Beauger''
! scope=col | Group 1 (highest priority) || Responsible
+
Sometimes, the automatic proofs fail because the order of the applied tactics doesn't lead to the proof obligation discharge. Previously the ordering of tactics was lost at each change. Another issue is to have more than one possibility to combine the tactics. Indeed, various combinators called ''tacticals'' allow to combine tactics in a specific manner thus providing a sort of tactic arithmetic. The advanced preferences for auto-tactics solved this two issues.
|-
 
|Performance <br /> - Core (large models, etc.) <br /> - GUI (incl. prover UI, edition, etc.) || SYSTEREL
 
|-
 
|Prover Performances <br /> - New rewriting rules / inference rules <br /> - Automatic tactics (preferences, timeout, etc.) || SYSTEREL
 
|-
 
|ProB Disprover (incl. counter examples to DLF POs) || Düsseldorf
 
|-
 
|Stability (crash, corruption, etc.)  || SYSTEREL
 
|-
 
|Editors || SYSTEREL/Düsseldorf
 
|-
 
|}
 
{{SimpleHeader}}
 
|-
 
! scope=col | Group 2 || Responsible
 
|-
 
| Prover Performances <br /> - SMT provers integration <br /> - connection with Isabelle  <br /> - Mathematical extensions <br /> - ProB || <br />SYSTEREL <br /> ETH Zürich <br /> Southampton/SYSTEREL <br /> Düsseldorf
 
|-
 
|Scalability <br /> - Decomposition <br /> - Modularisation plug-in <br /> - Team-based development || <br /> Southampton <br /> Newcastle <br /> Southampton
 
|-
 
|Plug-in incompatibilities || Newcastle
 
|-
 
|Model-based testing || Pitesti/Düsseldorf
 
|-
 
|ProR || Düsseldorf
 
|}
 
{{SimpleHeader}}
 
|-
 
! scope=col | Group 3 || Responsible
 
|-
 
|Scalability <br /> - Generic instantiation <br /> - UML-B maintenance <br /> || <br /> Southampton <br /> ETH Zürich/Southampton
 
|-
 
|Code Generation || Southampton
 
|}
 
{{SimpleHeader}}
 
|-
 
! scope=col | Group 4
 
|-
 
|Prover Integrity
 
|-
 
|Integrity of Code Generation
 
|}
 
== Platform maintenance ==
 
The platform maintenance, as it can be deduced from the above tables in section [[#Motivations | Motivations]], mainly concerned stability and performance improvement. These topics will be discussed and detailed in a separate chapter about scalability improvements.<br>
 
However, other improvements of utmost importance were made on the platform. These improvements either came from DEPLOY partners specific needs, or were corresponding to previously identified needs (listed in D32 - Model Construction tools & Analysis III Deliverable).
 
Hence we review below the motivations of some noteworthy implemented features:
 
* A Possibility to highlight patterns in the Prover UI.
 
This feature came from a request of DEPLOY partners<ref name="searchInPUI">https://sourceforge.net/tracker/?func=detail&atid=651672&aid=3092835&group_id=108850</ref>, often facing the need to find particular patterns such as expressions in long predicates (e.g. long goals). Since Rodin 2.2, and its new Proving UI interface, a nice feature was added, allowing to search and highlight a string pattern into the whole Proving UI views and editors. This function as also been enabled on direct selection of text in this UI.
 
* A better output providing warnings and errors in case of wrong or missing building configurations.
 
This issue, often seen as a bug or as a plug-in incompatibility, was raised when a user imports and tries to use a model on a platform with some missing required plug-ins. The user often thought his models corrupted whereas Rodin was not able to build them, and hid this information to the user. This is why, since Rodin 2.3, an output has been provided in such case, taking the form of warnings or errors that any user can understand and review. This is a first answer to Rodin plug-in incompatibilities issues.
 
* The switch to Eclipse 3.7.
 
Due to the major improvements made every year in Eclipse releases and the continuously growing number of contributing projects which are for some of them used as basis for Rodin plug-ins, the Rodin platform follows the evolution and is adapted every year quickly to the latest Eclipse version available. This year, Rodin 2.3 originated the switch from Eclipse 3.6 to Eclipse 3.7.
 
* A Handbook to complete and enhance the existing documentation.
 
At the DEPLOY Plenary Meeting in Zürich in 2010, it has been stated that the current documentation, in its state at that time, would not support a engineer starting using the tools without significant help of an expert <ref name="documentationoverhaul>http://wiki.event-b.org/index.php/User_Documentation_Overhaul</ref>. Significant efforts to improve the documentation were performed and coordinated by Düsseldorf, and took form of a handbook<ref name="RodinHandbook">http://handbook.event-b.org/</ref>. The Rodin handbook has the aim to minimize the access to an expert, by providing the necessary assistance to an engineer in the need to be productive using Event-B and the Rodin toolset. The contents of the handbook, user oriented, were originated by some contents of the Event-B wiki.
 
  
== Mathematical extensions / Theory Plug-in ==
+
== Isabelle Plug-in ==
{{TODO}} ''To be completed by Issam Maamria''
+
{{TODO}} ''To be completed by Matthias Schmaltz''
== Plug-in Incompatibilities ==
+
== ProB Disprover ==
By its extensibility nature, the Rodin platform is susceptible to incompatibilities. Indeed, there are many ways in which incompatibilities could occur, and it occurred in the lifetime of DEPLOY. A good example, is the dependency management. Suppose that a bundle x_v1.0 is needed by a plug-in A (i.e. a dependency from A has been defined to x in at most the version 1.0) and installed in Rodin. Then the plug-in x_v1.1 is needed by a plug-in B. The both versions 1.0 and 1.1 of x could not be installed and used at the same time and create thus some usage incompatibility.
+
{{TODO}} ''Daniel Plagge, Jens Bendiposto''  
 
+
== SMT Solver Integration ==
== Modularisation ==
+
{{TODO}} ''Laurent Voisin'' & ''Yoann Guyot''
{{TODO}} ''To be completed by Alexei Illiasov''
 
== Decomposition ==
 
{{TODO}} ''To be completed by Renato Silva''
 
== Team-based Development ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''  
 
== UML-B ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== ProR ==
 
 
 
While the original requirements plug-in for Rodin was useful as a prototype, a number of shortcomings lead to a new development.  In particular, the original plug-in was a traceability tool with externally managed requirements.  With ProR, requirements are authored and edited within Eclipse.  The original plug-in supported only a limited number of attributes and flat (unstructured) requirements.  ProR supports all data structures that the ReqIF standard<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> supports. Further, ReqIF-support for industry tools like Rational DOORS, MKS or IRqA is expected in the near future, while the original plug-in required a custom adaptor for each data format.
 
 
 
ProR is developed independently from Rodin.  Dependencies to Rodin exist only in the Rodin integration plug-in.  This significantly decreases the maintenance effort for the integration plugin, while increasing the visibility of ProR in the Open Source community.  The move of ProR from the University of Düsseldorf to the Eclipse Foundation increases visibility even further.  The Rodin integration plug-in is maintained as an independent project at github.
 
 
 
== BMotion Studio ==
 
The communication between a developer and a domain expert (or manager) is very important for successful deployment of formal methods. On the one hand it is crucial for the developer to get feedback from the domain expert for further development. On the other hand the domain expert needs to check whether his expectations are met. An animation tool allows to check the presence of desired functionality and to inspect the behaviour of a specification, but requires knowledge about the mathematical notation. To avoid this problem, it is useful to create domain specific visualisations. However, creating the code that defines
 
the mapping between a state and its graphical representation is a rather time consuming task. It can take several weeks to develop a custom visualisation.
 
 
 
BMotion Studio is a visual editor which enables the developer of a formal model to set-up easily a domain specific visualisation for discussing it with the domain expert. BMotion Studio comes with a graphical editor that allows to create a visualisation within the modeling environment. Also, it does not require to use a different notation for gluing the state and its visualisation.
 
  
 
= Choices / Decisions =
 
= Choices / Decisions =
== Platform maintenance ==
+
== New rewriting and inference rules ==
* Revisited task priority
+
{{TODO}} ''To be completed by Laurent Voisin''
This year, the process of giving priority to maintenance tasks was revisited according the the refocus mentioned above. The aim was to address all the major scalability issues before the end of DEPLOY. Thus, the requests coming from DEPLOY partners were given high priorities, and they were also prioritized against the already planned tasks coming from both DEPLOY partners and the Description of Work.
+
== Advanced Preferences for Auto-tactics ==
* Keep 32-bit versions of the Rodin platform on linux and windows systems
+
{{TODO}} ''To be completed by Nicolas Beauger''
It was asked by end users to make both 32-bit and 64-bit versions of the Rodin platform available for Linux and Windows platforms. Only a 64-bit version of Rodin is available on Mac platforms as 32-bit Mac (early 2006) platforms are no longer maintained. The request to offer 64-bit was motivated by the possibility to increase for them the available Java heap size for some memory greedy platforms (these before 2.3). However, the drawbacks of assembling and maintaining more platforms (5 platforms instead of 3) and the corrections brought to the database which improved the memory consumption pushed away the limitations of the platform, made this request not relevant for now.
+
Since Rodin 2.1, simple tactic profiles have been added. They allow to persiste and set specifically for some project various ordered ways to apply the basic tactics. Since Rodin 2.3, tacticals and parameterisation have been added to the profiles increasing even more the potential of such proving feature. The combinators allow for exemple to loop on a subset of tactics, including existing profiles, and the parameterisation allows for example to set a timeout on external provers such as AtelierB P1.
  
== Mathematical extensions / Theory Plug-in ==
+
== Isabelle Plug-in ==
{{TODO}} ''To be completed by Issam Maamria''
+
{{TODO}} ''To be completed by Matthias Schmaltz''
== Plug-in Incompatibilities ==
+
== ProB Disprover ==
It has been decided in cooperation with all the WP9 partners to find better ways to address the plug-in incompatibility issues. First of all, the various partners refined the concept of "plug-in incompatibility". Hence, various aspects could be identified and some specific answers were given to each of them. The user could then defined more clearly the incompatibility faced. Plug-in incompatibilities can be separated in two categories:
+
{{TODO}} ''Daniel Plagge, Jens Bendiposto''  
:* Rodin platform/plug-in incompatibilities, due to some wrong match between Rodin included packages and the plug-in dependencies (i.e. needed packages). These incompatibilities, when reported, allowed the plug-in developers to contact SYSTEREL in charge of managing the packages shipped with a given version of Rodin. It could also allow traceability of incompatibilities and information to the user through a specific and actualized table on each Rodin release notes page on the Wiki<ref name="incompTableA">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Current_plug-ins</ref>.
+
== SMT Solver Integration ==
:* Plug-in/plug-in incompatibilities, due to some wrong match between needed/installed packages, or API/resources incompatible usage. A table was created on each release notes wiki page, and a procedure was defined<ref name="incompTableB">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Known_plug-in_incompatibilities</ref> so that identified incompatibilities are listed and corrected by the concerned developers.
+
{{TODO}} ''Laurent Voisin'' & ''Yoann Guyot''
It appeared that cases of using a model which references some missing plug-ins were formerly often seen as compatibility issues although they were not.<br>
 
After the incompatibilities have been identified, the developing counterparts being concerned assigned special tasks and coordination to solve issues the soonest as possible. Incompatibilities are often due to little glitches or desynchronisation and such direct coordination of counterpart appeared appropriate because quick and effective.
 
 
 
== Modularisation ==
 
{{TODO}} ''To be completed by Alexei Illiasov''
 
== Decomposition ==
 
{{TODO}} ''To be completed by Renato Silva'' 
 
== Team-based Development ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''  
 
== UML-B ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== ProR ==
 
 
 
The following key decisions were made when developing ProR:
 
 
 
* '''New development, rather than continuing the original plug-in''' - the architecture of ProR differs significantly from that of the original plug-in (see [[D45_General_Platform_Maintenance#ProR]].  In addition, new technologies like EMF promised a cleaner, more powerful framework for an implementation.
 
 
 
* '''ReqIF as the underlying data model''' - the ReqIF standard <ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> is gaining traction and promises interoperability with industry tools.  In addition, a digital version of the data model was available for free and could serve as the foundation for the model code.
 
 
 
* '''The Eclipse Modeling Framework''' (EMF) was identified as a technology that would allow a quick and clean foundation for an implementation.  Further, the Rodin EMF-plug-in represents a convenient interface for integrating ProR and ProB.  Last, the digital data model from the OMG could be imported directly into EMF and used for generating the model code.
 
 
 
* '''Keeping ProR independent from Rodin''' - There is significant interest in ReqIF right now, but this interest is unrelated to formal methods.  By providing an implementation that is independent from Rodin, we have a much larger target group of potential users and developers.  By carefully designing extension points, we can still provide a powerful Rodin integration.
 
 
 
* '''Eclipse Foundation Project''' - we were actively establishing an open source community around ProR.  By recruiting engaged partners early on, development progressed faster than anticipated.  By becoming an Eclipse Foundation project <ref name="rmf">http://eclipse.org/rmf</ref>, we exceeded our goals in this respect.
 
 
 
== BMotion Studio ==
 
The following key decisions were made when developing BMotion Studio:
 
 
 
* '''Keeping BMotion Studio user-friendly''' - The user should be able to create a visualization not requiring additional skills in programming languages.
 
* '''ProB as animator for providing state information''' - With the ProB animator, we have a powerful tool for interacting with the model.
 
* '''Provide extensibility for specific domains''' - By carefully designing extension points, we can provide a powerful integration for specific domains.
 
* '''Keeping BMotion Studio independent from Rodin''' - By providing an implementation that is independent from Rodin, we have a much larger target group of potential users and developers.
 
  
 
= Available Documentation =
 
= Available Documentation =
* Core platform:
+
* {{TODO}} Links for New rewriting and inference rules
:The following pages give useful information about the Rodin platform releases:
+
* {{TODO}} Links for Advanced Preferences for Auto-tactics
:* Release notes<ref>http://wiki.event-b.org/index.php/Rodin_Platform_Releases</ref>.
+
* {{TODO}} Links for Isabelle Plug-in
:* Bugs<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651669</ref>.
+
* {{TODO}} Links for ProB Disprover
:* Feature requests<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651672</ref>.
+
* {{TODO}} Links for SMT Solver Integration
*The Rodin handbook is proposed as a PDF version and a HTML version and a dedicated plug-in makes it available as help within Rodin<ref name="RodinHandbook">http://handbook.event-b.org/</ref>.
 
 
 
*{{TODO}} Links for Mathematical extensions / Theory Plug-in
 
*{{TODO}} Links for Modularisation
 
*{{TODO}} Links for Decomposition
 
*{{TODO}} Links for Team-based Development
 
*{{TODO}} Links for UML-B
 
* Links for ProR
 
** ProR at the Eclipse Foundation <ref name="rmf">http://eclipse.org/rmf</ref>
 
** ProR Documentation for end users and plugin developers <ref>http://pror.org</ref>
 
* Links for BMotion Studio
 
** BMotion Studio Documentation for end users and plugin developers <ref>http://www.stups.uni-duesseldorf.de/BMotionStudio</ref>
 
  
 
= Status =
 
= Status =
== Platform maintenance ==
+
== New rewriting and inference rules ==
By the end of the project, there are :
+
{{TODO}} ''To be completed by Laurent Voisin''
* xx bugs reported and open. All with a priority lower or equal to 5.
+
== Advanced Preferences for Auto-tactics ==
* xx feature requests expressed and still open.
+
{{TODO}} ''To be completed by Nicolas Beauger''
 
+
== Isabelle Plug-in ==
== Mathematical extensions / Theory Plug-in ==
+
{{TODO}} ''To be completed by Matthias Schmaltz''
{{TODO}} ''To be completed by Issam Maamria''
+
== ProB Disprover ==
== Plug-in Incompatibilities ==
+
{{TODO}} ''Daniel Plagge, Jens Bendiposto''  
As the time of writing this deliverable, no plug-in incompatibilities are left or known to exist between the platform and plug-ins or between plug-ins.
+
== SMT Solver Integration ==
 
+
{{TODO}} ''Laurent Voisin'' & ''Yoann Guyot''
== Modularisation ==
 
{{TODO}} ''To be completed by Alexei Illiasov''
 
== Decomposition ==
 
{{TODO}} ''To be completed by Renato Silva''
 
== Team-based Development ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''  
 
== UML-B ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== ProR ==
 
 
 
ProR took on a life on its own as part of the Requirements Modeling Framework<ref name="rmf">http://eclipse.org/rmf</ref>.  It is currently in the incubation stage of an Eclipse project.  There are currently five committers in total, with two from the Rodin project, namely Michael Jastram (Project Lead) and Lukas Ladenberger.
 
 
 
The Rodin integration supports:
 
 
 
* Creating traces between model elements and requirements
 
* Highlighting of model elements in the requirements text
 
* Marking of invalidated traces, where either the requirement or model element had changed.
 
 
 
The Rodin integration is hosted at GitHub.
 
 
 
== BMotion Studio ==
 
{{TODO}} ''To be completed by Lukas Ladenberger''
 
 
 
= References =
 
<references/>
 
  
 
[[Category:D45 Deliverable]]
 
[[Category:D45 Deliverable]]

Revision as of 17:44, 23 November 2011

Overview

  • Two tasks concerned the prover performance from the core platform: the addition of rewriting and inference rules, and the addition of a mechanism to allow the customization and the parametrization or combination of tactics. While the addition of rewriting and inference rules has always been a regular task to enhance the Rodin integrated prover during DEPLOY lifetime, a new way to manage tactics has been implemented. In fact, the user is now able to define various types of tactics called 'profiles' which could be customized and parameterized tactics to discharge some specific proof obligations.
  • TODO An overview of the contribution about the ProB Disprover (Daniel Plagge, Jens Bendiposto)
  • The SMT Solvers plug-in allowing to use the SMT solvers within Rodin is an effective alternative to the Atelier-B provers, particularly when reasoning on linear arithmetic. TODO (Laurent Voisin, Yoann Guyot)

Motivations

New rewriting and inference rules

In an Event-B development, more than 60% of the time is spent on proofs. It has been a continuous aim to increase the number of automatically discharged proof obligations (POs) by improving the capabilities of the integrated sequent prover through the addition of rewriting and inference rules. These rules were provided through tactics, or existing or newly created. These tactics were automatic, or manual, or sometimes both. Providing new proving rules, even if it sometimes does not increase directly the number of automatically discharged POs aims to help the user to interactively discharge them and spare his time.

Advanced Preferences for Auto-tactics

TODO To be completed by Nicolas Beauger Sometimes, the automatic proofs fail because the order of the applied tactics doesn't lead to the proof obligation discharge. Previously the ordering of tactics was lost at each change. Another issue is to have more than one possibility to combine the tactics. Indeed, various combinators called tacticals allow to combine tactics in a specific manner thus providing a sort of tactic arithmetic. The advanced preferences for auto-tactics solved this two issues.

Isabelle Plug-in

TODO To be completed by Matthias Schmaltz

ProB Disprover

TODO Daniel Plagge, Jens Bendiposto

SMT Solver Integration

TODO Laurent Voisin & Yoann Guyot

Choices / Decisions

New rewriting and inference rules

TODO To be completed by Laurent Voisin

Advanced Preferences for Auto-tactics

TODO To be completed by Nicolas Beauger Since Rodin 2.1, simple tactic profiles have been added. They allow to persiste and set specifically for some project various ordered ways to apply the basic tactics. Since Rodin 2.3, tacticals and parameterisation have been added to the profiles increasing even more the potential of such proving feature. The combinators allow for exemple to loop on a subset of tactics, including existing profiles, and the parameterisation allows for example to set a timeout on external provers such as AtelierB P1.

Isabelle Plug-in

TODO To be completed by Matthias Schmaltz

ProB Disprover

TODO Daniel Plagge, Jens Bendiposto

SMT Solver Integration

TODO Laurent Voisin & Yoann Guyot

Available Documentation

  • TODO Links for New rewriting and inference rules
  • TODO Links for Advanced Preferences for Auto-tactics
  • TODO Links for Isabelle Plug-in
  • TODO Links for ProB Disprover
  • TODO Links for SMT Solver Integration

Status

New rewriting and inference rules

TODO To be completed by Laurent Voisin

Advanced Preferences for Auto-tactics

TODO To be completed by Nicolas Beauger

Isabelle Plug-in

TODO To be completed by Matthias Schmaltz

ProB Disprover

TODO Daniel Plagge, Jens Bendiposto

SMT Solver Integration

TODO Laurent Voisin & Yoann Guyot