Difference between pages "D45 Code Generation" and "D45 General Platform Maintenance"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Andy
 
imported>Tommy
 
Line 1: Line 1:
 
= Overview =
 
= Overview =
−
The code generation plug-in allows the generation of code for typical real-time embedded control software from refined Event-B models. Such a feature will be an important factor in ensuring eventual deployment of the DEPLOY approach within industrial organisations.
+
The Rodin platform versions concerned by this deliverable are:
 +
* 2.1(08.02.2011),
 +
* 2.2(01.06.2011),
 +
* 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 has been put on correcting usability issues. Indeed, during the 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).
  
−
= Motivations =
+
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.
−
DEPLOY industrial partners are interested in the formal development of multi-tasking, embedded control systems. During the project, work has been undertaken to investigate automatic generation, from Event-B models, for these type of systems
+
 
−
<ref name="aaa">http://eprints.soton.ac.uk/270824/ "Edmunds, Andrew and Butler, Michael (2010) Tool Support for Event-B Code Generation. In, WS-TBFM2010"</ref><ref name="aab">http://eprints.soton.ac.uk/272006/ "Edmunds, Andrew and Butler, Michael (2011) Tasking Event-B: An Extension to Event-B for Generating Concurrent Code. In, PLACES 2011, Saarbrucken, Germany"</ref><ref name="aac">http://eprints.soton.ac.uk/272771/ "Edmunds, Andrew, Rezazadeh, Abdolbaghi and Butler, Michael (2011) From Event-B Models to Code: Sensing, Actuating, and the Environment. At SBMF2011, Sao Paulo, Brazil, 28 - 26 Sep 2011."</ref><ref name="aad">http://eprints.soton.ac.uk/335400/ "Edmunds, Andrew, Rezazadeh, Abdolbaghi and Butler, Michael (2012) Formal modelling for Ada implementations: tasking Event-B. In, Ada-Europe 2012: 17th International Conference on Reliable Software Technologies, Stockholm, SE, 11 - 15 Jun 2012. 14pp. (In Press)"</ref><ref name="aae">http://eprints.soton.ac.uk/336226/ "Edmunds, Andrew, Butler, Michael, Maamria, Issam, Silva, Renato and Lovell, Chris (2012) Event-B code generation: type extension with theories. In, ABZ 2012, Pisa, IT, 19 - 21 Jun 2012. 4pp. (In Press)"</ref>. Initially, we chose to translate to the Ada programming language
+
* General platform maintenance (Thomas Muller)
 +
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 warning 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.
 +
These items will be detailed hereafter in this chapter.
 +
 
 +
