Difference between pages "Mode/FT Views" and "Parallel Composition using Event-B"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Ilya.lopatkin
m (New page: The Mode/FT Views plugin is a modelling environment for constructing modal and fault tolerance features in a concise manner and formally linking them to Event-B models. Here, mode is a uni...)
 
imported>Renato
 
Line 1: Line 1:
The Mode/FT Views plugin is a modelling environment for constructing modal and fault tolerance features in a concise manner and formally linking them to Event-B models. Here, mode is a unit of expected system functionality under distinguished working conditions of a system. The system is a set of modes connected by transitions. Mode transitions represent the changes in working conditions due to environment or system evolution. Fault tolerance part gives two types of transition specialisation: error and recovery. Each triggers additional structural checks and reserves a place to trace FT requirements.
+
{| align="right"
A Mode/FT view is a graph diagram containing modes and transitions which provide additional information necessary for establishing a formal connection with the model. The tool statically checks the views and generates a number of [[proof obligations]].
+
| __TOC__
 +
|}
  
 +
==News ==
 +
* ''28th May 2010'': [[#Version_1.1.7|Version 1.1.7]] released. It is based on Rodin 1.3.x.
 +
* ''25th February 2010'': [[#Version_1.1.6|Version 1.1.6]] released. It is based on Rodin 1.2.x.
 +
* ''2nd November 2009'': [[#Version_1.1.4|Version 1.1.4]] released. It is based on Rodin 1.1.0.
 +
* ''3rd July 2009'': [[#Version_1.1.3|Version 1.1.3]] released. It is based on Rodin 1.0.
 +
* ''1st July 2009'': [[#Version_1.1.2|Version 1.1.2]] released. It is based on Rodin 1.0.0 RC1.
  
==== Development process ====
+
==Shared Event Composition Plug-in ==
  
The Mode/FT views (simply ''views'' in the rest of the page) development process is a chain of views much like Event-B models. One starts with the most abstract view and adds details on further levels. We call this process the ''detalisation'' to distinguish it from the Event-B refinement. However, we use the verb ''refine'' to talk about mode/FT elements’ references to their abstract counterparts. There shouldn’t be any confusion: a mode only refines another mode, and Event-B model can only refine another Event-B model. The detalisation process is a mirror of the Event-B refinement process on a views side.
+
[[User:Renato]] at [[Southampton]] is in charge of the [[Parallel Composition using Event-B]].
Each view is built using a set of rules:
 
* simple rules applied within a single view – these are checked statically,
 
* detalisation rules - structural static checks plus proof obligations generated,
 
* Event-B linkage rules – static check against a SC-model
 
Disobedience to these rules leads to errors during the static check.
 
As an output, each view generates a number of proof obligations to be discharged by a user. These POs formally ensure that the mode/FT view is actually a view on the model under consideration. Informally, we can say that views restrict what can be modeled in Event-B in order to meet modal and FT specifications.
 
Note that during the development process, a model does not necessarily have to have an associated view nor it has to have only one such view. Any number of views can refer to the model – this is a design choice. On the figure, there is no view for “m12” model, and the view “m13.mode” refines its closest abstract view (can be m11.mode for instance).
 
  
Modes and transitions
+
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 reusability and combination of systems especially when it comes to distributed systems. While applying composition, properties must be maintained and proofs obligations need to be discharged in order for the final result to be considered valid. Our goal is to add this feature to the Rodin Platform (using Event-B notation) and study the concerns, properties, conditions, proof obligations, advantages and disadvantages when create/analysing system specifications. Since the composition maintains the monotonicity property of the systems, the sub-systems can be refined independently on a further stage, preserving composition properties.
Mode is a general characterisation of a system behaviour. To match this notion in terms of Event-B models, modes are mapped into groups of events. A Mode/FT view is a set of modes providing different functionality under differing operating conditions. We use the terms \emph{assumption} to denote the different operating conditions and \emph{guarantee} to denote the functionality ensured by the system under the corresponding assumption. With assumption and guarantee of a mode being predicates expressed on the same variables as an Event-B machine, we are able to impose restrictions on the way modes and transitions are mapped into model events and thus cross-check design decisions in either part.
 
  
Formally, a mode is characterised by a pair $A / G$ where:
+
[[Image:share_event_machine.jpeg]]
\begin{itemize}
 
\item $A(v)$ is an assumption - a predicate over the current system state;
 
\item $G(v, v')$ is a guarantee, a relation over the current and next states of the system; and
 
\item vector $v$ is the set of model variables.
 
\end{itemize}
 
  
A system switches from one mode into another through a mode transition that non-deterministically updates the state of $v$ in such a way that the assumption of the source mode becomes false while assumption of the target mode becomes true. Let us consider two modes, $i$ and $j$. A mode transition is required to establish a new state $v'$ such that $\neg A_i(v')$ and $A_j(v')$  while it is not under obligation to respect $G_i(v,v')$.
 
  
Similar to modes, transitions are mapped into groups of events, however mode and transition events have different meanings. Mode events represent internal mode transitions which must preserve the mode assumption. Transition events represent possible switches between modes. Only one event of a group can fire a transition while all of them have to exhibit transition properties: they have to preserve a target mode assumption and falsify a source mode assumption.
+
[[Image:share_event_mach_comp1.jpeg]]
 +
[[Image:share_event_machine_comp2.jpg]]
  
Detalisation conditions
+
A machine '''''S''''' with events '''''e1, e2, e3''''' and '''''e4''''' and variables '''''v1, v2''''' and '''''v3''''' can be decomposed using event (de)-composition of event ''e2'' (as can be seen above). This would result in the machine '''''S1''''' and '''''S2''''' that have a partial part of the event ''e2'': machine ''S1'' has the part related to the variable ''v1'' (''e2''') and machine ''S2'' has the part related to the machine ''v2'' (''e2''<nowiki>''</nowiki>). Also some other events are separated (''e1'' and ''v1'' only exist on machine ''S1'' and events ''e3'' and ''e4'' with variable ''v3'' only exist on the machine ''S2'') as can be seen above.
The detalisation conditions force user to structure and model mode/FT features in a refinement manner. One starts with an abstract representation of the system under development and adds determinism by obeying to the detalisation rules. These rules are:
 
• Mode detalisation
 
o Each abstract mode must be refined by at least one concrete mode.
 
o Assumptions of concrete modes may be weaker than the corresponding assumption of an abstract mode, while the guarantees should be stronger (see POs explanation below). By weakening the assumptions we are widening the operating conditions of a mode, and by strengthening the guarantees we are making the system behavior in this mode more deterministic.
 
• New transitions can be added between concrete modes which refine the same abstract mode. It is therefore guaranteed that such transitions didn’t exist on abstract level and are a proper detalisation of an abstract mode behavior (its internal transitions).
 
• New transitions can be added between concrete modes which refine different abstract modes given that there are corresponding transitions between abstract modes on the abstract level.
 
• No transitions can be added which do not project properly into the abstract transitions. If we project all the concrete modes into their abstract counterparts, then the transitions should either project into an internal transition within a mode (that is a mode itself) or into an existing transition. For example, let us imagine two modes and a transition between them: A->B. We refine A into A1, A2, and A3, and B into B1. Now, there can be any transitions between A1, A2, A3 because we don’t see such transitions on abstract level and they are a part of internal behavior of A. There can be any transitions from A1, A2, A3 to B1 but at least one must exist to refine the A->B transition. However, no transition from B1 can exist, otherwise it would project into B->A transition which does not exist on abstract level.
 
  
Rules for building views
+
The composition is based on proposals for parallel composition in Event-B in the following paper: [http://deploy-eprints.ecs.soton.ac.uk/51/].
  
All modes must have unique names with exception of the start and terminal modes which do not have names. The names are used in proof obligations.
+
==Installing/Updating ==
Every mode and transition must specify at least one event. All transitions from the start mode are implicitly mapped into INITIALISATION event.
 
Each mode with exception of the start and terminal modes must specify its assumption and guarantee. Both are predicates over the model variables, guarantee is a before-after predicate (after-values are denoted with a prime). Both are checked against a statically checked Event-B model.
 
Each mode must specify an abstract mode with its “refines” clause. An exception is when this view is the first, the most abstract one, in this case detalisation conditions are not checked and modes shouldn’t refine anything.
 
Each abstract mode from the abstract view must have at least one concrete mode in the concrete view.
 
Concrete modes and transitions must properly project into corresponding abstract modes and transitions.
 
  
 +
The installation or update for the shared event composition plug-in is available under the main Rodin Update site (http://rodin-b-sharp.sourceforge.net/updates). It is available for the category 'Shared Event Composition'. Like always, after the installation, restarting the application is recommended.
  
Proof obligations
+
 
 +
==Usage==
 +
 
 +
In order to use the composition plug-in, it is necessary to create a composition file (bcp extension).
 +
 
 +
# To create a new composition file, go to Toolbar (on top), New>>Other... Event-B>>Composition Machine. Then select the project (if not selected already) and filename (by default is cm.bcp).
 +
# Bcp files are visible on Event-B perspective(from Rodin 0.9). For Rodin 0.8.2, go to Resource or Java perspective to edit the file.
 +
# After editing the properties of the bcp file, you can generate a new bum file (machine), by using the green button on the toolbar (CM - symbol of machine) or by right clicling on the bcp file and choose the option :'Create Composed Machine'. You will have to introduce a name for the new machine and after that is just press 'OK'.
 +
 
 +
 
 +
The Shared Event Composition Plugin is divided in 6 sections:
 +
 
 +
* '''Refines''' : allows to define an abstract machine of this composed machine. It is a valid machine that exists on the project.
 +
* '''Includes''': to compose a model, it is necessary to define which sub-systems(machines) interact. The machines must be abstract (not refinements of other machines) and have to be valid. It is also possible to choose if the included machine invariant should be visible to the composed machine or not (for proof optimization).
 +
* '''Sees''': allows to add contexts to the composed machine. The contexts seen by the ''included machines'' are visible to the composed machine. So it is only allowed to see contexts that are not already seen by the composed machine.
 +
* '''Invariants''': allows the inclusion of invariant clauses to the composed file. The inclusion of more invariants (from the included machines) depends on the user’s choice on ''Includes''. The defined invariants on the composed machine are “joint” properties between the included machines (gluing invariants), so variables and contexts from all the included machines become part of the composed machine scope.
 +
*'''Composes Events''': the interaction between systems only happens when the composed events are synchronised and ready to be executed. The systems can interact through shared parameters. It is possible to define the following properties for composes events:
 +
** Name: name of the composes event
 +
** Extended/Not Extended: in the composes machine refines an abstract machine and if there are events with the same name, the concrete event can extend the abstract one (from Rodin 0.9).
 +
** Convergence: event can be chosen from ''Ordinary'', ''Convergence'' or ''Anticipated''.
 +
 
 +
 
 +
Still under '''Composes Events''', there are more properties that characterise a composed event:
 +
* '''Refines''' : possibility to choose if the composes event it is a refinement of an abstract event
 +
* '''Combines Event''': selection of the events that shall be composed. First the machine (out from the included machine list) is chosen and after, which event is supposed to be combined. It is possible to have only one combined event.
 +
** The parameters are listed in one single (composed) event. Parameters (from different events) with the same name will be merged (becoming only one parameter). This correspond to the shared event composition with message passing, where a parameter is passed from one event to other.
 +
** The guards from the different combined events are merged using conjuction. So this composed event will be available if all the guards are true.
 +
** the actions are also merged and executed in parallel.
 +
 
 +
 
 +
Like mention above,a machine can be generated containing all the properties defined on the composed machine file. The generation of the new machine can be executed by using the green button on the toolbar (CM - symbol of machine) or by right clicling on the bcp file and choosing the option :''Create Composed Machine''. A name for the new machine have to be introduced (a name is suggested by default ) and by clicking 'OK' or 'Override', a new machine file is generated.
 +
 
 +
== Bugs, Features and Comments ==
 +
 
 +
''Any reports of bugs, features or comments are welcome. You can add any of them here.''
 +
 
 +
====Bugs ====
 +
* -
 +
 
 +
====Features ====
 +
* Composition of machines that belong to different projects
 +
 
 +
====Comments ====
 +
* -
 +
 
 +
== Releases ==
 +
 
 +
=====Version 1.1.7 =====
 +
 
 +
''28th May 2010''
 +
 
 +
Version compatible with Rodin 1.3.x
 +
 
 +
*Features
 +
** Composition now allows the selection of the project of the machines to compose. The context must exist in the composed machine project.
 +
 
 +
=====Version 1.1.5 =====
 +
 
 +
''25th February 2010''
 +
 
 +
Version compatible with Rodin 1.2.x
 +
 
 +
=====Version 1.1.4 =====
 +
 
 +
''2nd November 2009''
 +
 
 +
Version compatible with Rodin 1.1.0
 +
 
 +
*Features
 +
** Section related with 'VARIANT' was removed.
 +
** Labels of the elements in the generated machine used '\' instead of '/' for the separation.
 +
 
 +
 
 +
=====Version 1.1.3 =====
 +
 
 +
''3rd July 2009''
 +
 
 +
Version compatible with Rodin 1.0.
 +
 
 +
*Bugs
 +
** Corrected problem when loading the image on the composition machine.
 +
 
 +
 
 +
*Improvements
 +
** Added package corresponding to the renaming of elements in the bcp files.
 +
 
 +
 
 +
=====Version 1.1.2 =====
 +
 
 +
''1st July 2009''
 +
 
 +
Version compatible with Rodin 1.0.0.
 +
 
 +
*Improvements
 +
** By adding a machine in the refines section, the events of the abstract machine are automatically added as a composed event.
 +
** Added the 'extended' button to the composed events.
 +
 
 +
 
 +
[[Category:Parallel composition plugin]]
 +
[[Category:User documentation]]

Revision as of 17:34, 28 May 2010

News

  • 28th May 2010: Version 1.1.7 released. It is based on Rodin 1.3.x.
  • 25th February 2010: Version 1.1.6 released. It is based on Rodin 1.2.x.
  • 2nd November 2009: Version 1.1.4 released. It is based on Rodin 1.1.0.
  • 3rd July 2009: Version 1.1.3 released. It is based on Rodin 1.0.
  • 1st July 2009: Version 1.1.2 released. It is based on Rodin 1.0.0 RC1.

Shared Event Composition Plug-in

User:Renato at Southampton is in charge of the Parallel Composition using Event-B.

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 reusability and combination of systems especially when it comes to distributed systems. While applying composition, properties must be maintained and proofs obligations need to be discharged in order for the final result to be considered valid. Our goal is to add this feature to the Rodin Platform (using Event-B notation) and study the concerns, properties, conditions, proof obligations, advantages and disadvantages when create/analysing system specifications. Since the composition maintains the monotonicity property of the systems, the sub-systems can be refined independently on a further stage, preserving composition properties.

Share event machine.jpeg


Share event mach comp1.jpeg Share event machine comp2.jpg

A machine S with events e1, e2, e3 and e4 and variables v1, v2 and v3 can be decomposed using event (de)-composition of event e2 (as can be seen above). This would result in the machine S1 and S2 that have a partial part of the event e2: machine S1 has the part related to the variable v1 (e2') and machine S2 has the part related to the machine v2 (e2''). Also some other events are separated (e1 and v1 only exist on machine S1 and events e3 and e4 with variable v3 only exist on the machine S2) as can be seen above.

The composition is based on proposals for parallel composition in Event-B in the following paper: [1].

Installing/Updating

The installation or update for the shared event composition plug-in is available under the main Rodin Update site (http://rodin-b-sharp.sourceforge.net/updates). It is available for the category 'Shared Event Composition'. Like always, after the installation, restarting the application is recommended.


Usage

In order to use the composition plug-in, it is necessary to create a composition file (bcp extension).

  1. To create a new composition file, go to Toolbar (on top), New>>Other... Event-B>>Composition Machine. Then select the project (if not selected already) and filename (by default is cm.bcp).
  2. Bcp files are visible on Event-B perspective(from Rodin 0.9). For Rodin 0.8.2, go to Resource or Java perspective to edit the file.
  3. After editing the properties of the bcp file, you can generate a new bum file (machine), by using the green button on the toolbar (CM - symbol of machine) or by right clicling on the bcp file and choose the option :'Create Composed Machine'. You will have to introduce a name for the new machine and after that is just press 'OK'.


The Shared Event Composition Plugin is divided in 6 sections:

  • Refines : allows to define an abstract machine of this composed machine. It is a valid machine that exists on the project.
  • Includes: to compose a model, it is necessary to define which sub-systems(machines) interact. The machines must be abstract (not refinements of other machines) and have to be valid. It is also possible to choose if the included machine invariant should be visible to the composed machine or not (for proof optimization).
  • Sees: allows to add contexts to the composed machine. The contexts seen by the included machines are visible to the composed machine. So it is only allowed to see contexts that are not already seen by the composed machine.
  • Invariants: allows the inclusion of invariant clauses to the composed file. The inclusion of more invariants (from the included machines) depends on the user’s choice on Includes. The defined invariants on the composed machine are “joint” properties between the included machines (gluing invariants), so variables and contexts from all the included machines become part of the composed machine scope.
  • Composes Events: the interaction between systems only happens when the composed events are synchronised and ready to be executed. The systems can interact through shared parameters. It is possible to define the following properties for composes events:
    • Name: name of the composes event
    • Extended/Not Extended: in the composes machine refines an abstract machine and if there are events with the same name, the concrete event can extend the abstract one (from Rodin 0.9).
    • Convergence: event can be chosen from Ordinary, Convergence or Anticipated.


Still under Composes Events, there are more properties that characterise a composed event:

  • Refines : possibility to choose if the composes event it is a refinement of an abstract event
  • Combines Event: selection of the events that shall be composed. First the machine (out from the included machine list) is chosen and after, which event is supposed to be combined. It is possible to have only one combined event.
    • The parameters are listed in one single (composed) event. Parameters (from different events) with the same name will be merged (becoming only one parameter). This correspond to the shared event composition with message passing, where a parameter is passed from one event to other.
    • The guards from the different combined events are merged using conjuction. So this composed event will be available if all the guards are true.
    • the actions are also merged and executed in parallel.


Like mention above,a machine can be generated containing all the properties defined on the composed machine file. The generation of the new machine can be executed by using the green button on the toolbar (CM - symbol of machine) or by right clicling on the bcp file and choosing the option :Create Composed Machine. A name for the new machine have to be introduced (a name is suggested by default ) and by clicking 'OK' or 'Override', a new machine file is generated.

Bugs, Features and Comments

Any reports of bugs, features or comments are welcome. You can add any of them here.

Bugs

  • -

Features

  • Composition of machines that belong to different projects

Comments

  • -

Releases

Version 1.1.7

28th May 2010

Version compatible with Rodin 1.3.x

  • Features
    • Composition now allows the selection of the project of the machines to compose. The context must exist in the composed machine project.
Version 1.1.5

25th February 2010

Version compatible with Rodin 1.2.x
Version 1.1.4

2nd November 2009

Version compatible with Rodin 1.1.0 
  • Features
    • Section related with 'VARIANT' was removed.
    • Labels of the elements in the generated machine used '\' instead of '/' for the separation.


Version 1.1.3

3rd July 2009

Version compatible with Rodin 1.0.

  • Bugs
    • Corrected problem when loading the image on the composition machine.


  • Improvements
    • Added package corresponding to the renaming of elements in the bcp files.


Version 1.1.2

1st July 2009

Version compatible with Rodin 1.0.0.

  • Improvements
    • By adding a machine in the refines section, the events of the abstract machine are automatically added as a composed event.
    • Added the 'extended' button to the composed events.