Difference between pages "UML-B Integration and Improvements" and "User:Nicolas/Collections/ADVANCE Deliverable D3.4"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Colin
 
imported>Nicolas
(D3.4 main entry point, initial revision)
 
Line 1: Line 1:
=== UML-B Integration with Event-B===
+
== Introduction ==
 +
The purpose of this page is to give a common structure and guidelines to collaboratively build the ADVANCE Deliverable D3.4 (Methods and tools for model construction and proof III) which will be delivered to the European Commission at month 38 (2014-10-31).
 +
The DOW reads:
 +
<blockquote>
 +
This deliverable provides a summary of the improvements made to the Rodin Platform throughout the project. It validates the delivery of improvements to both tools and methods for model construction and proof against the original plan. In addition, it reports on the development of formal design patterns that have arisen from the case studies of WP1 and WP2 and nature and availability of the supporting documentation and tutorials. It also reports on the composition / decomposition cookbook.
 +
</blockquote>
  
[[UML-B]] provides a 'UML-like' graphical front end for Event-B. It adds support for class-oriented and state machine modelling but also provides visualisation of existing Event-B modelling concepts. UML-B is similar to UML but is a new notation with its own meta-model. UML-B provides tool support, including drawing tools and a translator to generate Event-B models. The tools are closely integrated with the Event-B tools so that when a drawing is saved the translator automatically generates the corresponding Event-B model. The Event-B verification tools (syntax checker and prover) then run automatically providing an immediate display of problems which are indicated on the relevant UML-B diagram element.  However, many features of UML-B are a replication of corresponding Event-B features. For example, the project diagram in UML-B, uses the concepts of machines and contexts and their relationships (refines, sees and extends). The project diagram would be just as applicable to an Event-B project that did not use any UML like modelling concepts. Similarly, while modelling in UML-B class diagrams, model elements are introduced to a machine that are directly equivalent to their Event-B counterparts. Greater integration would allow UML-B diagrams to be interspersed with Event-B model elements in a flexible mixed modelling interface. This has not been possible due to the differing underlying technologies used for Event-B (bespoke data repository) and UML-B (EMF).
+
== Schedule ==
 +
*the template of the deliverable is released on 2014-10-06
 +
*the contents are contributed by 2014-10-22
 +
*the draft for internal review is sent on 2014-10-24
 +
*the final deliverable is produced for 2014-10-31
  
The integration between UML-B and Event-B will be improved by introducing an [[EMF_framework_for_Event-B|EMF framework for Event-B]]. This will allow UML-B to be re-implemented as an extension to Event-B. Work has begun on this framework and resulting integrated tools will become available during 2009.
+
== Template ==
 +
