Revisiting Feasibility POs: Difference between revisions

From Event-B
Jump to navigationJump to search
imported>Laurent
Initial complete version
 
imported>Laurent
Various typos fixed + new section on WD
Line 64: Line 64:


       v' = 1                  // abstract before-after predicate
       v' = 1                  // abstract before-after predicate
       −(w' * w') = v'         // witness
       v' = −(w' * w')        // witness
   |-  ∃ w' · w' * w' = −1    // feasibility predicate
   |-  ∃ w' · w' * w' = −1    // feasibility predicate


where the abstract before-after predicate has been applied as a substitution to the witness.
where the witness (which is deterministic) has been applied as a substitution
to the abstract before-after predicate.


This proof obligation is easily discharged by instantiating the existential
This proof obligation is easily discharged by instantiating the existential
Line 74: Line 75:
From this example, the flaw in the proof obligation comes from the presence of
From this example, the flaw in the proof obligation comes from the presence of
the two hypotheses together.  If we remove any of them, then the proof
the two hypotheses together.  If we remove any of them, then the proof
obligation becomes unprovable, as expected.  So, we need to remove one of these
obligation becomes unprovable, as expected.  So, we need to remove at least one
hypotheses to make the <tt>FIS</tt> PO correct.
of these hypotheses to make the <tt>FIS</tt> PO correct.


==A Bit of History==
==A Bit of History==
Line 92: Line 93:


The idea backing this change was to try to allow users to reuse somehow the
The idea backing this change was to try to allow users to reuse somehow the
<tt>FIS</tt> proof already carried on for the abstract actions when proving
feasibility proof already carried on for the abstract actions when proving
feasibility of the concrete actions.  For this, the POG adds one hypothesis
feasibility of the concrete actions.  For this, the POG adds one hypothesis
which corresponds to the feasibility predicate already proved in the
which corresponds to the feasibility predicate already proved in the
Line 143: Line 144:
out the witness does not loose any expressivity and is indeed much simpler.
out the witness does not loose any expressivity and is indeed much simpler.


==About Well-Definedness of Actions==
==Similar Proof Obligation==


Looking at the code of the proof obligation generator, it appears that the
Looking at the code of the proof obligation generator, it appears that the
Line 151: Line 152:
hypothesis can introduce inconsistency.  Following the same reasoning, it is
hypothesis can introduce inconsistency.  Following the same reasoning, it is
decided to also drop the witness from <tt>WD</tt> proof obligations.
decided to also drop the witness from <tt>WD</tt> proof obligations.
==About Well-Definedness==
Is the feasibility proof obligation envisaged so far well-defined? Let's have a closer look to this proof obligation using the notation from Jean-Raymond Abrial's book (section 5.2, pp 188&ndash;203). The feasibility proof obligation for an action is defined in the book as
<blockquote><math>
\begin{array}{ll}
& \text{Axioms and theorems}\\
& \text{Invariants and theorems}\\
& \text{Guards of the event}\\
\vdash & \exist v'\qdot\text{before-after predicate}
\end{array}
</math></blockquote>
In the case of an abstract event, this proof obligation refines to
<blockquote><math>
\begin{array}{ll}
& \text{Axioms and theorems}\\
& \text{Abstract invariants and theorems}\\
& \text{Abstract event guards}\\
\vdash & \exist v'\qdot\text{abstract before-after predicate}
\end{array}
</math></blockquote>
and for a concrete event that refines an abstract one, the proof obligation becomes
<blockquote><math>
\begin{array}{ll}
& \text{Axioms and theorems}\\
& \text{Abstract invariants and theorems}\\
& \text{Concrete invariants and theorems}\\
& \text{Concrete event guards}\\
\vdash & \exist v'\qdot\text{concrete before-after predicate}
\end{array}
</math></blockquote>
If we want to add the feasibility of the abstract actions in the feasibility proof obligation of the concrete actions, we need to ensure that all its hypotheses are indeed well-defined and valid. The only ones missing are the guards of the abstract event.
In case of a regular or split refinement, the <tt>GRD</tt> proof obligation permits this introduction. And its alter ego for merge refinement (i.e., <tt>MRG</tt>) allows to introduce the disjunction of the abstract guards.  In the latter case, as all abstract events have the same actions, we still can use this disjunction to introduce the feasibility of the abstract actions.  In both cases, the proof obligation that we use to introduce the feasibility of the abstract action is independent of the feasibility of the concrete action, so we do not introduce any circular reasoning.
We finally end up with the following extended proof obligation for the feasibility proof obligation of a concrete event:
<blockquote><math>
\begin{array}{ll}
& \text{Axioms and theorems}\\
& \text{Abstract invariants and theorems}\\
& \text{Concrete invariants and theorems}\\
& \text{Concrete event guards}\\
& \text{Witness predicates for parameters}\\
& \text{Disjunction of abstract guards}\\
& \text{Abstract before-after predicate}\\
\vdash & \exist v'\qdot\text{concrete before-after predicate}
\end{array}
</math></blockquote>


