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

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Colin
 
imported>Andy
(New page: === Overview === This first paragraph shall identify the involved partners and give an overview of the contribution. In particular, it shall provide answers to the following questions: ...)
 
Line 1: Line 1:
{{TOCright}}
+
=== Overview ===
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 ==
+
This first paragraph shall identify the involved partners and give an overview of the contribution. In particular, it shall provide answers to the following questions:
The following tasks were planned at some stage of the [[Deploy]] project.
 
=== Rodin Index ===
 
[[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.
+
    * What are the common denominations?
 +
    * Is it a new feature or an improvement?
 +
    * What is the main purpose?
 +
    * Who was in charge?
 +
    * Who was involved?
  
 +
=== Motivations ===
  
 +
This paragraph shall express the motivation for each tool extension and improvement. More precisely, it shall first indicate the state before the work, the encountered difficulties, and shall highlight the requirements (eg. those of industrial partners). Then, it shall summarize how these requirements are addressed and what are the main benefits.
  
=== UML-B plugin ===
+
=== Choices / Decisions ===
[[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.
+
This paragraph shall summarize the decisions (eg. design decisions) and justify them. Thus, it may present the studied solutions, through their main advantages and inconvenients, to legitimate the final choices.
  
 +
=== Available Documentation ===
  
*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.
+
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.
  
* Better support for state machine refinement in UML-B. This is a revision to UML-B. It 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 of a refined statemachine can be elaborated by adding child statemachines and transitions can be elaborated within these child statemachines.
+
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.
  
== Exploratory tasks ==
+
=== Planning ===
=== 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.
 
  
 
+
This paragraph shall give a timeline and current status (as of 28 Jan 2011).
 
 
== 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 10:41, 1 December 2010

Overview

This first paragraph shall identify the involved partners and give an overview of the contribution. In particular, it shall provide answers to the following questions:

   * What are the common denominations?
   * Is it a new feature or an improvement?
   * What is the main purpose?
   * Who was in charge?
   * Who was involved? 

Motivations

This paragraph shall express the motivation for each tool extension and improvement. More precisely, it shall first indicate the state before the work, the encountered difficulties, and shall highlight the requirements (eg. those of industrial partners). Then, it shall summarize how these requirements are addressed and what are the main benefits.

Choices / Decisions

This paragraph shall summarize the decisions (eg. design decisions) and justify them. Thus, it may present the studied solutions, through their main advantages and inconvenients, to legitimate the final choices.

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