Current Developments: Difference between revisions

Latest revision as of 16:35, 18 March 2014

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

You may also have a look at past developments.

Current Tasks

The following tasks were planned at some stage of the Deploy or Advance project.

Code Generation

For an overview of Tasking Event-B see Tasking Event-B Overview.

For information about the recent release see Code Generation.

The tutorial is available at Code Generation Tutorial.

Core Platform

Extended Operator Translation

The purpose of this development is to improve the support of mathematical extensions in external provers without changing them.

Text Editor

The efforts in Düsseldorf (Fabian) and Newcastle (Alexei) have been joined to create a single text editor which will be part of the EMF framework for Event-B (see that section for details).

The first version of the TextEditor will be released in a few weeks (following the Rodin 1.0 release). Until then we are going to release a few testing releases (beta) for interested users. Find detailed information on the page TextEditor.

Plug-ins

Modularisation Plug-in

The Modularisation Plug-in provides facilities for structuring Event-B developments into logical units of modelling, called modules. The module concept is very close to the notion Event-B development (a refinement tree of Event-B machines). However, unlike a conventional development, a module comes with an interface. An interface defines the conditions on how a module may be incorporated into another development (that is, another module). The plug-in follows an approach where an interface is characterised by a list of operations specifying the services provided by the module. An integration of a module into a main development is accomplished by referring operations from Event-B machine actions using an intuitive procedure call notation.

UML-B Improvements

Southampton is in charge of UML-B plug-in.

A new version of UML-B is being developed that will have improved integration with Event-B. The new version will be built as an extension to the EMF framework for Event-B. While this new version is being developed improvements are also being made to the existing version of UML-B. Both topics are covered in more detail on the following page: UML-B Integration and Improvements

ProB Plug-in

Düsseldorf is in charge of ProB.

Work already performed

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. On the classical B side we have moved to a new, more robust parser (which is now capable of parsing some of the more complicated AtelierB specifications from Siemens).

On the developer side, we have moved to a continuous integration infrastructure using CruiseControl. Rodin is also building from CVS in that infrastructure.

Developers can build tools on top of ProB using the ProB API.

Ongoing and future developments

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, but they need to be fully tested and integrated into the plugin:

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

Parallel Composition Plug-in

Southampton is in charge of the Parallel Composition using Event-B .

The purpose of the plug-in is to allow the parallel composition of several Event-B machines into a composite machine. The machine composition uses a shared event composition, where separate machines operate on disjoint variables and machines interact by synchronising on events that may share parameters.

This plug-in allows:

Selection of machines that will be part of the composition (Includes Section)
Possible selection of an abstract machine (Refines Section)
Possible inclusion of invariants that relate the included machines (Invariant Section and use of the monotonicity )
Invariants of included machines are conjoined.
Selection of events that will be merged. The event(s) must come from different machines. At the moment, events with parameters with same name are merged. If it is a refinement composition, it is possible to choose the abstract event that is being refined.
Initialisation event is the parallel composition of all the included machines' initialisations.
For a composed event, the guards are conjoined and the all the actions are composed in parallel.

Currently, after the conclusion of the composition machine, a new machine can be generated, resulting from the properties defined on the composition file. This allows proofs to be generated as well as a visualisation of the composition machine file. In the future, the intention is to make the validation directly on the composition machine file directly where proofs would be generated ( and discharged) - the new machine generation would be optional. An event-b model for the validation/generation of proofs in currently being developed. Another functionality which should be quite useful for the composition (but not restricted to that) is renaming:

while composing, two machines may have variables with the same name for instance (which is not allowed for this type of composition). In order to solve this problem, one would have to rename one of the variables in order to avoid the clash, which would mean change the original machine. A possible solution for that would be to rename the variable but just on composition machine file, keeping the original machine intact. A renaming framework designed and developed by Stefan Hallerstede and Sonja Holl exists currently although still on a testing phase. The framework was developed to be used in a general fashion (not constrained to event-b syntax). The idea is to extend the development of this framework and apply to Event-B syntax (current development).

There is a prototype for the composition plug-in available that works for Rodin 0.9.2.1 available from the Rodin Main Update Site soon, under 'Shared Event Composition'.

Refactoring Framework Plug-in

Southampton is in charge of the Refactoring Framework.

The intention of the plug-in is to allow the renaming/refactoring of elements on a file (and possible related files). Although created to be used in a general way, the idea is to embed this framework on the Rodin platform, using Event-B syntax. This plug-in was initially designed and developed by Stefan Hallerstede and Sonja Holl.

