ADVANCE D3.3 Model Composition and Decomposition

From Event-B
Jump to navigationJump to search


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 re-usability and combination of systems especially when it comes to distributed systems.
One of the most important feature of the Event-B approach is the possibility to introduce new events during refinement steps, but a consequence is an increasing complexity of the refinement process when having to deal with many events and many state variables.

Model decomposition is a powerful technique to scale the design of large and complex systems. It enables first developers to separate components development from the concerns of their integration and orchestration. Moreover, it tackles the complexity problem mentioned above, since decomposition allows the partitioning the complexity of the original model into separated components. This allows a decomposed part of the model to be treated as an independent artifact so that the modeller can concentrate on this part and does not have to worry about the other parts.
Composition and decomposition can be seen as inverse operations: while composition starts with different components that can be assembled together, decomposition starts with a single components that can be partitioned into different components.

Motivations / Decisions

While applying composition, properties must be maintained and proofs obligations need to be discharged in order for the final result to be considered valid. Since the composition maintains the monotonicity property of the systems, the sub-systems can be refined independently on a further stage, preserving composition properties.

In the latest version released (v1.6.1), some bugs are fixed to make it compatible with Rodin v2.8.

The main goal of Decomposition is to "cut" a model M into sub-models M_1, ..., M_n, which can 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. Note that this particular recomposition will never be performed in practice.

In an shared variable decomposition, the events of a model are partitioned to form the events of the sub-models. In parallel, the variables on which these events act are distributed among the sub-models.
In an shared event decomposition, the variables of a model are partitioned among the sub-models. Consequently, the events are partitioned accordingly to each sub-model.

In the latest version released (v1.2.6) compatible with Rodin v2.8, some bugs are fixed.

Composition and decomposition have already been identified as important features for the WP1 and WP2 case studies and they will continue to be evaluated by these WPs.

Available Documentation

Documentation for composition is available in:

  • A user guide and release history on the Event-B wiki[1].
  • A paper: Towards the Composition of Specifications in Event-B[2].

Documentation for decomposition is available in:

  • The decomposition user guide[3].
  • The decomposition description[4].
  • A paper on the decomposition Tool for Event-B[5].
  • A Survey on Event-B Decomposition[6].


Support for animation directly over a composed machine is planned. This will allow multiple machine to interact with each other. Improvements in usability of the tool will be made.

Although the actual decomposition operation is mature enough, the feeling is that the steps leading to that stage require some additional support. The preparation steps preceding the decomposition usually require some adjustments to the model in order to the decomposition to be beneficial in the following refinements of each generated sub-component. Therefore we aim to:

  • Receive more feedback from the users to improve tool usability.
  • Auto fixing of problems before executing decomposition: building a set of problem templates and respective solutions to be suggested to the modeller before executing decomposition.
  • Build a list of architectures templates to be used for decomposition according to the number of sub-components to be generated/kind of architecture to be followed/etc.