Difference between pages "D45 General Platform Maintenance" and "D45 Scalability"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Tommy
m
 
imported>Tommy
 
Line 1: Line 1:
 
= Overview =
 
= Overview =
The Rodin platform versions concerned by this deliverable are:
+
* '''Improved Performance''' According to the refocus mentionned in the [[D45_General_Platform_Maintenance#Motivations| General Platform Maintenance]] chapter, much of the reworking efforts performed on the core plateform basically aimed to overcome Rodin scalability weaknesses, and the continuous need of seamless proving experience. The whole performance was enhanced by core implementation and user interface refactorings. Improvements made to the proving experience will be detailed in a separate chapter.
* 2.1(08.02.2011),
+
* {{TODO}} An overview of the contribution about the design pattern management / Generic Instantiation (Thai Son Hoang)  
* 2.2(01.06.2011),
+
* '''Edition''' It appeard along DEPLOY, the models defined by pilots becoming industrial sized due to the level of complexity reached, that the edition became a central concern.
* 2.2.2(01.08.2011),
+
:*The legacy structured editor based on a form edition specific achitecture reach its limits in responsivness and hence in usability when being constrained to display a huge amount of graphical elements.
* 2.3(04.10.2011),
+
:*During this last year of DEPLOY, Camille textual editor had to tackle challenges related to ressources mapping and management for projects of industrial size mentionned above or even the design of extension capabilities, that became a major concern since the grammar could be extended with theories.
* 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 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.
 
 
 
* Core platform maintenance (Thomas Muller)
 
According to the previously mentionned refocus, the maintenance tasks performed on the core plateform basically aimed to overcome Rodin scalability weaknesses, and the continuous need of seamless proving experience. The performance was enhanced by core implementation and user interface refactorings. The proving usability was enhanced by the possibility to customize, combine, and parameterize tactics and the addition of new inference and rewriting rules. This will however be details in the chapter relating the prover improvements.
 
 
 
* {{TODO}} An overview of the contribution about Mathematical extensions / Theory Plug-in (Issam Maamria)
 
 
 
* {{TODO}} An overview of the contribution about Plug-in Incompatibilities (All partners)
 
 
 
* {{TODO}} An overview of the contribution about Modularisation (Alexei Illiasov)
 
 
 
* {{TODO}} An overview of the contribution about Decomposition (Renato Silva)
 
 
 
* {{TODO}} An overview of the contribution about Team-based Development (Colin Snook, Vitaly Savicks)
 
 
 
* {{TODO}} An overview of the contribution about UML-B (Colin Snook, Vitaly Savicks)
 
 
 
* {{TODO}} An overview of the contribution about ProR (Michael Jastram)
 
  
 
= Motivations =
 
= Motivations =
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}}
+
== Improved Performance ==
|-
+
It appeared that the various DEPLOY partners encountered several major issues while editing large models. Some were related to the core code of the Rodin platform, causing crashes, loss of data, corruption in models. Some other were related to the UI causing platform hanging, and sometimes leading to its freezing which required sometimes to kill the Rodin process, thus also leading to potential loss of data and corruption in models. Hence, it appeared necessary to solve such issues before the end of DEPLOY.
! 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 Zurich <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 Zurich/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]], concerned stability and performance improvement. The prover performance improvement, and the addition of a textual structured editor will be discussed and detailed in separate chapters.<br>
 
The various DEPLOY partners encountered several major issues while editing large models. Some were related to the core code of the Rodin platform, causing crashes, loss of data, corruption in models. Some other were related to the UI causing platform hanging, and sometimes leading to its freezing which required sometimes to kill the Rodin process, thus also leading to potential loss of data and corruption in models. Hence, it appeared necessary to solve such issues before the end of DEPLOY.
 
  
== Mathematical extensions / Theory Plug-in ==
+
== Design Pattern Management / Generic Instantiation ==
{{TODO}} ''To be completed by Issam Maamria''
+
{{TODO}} ''To be completed by Thai Son Hoang''
== Plug-in Incompatibilities ==
+
== Edition ==
{{TODO}} ''To be completed by all partners''
+
{{TODO}} ''To be completed by Thomas Muller, Ingo Weigelt''
== 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 =
 
= Choices / Decisions =
== Platform maintenance ==
+
== Improved Performance ==
SYSTEREL lead a two phase investigation to have a better idea of the work to be done to improve the performance. Each phase being followed by some refactoring of the code. Out of the early investigation, a cause and effect relationship has been found between perfomance loss and the various reported bugs, such as "platform hanging" bugs or even "no more handle" bugs related to the high consumption of graphical elements on Windows platforms. Indeed, it appeared that solving the performance issues sometimes solved induced bugs as well.<br>
+
SYSTEREL lead a two phase investigation to have a better idea of the work to be done. Each phase being followed by some refactoring of the code. Out of the early investigation, a cause and effect relationship has been found between perfomance loss and the various reported bugs, such as "platform hanging" bugs or even "no more handle" bugs related to the high consumption of graphical elements on Windows platforms. Indeed, it appeared that solving the performance issues sometimes solved induced bugs as well which made the scalability improvement tasks emcompass the maintenance goals.<br>
 
Later, a deeper investigation was performed, to indentify and tackle the remaining performance issues. Profiling and code review were the two techniques used. The profiling strategy allowed to get a better localisation of the performance loss in both UI and core code while the code review helped to understand the intrinsic misuses or drawbacks of particular components and/or architectures.
 