* {{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)
  
−
<ref name="aaf" J. Barnes. Programming in Ada 2005. International Computer Science Series. Addison Wesley, 2006.</ref>
+
* {{TODO}} An overview of the contribution about UML-B (Colin Snook, Vitaly Savicks)
  
−
, and use it as a basis for the abstractions used in our approach.<br>
+
* {{TODO}} An overview of the contribution about ProR (Michael Jastram)
−
We described our previous code generation feature as a demonstrator tool; chiefly a tool designed as a proof of concept, used by us to validate the approach. In this sense, the tool as it stands now, is the first prototype intended to be used by developers, and thus motivated numerous evolutions and new features such as:
 
−
* allowing a more seamless edition of tasking Event-B,
 
−
* supporting extensibility,
 
−
* supporting other target languages than just Ada,
 
−
* supporting programming concepts reification using abstract translators.
 
  
−
= Choices / Decisions =
+
= Motivations =
−
Considering the demonstrator as a baseline, we can list the new features as follows:
+
The tasks to solve the issues faced by the DEPLOY partners have been listed and being 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 ressourced 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 is beyond the scope of DEPLOY.
−
* Tasking Event-B is now integrated with the Event-B explorer. It uses the extensibility mechanism of Event-B EMF (In the previous version it was a separate model).
 
−
* Tasking Event-B is now integrated with the Event-B model editors. Tasking Event-B features can now be edited in the same place as the other Event-B features.
 
−
* We have the ability to translate to Java and C, in addition to Ada source code; and the source code is placed in appropriate files within the project.
 
−
* We use theories to define translations of the Event-B mathematical language (Theories for Ada and C are supplied).
 
−
* We use the theory plug-in as a mechanism for defining new data types , and the translations to target data types.
 
−
* The Tasking Event-B to Event-B translator is fully integrated. The previous tool generated a copy of the project, but this is no longer the case.
 
−
* The translator is extensible.
 
−
* The composed machine component is used to store event 'synchronizations'.
 
−
* Minimal use is made of the EMF tree editor in Rose.
 
  
−
These evolutions will be detailed hereafter. Moreover, the code generators have been completely re-written. The translators are now implemented using Java only. In our previous work we attempted to make use of the latest model-to-model transformation technology, available in the Epsilon tool set, but we decided to revert to Java since Epsilon lacked the debugging and productivity features of the Eclipse Java editor.
+
{{SimpleHeader}}
 +
|-
 +
! scope=col | Group 1 (highest priority) || Responsible
 +
|-
 +
|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 prioritary improvements were made on the platform. These improvements or 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 ProverUI.
 +
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 ProvingUI interface, a nice feature was added, allowing to search and highlight a string pattern into the whole ProvingUI views and editors. This function as also been enabled on direct selection of text in this UI.
 +
* A better output providing warning and errors in case of wrong or missing building configurations.
 +
This issue, often seen as a bug or a plug-in incompatibility, raises when a user imoprts and tries to use a model on a platform with some missing plug-ins needed on build. The user often use to think his models corrupted although Rodin just being not able to build them, and hiding this information to the user. This is why, since Rodin 2.3, an output in such case has been provided taking the form of warnings or errors that any user can review. This is a partial answer to Rodin plug-in incompatibilities issue.
 +
* The switch to Eclipse 3.7.
 +
Due to the major improvements made every year in every 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 support of an expert <ref name="documentationoverhaul>http://wiki.event-b.org/index.php/User_Documentation_Overhaul</ref>. Losts of 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 the contents of the Event-B wiki, which have been finally migrated from the wiki to the Rodin handbook.
  
−
== Tasking Event-B and its edition ==
+
== Mathematical extensions / Theory Plug-in ==
−
A text-based task body editor was added, to minimize the amount of editing required with the EMF tree editor. The task body editor is associated with a parser-builder; after the text is entered in the editor the EMF representation is generated (by clicking a button) that is, assuming parsing is successful. If the parser detects an error, information about the parse error is displayed in an adjoining text box. When specifying events in the task body, there is no longer a need to specify two events involved in a synchronization. The code generator automatically finds the corresponding event of a synchronization, based on the event name, and using the composed machine component. Composed machines are used to store event 'synchronizations', and are generated automatically during the decomposition process. This reduces the amount of typing in the TaskBody editor, since we no longer need to specify both local and remote (synchronizing) events.  The new feature also overcomes the 'problem' that we previously experienced, with duplicate event names in a development, and event selection, when specifying the task body. The EMF tree editor in Rose is now only used minimally; to add annotations for Tasking, Shared and Environ Machines; typing annotations, and parameter direction information; and sensing/actuating annotations, where necessary. Further work is under way to integrate the code generation feature with the new Rodin editor.
+
{{TODO}} ''To be completed by Issam Maamria''
 +
== Plug-in Incompatibilities ==
 +
{{TODO}} ''To be completed by all partners''
 +
== 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 ==
 +
{{TODO}} ''To be completed by Michael Jastram''
  
−
== Allowing Extensibility ==
+
= Choices / Decisions =
−
The code generation approach is now extensible; in that, new target language constructs can be added using the Eclipse extension mechanism. The translation of target's mathematical language is now specified in the theory plug-in. This improves clarity since the the translation from source to target is achieved by specifying pattern matching rules. The theory plug-in is used to specify new data-types, and how they are implemented. Translated code is deposited in a directory in the appropriate files. An Ada project file is generated for use with AdaCore's GPS workbench. Eventually this could be enabled/disabled in a preferences dialog box. The Tasking Event-B to Event-B translator is now properly integrated. Control variable updates to the Event-B model are made in a similar way to the equivalent updates in the state-machine plug-in. The additional elements are added to the Event-B model and marked as 'generated'. This prevents users from manually modifying them, and allows them to be removed through a menu choice.
+
== Platform maintenance ==
 +
* Revisited task priority
 +
This year, the process of giving priority to maintenance tasks was revisited according the the refocus mentionned above. The aim was address all the major scalability issues before the end of DEPLOY. Thus not only the requests coming from DEPLOY partners were given high priorities, but they were prioritized against the already planned tasks coming from both DEPLOY partners and the Description of Work. This prioritization was performed or internally at each WP9 member site, if the task is short (i.e. less than one man-week), or during the WP9 bi-weekly telephone conferences otherwise. 
 +
* A way to tackle plug-in incompatibilities
 +
It has been decided in concertation 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:
 +
:* Rodin/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 developpers to contact SYSTEREL in charge of managing the packages shipped with a given version of Rodin. It could also allow tracability 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>.
 +
:* plug-in/plug-in incompatibilities, due to some wrong match between needed/installed packages, or API/ressources 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.
 +
It appeared that cases of using a model which references some missing plug-ins were formerly often seen as compatibility issues although they are not.
  
−
== Targeting new Languages ==
+
* Keep 32-bit versions of the Rodin platform on linux and windows systems
−
Making the step from Event-B to code is a process that can be aided through automatic code generation.
+
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 no longer relevant for now.
−
The code generation plug-in for Rodin is a new tool for translating Event-B models to concurrent programmes.
 
−
However users of such a tool will likely require a diverse range of target languages and target platforms, for which we do not currently provide translations.Some of these languages may be subtly different to existing languages and only have modest differences between the translation rules, for example C and C++, whilst others may have more fundamental differences. As the translation from Event-B to executable code is non-trivial and to reduce the likelihood of error, we want to generalize as much of the translation as possible so that existing translation rules are re-used.
 
−
Therefore significant effort is needed to ensure that such a translation tool is extensible to allow additional languages to be included with relative ease. Here we concentrate on translation from a previously defined Common Language Meta-model, the intermediary language IL1, which Event-B translates to directly. IL1 is an EMF metamodel representation of generic properties and functionality found in many programming languages. It has representations for key structural concepts such as variables, subroutines, function calls and parameters. The translation of predicates and expressions contained within the code are handled by a new extension to the theory plug-in, which allows translation rules to be developed for specific target languages within the Rodin environment. The generic nature of the intermediary language is designed to allow for a wide range of different target languages. Developers of new target languages are required to write translators in Java for the conversion from the EMF representation to the code of their target language. To do this we provide a central translation manager, that takes an IL1 model and automatically calls the appropriate translators for each element of the model, whilst also providing the link to the predicate and expression translators provided by the new theory plug-in. The developer registers their translators for the target language through an extension point, where currently there are 15 light-weight translators required for a new target language.
 
−
To aid the developer, we provide abstract translators for each required element in the IL1 model that has to be translated. These translators perform the majority of the translation automatically, meaning that in most cases all the developer is required to do is format strings into the appropriate structure for their target language.
 
−
For example in an branch statement, the developer would be required to write a method stating how a branch is defined and structured in their language, using a set of previously translated guard conditions and actions.
 
−
Importantly, the flexibility remains for the developer to re-write any of the translations if the ones provided are not suitable.
 
  
−
== Using Abstract Translators ==
+
== Mathematical extensions / Theory Plug-in ==
−
To test our approach, we have built translators for C, Ada and Java using the same underlying abstract translators.
+
{{TODO}} ''To be completed by Issam Maamria''
−
Additionally we consider the case where a new language may be required that has only modest differences to an existing language. A good example of this is to consider the case where a different library may want to be used from one used in an existing translation. For instance in C, concurrency can be achieved through different mechanisms such as OpenMP or Pthreads. In this case it may be that all but the mechanism for handling a subroutine call are the same, meaning that the majority of the translation can occur using common translators, with separate translators for the different methods of handling a subroutine call. To allow for this we allow the developer to assign a core and specialisation language to each translator they build. In cases where a translator for the specialisation language does not exist, the translator will automatically defer to the default core language translator, if one exists. This means that default translators for a particular core language can be written for the majority of the translation, with specialisations being provided where differences occur. The core and specialisation of the language is also reflected in the theory translator, meaning that language theories are only required for the core languages, rather than for each individual specialization.
+
== Plug-in Incompatibilities ==
 +
{{TODO}} ''To be completed by all partners''
 +
== 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 ==
 +
{{TODO}} ''To be completed by Michael Jastram''
  
 
= Available Documentation =
 
= Available Documentation =
−
We have updated the documentation, including the Tasking Event-B Overview, and Tutorial materials.
+
* Core platform:
−
[[TODO]] ''complete''
+
:The following pages give useful information about the Rodin platform releases:
 +
:* Release notes<ref>http://wiki.event-b.org/index.php/Rodin_Platform_Releases</ref>.
 +
:* Bugs<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651669</ref>.
 +
:* Feature requests<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651672</ref>.
 +
*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>http://handbook.event-b.org/</ref>.
 +
 
 +
*{{TODO}}  Links for Mathematical extensions / Theory Plug-in
 +
*{{TODO}}  Links for Plug-in Incompatibilities
 +
*{{TODO}}  Links for Modularisation
 +
*{{TODO}}  Links for Decomposition
 +
*{{TODO}}  Links for Team-based Development
 +
*{{TODO}}  Links for UML-B
 +
*{{TODO}}  Links for ProR
  
 
= Status =
 
= Status =
 +
== Platform maintenance ==
 +
By the end of the project, there are :
 +
* xx bugs reported and open. All with a priority lower or equal to 5.
 +
* xx feature requests expressed and still open.
 +
 +
== Mathematical extensions / Theory Plug-in ==
 +
{{TODO}} ''To be completed by Issam Maamria''
 +
== Plug-in Incompatibilities ==
 +
{{TODO}} ''To be completed by all partners''
 +
== 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 ==
 +
{{TODO}} ''To be completed by Michael Jastram''
  
−
We released a new version of the code generator on 22-03-2012. The changes were made to the methodology, user interface, and tooling. The first version of the code generator supported translation to Ada, and the current version also has limited support for C.
 
  
 
= References =
 
= References =

Revision as of 09:33, 21 November 2011

Overview

The Rodin platform versions concerned by this deliverable are:

  • 2.1(08.02.2011),
  • 2.2(01.06.2011),
  • 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 has been put on correcting usability issues. Indeed, during the 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[1] and the SourceForge[1] databases (bugs and feature requests) for details about the previous and upcoming releases of the Rodin platform.

  • General platform maintenance (Thomas Muller)

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

These items will be detailed hereafter in this chapter.

  • 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)
  • TODO An overview of the contribution about ProR (Michael Jastram)

