22659
>> Rustan Leino: So let's get started. Welcome to the second edition of a series
that was started by Jean-Raymond Abrial last week. He is here for a month.
And he's teaching us about various program refinement methods he has
developed over the years including event B and Rodin and such things.
So last week we had the first lecture. And we learned about how to refine a
bridge system connecting the mainland to an island, and I the we'll discover other
examples today. All right.
>> Jean-Raymond Abrial: Thank you very much. So we'll continue today with
the welcome everybody. We continue today with the example. I hope that we
finish it and then we can start a second example on mechanic price, and the idea
is to cover this next time and probably the beginning of next week and then I
intend to change completely subjects and develop small sequential program.
Next week. And we will see whether we have time to do more.
So remember last time we had initial model, which was very simple. And then
we went on to refinement of it by introducing the bridge. And we did some
refinement. And we were stopped with a number of proof obligations for all
events, events that were already present in the abstraction. The refinement
imposed transferring of the guard and the concrete invariant preservation and
from new events because we have seen that we have introduced some events
that were not present in the abstraction.
We have to refine -- to prove that we refined the implicit skip event. And also the
very important thing is the absence of divergence. So those new events cannot
take control forever. So we have to define a variant which would be a natural
number, and prove that altogether these new events decrease variance, so they
cannot take control forever and eventually the old event could be executed also.
And finally for all events, we have to prove relative [inaudible] freedom. In our
case, in this example this is absolute freedom, because the abstraction was
already developed free.
And so we prove in general that the disjunction of all the abstract guard implies
the disjunction of the complete guards.
Okay. So here is the rough statement about the prove obligation. So the guard
strengthening first and then the maintenance of the concrete invariant. This is
the same for the initialization. And for the new events we have to define a variant
which is a natural number, prove that the variant is decreased, and here is the
proof rule for the developed fullness. And what you can see is that all these
proof obligations are taking care in the tool by, the tool by a plug-in like the proof
obligation generator so we do not have to write down ourselves all these things.
So the proof obligation, the proof obligation generator study the formal text and
generate a proof obligation and then send the result of what is done to the
prover.
We will go in the middle of this lecture we will go on to have a look at the
platform. This is a state of the first refinement. We had a constant D. You
remember, the maximum number. We have three availables, A, B, C, which are
all natural numbers.
They are related here with the abstract value N. This is the so-called gluing
invariant. Gluing the complete variable to the abstract one.
Here we have the important invariant explaining that the bridge is one way. A
being the number of cars on one, going in one direction, and C the number of
cars going in the other direction. So A is 0 or C is 0. This is the formalization of
the fact that the bridge is one way and then we have this variant.
Okay. And this is were the various events. Initially everything is 0. There is no
cars nowhere. ML in. So mainland in, when there is no bridge -- when there is
some car on the bridge going to the mainland. ML out, C 0 because the bridge is
one way, and A plus B is smaller than B because of the maximum number, and
we have A becomes -- is increased.
And then IL in and IL out. So so much for this. And now let's go to the second
refinement.
So the idea of the second refinement you remember refinement strategy from
two, the maximum number of cars, from three, one-way bridge, and now we are
introducing the traffic light and this corresponds to the requirement equipment
one, two, three.
So I remind you of the equipment. We have the bridge. We have the two traffic
lights.
The problem you see is that if we go into this, especially ML out here and IL out,
these events are supposed to be executed by a driver. So the driver clearly
cannot do this count or do this, especially here.
So we have to authorize the driver in another way and especially this is the role
of the traffic light.
So we introduce a constant set of color and with two color red and green that are
different. And then we introduce two traffic lights. Mainland traffic light and
island traffic light.
And these two events IR in and ML in are not modified. They are not connected
to the traffic light.
And so now here we have this event, and we would like to handle refinement for
the event ML out.
So a green mainland traffic light implies safe access to the bridge. So therefore
we clearly have to introduce this invariant when MLT is green. So -- and this is
green, then the conditions for accessing, for accessing the bridge, which were
the guards of ML out, implies by MLT green. And therefore this is the abstract
ML out we had, and now the concrete ML out is just we replace the guard by
MLT green. And because we have the previous, because we have the previous
invariant, clearly we are strengthening the guard because this guard implies this
definition of this invariant. And we have exactly the same thing in the other
direction.
A green axis, a green island traffic light implies safe access to the bridge. So
therefore we have this one and this is were the conditions for the island going out
here, and then we have this which is exactly the similar situation as before for ML
out.
ILT green implies this. So we have indeed a guard strengthening.
And now we have to introduce new events for turning lights red or green. And
again this is very simple. It becomes green when the condition for being green
holds and when it is already red, and symmetrically here for ILT green. So these
are new events, and you can have new events, we have to prove the refinement
skips, which would be easy, because this and this, MLT and ILT didn't exist in the
abstraction but we have to prove, of course,that the preserve the invariant.
So here is our situation. We have the two traffic lights and these two invariant.
And, ah, we have something interesting here as a refinement which is called
super position refinement. Because you remember last time, when we refine, we
replace N by ABC and we had the gluing invariant A plus B plus C equals 2 N.
Now this is not the case anymore. Here we super pose -- we extend our space
by adding MLT and ILTL. But the variable ABC remains the same. It's called a
super position of refinement.
Usually this refinement is rather simple. And the summary of the old events so
far is just -- is just this. And these events are not changed.
So this is -- here's what I've explained by super position. And here is the proof
obligation for super position, when we have an abstract event dealing with
variable U and V. And a concrete event dealing with value W and V. So V is the
same here and here.
What we have to prove is it's called the simulation. We have to prove that under
the axioms, under the invariant, under the gluing invariant, gluing the concrete to
the abstract variable, and the guards of the abstraction here, when the
expression here on the right on the side of this color equal are the same, under
this. So they do exactly the same. There is no change in what is done on the
super posed variable.
So it's a new proof obligation called Sing. So what we have to prove is to apply
guards, strengthening, SIM and I mean, are our four events with these two main
invariants. This is the job we have to do.
Remember, the idea is to propose some extension of the state, propose some
new invariant. This is what we've done here. Propose some refinement of all
events. Propose maybe some new events and then prove that all this diverse
proposition are coherent, namely, that they obey the proof obligations.
So here is the old situation. The new situation, it's quite convenient to put them
close to each other. Because we can see. This scene is completely trivial
because we see the actions here are exactly the same. So there's no problem
with Sim.
And now we have to proof guard. Guard is trivial in these two cases, because in
this case this is the same guard. Precisely I've already explained this, precisely
because of this invariant, this guard implies this one and this guard implies this
one.
So far we have safe, it's not too difficult. And then INV applied to these two is all
trivially -- I have no white board here.
>> Rustan Leino: No, it's behind that ->> Jean-Raymond Abrial: Here, so we have to prove, for example, that all MLTL
equals green, implies A plus B smaller than D and C equals 0. This is the
hypothesis. For example, let's work with this one. So we have also the guard 0
is smaller than C. And we have to prove exactly the same C. So MLTL equals
green, implies A plus B smaller than B because A and B are not changed, and
then NC minus 1 equals 0. This is what I have to prove. So in order to prove this
I can do a deduction here, so I move this and put MLTL equals green here,
equals green here. So now I can do some modest finance. So I can remove
this, and this is what remains here. And here I see that C is 0 and C is positive.
So I have a contradiction in the hypothesis. So therefore I have no problem to
prove this.
And I have similar, very simple proof for this one and this one and this one and
the two here. So these cases are simple. Now, we have a problem -- we have a
problem with these two. They raised some difficulties and because in each time,
when we prove, we stop the proof with something like this. I can show you with a
tool, we stopped with this. And we discovered that we have this and this.
We have these two hypotheses, which say that both traffic lights are green. Both
traffic lights are green is certainly something we want to avoid, because precisely
the bridge is one way. And we figured out that we forgot completely this
invariant, precisely saying that we cannot be read simultaneously.
So let me quickly -- let me quickly go to the tool. So we load the platform. Okay.
We have the car example here. We have M 2. So we see the variables. We
see the invariant. Let's forget about those for the moment and we have -- and we
have our events. So now let's go here. And we see that the smiley here is not
green, so it means we have some problems. And we can see the problems.
This is precisely with ML out, and IL out and there is a forced one.
So let's have a look at what happens here. So we go, we click twice and we can
see the proof and we can see exactly what I said to you. We want -- we had to
prove a contradiction and we have MLTL green and ILTL green, at the point
where the prover stops. And this is all -- this is the same for all this things. We
can have a look at the proof tree. So this is the proof tree. We saw the various
things that have been done, and we see the point where he stops.
So what am I going to do is precisely to enter MLTL red or ILTL red. So let's do
this. So in order to do this, we go back here. We go to did it. We open the
invariants. And what -- I've prepared something. I put two here for this invariant,
and I'm removing this. Now what I'm going to do is to precisely put this here.
Okay. So now I've put this new invariant. So I will have a little star here because
M 2 has been modified. So I have to save it and look very carefully here. You
see the prover will work here, when I do this. And that's it. So the proof has
been done automatically. It's been finished automatically. And we have the A
here meaning that the proof was automatic. Okay.
Okay. So with add this and this is typically of the problem we found. You do a
development. You do a proof. You figure out that you cannot do some proof.
And you go into the proof that has been, that have been unfinished, not
undischarged. You look a bit at it, and you figure out more or less immediately
that one variant is missing.
>>: When you go for the variance, don't you want to prove it once, so the other
invariants calls because you could put simulations for events [inaudible].
>> Jean-Raymond Abrial: Yes.
>>: You don't prove all invariants are good.
>> Jean-Raymond Abrial: No, no, no, because what has been proved has
already been proved. Now, of course,because I add invariant, now if I change
the invariant, then the situation would be different, of course. And the prover,
hold out and figure out which ones are concerned and redo only the ones that
are concerned. Because we already with this little development have lots of
prove.
Okay. So let me continue now. Yeah, I would say that we could have guessed
this invariant by looking at these two requirements. This is quite often the case,
when people are doing models, they don't guess immediately what are all the
invariants, so again and again, the prover in proving the invariant proving the
refinement helps you debug your model.
We figured out also something that the event ML out, going out of the mainland,
has to be now split into two, either A plus B plus 1 is smaller than D. So we can
do that. Or A plus 1 plus B is equal to D. So we reached the maximum and
therefore at this moment we have to change the traffic light to red.
So it is possible, when you do have refinement, that you split an event into two or
three or more and these two events have to refine their common abstraction. So
we have to do this, and we have -- yes.
>>: How is this figured out during the prove that you need to [inaudible].
>> Jean-Raymond Abrial: Well, here. Here, certainly. If you don't -- if you don't
have this, and you are in this situation, then you cannot prove that the number of
cars is always smaller than or equal to D.
>>: That's the invariant of schedule MLT equals green, right? So basically they
didn't come up because they didn't make any purpose anymore, because we
didn't have any enough vacant rooms?
>> Jean-Raymond Abrial: This comes from the fact that we add, we add an
invariant concerning the traffic lights. So we add that MLTL is green when
precisely, or A plus B plus C.
>>: Didn't have any assignments because ->> Jean-Raymond Abrial: No, precisely, precisely. Suppose we go and do this.
But we have to prove that this events without the red ones ->>: That's not my question. My question is before you split night, yes. You
reduced the time record for guards, it has been productive, but we've never
signed them.
>> Jean-Raymond Abrial: Yes.
>>: What caused us to have to split this, one proof that failed, which one?
>> Jean-Raymond Abrial: Precisely the proof that MLTL is, B implies A plus B
plus C smaller or equal to D.
>>: I thought you proved them all before.
>> Jean-Raymond Abrial: [inaudible] No, not for this event.
>>: Can you jump that one is related?
>> Jean-Raymond Abrial: I didn't prove -- I didn't prove this invariant for ML out.
And when I want to prove it, I think about that it was not possible in all cases,
because we precisely had to prove that A plus 1 plus B is smaller than or equal
to D. So there is a proof by case, and in that case -Yes, of course.
>> Jean-Raymond Abrial: Okay, this is again a very intuitive explanation for
splitting the event IL out in the same situation.
Okay. So we are here now, and we have to prove now, because we have
introduced this new invariant, we have to prove that it is preserved. So therefore
here when MLTL becomes green, ILTL becomes red, of course,otherwise we
could not preserve this.
And here we have to do the same. Okay.
>>: Question about that speaking, you said that you split one event into two. But
I guess from that you need to somehow prove that they -- that one of them
[inaudible] into the next.
>> Jean-Raymond Abrial: What did you say, I'm sorry?
>>: One would trigger the next?
>>: You're not combining them [inaudible] you're saying these two events
together their guards cover all the cases -- it's not like a sequential one.
>>: [inaudible].
>> Jean-Raymond Abrial: Okay? So we have to introduce this. So we are okay
with refinement. And now we have to prove the absence of divergence, we have
to prove these two, which are the new ones, cannot diverge.
So you remember to prove this we have to introduce a variant and prove the
variant is decreased. And in fact we can't. We can't. And precisely these two
could take control forever.
So if we are in a situation where A and C are both 0, and B is positive, then they
can go forever. So this situation is just represented here. We can go forever like
this. Okay? So we have a problem here that we figure out because of this
necessity of having a variant for the new event, that they cannot control forever.
So we have to do something. So the situation, there are various possibilities,
various solutions here.
The solution I choose was to introduce two variables to put in variables, ML pass
and IL pass, and say that each light turned to green only at when at least one car
has passed in the other direction. Therefore we cannot do it indefinitely these
things.
So we introduce here. This is -- and what is interesting also again and again, this
is due to the fact that we couldn't prove something. So we figure out that we
have this situation.
So we introduce ML pass and IL pass. And, of course,we modify again, once
again ML out and ML out one and two with this. Because one car has passed,
and IL pass the same. And then for MLTL green, we introduce these two things
here.
And then we can exhibit a variant which is ML pass plus IL pass.
>>: I understand why you're doing this, but in practice this would not be a good
solution, obviously, right, because a car would have to wait forever until some
other car comes the other direction, right? So in practice, actually, it would have
to be this infinite loop of traffic lights changing every minute, even if no cars pass,
right? In fact ->> Jean-Raymond Abrial: Timer.
>>: You want -- a timer. So actually rule out this divergence, right? You would
want that, actually.
>> Jean-Raymond Abrial: Yes, this is also a possibility to have a timer.
>>: But it would still be divergent, though.
>> Jean-Raymond Abrial: No.
>>: Yes, because ->> Jean-Raymond Abrial: Yeah, it could be ->>: So do you have to refine the original model if you wanted to allow them?
>> Jean-Raymond Abrial: No. What you could do is accept the divergence,
because this is frequent. Sometimes you cheat, you say not everything is proved
for some good reasons, which are not ->>: Weakened the [inaudible].
>> Jean-Raymond Abrial: [inaudible].
>>: Is that what you went for.
>> Jean-Raymond Abrial: It's not the developed -- it's the variant, the variant.
>>: So is it easy to make sure that ->> Jean-Raymond Abrial: But I think ->>: Is it always allowing what you won't allow.
>> Jean-Raymond Abrial: I think with a timer you can still have -- you can still
have a variant, because you could introduce a clock.
>>: Yeah, you have a variant corresponding to the original. What you're trying to
prove is you're saying the new events are not going to just go on forever without
enrolling some old event, that's still going to be the case in my solution, because
I want the lights to change every minute. There's no old event. There's no cars
passing, right?
>> Jean-Raymond Abrial: Yeah.
>>: So it has to be divergent in a way that still has some control.
>> Jean-Raymond Abrial: Yeah.
>>: So at that point it would just have to be weakened that ->> Jean-Raymond Abrial: Yeah, something like this. And, for example, in -here. I don't remember which one. Yeah, in another system also which I think it
was different. This was -- yeah, it was about developed freeness, sometimes
you have to accept that the system can be deadlock free, deadlock in a very,
very special situation and then you accept it and so you don't do -- you say the
proof -- your proof cannot be done but accepted because this situation is very
real, something like this.
So here I have to prove a little more for -- I have to prove the decreasing of the
variant, and therefore for doing this, I have to introduce this, because here you
can see IL pass one. So IL pass press 0 ML pass plus 1 here. So here I have to
say when MLTL is red then ML pass is equal to 1 so I indeed have a decreasing.
So again this invariant is discovered doing the proof.
So the conclusion of the second refinement is that we discover four errors. We
introduce several additional invariant. We corrected four events, and we
introduced two new more variables. So this is the result of the second
refinement. Okay here are the rules SIM that I've added and here are the state
with the new invariants.
And the various events. Okay. So let's go now to the third refinement.
So in the third refinement, we are going to do something very important. We are
going to introduce the sensors to check the entrance or the exit of some cars.
But here we are going to be very, very careful on exactly what is the status of our
variables. The variable small A, small B and small C in fact we were so far we
were a bit cheating, and that's always the case when there's an abstraction,
because these variables were the variables as controlled and modified by the
future software. And they might be different from the real variable, which is the
physical number of cars in the system. So we are going to be very careful and
introduce these two kind of things.
And I will show you the problem. So here is the physical system. And here is the
final system we want to build. We have the controller, which is a piece of
software.
And we have the environment. And the environment has got physical equipment,
the traffic lights, the sensors, and also the physical cars. And here we have
some information going from the software to the traffic lights, and here thanks to
the sensors, we have some information coming into the controller.
Okay. So what happens here is that when a car is detected here in the
environment, this detection is not coming immediately here because it goes
through this channel.
So in fact we have a difference between the picture that the controller used in
order to control the system and the real system. And in fact the property that we
had that the number of cars on the island bridge was smaller than a certain
quantity, and something like -- and the fact that the cars, that the bridge is one
way deal with this variable, with the physical cars, not with these variables.
So we have to prove that in spite of the difference between this and this, in spite
of the fact that the controller reacts on a fuzzy picture of the reality, the system in
fact works correctly here at the level of the environment.
And this is very, very common into an embedded system where your embedded
system, your software, it's exactly like we have in our brain. Your software reacts
on a fuzzy picture of the environment, and he tries to make the environment
being correct.
So in fact you see here I have started -- I have started my development on this
side, and little by little I introduce the equipment, and I now cover both sides, the
environment and the controller. It would have been possible to revert completely
and to start here, which in a sense would have been more coherent to start here,
and to define exactly at this level on the real physical variables what we want,
and then to establish how a controller could make sure that the situation we want
is indeed the situation that we effectively have.
And so if a colleague of mine in Zurich has taken exactly the same that problem
and he started from here and goats from here. I think he's right. I think it's better
to start here and then to construct, because we want to construct something
correctly, to construct something that indeed makes this, the loads we establish
at this point being obeyed. But in this example, I've done the other way around.
So let me now see our global system. We have the controller variable A, BC,
and ML pass and IL pass, this is the one we've been using so far. And now we
have some physical variable. I put them in upper case letter. Big A, big B, big C,
which are the physical number of cars, which is not exactly the same as A, B, C,
and we have precisely to localize them, to relate them, and then we have the
status of the value sensor, which is also some physical variable.
And we have some channel variable which correspond to MLTL and ILTL, which
is the connection between the computer and the two traffic lights. And here I'm
still cheating a bit, because I suppose that the connection between the computer
and the traffic light is here, is instantaneous. So that's the reason why I put
MLTL and ILTL here as channel variables.
So now I have to introduce channel variables in this direction here. And they
correspond to the information sent by the sensors to the computer and here is
the way a sensor works.
So there is no cars. And then there is a car coming on the sensor. So the car is
sitting on the sensor. And then the car is going out to move to enter the bridge,
going in all the other direction, in this edge-there was an edge triggered interrupt
here that goes to the controller precisely at that moment.
Okay? So here there's a final situation. We have controller with ABC, ML pass,
IL pass where the environment with this, and then we have ILTL, MLTL channels
and then this interrupt channel in the other way.
So you see also something important here, you see what we are modeling is we
are not modeling only our controller, we are modeling the controller and an
environment together. Later on, of course, when we finally produce the code, we
will be interested in this.
And what we are sure is that the code here will be current with this. So the
system will be correct by construction. We have to be very careful here. Correct
by construction, relative to the model of the environment we've done. Now, if the
model of the environment doesn't correspond to something physical, then, of
course, that software will not be correct.
So this is very, very important. And to establish and hear this is extremely
simple, of course, but that environment may have far more things here and far
more assumptions.
So what we prove finally is that this final program here, software, will be current
relative to the assumption about the environment, and moreover it controls the
environment according to some laws which are the basic functions of the system.
Okay? So let me introduce now another carrier sensor, two constants, on and
off. And then we introduce the four sensor variables.
And then we start to figure out some invariant, if the sensor IL in is on, there is a
card on the sensor then big A is positive, of course. Here big B and big C. And
this takes care of this, the sensors are used to detect the presence of cars
entering or leaving the bridge. So we have these three invariants here. They are
physical -- they're invariant of the environment.
And here cars are not supposed to pass on red traffic light, only on green one.
You see when ML out 10 is true which means that the interrupt has been sent to
the computer it's because the car is moving out of the sensor he was sitting.
Then MLTL must be green.
So this is here we take into account this rule and the same for ILTL.
>>: So will the system break down if drivers disobey the traffic laws?
>> Jean-Raymond Abrial: I'm not responsible.
>>: That's going to happen, right?
>> Jean-Raymond Abrial: Yeah, if you want to buy -- if you want this, I can do
something, but you have to give me more money.
Okay. This is very important. And this is very important if you buy my system
that you sign on this, okay? Because I will not be responsible. And this is also
very important to precisely write down all these things.
Okay. And it is absolutely -- and it is an assumption about the environment. And
my system works if this assumption is obeyed. If it is not, I'm not responsible.
Okay?
>>: Sensors are behind the [inaudible] so basically you turn right you stop your
car here, when it's green you move forward and then the sensor works.
>> Jean-Raymond Abrial: No, no, no, the idea is that -- well, you have the traffic
light. You have the sensor and you are here. Okay.
>>: So you have -- so only after it's green then you are supposed to touch the
sensor?
>> Jean-Raymond Abrial: No, no, no. You can sit on the sensor. You can be on
the sensor. It's red. You wait, but you remember nothing is sent to the computer
it's sent only when you leave.
>>: Okay. So it could be in front of you, it could be closer to the front but you
don't have to stop.
>> Jean-Raymond Abrial: You see, all your questions are really interesting. It
means that the purpose of doing this is just precisely to have all these questions
coming, and coming only on doing the model. I have not yet done, written a
piece in a line of code. And it's not expensive to do this.
But you ask all these questions. We discuss, we disagree, we agree, you pay
more, or you pay less. [laughter].
This is very important. The problem and it is always -- it is quite often forgotten.
This is a problem that we want -- suppose our computer is very, very, very slow.
Then it cannot handle -- it cannot do the job before a new car is coming. So here
I have something which is a bit strange, which is linking some physical and some
computer variables together to indicate that -- and this was forgotten, the
controller must be fast enough so as to be able to treat all the information coming
from the environment.
And this is often forgotten. And in industry, in developing large systems, quite
often people find out this problem that the computer is not powerful enough.
Because it is not able to, usually this system works with big loops, and the
computer is not able to treat all the information before going to the next -- and
this is what is written here. And now I'm linking -- now I'm linking the smaller and
the big A. And you see that sometimes small A and big A are the same.
Sometimes we have As, A plus 1 or A minus 1 or big A, small A. This is
precisely here this question that we have a fuzzy picture, A, which is not always
the same as big A. And we have the same for B and C. And now what we have
to prove is precisely that the one way and the fact that there is no -- the number
of physical car is smaller than D is still true.
So here we prove that, again, in spite of the fuzzy picture on small A, small B,
small C, the computer is the program is able to maintain this one.
So if we start the other way around, we would have started with this, and prove
that we have a similar load inside the computer. So you see again this is very,
very important for this kind of system and very often forgotten to make the
distinction and I want to hammer this, between the physical variable on the
environment and the logical variable inside the computer and showing that they
are not exactly the same but in spite of that the system reacts correctly.
>>: Are there any provisions say in MP or whatever for separating the two, for
example, having events that are only supposed to happen within the software
and only a time or two. So you actually prove that, say, the software isn't secretly
looking at the physical variable involved?
>> Jean-Raymond Abrial: Yeah, exactly. Exactly. And this is precisely -- this is
very important what you state here.
The problem is that when you are running an abstract, at an abstract level, you
can cheat. So the environment can look inside the computer and the computer
can look inside the environment without going through the channels.
Because the idea is to always introduce a channel at the very end. So for a while
you have a hybrid system which is a monster which doesn't exist, and then you
refine, you refine, you refine, and this is the reason why I have chosen to have
small letters and big letters to precisely make the distinction between the two.
And then you have to figure out that all the events that are supposed to be in the
environment are working only with big variables and all the events are dealing
with the computer with feature software are with small variables and according to
the environment you might have mixed things, and then you separate things and
it's possible to -- there is a plug-in where you can decompose. So you
decompose and you have exactly the system that I showed to you. You have the
environment, the software and you have channels between the two.
And now I'm not going to go on to this, so we have some refinement of these
events and here is the final situation. That's really interesting. We have as many
physical events as we have logical events in the computer. So this is the
environment. And this is the future software.
>>: I have one question, so the separation between physical events and logical
events, it makes a lot of sense but at some point you have to model the physical
event causes some logical variable to change in the channel.
>> Jean-Raymond Abrial: Yeah.
>>: So is that special? Because that seems to be one case where you do have a
cross -- where you enroll both physical and the logical elements, right?
>> Jean-Raymond Abrial: No, no, you have three kinds of variables. You have
the logical variable. You have the physical variable, and you have the channel
variables. Okay. And so the channels variable, for channel going out, are written
here and tested here. And the other way around here. So you have really three
kinds of variables.
>>: But the two end posts, those three ->> Jean-Raymond Abrial: No, the tool doesn't impose anything here. The tool
doesn't impose. This is a way of doing it systematically.
So question on proving. So we -- what needs to be systematically proved
invariant preservation correct refinement no divergence and no deadlock, where
is this proof done, so I have many kinds of proof obligation generator and the
prover which is automatic or interactive.
And the tool, the main tools are the proof obligation generator, the prover, and
translator into hardware or software languages.
And the tool is embedded in the development database.
>>: What do you use in [inaudible].
>> Jean-Raymond Abrial: Excuse me?
>>: What prove do you use?
>> Jean-Raymond Abrial: We developed our own proffers and we have
connections to external prover but so far this is mainly our own prover.
>>: What kind of a prover is it?
>> Jean-Raymond Abrial: It's a prover working with set theory arithmetic. And
we have one prover working directly at this level. And we have also another
prover and two other provers called PP and UPP. So there is a translation of the
set theoretic statement into first order predicate calculus, and then this is a first
order calculus that does the job.
>>: [inaudible].
>> Jean-Raymond Abrial: Sorry?
>>: So your own development?
>> Jean-Raymond Abrial: Yeah. Yeah. So let me just show you the final thing
about it. So if I go on top here, and on this -- oops. On this little window here, I
have the statistic of the proofs.
So you see, the proof is quite significant, 252 proofs. There are lots of proofs at
this level. And we have two -- we have two interactive proofs, literal interactive
proofs. They are essentially on the deadlock freeness because there's lots of
disjunction and the prover could be better on this. But this is not too bad but it
shows, you see, that a simple system like this requires a lot of proof to do all
these things. So it's exactly 2:30 so we are going to stop here now. So next time
I will again start the mechanic price, and here what I'm going to introduce is the
notion of formal design pattern, you know the notion of design pattern in OO, you
know that. And the idea is to [inaudible] this concept and to see if we could have
something that occurring very often so that off-the-shelf we have little things that
are prepared and we can use them within some formal development. Okay.
Thank you very much.
[applause]