Difference between pages "D45 General Platform Maintenance" and "Parallel Composition using Event-B"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Tommy
 
imported>Mathieu
 
Line 1: Line 1:
= Overview =
+
[[User:Renato]] at [[Southampton]] is in charge of the [[Parallel Composition using Event-B]].
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<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.
+
Composition is the process by which it is possible to combine different sub-systems into a larger system. Known and studied in several areas, this has the advantage of reusability and combination of systems especially when it comes to distributed systems. While applying composition, properties must be maintained and proofs obligations need to be discharged in order for the final result to be considered valid. Our goal is to add this feature to the Rodin Platform (using Event-B notation) and study the concerns, properties, conditions, proof obligations, advantages and disadvantages when create/analysing system specifications. Since the composition maintains the monotonicity property of the systems, the sub-systems can be refined independently on a further stage, preserving composition properties.
  
* General platform maintenance (Thomas Muller)
+
[[Image:share_event_machine.jpeg]]
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)
+
[[Image:share_event_mach_comp1.jpeg]]
 +
[[Image:share_event_machine_comp2.jpg]]
  
* {{TODO}} An overview of the contribution about Plug-in Incompatibilities (All partners)  
+
A machine '''''S''''' with events '''''e1, e2, e3''''' and '''''e4''''' and variables '''''v1, v2''''' and '''''v3''''' can be decomposed using event (de)-composition of event ''e2'' (as can be seen above). This would result in the machine '''''S1''''' and '''''S2''''' that have a partial part of the event ''e2'': machine ''S1'' has the part related to the variable ''v1'' (''e2''') and machine ''S2'' has the part related to the machine ''v2'' (''e2''<nowiki>''</nowiki>). Also some other events are separated (''e1'' and ''v1'' only exist on machine ''S1'' and events ''e3'' and ''e4'' with variable ''v3'' only exist on the machine ''S2'') as can be seen above.
  
* {{TODO}} An overview of the contribution about Modularisation (Alexei Illiasov)
+
The composition is based on proposals for parallel composition in Event-B in the following paper: [http://deploy-eprints.ecs.soton.ac.uk/51/].
  
* {{TODO}} An overview of the contribution about Decomposition (Renato Silva)
+
A release of the composition plugin for Rodin 0.8.2 is available (email me:ras07r@ecs.soton.ac.uk).
  
* {{TODO}} An overview of the contribution about Team-based Development (Colin Snook, Vitaly Savicks)
+
A release for Rodin 0.9.2.1 is now available from the Rodin Main Update Site.
  
* {{TODO}} An overview of the contribution about UML-B (Colin Snook, Vitaly Savicks)  
+
1. To create a new composition file (bcp file), go to Toolbar (on top), New>>Other... Event-B>>Composition Machine. Then select the project (if not selected already) and filename (by default is cm.bcp).
  
* {{TODO}} An overview of the contribution about ProR (Michael Jastram)
+
2. Bcp files are visible on Event-B perspective(from Rodin 0.9). For Rodin 0.8.2, go to Resource or Java perspective to edit the file.
  
= Motivations =
+
3. After editing the properties of the bcp file, you can generate a new bum file (machine), by using the green button on the toolbar (CM - symbol of machine) or by right clicling on the bcp file and choose the option :'Create Composed Machine'. You will have to introduce a name for the new machine and after that is just press 'OK'.
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.
 
  
{{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. Losts of efforts to improve the documentation were performed and coordinated by Düsseldorf, and took form of the Rodin Handbook. 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 were originated by the contents of the Event-B wiki, although these contents have now all been migrated to the Rodin handbook.
 
  
== Mathematical extensions / Theory Plug-in ==
+
'''
{{TODO}} ''To be completed by Issam Maamria''
+
==User Manual==
== 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 =
+
The Shared Event Composition Plugin is divided in 6 sections:
== Platform maintenance ==
 
* Revisited task priority
 
This year, the process to give priority to maintenance tasks was revisited according the the refocus mentionned above. 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
 
  
* keeop 32-bit versions of Rodin on linux and windows systems
+
* '''Refines''' : allows to define an abstract machine of this composed machine. It is a valid machine that exists on the project.
 +
* '''Includes''': to compose a model, it is necessary to define which sub-systems(machines) interact. The machines must be abstract (not refinements of other machines) and have to be valid. It is also possible to choose if the included machine invariant should be visible to the composed machine or not (for proof optimization).
 +
* '''Sees''': allows to add contexts to the composed machine. The contexts seen by the ''included machines'' are visible to the composed machine. So it is only allowed to see contexts that are not already seen by the composed machine.
 +
* '''Invariants''': allows the inclusion of invariant clauses to the composed file. The inclusion of more invariants (from the included machines) depends on the user’s choice on ''Includes''. The defined invariants on the composed machine are “joint” properties between the included machines (gluing invariants), so variables and contexts from all the included machines become part of the composed machine scope.
 +
*'''Variant''': since the composed machine can be a refinement of an abstract model, there is the possibility of introducing new events. In order to avoid divergence, variants are necessary for the new events.
 +
*'''Composes Events''': the interaction between systems only happens when the composed events are synchronised and ready to be executed. The systems can interact through shared parameters. It is possible to define the following properties for composes events:
 +
** Name: name of the composes event
 +
** Extended/Not Extended: in the composes machine refines an abstract machine and if there are events with the same name, the concrete event can extend the abstract one (from Rodin 0.9).
 +
** Convergence: event can be chosen from ''Ordinary'', ''Convergence'' or ''Anticipated''.
  
== 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 =
+
Still under '''Composes Events''', there are more properties that characterise a composed event:
* Core platform:
+
* '''Refines''' : possibility to choose if the composes event it is a refinement of an abstract event
:The following pages give useful information about the Rodin platform releases:
+
* '''Combines Event''': selection of the events that shall be composed. First the machine (out from the included machine list) is chosen and after, which event is supposed to be combined. It is possible to have only one combined event.
:* 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>.
 
  
*{{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 =
+
The '''Combination of Events''' can be expressed as:
== Platform maintenance ==
+
* The parameters are listed in one single (composed) event. Parameters (from different events) with the same name will be merged (becoming only one parameter). This correspond to the shared event composition with message passing, where a parameter is passed from one event to other.
By the end of the project, there are :
+
* The guards from the different combined events are merged using conjuction. So this composed event will be available if all the guards are true.
* xx bugs reported and open. All with a priority lower or equal to 5.
+
* the actions are also merged and executed in parallel.
* xx feature requests expressed and still open.
 
  
== Mathematical extensions / Theory Plug-in ==
+
Like mention above,a machine can be generated containing all the properties defined on the composed machine file. The generation of the new machine can be executed by using the green button on the toolbar (CM - symbol of machine) or by right clicling on the bcp file and choosing the option :''Create Composed Machine''. A name for the new machine have to be introduced (a name is suggested by default ) and by clicking 'OK' or 'Override', a new machine file is generated.
{{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 =
 
<references/>
 
  
[[Category:D45 Deliverable]]
+
 
 +
[[Category:Parallel composition plugin]]
 +
[[Category:User documentation]]

Revision as of 08:59, 4 March 2009

User:Renato at Southampton is in charge of the Parallel Composition using Event-B.

Composition is the process by which it is possible to combine different sub-systems into a larger system. Known and studied in several areas, this has the advantage of reusability and combination of systems especially when it comes to distributed systems. While applying composition, properties must be maintained and proofs obligations need to be discharged in order for the final result to be considered valid. Our goal is to add this feature to the Rodin Platform (using Event-B notation) and study the concerns, properties, conditions, proof obligations, advantages and disadvantages when create/analysing system specifications. Since the composition maintains the monotonicity property of the systems, the sub-systems can be refined independently on a further stage, preserving composition properties.

Share event machine.jpeg

Share event mach comp1.jpeg Share event machine comp2.jpg

A machine S with events e1, e2, e3 and e4 and variables v1, v2 and v3 can be decomposed using event (de)-composition of event e2 (as can be seen above). This would result in the machine S1 and S2 that have a partial part of the event e2: machine S1 has the part related to the variable v1 (e2') and machine S2 has the part related to the machine v2 (e2''). Also some other events are separated (e1 and v1 only exist on machine S1 and events e3 and e4 with variable v3 only exist on the machine S2) as can be seen above.

The composition is based on proposals for parallel composition in Event-B in the following paper: [1].

A release of the composition plugin for Rodin 0.8.2 is available (email me:ras07r@ecs.soton.ac.uk).

A release for Rodin 0.9.2.1 is now available from the Rodin Main Update Site.

1. To create a new composition file (bcp file), go to Toolbar (on top), New>>Other... Event-B>>Composition Machine. Then select the project (if not selected already) and filename (by default is cm.bcp).

2. Bcp files are visible on Event-B perspective(from Rodin 0.9). For Rodin 0.8.2, go to Resource or Java perspective to edit the file.

3. After editing the properties of the bcp file, you can generate a new bum file (machine), by using the green button on the toolbar (CM - symbol of machine) or by right clicling on the bcp file and choose the option :'Create Composed Machine'. You will have to introduce a name for the new machine and after that is just press 'OK'.


User Manual

The Shared Event Composition Plugin is divided in 6 sections:

  • Refines : allows to define an abstract machine of this composed machine. It is a valid machine that exists on the project.
  • Includes: to compose a model, it is necessary to define which sub-systems(machines) interact. The machines must be abstract (not refinements of other machines) and have to be valid. It is also possible to choose if the included machine invariant should be visible to the composed machine or not (for proof optimization).
  • Sees: allows to add contexts to the composed machine. The contexts seen by the included machines are visible to the composed machine. So it is only allowed to see contexts that are not already seen by the composed machine.
  • Invariants: allows the inclusion of invariant clauses to the composed file. The inclusion of more invariants (from the included machines) depends on the user’s choice on Includes. The defined invariants on the composed machine are “joint” properties between the included machines (gluing invariants), so variables and contexts from all the included machines become part of the composed machine scope.
  • Variant: since the composed machine can be a refinement of an abstract model, there is the possibility of introducing new events. In order to avoid divergence, variants are necessary for the new events.
  • Composes Events: the interaction between systems only happens when the composed events are synchronised and ready to be executed. The systems can interact through shared parameters. It is possible to define the following properties for composes events:
    • Name: name of the composes event
    • Extended/Not Extended: in the composes machine refines an abstract machine and if there are events with the same name, the concrete event can extend the abstract one (from Rodin 0.9).
    • Convergence: event can be chosen from Ordinary, Convergence or Anticipated.


Still under Composes Events, there are more properties that characterise a composed event:

  • Refines : possibility to choose if the composes event it is a refinement of an abstract event
  • Combines Event: selection of the events that shall be composed. First the machine (out from the included machine list) is chosen and after, which event is supposed to be combined. It is possible to have only one combined event.


The Combination of Events can be expressed as:

  • The parameters are listed in one single (composed) event. Parameters (from different events) with the same name will be merged (becoming only one parameter). This correspond to the shared event composition with message passing, where a parameter is passed from one event to other.
  • The guards from the different combined events are merged using conjuction. So this composed event will be available if all the guards are true.
  • the actions are also merged and executed in parallel.

Like mention above,a machine can be generated containing all the properties defined on the composed machine file. The generation of the new machine can be executed by using the green button on the toolbar (CM - symbol of machine) or by right clicling on the bcp file and choosing the option :Create Composed Machine. A name for the new machine have to be introduced (a name is suggested by default ) and by clicking 'OK' or 'Override', a new machine file is generated.