For each item covered in this document, a wiki page has been created (see [[#Contents | Contents]]) to give a brief description of the work that was carried on during third period of the project (Oct 2013-Nov 2014). The contents of each page should not go deeply into technical details, but should rather look like an executive summary. All details (papers, detailed wiki pages, etc.) should be made available as pointers.
 +
'''Moreover, each contribution shall be quite short (ca. two printed pages).'''
  
===Improvements to the existing version of UML-B===
 
While this new UML-B is being developed, improvements to the existing version of UML-B are ongoing. A new release of UML-B (0.5.0)) contains significant improvements, most notably the addition of support for refinement of statemachines. New features include:
 
  
* Support for refinement of state machines in UML-B. This release 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. This addition is described in more detail in [[Image:SaidButlerSnook09.pdf|Said, Butler and Snook]]
+
=== Overview ===
 +
This first paragraph shall identify the involved partners and give an overview of the contribution. In particular, it shall provide answers to the following questions:
 +
* What are the common denominations?
 +
* Is it a new feature or an improvement?
 +
* What is the main purpose?
 +
* Who was in charge?
 +
* Who was involved?
  
* 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.
+
=== Motivations / Decisions ===
 +
This paragraph shall express the motivation for each tool extension and improvement. More precisely, it shall first indicate the state before the work, the encountered difficulties, and shall highlight the requirements (eg. those of industrial partners). Then, it shall summarize how these requirements were addressed and what are the main benefits.
 +
This paragraph shall also summarize the decisions (eg. design decisions) and justify them. Thus, it may present the studied solutions, through their main advantages and inconvenients, to legitimate the final choices.
  
* 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 was formerly 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.
+
=== Available Documentation ===
 +
This paragraph shall give pointers to the available wiki pages or related publications. This documentation may contain:
 +
* Requirements.
 +
* Pre-studies (states of the art, proposals, discussions).
 +
* Technical details (specifications).
 +
* Teaching materials (tutorials).
 +
* User's guides.  
 +
A distinction shall be made on the one hand between these different categories, and on the other hand between documentation written for developers and documentation written for end-users.
  
* The properties view has been improved with the addition of a tab for 'model'. This tab allows direct access to the underlying EMF model element so that its properties can be viewed and changed.
+
=== Planning ===
 +
This paragraph shall give an outlook on the current status and the plans for future work.
 +
See also the [[Tool Development Roadmap]].
  
* Some improvements have been made to the UML-B perspective layout to reflect changes to the Event-B one. The task and problem views have been removed and the 'Rodin Problem' view has been added instead.
+
== Formatting rules ==
 +
In order to homogeneize the contributions and to ensure consistent spelling the following formatting rules shall be enforced:
 +
* See §4 of [http://wiki.event-b.org/images/Llncsdoc.pdf How to Edit Your Input File] for LLNCS formatting rules.
 +
* ADVANCE and Rodin shall be typed this way.
 +
* Contractions shall not be used (eg. write "does not" instead of "doesn't", "let us" instead of "let's", etc).
 +
* British english spelling shall be retained.
 +
* "plug-in" shall be preferred to "plugin".
 +
* Remember that the document is dated 2013-09-30, use past, present and future accordingly.
 +
* The dedicated category, <nowiki>[[Category:ADVANCE D3.4 Deliverable]]</nowiki>, shall be specified for wiki pages.
 +
* If you intend to use the same reference multiple times, please use the Cite extension [http://www.mediawiki.org/wiki/Extension:Cite/Cite.php].
 +
: By doing so, you will have to add the additional paragraph at the end of your page :
 +
==References==
 +
<nowiki><references/></nowiki>
 +
: Note that you can add references using the normal wikimedia links as well as using references nevertheless only the latter ones will appear in the references section on the wiki (e.g. all references will appear in the final PDF document whatever their type).
 +
 
 +
== Contents ==
 +
=== D3.4 ===
 +
 
 +
:[[ADVANCE D3.4 Introduction|Introduction]] (Laurent Voisin/Nicolas Beauger)
 +
 
 +
:[[ADVANCE D3.4 General Platform Maintenance|General Platform Maintenance]]
 +
:* Core Rodin platform (Laurent Voisin/Nicolas Beauger)
 +
:* UML-B Improvements (Colin Snook, Vitaly Savicks)
 +
:* ProR (Michael Jastram/Lukas Ladenberger)
 +
:* Camille (Ingo Weigelt)
 +
 
 +
:[[ADVANCE D3.4 Improvement of automated proof|Improvement of automated proof]]
 +
:* Integrated provers (Laurent Voisin/Nicolas Beauger)
 +
:* SMT Provers (Laurent Voisin)
 +
 
 +
:[[ADVANCE D3.4 Model Checking|Model Checking]] (Michael Leuschel & al.)
 +
 
 +
:[[ADVANCE D3.4 Language extension|Language extension]] (Asieh Salehi)
 +
 
 +
:[[ADVANCE D3.4 Model Composition and Decomposition|Model Composition and Decomposition]] (Asieh Salehi)

Revision as of 13:30, 6 October 2014

Introduction

The purpose of this page is to give a common structure and guidelines to collaboratively build the ADVANCE Deliverable D3.4 (Methods and tools for model construction and proof III) which will be delivered to the European Commission at month 38 (2014-10-31). The DOW reads:

This deliverable provides a summary of the improvements made to the Rodin Platform throughout the project. It validates the delivery of improvements to both tools and methods for model construction and proof against the original plan. In addition, it reports on the development of formal design patterns that have arisen from the case studies of WP1 and WP2 and nature and availability of the supporting documentation and tutorials. It also reports on the composition / decomposition cookbook.

Schedule

  • the template of the deliverable is released on 2014-10-06
  • the contents are contributed by 2014-10-22
  • the draft for internal review is sent on 2014-10-24
  • the final deliverable is produced for 2014-10-31

Template

For each item covered in this document, a wiki page has been created (see Contents) to give a brief description of the work that was carried on during third period of the project (Oct 2013-Nov 2014). The contents of each page should not go deeply into technical details, but should rather look like an executive summary. All details (papers, detailed wiki pages, etc.) should be made available as pointers. Moreover, each contribution shall be quite short (ca. two printed pages).


Overview

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

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

Motivations / Decisions

This paragraph shall express the motivation for each tool extension and improvement. More precisely, it shall first indicate the state before the work, the encountered difficulties, and shall highlight the requirements (eg. those of industrial partners). Then, it shall summarize how these requirements were addressed and what are the main benefits. This paragraph shall also summarize the decisions (eg. design decisions) and justify them. Thus, it may present the studied solutions, through their main advantages and inconvenients, to legitimate the final choices.

Available Documentation

This paragraph shall give pointers to the available wiki pages or related publications. This documentation may contain:

  • Requirements.
  • Pre-studies (states of the art, proposals, discussions).
  • Technical details (specifications).
  • Teaching materials (tutorials).
  • User's guides.

A distinction shall be made on the one hand between these different categories, and on the other hand between documentation written for developers and documentation written for end-users.

Planning

This paragraph shall give an outlook on the current status and the plans for future work. See also the Tool Development Roadmap.

Formatting rules

In order to homogeneize the contributions and to ensure consistent spelling the following formatting rules shall be enforced:

  • See §4 of How to Edit Your Input File for LLNCS formatting rules.
  • ADVANCE and Rodin shall be typed this way.
  • Contractions shall not be used (eg. write "does not" instead of "doesn't", "let us" instead of "let's", etc).
  • British english spelling shall be retained.
  • "plug-in" shall be preferred to "plugin".
  • Remember that the document is dated 2013-09-30, use past, present and future accordingly.
  • The dedicated category, [[Category:ADVANCE D3.4 Deliverable]], shall be specified for wiki pages.
  • If you intend to use the same reference multiple times, please use the Cite extension [1].
By doing so, you will have to add the additional paragraph at the end of your page :
==References==
<references/>
Note that you can add references using the normal wikimedia links as well as using references nevertheless only the latter ones will appear in the references section on the wiki (e.g. all references will appear in the final PDF document whatever their type).

Contents

D3.4

Introduction (Laurent Voisin/Nicolas Beauger)
General Platform Maintenance
  • Core Rodin platform (Laurent Voisin/Nicolas Beauger)
  • UML-B Improvements (Colin Snook, Vitaly Savicks)
  • ProR (Michael Jastram/Lukas Ladenberger)
  • Camille (Ingo Weigelt)
Improvement of automated proof
  • Integrated provers (Laurent Voisin/Nicolas Beauger)
  • SMT Provers (Laurent Voisin)
Model Checking (Michael Leuschel & al.)
Language extension (Asieh Salehi)
Model Composition and Decomposition (Asieh Salehi)