This plug-in allows:

Defining extensions that can be used to select related files.
Defining extesions that can be used to rename elements based on the type of file.
Renaming of elements on a file and possible occurrences on related files.
Generating of a report of possible problems (clashes) that can occur while renaming.

Measurement Plug-In

The Measurement Plug-In to the RODIN platform will provide information both about the model itself and about the process of building the model. It has a double purpose:

provide feedback to the user about the quality of the Event-B model he is building and about potential problems in it or in the way he is building it.
automate the data collection process for the measurement and assessment WP. This data collected will be analyzed to identify global transfer (increase in model quality, size, complexity,...), tool shortcomings (usability, prover), modelling issues (to be addressed by training, language, tool evolution,...), etc.

Generic Instantiation

The context of a machine can be viewed as defining the parameters of that machine (carrier sets, constants, axioms). These parameters make a machine generic. We propose an approach for instantiating Event-B machines by replacing generic sets and constants with more specific sets and constants. The axioms of a context represent assumptions on the sets and constants that need to be satisfied whenever the machine is instantiated. The instantiation leads to proof obligations to ensure that the generic axioms are satisfied by the instantiation. For more details see Generic Instantiation page.

Rule-based Extensible Prover

Southampton is in charge of devising an extensible rule-based prover.

In order to extend the prover with new rewrite and inference rules, it is necessary to write Java code adding to the appropriate extension points. That way, it becomes very difficult to verify the soundness of the implemented rules. We propose a mechanism by which the prover can be extended with new rewrite rules and inference rules without compromising its soundness. Our proposal follows a similar approach employed by Event-B: generating proof obligations. We, initially, focus on adding the facility to specify rewrite rules. We envisage the mechanism to evolve to cover inference rules as well as the many mathematical extensions proposed in Mathematical_extensions. For more details, we refer to the Rule-based_Prover_Plug-in page. and File:Rule-based Prover Proposal.pdf.

Exploratory Tasks

Template Base Exporter

Some prototyping work is done in python, to explore how to use template engines to export rodin models to text, Latex, docbook, mediawiki,... The mercurial repository is available here. You can cloned it by installing mercurial on your computer and doing hg clone https://bitbucket.org/matclab/rodin_exporter/.

Be warn that, for now, it bypass the rodin database API and does parse the .bum and .buc files directly. It is also highly experimental, so do not rely to much on the produced output.

(This work is done by Mathieu on his spare time...)

Others

AnimB

Christophe devotes some of his spare time for this plug-in.

For more details on AnimB Current Developments, see 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.

Team-Based Development

Usage Scenarios: In order to understand the problem properly, Düsseldorf created a number of usage Scenarios for Team-based Development.; A page has also been opened for merging proofs scenarios.

Team working based on EMF Compare: The EMF Compare project provides a comparison/merging style editor (similar to the Java merging editor used for synchronising changes with code repositories). This could be used to synchronise model changes into a repository such as SVN. The use of the EMF Compare editor relies on the EMF representation of Event-B that has already been developed and is available. A prototype plug-in is available which enables the use of the EMF compare editor for Rodin Machines and Contexts. It is intended that deploy partners will try out this plug-in in order to gather requirements for the Teamwork plug-in.; More details are here: Team-based development

Wishlist

A wish list of tool plug-ins that cannot be resourced by Deploy is maintained.

@@ Line 2: / Line 2: @@
 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 ==
+You may also have a look at [[Past Developments|past developments]].
-The following tasks were planned at some stage of the [[Deploy]] project.
+== Current Tasks ==
+The following tasks were planned at some stage of the [[Deploy]] or [[Advance]] project.
+=== Code Generation ===
+For an overview of Tasking Event-B see [[Tasking Event-B Overview]].
+For information about the recent release see [[Code Generation]].
+The tutorial is available at [[Code Generation Tutorial]].
 === 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.
+====Extended Operator Translation====
-==== Undo / Redo ====
+The purpose of this [[Extended Operator Translation|development]] is to improve the support of mathematical extensions in external provers without changing them.
-[[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}}
 ==== Text Editor ====
