Difference between pages "D32 UML-B" and "D45 General Platform Maintenance"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Colin
 
imported>Jastram
(cleanup refs)
 
Line 1: Line 1:
 
= Overview =
 
= Overview =
Progress on UML-B consists of three parallel developments.
+
The Rodin platform versions concerned by this deliverable are:
# Enhancement and maintenance of the current and existing UML-B plug-in with new functionality and usability features.
+
* 2.1(08.02.2011),
# Development of a new plug-in to provide animation of UML-B state-machine diagrams.
+
* 2.2(01.06.2011),
# Development of a new plug-in (called iUML-B) that provides an alternative to UML-B which is more closely integrated with Event-B.
+
* 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 was put on correcting usability issues. Indeed, during the annual 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).
  
== Enhancement and Maintenance of Existing UML-B ==
+
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.
  
:The main progress on UML-B has been to implement new features, improve usability and fix bugs. As in the previous years of DEPLOY, these bugs and features are reported either by email or through dedicated SourceForge trackers. The list below gives an overwiew of the noteworthy features added in UML-B during the past year:
+
* General platform maintenance
 +
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 warnings 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.
  
:# Functional enhancements to modelling
+
* {{TODO}} An overview of the contribution about Mathematical extensions / Theory Plug-in (Issam Maamria)
:#* State-machine transitions emanating from multiple states. It is often the case that a transition may occur from several (possibly all) states within a state-machine. Such models were impossible to represent in UML-B. Two pseudo-states were added to represent this. Firstly an 'ANY' pseudo-state can be used as a transition source to represent that the transition can occur from ANY state of the state-machine. Secondly a disjunctive pseudo-state can be used to combine several transitions from different source states into a single transition.
 
:#* Conceptual Singleton classes - provides a conceptual grouping of associated modelling elements without generating the lifting mechanisms of a class.
 
:#* Super-type arrows to target ExtendedClassTypes and RefinedClasses - this functionality was missing in previous versions.
 
:#* Event convergence property on state-machine transitions - convergence was previously available only on events
 
:# Enhancements to improve usability
 
:#* Report to user if translation didn't proceed due to model validator - previously, it was not clear when the model had failed validation and the translation had not been executed.
 
:#* Improve refresh of diagrams - in some situations the diagram graphics did not update error marking and properties changes unless some other event caused a refresh.
 
:#* Improvements and additions to model validations - some model validations were inconsistent or incomplete.
 
:#* Preference for line routing style for each diagram type - allows the user to choose whether to use rectilinear or oblique line routing for each diagram type.
 
:# Corrections
 
:#* Correct and improve missing default labelling in diagrams.
 
:#* Corrections and improvements to automatic diagram deletion.
 
:#* Improved management of diagram files when model changes.
 
:#* Add missing comment fields in properties view.
 
  
== UML-B State-machine Animation Plug-in==
+
* {{TODO}} An overview of the contribution about Plug-in Incompatibilities (All partners)
:The UML-B State-machine Animation Plug-in is a new feature developed by University of Southampton as a response to a request from industrial partners to support the animation of UML-B state-machine diagrams. The essence of the request was to provide a means of visualising the animation and model-checking process of Event-B machines modelled in UML-B tool, in particular state-machines, thus to simplify this process. The tool integrates the capabilities of ProB animation and UML-B State-machine notation.
 
  
== iUML-B - Integrated UML-B ==
+
* {{TODO}} An overview of the contribution about Modularisation (Alexei Illiasov)
: The prototype iUML-B plug-in (not yet released) is an extension to the Event-B EMF framework. It will consist of a collection of independent plug-ins that provide support for diagrammatic modelling integrated with Event-B textual modelling. At this stage a plug-in to show the project structure (in terms of machines and contexts and their relationships) has been released. A plug-in to support state-machine diagrams integrated with textual Event-B is at a prototype stage and nearing release. Plug-ins to support other kinds of diagram are in the early stages of development.
+
 
 +