==Conclusion==
==Conclusion==

Revision as of 13:56, 29 January 2012

The Issue

Son recently reported a bug in the Proof Obligation Generator (POG) of Rodin 2.3 where one could have an event-B project containing two machines where all proof obligations are discharged automatically although the concrete machine contains invariant \bfalse. This is not something expected so some proof obligations must be wrong.

Analysis

Looking more closely at the example attached to the bug, it appears that the initialisation of the concrete machine is magic. It is therefore normal that it can establish a \bfalse invariant. However, the feasibility proof obligation FIS is supposed to work as a filter and prevent models from containing magic actions. In the example, the FIS proof obligation of the concrete initialisation is easily discharged and thus does not play its filter role. This proof obligation is therefore wrong and needs to be fixed.

In a nutshell, the example attached to the bug, can be reduced to the following. Take a machine M with the following contents

 MACHINE
 	M
 VARIABLES
 	v
 INVARIANTS
 	inv1:	v = 1	  not theorem
 EVENTS
 	INITIALISATION:	  not extended ordinary
 		THEN
 			act1:	v :∣ v' = 1
 		END
 END

and a concrete machine N refining M such as

 MACHINE
 	N
 REFINES
 	M	
 VARIABLES
 	w
 INVARIANTS
 	inv1:	v = −(w * w)	  not theorem
 EVENTS
 	INITIALISATION:	  not extended ordinary
 		WITH
 			v':	v' = −(w' * w')
 		THEN
 			act1:	w :∣ w' * w' = −1
 		END
 END

In Rodin 2.3, the FIS PO generated for the action of the initialisation of N is

    −(w' * w') = 1
 |- ∃ w' · w' * w' = −1

which is a contraction of the theoretical proof obligation

     v' = 1                  // abstract before-after predicate
     v' = −(w' * w')         // witness
 |-  ∃ w' · w' * w' = −1     // feasibility predicate

where the witness (which is deterministic) has been applied as a substitution to the abstract before-after predicate.

This proof obligation is easily discharged by instantiating the existential quantifier of the goal with w'.

From this example, the flaw in the proof obligation comes from the presence of the two hypotheses together. If we remove any of them, then the proof obligation becomes unprovable, as expected. So, we need to remove at least one of these hypotheses to make the FIS PO correct.

A Bit of History

In Jean-Raymond Abrial's book, the feasibility PO does not contain any of these hypotheses. It was also the case in early versions of the Rodin platform. Looking at the code history, it appears that the faulty hypotheses were added in commit r2786 of Tue Jan 9 2007 with comment

Changed structure of generated POs.
The POG now tries to put feasibility of abstract actions in the hypothesis of refined event actions. As a consequence the guard strengthening PO is now stronger.

The idea backing this change was to try to allow users to reuse somehow the feasibility proof already carried on for the abstract actions when proving feasibility of the concrete actions. For this, the POG adds one hypothesis which corresponds to the feasibility predicate already proved in the abstraction together with the witness that describes the link between the abstract and concrete actions.

On the one hand, there is no problem with the feasibility predicate of the abstraction as it has already been proved in the abstraction under a more restricted set of hypotheses (e.g., the concrete guards were not present).

On the other hand, stating also the witness that links after values of abstract and concrete variables introduces a circular reasoning, as the witness supposes that after values of concrete variables do exist, which is the exact meaning of the feasibility proof obligation. We are thus left with a proof obligation to demonstrate the existence of something, assuming that this something already exists!

