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

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Pascal
 
imported>Andy
 
Line 1: Line 1:
= Overview =
+
The Event-B method, and supporting tools have been developed during the DEPLOY project. A number of the 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. Initially, we chose to translate to the Ada programming language, and use it as a basis for the abstractions used in our approach. The first version of the code generator supported translation to Ada, and the current version also has limited support for C.  
The main goal of the platform corrective and evolutive maintenance is to fix the listed known bugs, and implement some new requested features. As in the previous years of Deploy, these bugs and features are reported either by mail or through dedicated SourceForge trackers.
 
  
The terse list below gives an overwiew of the noteworthy features added in the main platform during the past year:
+
We released a new version of the code generator on 21-03-2012. We have made changes to the methodology, user interface, and tooling. 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. We have also updated the documentation, including the Tasking Event-B Overview, and Tutorial materials.  
* Proof replay on undischarged POs (releases 1.3 and upper)
 
: It often happens, while modifying a model, that a set of previously manually discharged POs are slightly changed and need to be discharged again. However, replaying the proof for those POs could most of the time be enough to discharge it. Hence, a command was added to manually try replaying the proofs for a set of undischarged POs. This request was expressed by [https://sourceforge.net/tracker/?func=detail&aid=2949606&group_id=108850&atid=651672 end users]. See [http://wiki.event-b.org/index.php/Proof_Obligation_Commands].
 
* Rule Details View (releases 2.0 and upper)
 
: When doing an interactive proof, one is guided by the proof tree appearing on the proof tree view. However, it is sometimes needed to get more informations about the rules being involved in a proof, such as instantiation details, hidden hypotheses, etc. The [http://wiki.event-b.org/index.php/Rodin_Proving_Perspective#Rule_Details_View Rule Details View] displaying such details has been added.
 
* Refactoring plug-in (releases 1.2 and upper)
 
: ---
 
* Documentation
 
: Plug-in developers expressed their need to get a detailed documentation about Rodin extension ability. A dedicated [http://wiki.event-b.org/index.php/Plug-in_Tutorial tutorial][http://wiki.event-b.org/index.php/D23_General_Platform_Maintenance#Available_Documentation] has been written accordingly, and was the support of a training session given at the [http://www.event-b.org/rodin10.html Rodin User and Developer Workshop] in Düsseldorf this year.
 
  
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.
+
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. However, we can use the demonstrator as a baseline, and describe the new features as follows:
  
= Motivations =
 
The evolutive maintenance (resp. corrective maintenance) has its origin in the Deploy project's description of work, and the various requests (resp. bug reports) listed by WP1-4 partners, developers and users. Since the Deploy project's birth, various streams can be used to express feature requests or track an encountered bug :
 
: - [http://wiki.event-b.org/index.php/D23_General_Platform_Maintenance#Available_Documentation dedicated trackers],
 
: - DEPLOY mailing lists.
 
Maintenance tasks to perform are collected from the aforementioned streams and scheduled during WP9 meetings. These tasks are processed in the same way as the task planned in the description of work.
 
  
The following table describes the main tasks performed or scheduled tasks motivating the evolutive maintenance :
+
* 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).
 +
* We have the ability to translate to C and 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 Rose Editor is used for editing the Tasking Event-B. A text-based editor is provided, using the Rose extension, for editing the TaskBody.
 +
* The composed machine component is used to store event 'synchronizations'.
 +
* Minimal use is made of the EMF tree editor in Rose.
  
{{SimpleHeader}}
+
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.
|-
 
! scope=col | Origin || Maintenance Task || Done in 2010 || Scheduled in 2011
 
|-
 
| WP1-4 partners|| Updating fields of records || x ||
 
|-
 
| WP1-4 partners|| Team work || x ||
 
|-
 
| WP1-4 partners|| Increase platform performances ||  || x
 
|-
 
| WP1-4 partners|| Search in goal window ||  || x
 
|-
 
| WP1-4 partners|| Preferences for the automatic tactics ||  || x
 
|-
 
| Plug-in developers|| API to extend the Pretty Printer view || x ||
 
|-
 
| Plug-in developers|| View the error log || x ||
 
|-
 
| End Users|| Adding a replay proof command in the Event-B explorer || x ||
 
|-
 
| End Users|| Having auto-completion in proof control || x ||
 
|- 
 
| End Users|| Displaying instantiated hypotheses || x ||
 
|- 
 
| End Users || Displaying the inherited elements || || x
 
|}
 
  
= 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.
* Task priority
 
: Listed tasks are being given a priority during WP9 bi-weekly meetings, and then assigned to partners in charge of their processing. It has been decided to give a higher priority to WP1-4 partner's requests.
 
* 64-bit release of Rodin for Mac platforms
 
: A major UI bug, due to some incompatibilities between Eclipse 3.5 and Java 1.6 on Mac platforms motivated the migration to the Eclipse 3.6 as basis for the Rodin 2.0 platform. In the meantime, as the 32-bit Java Virtual Machine is no longer supported on Mac platforms, Rodin migrated to Java 1.6, so that the release 2.0 of Rodin became a 64-bit Mac platform only.
 
: The Rodin platforms family is then composed of three executables : 32-bit platforms for Linux and Windows environments and a 64-bit platform for Mac computers.
 
* Rodin sources
 
: The sources of Rodin releases are now packed with the platform. It has been decided to ship the sources in every platform release. It is, for developers, a convenient alternative to the available sources on SourceForge (See [http://wiki.event-b.org/index.php/Using_Rodin_as_Target_Platform]).
 
* Release notes
 
: The release notes contain information about the released plug-ins and centralise the requirements or existing issues which could not be stated at the main platform release date. Thus, since Rodin 2.0 release, it has been chosen to link the contents of the release notes text file included in Rodin releases, with the contents of the dedicated Wiki page.
 
 
 
= Available Documentation =
 
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].
 
* Bugs.
 
: See [http://sourceforge.net/tracker/?atid=651669&group_id=108850].
 
* Feature requests.
 
: See [http://sourceforge.net/tracker/?group_id=108850&atid=651672].
 
 
 
The user manual, user tutorial and other developer documentation on the [http://wiki.event-b.org wiki] are continuously, and collaboratively updated and enhanced. A major update (see [http://wiki.event-b.org/index.php?title=D32_General_Platform_Maintenance#Overview]) to the developer documentation about Rodin extension ability has been done.
 
 
 
= Planning =
 
During the coming year, special efforts will be made on the following topics, which where pointed out at the last plenary meeting by the WP1-WP4 and encompass end-user requests:
 
* Platform stability
 
: Currently, users struggle through performance flows in the Rodin platform while editing or proving a model. Solving these issues represents a real challenge for the coming year and will be mandatory for the industrial adoption of Rodin and Event-B.
 
* Prover integrity
 
: Reaching a state where POs are hundred percent automatically proved is the wager that Rodin developers aim. Getting close to this ideal will increase the satisfaction of industrial users and decrease costs. Enhancing prover facilities are as well, one significant help given to the person in charge of the proving. Enhancing prover is then a continuous task that will be performed until the Deploy project's end. However, such automatic or manual pieces of program are main points of integrity concerns. Ensuring their correctness and getting more confidence into them, will thus be a task conducted during the coming year.
 
* Plug-in incompatibilities
 
: The problem occurs when several plug-ins are installed and conflicts exist between them. The cumbersome behaviour often spawned by such incompatibilities leads to user's disappointment, or even to the impossility to use the platform. Particular efforts will be lead to identify the sources of incompatibilities amongs plug-in and coordinate the assignment and processing of the necessary corrective maintenance tasks.
 
 
 
[[Category:D32 Deliverable]]
 

Revision as of 10:29, 21 March 2012

The Event-B method, and supporting tools have been developed during the DEPLOY project. A number of the 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. Initially, we chose to translate to the Ada programming language, and use it as a basis for the abstractions used in our approach. The first version of the code generator supported translation to Ada, and the current version also has limited support for C.

We released a new version of the code generator on 21-03-2012. We have made changes to the methodology, user interface, and tooling. 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. We have also updated the documentation, including the Tasking Event-B Overview, and Tutorial materials.

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. However, we can use the demonstrator as a baseline, and describe the new features as follows:


  • 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).
  • We have the ability to translate to C and 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 Rose Editor is used for editing the Tasking Event-B. A text-based editor is provided, using the Rose extension, for editing the TaskBody.
  • The composed machine component is used to store event 'synchronizations'.
  • Minimal use is made of the EMF tree editor in Rose.

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.

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.