Motivations

The tasks to solve the issues faced by the DEPLOY partners have been listed and being 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 ressourced 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 is beyond the scope of DEPLOY.


Group 1 (highest priority) Responsible
Performance
- Core (large models, etc.)
- GUI (incl. prover UI, edition, etc.)		 SYSTEREL
Prover Performances
- New rewriting rules / inference rules
- 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
Group 2 Responsible
Prover Performances
- SMT provers integration
- connection with Isabelle
- Mathematical extensions
- ProB
SYSTEREL
ETH Zürich
Southampton/SYSTEREL
Düsseldorf
Scalability
- Decomposition
- Modularisation plug-in
- Team-based development
Southampton
Newcastle
Southampton
Plug-in incompatibilities Newcastle
Model-based testing Pitesti/Düsseldorf
ProR Düsseldorf
Group 3 Responsible
Scalability
- Generic instantiation
- UML-B maintenance

Southampton
ETH Zürich/Southampton
Code Generation Southampton
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, mainly concerned stability and performance improvement. These topics will be discussed and detailed in a separate chapter about scalability improvements.
However, other prioritary improvements were made on the platform. These improvements or 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 ProverUI.

This feature came from a request of DEPLOY partners[2], 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 ProvingUI interface, a nice feature was added, allowing to search and highlight a string pattern into the whole ProvingUI views and editors. This function as also been enabled on direct selection of text in this UI.

  • A better output providing warning and errors in case of wrong or missing building configurations.

