Difference between revisions of "D23 Decomposition"

From Event-B
Jump to navigationJump to search
imported>Pascal
imported>Pascal
Line 21: Line 21:
 
The main decision concerning the implementation of the Event-B model decomposition in the Rodin platform was to make available both decomposition styles (''shared variables'' vs. ''shared events'') through a single plug-in. These approachs are indeed complementary and the end-user may take advantage of the former or of the latter, depending on the model (eg. the ''shared variables'' approach seems more suitable when modelling parallel system, and the ''shared events'' approach seems more suitable when modelling message-passing distributed systems).
 
The main decision concerning the implementation of the Event-B model decomposition in the Rodin platform was to make available both decomposition styles (''shared variables'' vs. ''shared events'') through a single plug-in. These approachs are indeed complementary and the end-user may take advantage of the former or of the latter, depending on the model (eg. the ''shared variables'' approach seems more suitable when modelling parallel system, and the ''shared events'' approach seems more suitable when modelling message-passing distributed systems).
  
* technical aspects
+
Choices, either related to the plug-in core or to the plug-in graphical user interface, have been made with the following constraints in mind:
* modularity / homogeneity
+
* Planning. Some options, such as using the Graphical Modelling Framework for the decomposition visualization, or outsourcing the context decomposition, have not been explored (at least in the first instance), mainly because of time constraints (according to the DEPLOY description of work, the decomposition support was expected by the end of 2009).
* easiest for a first version
+
* Easy-to-use (but not simplistic however) tool. It applies on the one hand to the tool implementation (decomposition wizard, configuration file to replay the decomposition), and on the other hand to the tool documentation (the purpose of the user's guide is to provide useful information for beginners and for more advanced users, in particular through a ''Tips and Tricks'' section).
 +
* Modularity and consistency. In particular, the developments have not been performed in the Event-B core but the Eclipse extension mechanisms have been used instead to keep the the plug-in independent (eg. the static checker, the proof obligation generator and the editor have been extended).
 +
* Performances.
 +
* Recursivity. Thus, it is possible to decompose a previously decomposed model.
  
See the specification for technical decisions (eg. events partition is the first step for A-style decomposition).
+
Other technical decisions (eg. why is the event partition the first step for the ''shared variables'' decomposition?) are justified in the specification wiki pages.
 
 
{{TODO}}
 
This paragraph shall 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.
 
 
 
 
 
The configuration (i.e. the identification of the machine taken as input for the
 
decomposition, the identification of the sub-machines to be generated and
 
the first step of the decomposition) shall be performed through the Graphical
 
User Interface (GUI) of the Rodin platform. It is indeed more suitable for
 
the end-user to visualize the configuration. In the future the option of using
 
GMF (Graphical Modelling Framework) for the decomposition visualization
 
will be explored.
 
 
 
As far as possible, the developments shall not be performed in the Event-
 
B core: dedicated extension points shall be used instead to keep as much
 
independent as possible from the core.
 
 
 
The created projects and components (machines and contexts) shall be
 
tagged as “automatically generated”.
 
 
 
The non-decomposed model is assumed to be proved.
 
 
 
The decomposition does not generate new POs.
 
 
 
See the specification for technical decisions (eg. events partition is the first step for A-style decomposition).
 
  
 
= Available Documentation =
 
= Available Documentation =

Revision as of 13:30, 10 November 2009

Motivations

One of the most important feature of the Event-B approach is the possibility to introduce new events and data-refinement of variables during refinement steps.

It however results in an increasing complexity of the refinement process when having to deal with many events, many state variables, and consequently many proof obligations. This is well illustrated in the Event build-up slide of the Wright presentation during the Rodin Workshop 2009.

See http://wiki.event-b.org/index.php/Image:Steve_Wright_Quite_Big_Model_Presentation.pdf.

The purpose of the Event-B model decomposition is precisely to give a way to address such a difficulty, by cutting a large model M into smaller sub-models M_1, ..., M_n. The sub-models can then be refined separately and more comfortably than the whole. The constraint that shall be satisfied by the decomposition is that these refined models might be recomposed into a whole model MR in a way that guarantees that MR refines M.

Two methods have been identified for model decomposition: the shared variable decomposition (or A-style decomposition), and the shared event decomposition (or B-style decomposition). They both answer to this requirement.

The model decomposition leads to some interesting benefits:

  • Design/architectural decision. It applies in particular when it is noticed that it is not necessary to consider the whole model for a given refinement step, because only a few events and variables are involved instead.
  • Complexity management. In other words, it alleviates the complexity by splitting the proof obligations over the sub-models.
  • Team development. More precisely, it gives a way for several developers to share the parts of a decomposed model, and to work independently and possibly in parallel on them.

Note that the possibility of team development is among the current development priorities for all industrial partners. The model decomposition is a first answer to this large problematic.

Choices / Decisions

The main decision concerning the implementation of the Event-B model decomposition in the Rodin platform was to make available both decomposition styles (shared variables vs. shared events) through a single plug-in. These approachs are indeed complementary and the end-user may take advantage of the former or of the latter, depending on the model (eg. the shared variables approach seems more suitable when modelling parallel system, and the shared events approach seems more suitable when modelling message-passing distributed systems).

Choices, either related to the plug-in core or to the plug-in graphical user interface, have been made with the following constraints in mind:

  • Planning. Some options, such as using the Graphical Modelling Framework for the decomposition visualization, or outsourcing the context decomposition, have not been explored (at least in the first instance), mainly because of time constraints (according to the DEPLOY description of work, the decomposition support was expected by the end of 2009).
  • Easy-to-use (but not simplistic however) tool. It applies on the one hand to the tool implementation (decomposition wizard, configuration file to replay the decomposition), and on the other hand to the tool documentation (the purpose of the user's guide is to provide useful information for beginners and for more advanced users, in particular through a Tips and Tricks section).
  • Modularity and consistency. In particular, the developments have not been performed in the Event-B core but the Eclipse extension mechanisms have been used instead to keep the the plug-in independent (eg. the static checker, the proof obligation generator and the editor have been extended).
  • Performances.
  • Recursivity. Thus, it is possible to decompose a previously decomposed model.

Other technical decisions (eg. why is the event partition the first step for the shared variables decomposition?) are justified in the specification wiki pages.

Available Documentation

The following wiki pages have been respectively written for developers and end-users to document the Event-B model decomposition:

  • Shared variables (A-style) decomposition specification.
See http://wiki.event-b.org/index.php/Event_Model_Decomposition.
  • Decomposition plug-in user's guide.
See http://wiki.event-b.org/index.php/Decomposition_Plug-in_User's_Guide.

Planning

The decomposition plug-in is available since release 1.2 of the platform.

See http://wiki.event-b.org/index.php/Rodin_Platform_1.2_Release_Notes.