+The efforts in [[Düsseldorf]] ([[User:Fabian|Fabian]]) and [[Newcastle]] ([[User:Alexei|Alexei]]) have been joined to create a single text editor which will be part of the [[#EMF framework for Event-B|EMF framework for Event-B]] (see that [[#EMF framework for Event-B|section]] for details).
+The first version of the TextEditor will be released in a few weeks (following the Rodin 1.0 release). Until then we are going to release a few testing releases (beta) for interested users. Find detailed information on the page [[Text Editor|TextEditor]].
 === Plug-ins ===
-==== 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}}
+==== Modularisation Plug-in ====
-This plug-in allows:
+The [[Modularisation Plug-in]] provides facilities for structuring Event-B developments into logical units of modelling, called modules. The module concept is very close to the notion Event-B development (a refinement tree of Event-B machines). However, unlike a conventional development, a module comes with an interface. An interface defines the conditions on how a module may be incorporated into another development (that is, another module). The plug-in follows an approach where an interface is characterised by a list of operations specifying the services provided by the module. An integration of a module into a main development is accomplished by referring operations from Event-B machine actions using an intuitive procedure call notation.
-* 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 ====
+==== UML-B Improvements ====
 [[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.
+A new version of UML-B is being developed that will have improved integration with Event-B. The new version will be built as an extension to the EMF framework for Event-B. While this new version is being developed improvements are also being made to the existing version of UML-B. Both topics are covered in more detail on the following page:
+[[UML-B Integration and Improvements]]
-*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.
-* 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.
 ==== ProB Plug-in ====
 [[Düsseldorf]] is in charge of [[ProB]].
-{{details|ProB current developments|ProB current developments}}
+<!-- {{details|ProB current developments|ProB current developments}} -->
-{{TODO|describe current work in [[ProB current developments]]}}
+===== Work already performed =====
 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.
+On the classical B side we have moved to a new, more robust parser (which is now capable of parsing some of the more complicated AtelierB
+specifications from Siemens).
+On the developer side, we have moved to a continuous integration infrastructure using CruiseControl. Rodin is also building from CVS in that infrastructure.
+Developers can build tools on top of ProB using the [[ProB API]].
-{{TODO|add a short summary about current works for ProB here}}
+===== Ongoing and future developments=====
 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:
+We have prototypes for several extensions working, but they need to be fully tested and integrated into the plugin:
-- an inspector that allows the user to inspect complex predicates (such as invariants or guards) as well as expressions in a tree-like manner
+* 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 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
+* a 2D viewer to inspect the state space of the specification
+==== Parallel Composition Plug-in ====
+[[Southampton]] is in charge of the [[Parallel Composition using Event-B]] .
+The purpose of the plug-in is to allow the parallel composition of several Event-B machines into a composite machine. The machine composition uses a shared event composition, where separate machines operate on disjoint variables and
+machines interact by synchronising on events that may share parameters.
+This plug-in allows:
+* Selection of machines that will be part of the composition (''Includes'' Section)
+* Possible selection of an abstract machine (''Refines'' Section)
+* Possible inclusion of invariants that relate the included machines (''Invariant'' Section and use of the monotonicity )
+* Invariants of included machines are conjoined.
+* Selection of events that will be merged. The event(s) must come from different machines. At the moment, events with parameters with same name are merged. If it is a refinement composition, it is possible to choose the abstract event that is being refined.
+* Initialisation event is the parallel composition of all the included machines' initialisations.
+* For a composed event, the guards are conjoined and the all the actions are composed in parallel.
+Currently, after the conclusion of the composition machine, a new machine can be generated, resulting from the properties defined on the composition file. This allows proofs to be generated as well as a visualisation of the composition machine file. In the future, the intention is to make the validation directly on the composition machine file directly where proofs would be generated ( and discharged) - the new machine generation would be optional. An event-b model for the validation/generation of proofs in currently being developed. Another functionality which should be quite useful for the composition (but not restricted to that) is '''renaming''':
+* while composing, two machines may have variables with the same name for instance (which is not allowed for this type of composition). In order to solve this problem, one would have to rename one of the variables in order to avoid the clash, which would mean change the original machine. A possible solution for that would be to rename the variable but just on composition machine file, keeping the original machine intact. A renaming framework designed and developed by Stefan Hallerstede and Sonja Holl exists currently although still on a testing phase. The framework was developed to be used in a general fashion (not constrained to event-b syntax). The idea is to extend the development of this framework and apply to Event-B syntax (current development).
+There is a prototype for the composition plug-in available that works for Rodin 0.9.2.1 available from the Rodin Main Update Site soon, under 'Shared Event Composition'.
+==== Refactoring Framework Plug-in ====
+[[Southampton]] is in charge of the [[Refactoring Framework]].
+The intention of the plug-in is to allow the renaming/refactoring of elements on a file (and possible related files). Although created to be used in a general way, the idea is to embed this framework on the Rodin platform, using Event-B syntax. This plug-in was initially designed and developed by Stefan Hallerstede and Sonja Holl.
+This plug-in allows:
+* Defining extensions that can be used to select related files.
+* Defining extesions that can be used to rename elements based on the type of file.
+* Renaming of elements on a file and possible occurrences on related files.
+* Generating of a report of possible problems (clashes) that can occur while renaming.
+==== Measurement Plug-In ====
+The [[Measurement Plug-In]] to the RODIN platform will provide information both about the model itself and about the process of building the model.
+It has a double purpose:
+* provide feedback to the user about the quality of the Event-B model he is building and about potential problems in it or in the way he is building it.
+* automate the data collection process for the measurement and assessment WP. This data collected will be analyzed to identify global transfer (increase in model quality, size, complexity,...), tool shortcomings (usability, prover), modelling issues (to be addressed by training, language, tool evolution,...), etc.
+==== Generic Instantiation ====
+The context of a machine can be viewed as defining the parameters of that machine
+(carrier sets, constants, axioms).  These parameters make a machine generic.
+We propose an  approach for  instantiating Event-B  machines by replacing generic sets and constants
+with more specific sets and constants.  The axioms of a context represent assumptions on the
+sets and constants that need to be satisfied whenever the machine is instantiated.
+The instantiation leads to proof obligations
+to ensure that the generic axioms are satisfied by the instantiation.  For more details see [[Generic Instantiation | Generic Instantiation page]].
+==== Rule-based Extensible Prover ====
+[[Southampton]] is in charge of devising an extensible rule-based prover.
+In order to extend the prover with new rewrite and inference rules, it is necessary to write Java code
+adding to the appropriate extension points. That way, it becomes very difficult to verify the soundness of the
+implemented rules. We propose a mechanism by which the prover can be extended with new rewrite rules
+and inference rules without compromising its soundness. Our proposal follows a similar
+approach employed by Event-B: generating proof obligations. We, initially, focus on adding the facility to specify
+rewrite rules. We envisage the mechanism to evolve to cover inference rules as well as the many mathematical extensions
+proposed in [[Mathematical_extensions]]. For more details, we refer to the [[Rule-based_Prover_Plug-in]] page.
+and [[Image:Rule-based_Prover_Proposal.pdf | Proposal for a rule-based extensible prover]].
 == Exploratory Tasks ==
-=== One Single View ===
+=== Template Base Exporter ===
-[[Maria]] is in charge of this exploratory work during is internship.
+Some prototyping work is done in python, to explore how to use template engines to export rodin models to text, Latex, docbook, mediawiki,...
-{{details|Single View Design|Single View Design}}
+The [http://www.mercurial.org mercurial] repository is available [https://bitbucket.org/matclab/rodin_exporter/ here]. You can cloned it by installing mercurial on your computer and doing <code>hg clone https://bitbucket.org/matclab/rodin_exporter/</code>.
-The goal of this project is to present everything in a single view in Rodin. So the user won't have to switch perspectives.
+Be warn that, for now, it bypass the rodin database API and does parse the .bum and .buc files directly. It is also highly experimental, so do not rely to much on the produced output.
+(This work is done by [[User:Mathieu|Mathieu]] on his spare time...)
 == Others ==
 === AnimB ===
-[[Christophe]] devotes some of its spare time for this plug-in.
+[[User:Christophe|Christophe]] devotes some of his 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:
@@ Line 81: / Line 146: @@
 :The history of the animation will be collected.
+=== Team-Based Development ===
+; Usage Scenarios
+: In order to understand the problem properly, [http://www.stups.uni-duesseldorf.de/ Düsseldorf] created a number of usage [[Scenarios for Team-based Development]].
+: A page has also been opened for [[Scenarios for Merging Proofs|merging proofs scenarios]].
+;Team working based on EMF Compare
+:The EMF Compare project provides a comparison/merging style editor (similar to the Java merging editor used for synchronising changes with code repositories). This could be used to synchronise model changes into a repository such as SVN. The use of the EMF Compare editor relies on the  [[EMF framework for Event-B|EMF representation of Event-B]] that has already been developed and is available. A prototype plug-in is available which enables the use of the EMF compare editor for Rodin Machines and Contexts. It is intended that deploy partners will try out this plug-in in order to gather requirements for the Teamwork plug-in.
+:More details are here: [[Team-based development]]
+=== Wishlist ===
+A [[Plug-in Wishlist | wish list]] of tool plug-ins that cannot be resourced by [[Deploy]] is maintained.
 [[Category:Work in progress]]