This issue, often seen as a bug or a plug-in incompatibility, raises when a user imoprts and tries to use a model on a platform with some missing plug-ins needed on build. The user often use to think his models corrupted although Rodin just being not able to build them, and hiding this information to the user. This is why, since Rodin 2.3, an output in such case has been provided taking the form of warnings or errors that any user can review. This is a partial answer to Rodin plug-in incompatibilities issue.

  • The switch to Eclipse 3.7.

Due to the major improvements made every year in every 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 support of an expert [3]. Losts of efforts to improve the documentation were performed and coordinated by Düsseldorf, and took form of a handbook[4]. 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 the contents of the Event-B wiki, which have been finally migrated from the wiki to the Rodin handbook.

Mathematical extensions / Theory Plug-in

TODO To be completed by Issam Maamria

Plug-in Incompatibilities

TODO To be completed by all partners

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

TODO To be completed by Michael Jastram

Choices / Decisions

Platform maintenance

  • Revisited task priority

This year, the process of giving priority to maintenance tasks was revisited according the the refocus mentionned above. The aim was address all the major scalability issues before the end of DEPLOY. Thus not only the requests coming from DEPLOY partners were given high priorities, but they were prioritized against the already planned tasks coming from both DEPLOY partners and the Description of Work. This prioritization was performed or internally at each WP9 member site, if the task is short (i.e. less than one man-week), or during the WP9 bi-weekly telephone conferences otherwise.

  • A way to tackle plug-in incompatibilities

