Difference between pages "Generic Instantiation Plug-in User Guide" and "Proof Hints"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Asiehsalehi
 
imported>Son
 
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
The Generic Instantiation (GI) Feature plug-in allows to instantiate and reuse generic developments in other formal developments..
 
  
See the [http://wiki.event-b.org/index.php/Generic_Instantiation Generic Instantiation] page for technical details.
+
This document does NOT provide a way to avoid doing interactive proofs or pointing out the weakness of existing provers. Rather this document shows how to use information from doing interactive proofs to improve the clarity of models. As a consequence of these improvement, the obligations can be discharged automatically. We call these added information to the model "proof hints".
  
== Installing and Updating ==
+
This concept of "proof hints" already exists in the form of "witness" or "theorem" in Event-B. These useful features are designed not only to help with proving the correctness of the model but also to give more information about the particular model.
=== Setup ===
 
The following steps will guide you through the setup process:
 
# Download Rodin for your platform.
 
# Extract the downloaded zip file.
 
# Start Rodin from the folder where you extracted the zip file in the previous step.
 
# Install the Generic Instantiation Feature plug-in:
 
## In the menu choose ''Help'' -> ''Install New Software...''
 
## In the ''Work with'' dropdown list, choose the location URL: Rodin
 
## Select the ''Generic Instantiation Feature'' feature under the ''Utilities'' category, then click the check box
 
## Click ''Next'', after some time, the ''Install Details'' page appears
 
## Click ''Next'' and accept the license
 
## Click ''Finish''
 
## A ''Security Warning'' window may appear: click ''OK''
 
# Restart Rodin as suggested.
 
  
[[Image:GI_Install.jpg|center]]
+
The question is how we can decide which "features" are useful to have in the model. In principle we can go to the extreme and include the whole proof strategy into the model in order to be able to have it being discharged automatically. But this is undesirable since it will make the model difficult to understand. Having taken this into account we specify our criteria here for "proof hints".
  
Now you are ready to use the Generic Instantiation Feature plug-in.
+
1. It should help to understand the model better.
  
 +
2. It should improve the automatic proving rate of the model.
  
=== Update ===
+
In fact, we regard the first criterion as more important whereas the second criterion can be considered as a bonus for improving the clarity of the model. Below are our proposal for two kinds of proof hints: [[Hypothesis Selection | hypothesis selection]] and proof by cases.
The following steps will guide you through the update process:
 
# In Rodin open the preferences (''Window'' -> ''Preferences'' or for Mac: ''Rodin'' -> ''Preferences'')
 
# Find ''Install/Update'' -> ''Automatic Updates''
 
# Select ''Automatically find new updates and notify me''
 
  
As soon as Rodin finds a new update it will ask you if you would like to install it.
+
== Proof Hints ==
  
=== Release Notes ===
+
The presentation for each kind of proof hints is as follows:
See the [http://wiki.event-b.org/index.php/Generic_Instantiation_Release_History Generic Instantiation Feature Release History].
 
  
== Instantiating ==
+
1. '''Description''': A brief description of the proof hints with the situation where this can be helpful.
  
The example followed here to demonstrate the GI plug-in is from [[Image:Supporting_Reuse_of_Event-B_Developments_through_Generic_Instantiation.pdf | Supporting Reuseof Event-B Developments through Generic Instantiation]]
+
2. '''Example''': an example in Event-B is presented.
=== Running the Instantiate Action ===
 
The <tt>Instantiate</tt> action launches the instantiation wizard, which will perform the generic instantiation according to the preferences. It is available:
 
{|
 
|-
 
|1. Either from the toolbar of the Event-B explorer.
 
|2. Or from the contextual menu, when right-clicking on a machine.
 
|-
 
| valign="top" | [[Image:Ins_Explorer.jpg|center]]
 
| valign="top" | [[Image:Ins_Contextual.jpg|center]]
 
|}
 
  
=== Selecting the Pattern Machine and Problem Machine ===
+
3. '''Work around''': we show a solution (rather a work-around) for the current RODIN Platform.
* Pattern machine is the machine to be instantiated and reuse.
 
* Problem machine (optional) is the machine to be refined by the instantiating machine. In other words, the instantiating machine is a refinement of the problem machine.
 
  
[[Image:GI_Wizard.jpg|center]]
+
=== Hypothesis Selection ===
 +
'''Description''' In order to discharge the proof obligation, the developer just selects some hypotheses then invoke either AtelierB P0 or newPP restricted to finish these proofs. The solution is to (somehow) give "hints" to the Proof Obligation Generator (POG) to select these hypotheses automatically when generating the corresponding proof obligation.
  
=== Replacing Sets and Constants ===
+
'''Example''' Consider the following Event-B model
All sets and constants from the pattern context must be replaced by the available sets and constants in the context seen by instantiating machine.
 
  
[[Image:Replace_Set_Constant.jpg|center]]
+
[[Image:var-hypsel.png]]        [[Image:inv-hypsel.png]]
  
=== Renaming Variables and Events ===
+
[[Image:init-hypsel.png]]        [[Image:set-hypsel.png]]
  
[[Image:Rename_Var_Eve.jpg|center]]
+
Consider the proof obligation '''set/hypSel0_1/INV''' which states that the event '''set''' maintains invariant '''hypSel0_1''' (Here <math>\ldots</math> denotes the unselected hypotheses).
Variables and events (also event parameters) can be renamed.
+
[[Image:set-hypSel0_1-INV.png]]
 +
 
 +
Any provers works with only the selected hypotheses cannot discharge the above proof olbligation since the hypothesis <math>x \neq 0 \limp y \in \nat</math> is missing. The obligation with the appropriate hypothesis selection is as follows
 +
[[Image:set-hypSel0_1-INV-sel.png]]
 +
 
 +
'''Workaround''' Currently, given and event '''evt''' and invariant '''inv''', the invariant preservation proof obligation '''evt/inv/INV''' generated with the following hypotheses automatically selected;
 +
 
 +
* The invariant '''inv'''
 +
 
 +
* The guard of the event '''evt'''
 +
 
 +
In order to have the needed hypothesis selected automatically, we will add this hypothesis into the guard.  Moreover, in order to avoid changing event's behaviour, we will mark this extra guard as a theorem.  Apply this technique, the new event '''set''' is as follows
 +
[[Image:new-set-hypsel.png]]
 +
 
 +
Note that the extra (theorem) guard can be removed in the further refinement without generating any new proof obligation.
 +
 
 +
=== Case distinction ===
 +
'''Description''' In order to discharge a proof obligation, the developer makes a manual "proof by cases" based on some condition <math>P</math>. Afterwards, all branches of the proofs are discharged either by ML or AtelierB P0. The solution is to (somehow) give "hints" to the POG to generate different proof obligations for each case separately. ''Proof by cases'' is usually not applied automatically since this splits the proof tree which could lead to blows up in terms of the number of cases.
 +
 
 +
'''Example''' Consider the following Event-B model
 +
 
 +
[[Image:casesplit.png]]
 +
 
 +
Consider the proof obligation '''set/case0_1/INV''' (Here all hypotheses, including those hidden are shown)
 +
 
 +
[[Image:set-case0_1-INV.png]]
 +
 
 +
In order to finish the proof, a correct "proof by cases" is done to consider <math>a = 1</math> or <math>a \neq 1</math>.
 +
 
 +
'''Workaround''' To capture the effect of doing '''proof by cases''', we split the original event '''set''' into two different events as follows
 +
 
 +
[[Image:new-set-evts.png]]
 +
 
 +
[[Category:Proof]]
 +
[[Category:Work in progress]]

Revision as of 16:54, 5 March 2010

Introduction

This document does NOT provide a way to avoid doing interactive proofs or pointing out the weakness of existing provers. Rather this document shows how to use information from doing interactive proofs to improve the clarity of models. As a consequence of these improvement, the obligations can be discharged automatically. We call these added information to the model "proof hints".

This concept of "proof hints" already exists in the form of "witness" or "theorem" in Event-B. These useful features are designed not only to help with proving the correctness of the model but also to give more information about the particular model.

The question is how we can decide which "features" are useful to have in the model. In principle we can go to the extreme and include the whole proof strategy into the model in order to be able to have it being discharged automatically. But this is undesirable since it will make the model difficult to understand. Having taken this into account we specify our criteria here for "proof hints".

1. It should help to understand the model better.

2. It should improve the automatic proving rate of the model.

In fact, we regard the first criterion as more important whereas the second criterion can be considered as a bonus for improving the clarity of the model. Below are our proposal for two kinds of proof hints: hypothesis selection and proof by cases.

Proof Hints

The presentation for each kind of proof hints is as follows:

1. Description: A brief description of the proof hints with the situation where this can be helpful.

2. Example: an example in Event-B is presented.

3. Work around: we show a solution (rather a work-around) for the current RODIN Platform.

Hypothesis Selection

Description In order to discharge the proof obligation, the developer just selects some hypotheses then invoke either AtelierB P0 or newPP restricted to finish these proofs. The solution is to (somehow) give "hints" to the Proof Obligation Generator (POG) to select these hypotheses automatically when generating the corresponding proof obligation.

Example Consider the following Event-B model

Var-hypsel.png Inv-hypsel.png

Init-hypsel.png Set-hypsel.png

Consider the proof obligation set/hypSel0_1/INV which states that the event set maintains invariant hypSel0_1 (Here \ldots denotes the unselected hypotheses). Set-hypSel0 1-INV.png

Any provers works with only the selected hypotheses cannot discharge the above proof olbligation since the hypothesis x \neq 0 \limp y \in \nat is missing. The obligation with the appropriate hypothesis selection is as follows Set-hypSel0 1-INV-sel.png

Workaround Currently, given and event evt and invariant inv, the invariant preservation proof obligation evt/inv/INV generated with the following hypotheses automatically selected;

  • The invariant inv
  • The guard of the event evt

In order to have the needed hypothesis selected automatically, we will add this hypothesis into the guard. Moreover, in order to avoid changing event's behaviour, we will mark this extra guard as a theorem. Apply this technique, the new event set is as follows New-set-hypsel.png

Note that the extra (theorem) guard can be removed in the further refinement without generating any new proof obligation.

Case distinction

Description In order to discharge a proof obligation, the developer makes a manual "proof by cases" based on some condition P. Afterwards, all branches of the proofs are discharged either by ML or AtelierB P0. The solution is to (somehow) give "hints" to the POG to generate different proof obligations for each case separately. Proof by cases is usually not applied automatically since this splits the proof tree which could lead to blows up in terms of the number of cases.

Example Consider the following Event-B model

Casesplit.png

Consider the proof obligation set/case0_1/INV (Here all hypotheses, including those hidden are shown)

Set-case0 1-INV.png

In order to finish the proof, a correct "proof by cases" is done to consider a = 1 or a \neq 1.

Workaround To capture the effect of doing proof by cases, we split the original event set into two different events as follows

New-set-evts.png