Later, a deeper investigation was performed, to indentify and tackle the remaining performance issues. Profiling and code review were the two techniques used. The profiling strategy allowed to get a better localisation of the performance loss in both UI and core code while the code review helped to understand the intrinsic misuses or drawbacks of particular components and/or architectures.
== Mathematical extensions / Theory Plug-in ==
+
A good example, was the Event-B built-in editor based on form editors with a high use of greedy graphical components. Such architecture appeard to be weak when it was needed to display industrial size models. This affected the modelling experience with some long, and really annoying to the user, reaction lags. To solve such issue, it has been chosen to refactor the editors using a textual representation which was a light-weight graphical alternative to lower the number of needed components.
{{TODO}} ''To be completed by Issam Maamria''
+
 
== Plug-in Incompatibilities ==
+
== Design Pattern Management / Generic Instantiation ==
{{TODO}} ''To be completed by all partners''
+
{{TODO}} ''To be completed by Thai Son Hoang''
== Modularisation ==
+
== Edition ==
{{TODO}} ''To be completed by Alexei Illiasov''
+
{{TODO}} ''To be completed by Thomas Muller, Ingo Weigelt''
== 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 =
 
= Available Documentation =
* Core platform:
+
* {{TODO}} Links for Improved Performance
:The following pages give useful information about the Rodin platform releases:
+
* {{TODO}} Links for Design Pattern Management / Generic Instantiation
:* Release notes<ref>http://wiki.event-b.org/index.php/Rodin_Platform_Releases</ref>.
+
* {{TODO}} Links for Edition
:* 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 =
 
= Status =
== Platform maintenance ==
+
== Improved Performance ==
By the end of the project, there are :
+
The refactoring made on both core code and UI code allowed to gain up to 25 times speed-up on the UI, and almost a 2 times speed-up in the core code, making the platform usable in an industrial sized context.<br>
* xx bugs reported and open. All with a priority lower or equal to 5.
 
* xx feature requests expressed and still open.
 
 
 
== 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''
 
 
 
  
= References =
+
== Design Pattern Management / Generic Instantiation  ==
<references/>
+
{{TODO}} ''To be completed by Thai Son Hoang''
 +
== Edition ==
 +
{{TODO}} ''To be completed by Thomas Muller, Ingo Weigelt''
  
 
[[Category:D45 Deliverable]]
 
[[Category:D45 Deliverable]]

Revision as of 09:57, 21 November 2011

Overview

  • Improved Performance According to the refocus mentionned in the General Platform Maintenance chapter, much of the reworking efforts performed on the core plateform basically aimed to overcome Rodin scalability weaknesses, and the continuous need of seamless proving experience. The whole performance was enhanced by core implementation and user interface refactorings. Improvements made to the proving experience will be detailed in a separate chapter.
  • TODO An overview of the contribution about the design pattern management / Generic Instantiation (Thai Son Hoang)
  • Edition It appeard along DEPLOY, the models defined by pilots becoming industrial sized due to the level of complexity reached, that the edition became a central concern.
  • The legacy structured editor based on a form edition specific achitecture reach its limits in responsivness and hence in usability when being constrained to display a huge amount of graphical elements.
  • During this last year of DEPLOY, Camille textual editor had to tackle challenges related to ressources mapping and management for projects of industrial size mentionned above or even the design of extension capabilities, that became a major concern since the grammar could be extended with theories.

Motivations

Improved Performance

It appeared that the various DEPLOY partners encountered several major issues while editing large models. Some were related to the core code of the Rodin platform, causing crashes, loss of data, corruption in models. Some other were related to the UI causing platform hanging, and sometimes leading to its freezing which required sometimes to kill the Rodin process, thus also leading to potential loss of data and corruption in models. Hence, it appeared necessary to solve such issues before the end of DEPLOY.

Design Pattern Management / Generic Instantiation

TODO To be completed by Thai Son Hoang

Edition

TODO To be completed by Thomas Muller, Ingo Weigelt

Choices / Decisions

Improved Performance

SYSTEREL lead a two phase investigation to have a better idea of the work to be done. Each phase being followed by some refactoring of the code. Out of the early investigation, a cause and effect relationship has been found between perfomance loss and the various reported bugs, such as "platform hanging" bugs or even "no more handle" bugs related to the high consumption of graphical elements on Windows platforms. Indeed, it appeared that solving the performance issues sometimes solved induced bugs as well which made the scalability improvement tasks emcompass the maintenance goals.
Later, a deeper investigation was performed, to indentify and tackle the remaining performance issues. Profiling and code review were the two techniques used. The profiling strategy allowed to get a better localisation of the performance loss in both UI and core code while the code review helped to understand the intrinsic misuses or drawbacks of particular components and/or architectures. A good example, was the Event-B built-in editor based on form editors with a high use of greedy graphical components. Such architecture appeard to be weak when it was needed to display industrial size models. This affected the modelling experience with some long, and really annoying to the user, reaction lags. To solve such issue, it has been chosen to refactor the editors using a textual representation which was a light-weight graphical alternative to lower the number of needed components.

Design Pattern Management / Generic Instantiation

TODO To be completed by Thai Son Hoang

Edition

TODO To be completed by Thomas Muller, Ingo Weigelt

Available Documentation

  • TODO Links for Improved Performance
  • TODO Links for Design Pattern Management / Generic Instantiation
  • TODO Links for Edition

Status

Improved Performance

The refactoring made on both core code and UI code allowed to gain up to 25 times speed-up on the UI, and almost a 2 times speed-up in the core code, making the platform usable in an industrial sized context.

Design Pattern Management / Generic Instantiation

TODO To be completed by Thai Son Hoang

Edition

TODO To be completed by Thomas Muller, Ingo Weigelt