It has been decided in concertation 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:

  • Rodin/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 developpers to contact SYSTEREL in charge of managing the packages shipped with a given version of Rodin. It could also allow tracability of incompatibilities and information to the user through a specific and actualized table on each Rodin release notes page on the Wiki[5].
  • plug-in/plug-in incompatibilities, due to some wrong match between needed/installed packages, or API/ressources incompatible usage. A table was created on each release notes wiki page, and a procedure was defined[6] so that identified incompatibilities are listed and corrected by the concerned developers.

It appeared that cases of using a model which references some missing plug-ins were formerly often seen as compatibility issues although they are not.

  • Keep 32-bit versions of the Rodin platform on linux and windows systems

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 no longer relevant for now.

Mathematical extensions / Theory Plug-in

TODO To be completed by Issam Maamria

Plug-in Incompatibilities

TODO To be completed by all partners

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

TODO To be completed by Michael Jastram

Available Documentation

  • Core platform:
The following pages give useful information about the Rodin platform releases:
  • Release notes[7].
  • Bugs[8].
  • Feature requests[9].
  • 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[10].
  • TODO Links for Mathematical extensions / Theory Plug-in
  • TODO Links for Plug-in Incompatibilities
  • TODO Links for Modularisation
  • TODO Links for Decomposition
  • TODO Links for Team-based Development
  • TODO Links for UML-B
  • TODO Links for ProR

Status

Platform maintenance

By the end of the project, there are :

  • xx bugs reported and open. All with a priority lower or equal to 5.
  • xx feature requests expressed and still open.

Mathematical extensions / Theory Plug-in

TODO To be completed by Issam Maamria

Plug-in Incompatibilities

TODO To be completed by all partners

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

TODO To be completed by Michael Jastram


References

  1. ↑ 1.0 1.1 http://wiki.event-b.org/index.php/D32_General_Platform_Maintenance#Available_Documentation Cite error: Invalid <ref> tag; name "documentation" defined multiple times with different content
  2. ↑ https://sourceforge.net/tracker/?func=detail&atid=651672&aid=3092835&group_id=108850
  3. ↑ http://wiki.event-b.org/index.php/User_Documentation_Overhaul
  4. ↑ http://handbook.event-b.org/
  5. ↑ http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Current_plug-ins
  6. ↑ http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Known_plug-in_incompatibilities
  7. ↑ http://wiki.event-b.org/index.php/Rodin_Platform_Releases
  8. ↑ https://sourceforge.net/tracker/?group_id=108850&atid=651669
  9. ↑ https://sourceforge.net/tracker/?group_id=108850&atid=651672
  10. ↑ http://handbook.event-b.org/
Retrieved from ‘https://wiki.event-b.org/index.php?title=D45_Code_Generation&oldid=2830’