Modularisation Plug-in Composition Semantics: Difference between revisions
From Event-B
Jump to navigationJump to search
imported>Alexili New page: {{TODO|This is an internal draft document}} ==Approach 1: Reducing to A-style== ==Approach 2: Atomicity Refinement== |
imported>Alexili No edit summary |
||
| Line 1: | Line 1: | ||
{{TODO|This is an internal draft document}} | {{TODO|This is an internal draft document}} | ||
==The meaning of module composition== | |||
This page explains what it means to import a module and rely on the interface operations implemented by the module. In particular, how one can, at least in principle, construct a single flat Event-B machine from a specification where a final refinement step and its abstraction rely on modules. This serves two purposes: it gives exact characterisation of the behaviour of a modular specification; it serves as a reference for implementation-stage composition strategies. | |||
==Approach 1: Reducing to A-style== | ==Approach 1: Reducing to A-style== | ||
==Approach 2: Atomicity Refinement== | ==Approach 2: Atomicity Refinement== | ||
Revision as of 12:34, 22 October 2009
TODO: This is an internal draft document
The meaning of module composition
This page explains what it means to import a module and rely on the interface operations implemented by the module. In particular, how one can, at least in principle, construct a single flat Event-B machine from a specification where a final refinement step and its abstraction rely on modules. This serves two purposes: it gives exact characterisation of the behaviour of a modular specification; it serves as a reference for implementation-stage composition strategies.
