Difference between pages "Current Developments" and "D32 Code generation"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Leuschel
 
imported>Andy
 
Line 1: Line 1:
{{TOCright}}
+
'''THIS DOCUMENT IS NOT YET COMPLETE !!!'''
This page sum up the known developments that are being done around or for the [[Rodin Platform]]. ''Please contributes informations about your own development to keep the community informed''
 
  
== Deploy Tasks ==
+
=== Overview ===
The following tasks were planned at some stage of the [[Deploy]] project.
 
=== Core Platform ===
 
==== New Mathematical Language ====
 
==== Rodin Index Manager ====
 
[[Systerel]] is in charge of this task.
 
{{details|Rodin Index Design|Rodin index design}}
 
  
The purpose of the Rodin index manager is to store in a uniform way the entities that are declared in the database together with their occurrences. This central repository of declarations and occurrences will allow for fast implementations of various refactoring mechanisms (such as renaming) and support for searching models or browsing them.  
+
The code generation activity has been undertaken at the University of Southampton. This has been a new line of work for DEPLOY that was not identified in the original Description of Work for the project. The development of the approach, and the tools to support, it involved a number of team members at Southampton; and also at other institutions. This work draws on our recent experience with technologies such as ''Shared Event Decomposition'' [[http://wiki.event-b.org/index.php/Event_Model_Decomposition]], and the ''EMF Framework for Event-B'' [[http://wiki.event-b.org/index.php/EMF_framework_for_Event-B]]. There was collaboration at an early stage with Newcastle University, where we explored the commonalities between their flow plug-in [[http://wiki.event-b.org/index.php/Flows]] and the algorithmic structures used in our approach. Collaboration with the University of York was also established since we chose to use their ''Epsilon'' [[http://www.eclipse.org/gmt/epsilon/]] model-to-model transformation technology.
  
==== Undo / Redo ====
+
=== Motivations ===
[[Systerel]] is in charge of this task.
 
{{details|Undo Redo Design|Undo/Redo design}}
 
{{TODO|describe current work in [[Undo Redo Design]]}}
 
  
{{TODO|add a short summary about current work for undo/redo here}}
+
The decision was taken in 2009 [[http://wiki.event-b.org/index.php/D23_Code_Generation]] to include code generation as a project goal. It had been recognised that support for generation of code from refined Event-B models would be an important factor in ensuring eventual deployment of the DEPLOY approach within their organisations. This was especially true for Bosch and Space Systems Finland (SSF). After receiving more detailed requirements from Bosch and SSF, it became clear we should focus our efforts on supporting the generation of code for typical real-time embedded control software.
  
==== Text Editor ====
+
=== Choices / Decisions ===
  
=== Plug-ins ===
+
During the last year we have focussed on supporting the generation of code for typical real-time embedded control software. To this end we have developed a multi-tasking approach which is conceptually similar to that of the Ada tasking model. Individual tasks are treated as sequential programs; these are modelled by an extension to Event-B, called ''Tasking Machines''.  Tasks have mutually exclusive access to state variables through the use of protected resources. The protected resources correspond to Event-B machines. For real-time control, periodic and one-shot activation is currently supported; and it is planned to support aperiodic tasks in the near future. Tasks have priorities to ensure appropriate responsiveness of the control software. For the DEPLOY project, it was regarded as sufficient to support construction of programs with a fixed number of tasks and a fixed number of shared variables – no dynamic creation of processes or objects has been accommodated.  
==== Requirement Management Plug-in ====
 
[[User:Jastram|Michael]] at [[Düsseldorf]] is in charge of the [[:Category:Requirement Plugin|Requirements Management Plug-in]].
 
  
{{See also|ReqsManagement|Requirements Tutorial|l1=Requirements Management Plug-in}}
+
Our main goal this year has been to devise an approach for, and provide tool support for, code generation. In accord with the resources available during the year it was decided to limit the provision of tool support to that of a demonstrator tool. The tool is a proof-of-concept only, and lacks the productivity enhancements expected in a more mature tool. We also gained much practical experience with the development of a code generation framework.
  
This plug-in allows:
+
=== Available Documentation ===
* Requirements to be edited in a set of documents (independently from Rodin)
 
* Requirements to be viewed within Rodin
 
* Individual Requirements to be linked to individual Event-B-Entities
 
* A basic completion test to be performed
 
  
==== UML-B Plug-in ====
+
This paragraph shall give pointers to the available wiki pages or related publications. This documentation may contain:
[[Southampton]] is in charge of [[UML-B]] plug-in.
 
  
* Support for synchronisation of transitions from different statemachines. This feature will allow two or more transitions in different statemachines to contribute to a single event. This feature is needed because a single event can alter several variables (in this case statemachines) simultaneously.
+
    * Requirements.
 +
    * Pre-studies (states of the art, proposals, discussions).
 +
    * Technical details (specifications).
 +
    * Teaching materials (tutorials).
 +
    * User's guides.  
  
*Allow user to allocate the name of the 'implicit contextual instance' used in a class. Events and Transitions owned by a class are implicitly acting upon an instance of the class which has formerly been denoted by the reserved word 'self'. This modification allows the modeller to override 'self' (which is now the default name) with any other identifier. This feature is needed to avoid name clashes when synchronising transitions into a single event. It also allows events to be moved between different classes (or outside of all classes) during refinement without creating name clashes.
+
A distinction shall be made on the one hand between these different categories, and on the other hand between documentation written for developers and documentation written for end-users.
  
* Better support for state machine refinement in UML-B. This revision to UML-B allows a statemachine to be recognised as a refinement of another one and to be treated in an appropriate way during translation to Event-B. The states and transitions of a refined statemachine can be elaborated by adding more detailed hierarchical statemachines.
+
=== Planning ===
  
==== ProB Plug-in ====
+
This paragraph shall give a timeline and current status (as of 28 Jan 2011).
[[Düsseldorf]] is in charge of [[ProB]].
 
{{details|ProB current developments|ProB current developments}}
 
 
 
{{TODO|describe current work in [[ProB current developments]]}}
 
 
 
We have now ported ProB to work directly on the Rodin AST. Animation is working and the user can now set a limited number of preferences.
 
The model checking feature is now also accessible.
 
It is also possible to create CSP and classical B specification files. These files can be edited with BE4 and animated/model checked with ProB.
 
 
 
{{TODO|add a short summary about current works for ProB here}}
 
 
 
We are currently developing a new, better user interface.
 
We also plan to support multi-level animation with checking of the gluing invariant.
 
 
 
We have prototypes for several extensions working:
 
- an inspector that allows the user to inspect complex predicates (such as invariants or guards) as well as expressions in a tree-like manner
 
- a graphical animator based on SWT that allows the user to design his/her own animations easily within the tool
 
- a 2D viewer to inspect the state space of the specification
 
 
 
== Exploratory Tasks ==
 
=== One Single View ===
 
[[Maria]] is in charge of this exploratory work during is internship.
 
{{details|Single View Design|Single View Design}}
 
The goal of this project is to present everything in a single view in Rodin. So the user won't have to switch perspectives.
 
 
 
 
 
 
 
== Others ==
 
 
 
=== AnimB ===
 
[[Christophe]] devotes some of its spare time for this plug-in.
 
{{details|AnimB Current Developments|AnimB Current Developments}}
 
The current developments around the [[AnimB]] plug-in encompass the following topics:
 
;Live animation update
 
:where the modification of the animated event-B model is instantaneously taken into account by the animator, without the need to restart the animation.
 
;Collecting history
 
:The history of the animation will be collected.
 
 
 
 
 
 
 
[[Category:Work in progress]]
 

Revision as of 12:44, 1 December 2010

THIS DOCUMENT IS NOT YET COMPLETE !!!

Overview

The code generation activity has been undertaken at the University of Southampton. This has been a new line of work for DEPLOY that was not identified in the original Description of Work for the project. The development of the approach, and the tools to support, it involved a number of team members at Southampton; and also at other institutions. This work draws on our recent experience with technologies such as Shared Event Decomposition [[1]], and the EMF Framework for Event-B [[2]]. There was collaboration at an early stage with Newcastle University, where we explored the commonalities between their flow plug-in [[3]] and the algorithmic structures used in our approach. Collaboration with the University of York was also established since we chose to use their Epsilon [[4]] model-to-model transformation technology.

Motivations

The decision was taken in 2009 [[5]] to include code generation as a project goal. It had been recognised that support for generation of code from refined Event-B models would be an important factor in ensuring eventual deployment of the DEPLOY approach within their organisations. This was especially true for Bosch and Space Systems Finland (SSF). After receiving more detailed requirements from Bosch and SSF, it became clear we should focus our efforts on supporting the generation of code for typical real-time embedded control software.

Choices / Decisions

During the last year we have focussed on supporting the generation of code for typical real-time embedded control software. To this end we have developed a multi-tasking approach which is conceptually similar to that of the Ada tasking model. Individual tasks are treated as sequential programs; these are modelled by an extension to Event-B, called Tasking Machines. Tasks have mutually exclusive access to state variables through the use of protected resources. The protected resources correspond to Event-B machines. For real-time control, periodic and one-shot activation is currently supported; and it is planned to support aperiodic tasks in the near future. Tasks have priorities to ensure appropriate responsiveness of the control software. For the DEPLOY project, it was regarded as sufficient to support construction of programs with a fixed number of tasks and a fixed number of shared variables – no dynamic creation of processes or objects has been accommodated.

Our main goal this year has been to devise an approach for, and provide tool support for, code generation. In accord with the resources available during the year it was decided to limit the provision of tool support to that of a demonstrator tool. The tool is a proof-of-concept only, and lacks the productivity enhancements expected in a more mature tool. We also gained much practical experience with the development of a code generation framework.

Available Documentation

This paragraph shall give pointers to the available wiki pages or related publications. This documentation may contain:

   * Requirements.
   * Pre-studies (states of the art, proposals, discussions).
   * Technical details (specifications).
   * Teaching materials (tutorials).
   * User's guides. 

A distinction shall be made on the one hand between these different categories, and on the other hand between documentation written for developers and documentation written for end-users.

Planning

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