In summary, the witness linking abstract and concrete after-values must not be put in hypothesis of any FIS proof obligation.

Possible Solutions

Introducing the abstract feasibility predicate in hypothesis was a good idea, a priori. But if we cannot use the witness with it, is it still worth? Could we put another hypothesis that would link the abstract and concrete after states?

Looking more closely at the problem, we can get the following insight: the purpose of the witness is to describe how one can compute abstract after values from concrete ones. It is the purpose of the WFIS proof obligation to demonstrate that this computation is actually feasible.

However, in the case of the feasibility proof obligation, we need to go in the opposite direction: we know that we have abstract after values and we want to show the existence of concrete ones. We therefore want to use the witness in the opposite direction. And no proof obligation is generated to show that the witness can indeed be use in this opposite direction.

So, we have two possibilies for fixing the feasibility proof obligation:

  1. Either we keep the witness as hypothesis, but we generate a new proof obligation to show that the witness can be used to compute concrete after values from abstract ones.
  2. or we get rid of the witness in the feasibility proof obligation.

The first solution looks a bit heavy, as feasibility is the only place where the witness is used in the direction from abstract to concrete. In all other proof obligations, it is used from concrete to abstract. Therefore, introducing a new proof obligation just for this is not worth it.

In the second solution, during proof, one can always state again the witness, prove that it is invertible and then use it to achieve the proof. So leaving out the witness does not loose any expressivity and is indeed much simpler.

Similar Proof Obligation

Looking at the code of the proof obligation generator, it appears that the well-definedness (WD) proof obligation for concrete actions also has both the abstract before-after predicate and the witness in hypothesis. So this proof obligation is also erroneous as we've seen that this combination of hypothesis can introduce inconsistency. Following the same reasoning, it is decided to also drop the witness from WD proof obligations.

About Well-Definedness

Is the feasibility proof obligation envisaged so far well-defined? Let's have a closer look to this proof obligation using the notation from Jean-Raymond Abrial's book (section 5.2, pp 188–203). The feasibility proof obligation for an action is defined in the book as


\begin{array}{ll}
& \text{Axioms and theorems}\\
& \text{Invariants and theorems}\\
& \text{Guards of the event}\\
\vdash & \exist v'\qdot\text{before-after predicate}
\end{array}

In the case of an abstract event, this proof obligation refines to


\begin{array}{ll}
& \text{Axioms and theorems}\\
& \text{Abstract invariants and theorems}\\
& \text{Abstract event guards}\\
\vdash & \exist v'\qdot\text{abstract before-after predicate}
\end{array}

and for a concrete event that refines an abstract one, the proof obligation becomes


\begin{array}{ll}
& \text{Axioms and theorems}\\
& \text{Abstract invariants and theorems}\\
& \text{Concrete invariants and theorems}\\
& \text{Concrete event guards}\\
\vdash & \exist v'\qdot\text{concrete before-after predicate}
\end{array}

If we want to add the feasibility of the abstract actions in the feasibility proof obligation of the concrete actions, we need to ensure that all its hypotheses are indeed well-defined and valid. The only ones missing are the guards of the abstract event.

In case of a regular or split refinement, the GRD proof obligation permits this introduction. And its alter ego for merge refinement (i.e., MRG) allows to introduce the disjunction of the abstract guards. In the latter case, as all abstract events have the same actions, we still can use this disjunction to introduce the feasibility of the abstract actions. In both cases, the proof obligation that we use to introduce the feasibility of the abstract action is independent of the feasibility of the concrete action, so we do not introduce any circular reasoning.

We finally end up with the following extended proof obligation for the feasibility proof obligation of a concrete event:


\begin{array}{ll}
& \text{Axioms and theorems}\\
& \text{Abstract invariants and theorems}\\
& \text{Concrete invariants and theorems}\\
& \text{Concrete event guards}\\
& \text{Witness predicates for parameters}\\
& \text{Disjunction of abstract guards}\\
& \text{Abstract before-after predicate}\\
\vdash & \exist v'\qdot\text{concrete before-after predicate}
\end{array}

Conclusion

Therefore the witness hypothesis must be dropped from both the well-definedness and feasibility proof obligations of concrete actions. The before-after predicate of the abstract actions is still generated as hypothesis, as it can be useful even when the witness is not present.