* {{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)
 +
 
 +
== An overview of the contribution about ProR (Michael Jastram) ==
 +
 
 +
ProR is a replacement of the original requirements plug-in, which got discontinued in 2010.  It is based on the OMG ReqIF standard (<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref>), which provides interoperability with industry tools. It evolved into the Eclipse Foundation project "Requirements Modeling Framework" (RMF, <ref name="rmf">http://eclipse.org/rmf</ref>), resulting in significant visibility.  ProR is independent from Rodin. Integration is achieved with a separate plug-in that provides support for traceability and model integration.
  
 
= Motivations =
 
= Motivations =
 +
The tasks to solve the issues faced by the DEPLOY partners have been listed and have been 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 resourced 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 was too ambitious to be fully achieved in the scope of DEPLOY.
  
== Enhancement and Maintenance of Existing UML-B ==
+
{{SimpleHeader}}
The aim is to continually improve the usability of UML-B in the light of experience. Although the motivation for a more integrated version of UML-B that would be attractive to experienced Event-B users has been recognised for some time, the original aim of UML-B was to make formal modelling more accessible to new users. This aim remains valid and therefore the current non-integrated UML-B should be developed and enhanced wherever possible. Therefore, some issues concerning its usability have been identified and rectified. Some of these required enhancements to the modelling language. In particular, several case studies have highlighted the need for transitions that may be taken from any sub-state or a range of sub-states.
+
|-
 +
! 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 improvements of utmost importance were made on the platform. These improvements either 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 Prover UI.
 +
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 Proving UI interface, a nice feature was added, allowing to search and highlight a string pattern into the whole Proving UI views and editors. This function as also been enabled on direct selection of text in this UI.
 +
* A better output providing warnings and errors in case of wrong or missing building configurations.
 +
This issue, often seen as a bug or as a plug-in incompatibility, was raised when a user imports and tries to use a model on a platform with some missing required plug-ins. The user often thought his models corrupted whereas Rodin was not able to build them, and hid this information to the user. This is why, since Rodin 2.3, an output has been provided in such case, taking the form of warnings or errors that any user can understand and review. This is a first answer to Rodin plug-in incompatibilities issues.
 +
* The switch to Eclipse 3.7.
 +
Due to the major improvements made every year in 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 help of an expert <ref name="documentationoverhaul>http://wiki.event-b.org/index.php/User_Documentation_Overhaul</ref>. Significant efforts to improve the documentation were performed and coordinated by Düsseldorf, and took form of a handbook<ref name="RodinHandbook">http://handbook.event-b.org/</ref>. 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, user oriented, were originated by some contents of the Event-B wiki.
  
== Animation Plug-in ==
+
== Mathematical extensions / Theory Plug-in ==
The motivation for the Animation Plug-in was to extend already beneficial graphical notation of UML-B with animation capabilities similar to those that ProB tool provides for Event-B models. With the aid of such a plug-in animation and model checking would be possible on UML-B diagrams instead of translated and less obvious Event-B code. The resulting plug-in uses ProB tool to run the standard animation on translated models and animates UML-B state-machines at the same time.
+
{{TODO}} ''To be completed by Issam Maamria''
 +
== Plug-in Incompatibilities ==
 +
By its extensibility nature, the Rodin platform is susceptible to incompatibilities. Indeed, there are many ways in which incompatibilities could occur, and it occurred in the lifetime of DEPLOY. A good example, is the dependency management. Suppose that a bundle x_v1.0 is needed by a plug-in A (i.e. a dependency from A has been defined to x in at most the version 1.0) and installed in Rodin. Then the plug-in x_v1.1 is needed by a plug-in B. The both versions 1.0 and 1.1 of x could not be installed and used at the same time and create thus some usage incompatibility.
 +
 
 +
== 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 ==
 +
 
 +
While the original requirements plug-in for Rodin was useful as a prototype, a number of shortcomings lead to a new development.  In particular, the original plug-in was a traceability tool with externally managed requirements.  With ProR, requirements are authored and edited within Eclipse.  The original plug-in supported only a limited number of attributes and flat (unstructured) requirements.  ProR supports all data structures that the ReqIF standard<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> supports. Further, ReqIF-support for industry tools like Rational DOORS, MKS or IRqA is expected in the near future, while the original plug-in required a custom adaptor for each data format.
 +
 
 +
ProR is developed independently from Rodin.  Dependencies to Rodin exist only in the Rodin integration plug-in.  This significantly decreases the maintenance effort for the integration plugin, while increasing the visibility of ProR in the Open Source community.  The move of ProR from the University of Düsseldorf to the Eclipse Foundation increases visibility even further.  The Rodin integration plug-in is maintained as an independent project at github.
  
 
= Choices / Decisions =
 
= Choices / Decisions =
== Integrated UML-B ==
+
== Platform maintenance ==
: It was planned to develop a new version (iUML-B) of UML-B which is more integrated with Event-B. A precursor stage to this was to develop an EMF representation of Event-B. This was completed last year and is now used successfully by several plug-ins. A Records plug-in was developed in response to user requests. The Records plug-in was implemented as an extension to the Event-B EMF framework. This was seen as a 'practice run' before attempting a similar extension to support UML-B. However, the Records plug-in took longer than expected and this has delayed work on iUML-B. Some progress on iUML-B has recently been made with the release of a project level diagram tool for Event-B and some progress on representing State-Machine diagram models as an extension to the Event-B EMF models.
+
* Revisited task priority
 +
This year, the process of giving priority to maintenance tasks was revisited according the the refocus mentioned above. The aim was to address all the major scalability issues before the end of DEPLOY. Thus, the requests coming from DEPLOY partners were given high priorities, and they were also prioritized against the already planned tasks coming from both DEPLOY partners and the Description of Work.
 +
* Keep 32-bit versions of the Rodin platform on linux and windows systems
 +
It was asked by end users to make both 32-bit and 64-bit versions of the Rodin platform available for Linux and Windows platforms. Only a 64-bit version of Rodin is available on Mac platforms as 32-bit Mac (early 2006) platforms are no longer maintained. The request to offer 64-bit was motivated by the possibility to increase for them the available Java heap size for some memory greedy platforms (these before 2.3). However, the drawbacks of assembling and maintaining more platforms (5 platforms instead of 3) and the corrections brought to the database which improved the memory consumption pushed away the limitations of the platform, made this request not relevant for now.
  
== State-machine Animation Plug-in ==
+
== Mathematical extensions / Theory Plug-in ==
: The initial design decision was to extend the UML-B metamodel with the animation components. Due to difficulties with UML-B diagram extensibility an alternative option was determined to create a separate model, derived from UML-B state-machine subset, with incorporated animation support. This design was successfully implemented together with ProB and Rodin UI extensions into Animation plug-in, which supports such UML-B concepts as classes and different state-machine translation kinds, as well as Event-B refinement.
+
{{TODO}} ''To be completed by Issam Maamria''
 +
== Plug-in Incompatibilities ==
 +
It has been decided in cooperation with all the WP9 partners to find better ways to address the plug-in incompatibility issues. First of all, the various partners refined the concept of "plug-in incompatibility". Hence, various aspects could be identified and some specific answers were given to each of them. The user could then defined more clearly the incompatibility faced. Plug-in incompatibilities can be separated in two categories:
 +
:* Rodin platform/plug-in incompatibilities, due to some wrong match between Rodin included packages and the plug-in dependencies (i.e. needed packages). These incompatibilities, when reported, allowed the plug-in developers to contact SYSTEREL in charge of managing the packages shipped with a given version of Rodin. It could also allow traceability of incompatibilities and information to the user through a specific and actualized table on each Rodin release notes page on the Wiki<ref name="incompTableA">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Current_plug-ins</ref>.
 +
:* Plug-in/plug-in incompatibilities, due to some wrong match between needed/installed packages, or API/resources incompatible usage. A table was created on each release notes wiki page, and a procedure was defined<ref name="incompTableB">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Known_plug-in_incompatibilities</ref> so that identified incompatibilities are listed and corrected by the concerned developers.
 +
It appeared that cases of using a model which references some missing plug-ins were formerly often seen as compatibility issues although they were not.<br>
 +
After the incompatibilities have been identified, the developing counterparts being concerned assigned special tasks and coordination to solve issues the soonest as possible. Incompatibilities are often due to little glitches or desynchronisation and such direct coordination of counterpart appeared appropriate because quick and effective.
 +
 
 +
== 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 ==
 +
 
 +
The following key decisions were made when developing ProR:
 +
 
 +
* '''New development, rather than continuing the original plug-in''' - the architecture of ProR differs significantly from that of the original plug-in (see [[D45_General_Platform_Maintenance#ProR]].  In addition, new technologies like EMF promised a cleaner, more powerful framework for an implementation.
 +
 
 +
* '''ReqIF as the underlying data model''' - the ReqIF standard <ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> is gaining traction and promises interoperability with industry tools. In addition, a digital version of the data model was available for free and could serve as the foundation for the model code.
 +
 
 +
* '''The Eclipse Modeling Framework''' (EMF) was identified as a technology that would allow a quick and clean foundation for an implementation.  Further, the Rodin EMF-plug-in represents a convenient interface for integrating ProR and ProB.  Last, the digital data model from the OMG could be imported directly into EMF and used for generating the model code.
 +
 
 +
* '''Keeping ProR independent from Rodin''' - There is significant interest in ReqIF right now, but this interest is unrelated to formal methods.  By providing an implementation that is independent from Rodin, we have a much larger target group of potential users and developers.  By carefully designing extension points, we can still provide a powerful Rodin integration.
 +
 
 +
* '''Eclipse Foundation Project''' - we were actively establishing an open source community around ProR.  By recruiting engaged partners early on, development progressed faster than anticipated.  By becoming an Eclipse Foundation project <ref name="rmf">http://eclipse.org/rmf</ref>, we exceeded our goals in this respect.
  
 
= Available Documentation =
 
= Available Documentation =
The following pages give useful information about UML-B:
+
* Core platform:
* Lectures<ref name="UML-B">http://wiki.event-b.org/index.php/UML-B</ref>.
+
:The following pages give useful information about the Rodin platform releases:
* Tutorials<ref name="UML-B">http://wiki.event-b.org/index.php/UML-B</ref>.
+
:* Release notes<ref>http://wiki.event-b.org/index.php/Rodin_Platform_Releases</ref>.
* Worked Examples<ref name="UML-B">http://wiki.event-b.org/index.php/UML-B</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>.
 +
*The Rodin handbook is proposed as a PDF version and a HTML version and a dedicated plug-in makes it available as help within Rodin<ref name="RodinHandbook">http://handbook.event-b.org/</ref>.
 +
 
 +
*{{TODO}}  Links for Mathematical extensions / Theory Plug-in
 +
*{{TODO}}  Links for Modularisation
 +
*{{TODO}}  Links for Decomposition
 +
*{{TODO}}  Links for Team-based Development
 +
*{{TODO}}  Links for UML-B
 +
* Links for ProR
 +
** ProR at the Eclipse Foundation <ref name="rmf">http://eclipse.org/rmf</ref>
 +
** ProR Documentation for end users and plugin developers <ref>http://pror.org</ref>
 +
 
 +
= Status =
 +
== Platform maintenance ==
 +
By the end of the project, there are :
 +
* xx bugs reported and open. All with a priority lower or equal to 5.
 +
* xx feature requests expressed and still open.
  
UML-B State-machine Animation Plug-in:
+
== Mathematical extensions / Theory Plug-in ==
* General information<ref>http://wiki.event-b.org/index.php/UML-B_-_Statemachine_Animation</ref>
+
{{TODO}} ''To be completed by Issam Maamria''
* Tutorial<ref>http://wiki.event-b.org/index.php/Statemachine_Animation_Tutorial</ref>
+
== Plug-in Incompatibilities ==
 +
As the time of writing this deliverable, no plug-in incompatibilities are left or known to exist between the platform and plug-ins or between plug-ins.
  
= Planning =
+
== Modularisation ==
During the coming year, special efforts will be made on the following topics,  
+
{{TODO}} ''To be completed by Alexei Illiasov''
* Development of the Project Diagram Plugin for Event-B to make it extensible and/or to automatically cater for future component types.
+
== Decomposition ==
: The current version of the Project Diagram Plugin only supports Machines and Contexts and their relationships. Already, several plug-ins are contributing new kinds of components such as theories, tasking machines and compositions. The Project Diagram plug-in will be enhanced to provide an extension mechanism that allow other plug-ins to extend the project diagram to show new kinds of components and their relationship.
+
{{TODO}} ''To be completed by Renato Silva'' 
* Development of a State-machine diagram plug-in as an integrated part of Event-B modelling
+
== Team-based Development ==
: The State-machine diagram plug-in will provide a diagrammatic modelling environment based on state-machines alongside the usual Event-B modelling format. The two views will contribute to the same model simultaneously.
+
{{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''
  
In parallel with these new plug-ins, the current version of UML-B will continue to be enhanced. This may include some new modelling features such as better support for synchronisation of state-machines and support for more UML modelling details. However, usability of the current features is seen as the main objective. This will include,
 
* Support for copy, cut and paste of diagram elements so that they can be moved and/or replicated more easily,
 
* Support for re-attaching links (e.g. transitions) to different source/target elements,
 
* Facilities for refactoring/renaming elements,
 
* Support for the event extension mechanism of Event-B,
 
* Integration of Context Diagram model elements on Class diagrams,
 
* Improve facilities for navigating between state-machines and visualising multiple state-machines.
 
  
== References ==
+
= References =
 
<references/>
 
<references/>
  
[[Category:D32 Deliverable]]
+
[[Category:D45 Deliverable]]

Revision as of 15:39, 13 February 2012

Overview

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 was put on correcting usability issues. Indeed, during the annual 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[1] and the SourceForge[1] databases (bugs and feature requests) for details about the previous and upcoming releases of the Rodin platform.

  • General platform maintenance

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

An overview of the contribution about ProR (Michael Jastram)

ProR is a replacement of the original requirements plug-in, which got discontinued in 2010. It is based on the OMG ReqIF standard ([2]), which provides interoperability with industry tools. It evolved into the Eclipse Foundation project "Requirements Modeling Framework" (RMF, [3]), resulting in significant visibility. ProR is independent from Rodin. Integration is achieved with a separate plug-in that provides support for traceability and model integration.

Motivations

The tasks to solve the issues faced by the DEPLOY partners have been listed and have been 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 resourced 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 was too ambitious to be fully achieved in the scope of DEPLOY.


Group 1 (highest priority) Responsible
Performance
- Core (large models, etc.)
- GUI (incl. prover UI, edition, etc.)
SYSTEREL
Prover Performances
- New rewriting rules / inference rules
- 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
Group 2 Responsible
Prover Performances
- SMT provers integration
- connection with Isabelle
- Mathematical extensions
- ProB

SYSTEREL
ETH Zürich
Southampton/SYSTEREL
Düsseldorf
Scalability
- Decomposition
- Modularisation plug-in
- Team-based development

Southampton
Newcastle
Southampton
Plug-in incompatibilities Newcastle
Model-based testing Pitesti/Düsseldorf
ProR Düsseldorf
Group 3 Responsible
Scalability
- Generic instantiation
- UML-B maintenance

Southampton
ETH Zürich/Southampton
Code Generation Southampton
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, mainly concerned stability and performance improvement. These topics will be discussed and detailed in a separate chapter about scalability improvements.
However, other improvements of utmost importance were made on the platform. These improvements either 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 Prover UI.

This feature came from a request of DEPLOY partners[4], 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 Proving UI interface, a nice feature was added, allowing to search and highlight a string pattern into the whole Proving UI views and editors. This function as also been enabled on direct selection of text in this UI.

  • A better output providing warnings and errors in case of wrong or missing building configurations.

This issue, often seen as a bug or as a plug-in incompatibility, was raised when a user imports and tries to use a model on a platform with some missing required plug-ins. The user often thought his models corrupted whereas Rodin was not able to build them, and hid this information to the user. This is why, since Rodin 2.3, an output has been provided in such case, taking the form of warnings or errors that any user can understand and review. This is a first answer to Rodin plug-in incompatibilities issues.

  • The switch to Eclipse 3.7.

Due to the major improvements made every year in 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 help of an expert [5]. Significant efforts to improve the documentation were performed and coordinated by Düsseldorf, and took form of a handbook[6]. 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, user oriented, were originated by some contents of the Event-B wiki.

Mathematical extensions / Theory Plug-in

TODO To be completed by Issam Maamria

Plug-in Incompatibilities

By its extensibility nature, the Rodin platform is susceptible to incompatibilities. Indeed, there are many ways in which incompatibilities could occur, and it occurred in the lifetime of DEPLOY. A good example, is the dependency management. Suppose that a bundle x_v1.0 is needed by a plug-in A (i.e. a dependency from A has been defined to x in at most the version 1.0) and installed in Rodin. Then the plug-in x_v1.1 is needed by a plug-in B. The both versions 1.0 and 1.1 of x could not be installed and used at the same time and create thus some usage incompatibility.

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

While the original requirements plug-in for Rodin was useful as a prototype, a number of shortcomings lead to a new development. In particular, the original plug-in was a traceability tool with externally managed requirements. With ProR, requirements are authored and edited within Eclipse. The original plug-in supported only a limited number of attributes and flat (unstructured) requirements. ProR supports all data structures that the ReqIF standard[2] supports. Further, ReqIF-support for industry tools like Rational DOORS, MKS or IRqA is expected in the near future, while the original plug-in required a custom adaptor for each data format.

ProR is developed independently from Rodin. Dependencies to Rodin exist only in the Rodin integration plug-in. This significantly decreases the maintenance effort for the integration plugin, while increasing the visibility of ProR in the Open Source community. The move of ProR from the University of Düsseldorf to the Eclipse Foundation increases visibility even further. The Rodin integration plug-in is maintained as an independent project at github.

Choices / Decisions

Platform maintenance

  • Revisited task priority

This year, the process of giving priority to maintenance tasks was revisited according the the refocus mentioned above. The aim was to address all the major scalability issues before the end of DEPLOY. Thus, the requests coming from DEPLOY partners were given high priorities, and they were also prioritized against the already planned tasks coming from both DEPLOY partners and the Description of Work.

  • Keep 32-bit versions of the Rodin platform on linux and windows systems

It was asked by end users to make both 32-bit and 64-bit versions of the Rodin platform available for Linux and Windows platforms. Only a 64-bit version of Rodin is available on Mac platforms as 32-bit Mac (early 2006) platforms are no longer maintained. The request to offer 64-bit was motivated by the possibility to increase for them the available Java heap size for some memory greedy platforms (these before 2.3). However, the drawbacks of assembling and maintaining more platforms (5 platforms instead of 3) and the corrections brought to the database which improved the memory consumption pushed away the limitations of the platform, made this request not relevant for now.

Mathematical extensions / Theory Plug-in

TODO To be completed by Issam Maamria

Plug-in Incompatibilities

It has been decided in cooperation with all the WP9 partners to find better ways to address the plug-in incompatibility issues. First of all, the various partners refined the concept of "plug-in incompatibility". Hence, various aspects could be identified and some specific answers were given to each of them. The user could then defined more clearly the incompatibility faced. Plug-in incompatibilities can be separated in two categories:

  • Rodin platform/plug-in incompatibilities, due to some wrong match between Rodin included packages and the plug-in dependencies (i.e. needed packages). These incompatibilities, when reported, allowed the plug-in developers to contact SYSTEREL in charge of managing the packages shipped with a given version of Rodin. It could also allow traceability of incompatibilities and information to the user through a specific and actualized table on each Rodin release notes page on the Wiki[7].
  • Plug-in/plug-in incompatibilities, due to some wrong match between needed/installed packages, or API/resources incompatible usage. A table was created on each release notes wiki page, and a procedure was defined[8] so that identified incompatibilities are listed and corrected by the concerned developers.

It appeared that cases of using a model which references some missing plug-ins were formerly often seen as compatibility issues although they were not.
After the incompatibilities have been identified, the developing counterparts being concerned assigned special tasks and coordination to solve issues the soonest as possible. Incompatibilities are often due to little glitches or desynchronisation and such direct coordination of counterpart appeared appropriate because quick and effective.

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

The following key decisions were made when developing ProR:

  • New development, rather than continuing the original plug-in - the architecture of ProR differs significantly from that of the original plug-in (see D45_General_Platform_Maintenance#ProR. In addition, new technologies like EMF promised a cleaner, more powerful framework for an implementation.
  • ReqIF as the underlying data model - the ReqIF standard [2] is gaining traction and promises interoperability with industry tools. In addition, a digital version of the data model was available for free and could serve as the foundation for the model code.
  • The Eclipse Modeling Framework (EMF) was identified as a technology that would allow a quick and clean foundation for an implementation. Further, the Rodin EMF-plug-in represents a convenient interface for integrating ProR and ProB. Last, the digital data model from the OMG could be imported directly into EMF and used for generating the model code.
  • Keeping ProR independent from Rodin - There is significant interest in ReqIF right now, but this interest is unrelated to formal methods. By providing an implementation that is independent from Rodin, we have a much larger target group of potential users and developers. By carefully designing extension points, we can still provide a powerful Rodin integration.
  • Eclipse Foundation Project - we were actively establishing an open source community around ProR. By recruiting engaged partners early on, development progressed faster than anticipated. By becoming an Eclipse Foundation project [3], we exceeded our goals in this respect.

Available Documentation

  • Core platform:
The following pages give useful information about the Rodin platform releases:
  • The Rodin handbook is proposed as a PDF version and a HTML version and a dedicated plug-in makes it available as help within Rodin[6].
  • TODO Links for Mathematical extensions / Theory Plug-in
  • TODO Links for Modularisation
  • TODO Links for Decomposition
  • TODO Links for Team-based Development
  • TODO Links for UML-B
  • Links for ProR
    • ProR at the Eclipse Foundation [3]
    • ProR Documentation for end users and plugin developers [12]

Status

Platform maintenance

By the end of the project, there are :

  • 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

As the time of writing this deliverable, no plug-in incompatibilities are left or known to exist between the platform and plug-ins or between plug-ins.

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