22636
>> Rustan Leino: Good afternoon, everyone. My name is Rustan Leino, and it's
my great pleasure to introduce our speaker this afternoon Jean-Raymond Abrial.
Abrial has given, defined a number of formalisms that we're used to, the Z
notation, the B method and what he's going to talk about today the event beam.
Each sort of the B and event B gives you ways to develop programs starting from
specifications and models and going downwards step-wise for finding your
programs. And as are described in his new book here, which I'll be sure to flash.
These techniques have been used by Jean-Raymond Abrial and others, for
example, in the Paris metro system to prove some safety critical properties and
other systems. So he's going to teach us more about how to use the method.
Jean-Raymond Abrial: Good afternoon. Rustan, thank you very much for your
introduction. So I have the pleasure to start this event B course with a short
introduction, only two or three slides, and then we go on to our first example.
So let me just set up the scene. The purpose of the course is to show that
software and system could be carried by construction. So this is a very, very
important thing. And give some insight on modeling and formal reasoning using
this formalizing called event B. And this -- and to show also this can be made
practical with the Rodin platform. I'm not sure we'll have time to have practical
session with Rodin platform, but it is a free software so you can also download it
and use it.
And essentially what I will do is to cover some examples. So I've put a few of
them, probably not enough time to treat all of them, controlling cars on a bridge, I
think this would be today, and probably part of next time, and mechanic and price
controller. Mechanic price is very basic machine, but you'll find out that it is not
so simple and pedestrian as you can imagine.
And then file transfer protocol routing algorithm and the development of classical
sequential program dot, dot, dot.
But I'm pretty sure I will not reach the dot, dot, dot part. Okay. What you will
learn is by the end of the course I have the pretension to say we'll be more
comfortable or comfortable with modeling versus programming. Makes a clear
distinction between the two. And a very important notion of abstraction and
going the other way around refinement.
I've put within brackets these things because we will, I will not cover this,
because I will not have enough time. By the way, these slides will be made
available to you and also the chapter 1, which is the introductory chapter of the
book, and chapter 2 which covers this example.
So the text will be more elaborated than what I will say in the slides. So there is
no problem. You can have access to this. Please do not distribute too much
these things, because otherwise I might have some problem with Cambridge
University press.
So this is -- the introduction is finished and now we go to number two. Number
two is so this problem of controlling cars on a bridge. And so I will describe the
systems. So the idea is to present a complete development of a little system,
and the approach will be to have a series of model more and more and more
refined until we get something that could be translated into code. And this
approach is called refinement.
And the idea of the model is to formalize what an external observer could see of
the system. So it's completely different from programming. In programming, we
just instruct the computer to do something.
Here, we are going to, as engineers, we are going to suppose that we see the
system, this controlling cars, we see the system and we observe it. And we
observe it more and more and more and more carefully. And the result of this
observation precisely is to build some models. And at the end of it we just
jumped into programming, saying, ah, but the model now is so concrete that it
can be transformed to a program. So you see this idea of being quick by
construction, what we define, what we build our models, not program, model
which will be larger than the strictest-speaking piece of software. This would be
a model of the entire system. And so with each refinement, the observer zooms
on some more details.
So the purpose of this lecture, the number two, prove that each model can be
analyzed and prove to be correct with proofs, and as I've said to some of you last
time, the mechanics of proving will be exactly the same thing as the mechanics
of debugging by testing.
So we have the model. We do not execute the model, but we prove the model.
And, again, the model, the aim is to obtain something that is going by
construction, and the correctness criteria will be formulated as proof obligation.
And I will describe more carefully what are exactly this proof obligation. So I will
not cover these two again for the same reason I have said before.
What you will learn the concept of state and events, again we are not
programming, so there is no loop, there's no if then else, there's just assignment
and bare guarded commands. So these are the events, and the state on which
we are working.
And we will learn some principle of system development, essentially the notion
again of invariant and refinement.
So I think there is no need here to have a refresher on classical logic, and no
need to have refresher on formal proofs. So the outline -- the outline -- and this
is systematically followed when doing some development. First of all, writing
down requirement documents so that we start, when we start the development
we know exactly what are the requirements and I insist, last time also I insisted
on this is very, very important and especially again in industry these things are
not very good. So it's very important to write down really, really carefully this
requirement document. Then we define the refinement strategy. We are going
to see how we are going to use the requirement little by little in order to
eventually got a more and more concrete model.
And then number three is the development of the initial model and then the
refinement. So this is the outline. So the requirement document. So let me
describe this system in a very general way.
So this requirement document will be made of two texts embedded and shorter,
some general explanation, plus some well-defined boxed requirements.
So we are going to -- and this requirement will be labeled so there will be
concern either with the equipment of the system or the function of the system.
So the system we are going to build, a piece of software connected to some
equipment. This is very, very classical. And the function of this system is to
control car on the narrow bridge, but I will explain what I mean by control cars.
And the bridge is supposed to bring the mainland to a small island. So we have
our first very general function. The system is controlling car and a bridge
between the mainland and highland, so here you see here I repeat in some of the
requirement, I repeat what I have said but at the end of the definition of the
requirement document, we'll have a list of very well-defined requirements, and
we could forget about this.
So this can be restricted that way. We have the mainland and the bridge and the
island. The controller is equipped with two traffic lights, with two colors. Red and
green.
So this will be described here. We have a traffic light here and a traffic light here.
And they are both situated at both ends of the bridge, and this is restricted as
follows. And so what I do here is introduce things little by little. So we have the
mainland, the island, the bridge and now the two traffic lights.
So again we go a little more formal here. The traffic light control the entrance at
the bridge at both ends of it. So it's equipment number two, and ah, equipment
number three is absolutely fundamental. This is an assumption about the
equipment corresponding to people. In fact, with a car, driver, as opposed to
traffic light by not passing when the traffic light is red.
So we have this, and it is very important, because it means that if this is not true
at some point, then the system could crash or have a problem or difficulty. So
this is an assumption which make very, very clear under which case we consider
that the system will be correct.
Okay. So cars are not supposed to pass on traffic light only on green one. So
this is an assumption. And we have also some car sensors. And they are
supposed to detect the presence of car entering or leave the bridge and four
sensors, two situated on the bridge and two situated on the mainland, on the
island. So this is equipment before, and you can see the drawing. Yeah, you
can see the drawing here. So now we have the sensors here. So car, we are
supposed to drive on the right -- when I explain -- when I present this in British, in
Britain, there is a problem. People are confused.
Okay. So we have sensors here. We have traffic light. So the car is going here,
and again the sensors can enter, and the same for going out. And now we add
the two main functions of the system, which are the following: The number of
cars into the bridge and the island is limited for some reasons.
And the bridge is so narrow that the bridge is one way or another, not both at the
same time. So cars cannot cross each other on the bridge. Okay. So that's it.
That's it. We have three functions. The first one was very general. We have lots
of equipment. We have six, I think -- I think six equipment and we have these
two functions and that's it. And now we can remove all these texts here, put all
these things together, and this is the law. This is the law. And at the end of our
development we are going to check that we have indeed taken into account all
these assumptions for equipment and all these functional requirement for the
system itself.
Now, the next step -- yeah.
>>: It doesn't say anything in there about progress. So.
Jean-Raymond Abrial: About progress.
>>: About progress. So you can imagine a system that just didn't let any cars
pass across the bridge ever.
Jean-Raymond Abrial: Yeah.
>>: And that would be correct by this construction, according to at least the
functional requirements.
Jean-Raymond Abrial: You're right. We have to say something else, I agree with
this, that it is indeed possible for cars to go in. And you will see how we'll solve
this problem. Okay.
But thank you. That's a good point. The refinement strategy. The refinement
strategy, the role of the refinement strategy is to define apriori without starting the
value steps. And linking each step with the requirement. So we say in the first
step we take this one, this one, the second step, this one, this one. Also the goal
of the [inaudible] strategy is to start a traceability of the requirements. So we can
say at this point we have taken into account this requirement. We can tick it, and
at the end we have to be sure we have ticked all of them. And of course we feel
possible -- it would be possible to modify some of the requirements during the
formal development, because we might figure out that because they are not
formal we can figure out that some of them are impossible or bad or that we
could possibly change them.
So here is the refinement strategy. There might be some other, but this is the
one I have chosen. I have chosen to be interested in limiting number of cars, to
two, in the initial model. And the first refinement introducing the one-way bridge.
So the fact that the bridge is one way. And as you see here, I have not
introduced a traffic light and the sensor before the second and third refinement.
So in fact here what we do, we do something abstract, and we suppose that
there are some goal origin mechanism that can make the thing work incorrectly.
And here we say, ah, but this is not the case so we have to add some equipment,
the traffic light, and then the sensors. Okay?
So let me now enter our first formal development, our initial strategy. So limiting
the number of cars from two. So this model is as usual in the abstraction is
extremely simple, extremely abstract. We completely ignore the equipment. And
we do not even consider the bridge. So there is no bridge.
We are just interested in the bare island bridge and we're focusing on two,
limiting the number of cars on island bridge. So the sort of paradigm we're very
high in the sky and we do not see the bridge, we just see some -- we just see the
mainland and the island and we want to just define something that will make,
take into account this from two that there's a limited number of cars on the island
bridge. So that's the idea of the initial model.
So this is the drawing. No bridge between the two. And we have this component
here called island bridge. So we have now to define the dynamics. We have
essentially two events, two transitions to remember. We are considering only
transitions. And we have two transitions, ML out, mainland out. So a car is
going out from the mainland and ML in coming back to the mainland. So we
have two events.
So we are going to define these two events. First of all, define the static part.
We have a constant D, which is natural number, and D is the maximum number
of cars allowed in the island bridge. So in defining a model with event B you
have the static part which is called context in event B where you define all the
constants. And here we have a single constant with single axioms.
And then we'll define the dynamics now, essentially the state which it dynamically
changed and the values events.
So we have a single variable N and N is the number of cars in the island bridge.
And then we have this -- it's a natural number. And we have the basic invariant
here that N is smaller than or equal to D, and this takes account of N 2, the
number of cars is limited.
N is the effective number of cars in the island bridge. I'm sorry, it's so simple, it's
so trivial at this level, but you will see. It will become a little more complicated
later. And we'll find some problem.
So now we have the story about ML out. Mainland out. So we look at before
and after, like in the whole logic, so to speak, before we have a car here in the
mainland, ML out and then this car is now inside the island bridge. And so the
number of cars in the island bridge is just incremented. And ML in back to the
mainland it's exactly the opposite, the number of cars in the island bridge is
decremented, it's totally trivial. We can define very simply our two events. Just
an incrementing, incrementing and decrementing, so ML out is just defined this
way and this way.
These are not programs. These are models. Okay. This is the way this
transition works. N becomes N plus one. N becomes N minus one. And an
event is denoted by its name here and its action on the state, which is either in
this case incrementing or decrementing.
Okay. Oh, this is an -- and I've said here this is an approximation. Why is it an
approximation? This might be refined later. So be more -- be richer and it could
be wrong also. It might be insufficient at this stage not consistent with the
invariant, because we have defined the invariant, N smaller or equal to D, and we
change our hat and we find the dynamic, N plus 1 and N minus 1. And now we
have to reconcile the two to see whether the transition is consistent with the
invariant. And so we might have -- we have to do a proof here, very simple
proof, and we might discover that we have some problem.
Let's continue. So the invariant, the definition of an invariant, it's a constraint on
the outward value of the variable N small or equal to D. It must be in all
reachable states of the model. To verify this holds, we have to prove that it holds
in the initial state, have to define the initial state, and the invariant preserved by
all events. So we have to prove that it's preserved by all events.
And so we will formalize these things by proof obligation. POs. So these proof
obligation are completely systematic, we need a rigorous showing that each
proof propagation indeed holds.
So to also prove, we define together with the action of each event, before/after
predicate. Describes the relation between the value of the variables just before
and just after the even occurrence. The before value is denoted by the variable
name and the after value is denoted by priming the variable name N prime in our
case.
So it's completely trivial here. And N plus 1 gives a before/after predicate and
prime equals N plus 1, and N minus 1 gives N prime and equal N minus 1.
So by doing this little jump here from colony to equal by introducing the prime
here, we can enter into mathematics. We have no more something becomes
equal which looks like programming and now we can define clearly the proof
obligation.
So let me do this. So here are the before/after predicate. The after value is
defined, in this case just a warning, in this case M prime is defined as a function
of the before value. This is because the two assignment N plus one and N minus
one are deterministic but it could also be positive to have nondeterministic events
and we will not have this into this example but in further example we might have
this.
So this is not necessarily the case that we are always deterministic. And now our
intuition about the proof obligation. For example, this invariant, N is a natural
number. We consider ML out. This is the before/after predicate. And we have
to prove that the invariant here is kept. So therefore we have to prove N prime
belongs to the natural number, and N prime is just N plus one. This is an
assumption. And therefore we have to prove this. We have to prove that under
this hypothesis we can have this. Not very difficult. [inaudible] axiom.
So this is what we have to prove. And this is put under the form of a sequence.
You see the turn style here, all the hypothesis. We only have one here. Here
the goal or conclusion that we have to do.
Okay. So here at that point when I'm doing the course, in a more general way, I
introduce the piano axioms and various axiom in order to do this proof.
Okay. So the most general -- the general form for this invariant preservation
proof obligation is the following: In a vertical way, under the axioms and the
invariants as assumptions have to prove for each invariant that the modified
invariant, modified by the before/after predicate, is still true. Okay. So this is -so now this proof obligation will be part of a tool, of a plug-in into the platform
which will precisely be the proof obligation generator. So what the proof
obligation generators, it analyze the events. It transforms the colony equal into
the before/after predicate and generates according to this generates all the proof
obligation of all the things that has to be proved and pass all this to the prover
that is supposed to do these proofs.
So it's completely systematic. The tool is defined under Eclipse. And Eclipse is
quite nice because there are lots of possibilities to do things systematically with
Eclipse.
Okay. So here are the four proofs. We have two events. And we have two
invariants. Therefore, we have four proof obligations.
You have an idea about this proof obligation?
>>: Two -Jean-Raymond Abrial: Yeah, these two, we have a problem. This one no
problem. This one no problem. But here we have a problem. Because when N
is equal to D and the first one is not, small or equal to D, and here when N is 0, N
minus 1 is not a natural number. So we have a problem here.
We discover that our events are no good because of this. So we have to solve
this difficulty. Here, in fact we would like to have that N is smaller, strictly smaller
than D. And here we have to, we would like to have that N is positive.
And then N minus one is still a natural number. So there are clearly two
assumptions that are missing. Ah, two assumptions that are missing. Let's add
them, precisely, these are the two assumptions, let's add them to the events.
And so now we transform the events by adding to them guards. And so these
guards are here for this one and here for this one, and these guards, if you think
in terms of an execution, these are the necessary conditions for the event to
occur. And, of course, in the proof obligation, now we, because necessary
condition for the event to occur, therefore in the proof obligation, we are going to
add for each event we are going to add its guard. So we modify our proof
obligation into this one, axiom invariant guards of the events and modified
invariant.
Okay. So the idea here was to introduce in a gentle way the notion of guard. So
be very careful, a guard is not a precondition. Okay. A guard is not a
precondition. A guard -- and you will see that they work in a completely different
way, as far as refinement is concerned. When you have pre-post condition,
when you refine you can weaken the precondition, because you can buy
something that is more expensive.
For a guard, when you refine, we strengthen the guard. We make the guard
more precise. Why is that? That's very obvious, because we introduce more
things. Therefore, our abstract events now have to be made narrow because we
add new features or new functionalities in our system. So keep this in mind. A
guard and a precondition are some sort of dual concept. Again, by refinement,
you weaken a precondition. By refinement, you strengthen the guard. Okay?
And here we are not so much interested in precondition, because again we are
not programming. When you program, you need to have precondition protecting
a piece of code, because the caller, the people who call this thing they want to
have us prove and be sure that the people who call these things are within the
precondition.
So for a guard, and if the guard is false, if the precondition is false, crash, the
system cannot continue. Whereas when a guard is false, wait. Wait. The thing
is not, cannot occur just the thing cannot occur. And why we have that?
Because again we observe a system that is existing in our head, of course. We
observe the system and little by little we are going to make more and more
precision in this observation. So we are not interested in this approach. We are
not interested -- we will be eventually, of course, but we're not interested
primarily in the notion of precondition, but far more in the notion of guard.
Because, again, we are going to refine by making more and more features into
our system. Yeah?
>>: These events are executed electronically, right?
Jean-Raymond Abrial: Yeah.
>>: So the elite specification that we have right now about the consistency of the
events is being mirrored.
Jean-Raymond Abrial: Yes.
>>: Do you also have some notion of local invariants, or the invariant is
completely global, right.
Jean-Raymond Abrial: Yeah, completely global. Yeah, there is no notion.
>>: No notion of local invariant.
Jean-Raymond Abrial: No, sort of local thing is the guard. So you see it's written
here, when you prove something, you have all the invariant, the global golden
rule, plus the special thing concerning the event as an assumption and then
under this you prove the modified invariant.
>>: Right.
Jean-Raymond Abrial: Okay?
>>: I guess.
Jean-Raymond Abrial: So let me proceed. So here is the new proof obligation
and I added the guard according to my proof obligation. And now, of course, the
proof that is easy.
>>: Maybe I'm jumping ahead of the game but at some point we have to jump to
programming, right?
Jean-Raymond Abrial: Yes.
>>: Then we have to event the guard somehow.
Jean-Raymond Abrial: By click condition.
>>: I see, at that point we'll introduce the precondition.
Jean-Raymond Abrial: Yes.
>>: I see.
Jean-Raymond Abrial: Yes. We jump.
>>: Okay.
Jean-Raymond Abrial: And the requirement. It's possible for the system to be
blocked if all this [inaudible] falls. That means deadlock. We have to prove that
in our case that it is not the case, because we want that to be, we do not want
that to happen, and we, by the way, we are forgetting something. Once started
the system should work forever. There is no reason for the system to hold.
So you see also here the main thing we want to do is not just defining a program
that does something and give a result, it's a program that controls a situation.
And we do not want that program to stop.
So we add then four here. Once the system starts, it should run forever. So we
have to prove that indeed our system is deadlock-free. If we add no guard there
is no problem. But now we have guards. So it might be the case that in some
situation these guards are too strong, and the system becomes deadlocked.
So we have to prove the deadlock-freeness, and under the axiom and the
invariant, the disjunction of the guard is true.
And therefore if it's always true, then therefore the system is deadlock-free. And
it's really easy to do this. We have this. We have this invariant. So N smaller or
equal to D can be replaced by this so we have a prove by case. This case is
easy because we have this here. But when it's equal to D, we cannot prove it.
Okay. What happened?
>>: We need to -- have a lower bound on D.
Jean-Raymond Abrial: On D. On D.
>>: Greater than -Jean-Raymond Abrial: Because we have suggested that D is the natural
number. If D is 0, if D is 0 -- the system doesn't work. There is nothing
happening. So it's amazing -- it's amazing how when doing this you discover
little things where you've made mistakes. Okay. We have made the mistake of
defining the axiom for D, the limit, the upper limit of the number of cars on the
island and bridge and so we have to correct this. So we have to introduce
another axiom, which is four D, which for D it's positive.
Conclusion, we send to the proofs, we discovered three errors. We correct them
by adding some guards, adding in axioms, and here we see just like in this little
example the interaction between modeling and proving, you see. We go from
one to the other. We find out the problem. We go back to the model. We add
the guard. We go back to the proof that deadlock-free. We find the problem so
we add an axiom. So this back and forth is extremely important.
And the prover must be a tool which helps us doing this back and forth. Okay?
This is not a tool that proves [inaudible] theorem. This is very, usually very
simple and very pedestrian theorems, but they help us doing this debugging of
construction of the model.
So we define proof obligation. I've not defined this one, but it's very trivial. You
can see it in the text. The invariant preservation and the deadlock-freeness, and
this is the form of the proof obligation, which are again the basic ingredient, basic
elements of the proof obligation generator, I recall you as I've said already.
The system, the platform ingests the definition of the model, if it's correct,
syntactically, pass it to the proof obligation generator, the proof obligation
generator generate all the proof obligation and pass it to the prover.
And yourself you are sitting but it goes so fast for system like this that either you
get an error or the prover says I can't prove and you have to scratch your head
and say there was an error somewhere, I have to modify it, go back to the model
and go back then to the proof.
There's the [inaudible] of the system is just this. And the two axioms, the two
invariant, the two events, and the initialization, there is no cars anywhere.
So first refinement. So we have solved the problem of limiting the number of
cars, but this was in a very abstract situation when there was no bridge between
the two. So now we are going to introduce a bridge.
And the fact that it is a one-way bridge. We can find completely not the
program -- we will find the entire situation, because the bridge is not part of the
software. The bridge is part of the global situation.
So we are not introducing the sensors or the traffic lights, but we are introducing
now just a bridge. So this sort of paradigm is that we were very high in the sky
and now we go down with our parachute and we see more things.
Our view of the system is more accurate. We see the bridge separating the
mainland from the island. And we refine the state and we refine the events.
And we are going to add new events to the two we have. ML in and ML out. And
I told you last time that refinement is not only adding things to the state, but also
cutting the time at which we observe our system. Now we can observe our
system more accurately, and therefore we will introduce new events which can
modify things also.
So this is a situation. We have ML out for cars going out from the island -- from
the mainland. But now they go to the bridge, not directly onto the [inaudible]
because we have separated the two. And then when the car arrives here, we
have IL in, coming to the island. IL out, and ML in. So in red the emphasized
ones are the new ones. So we are going to also discuss the status of these new
events and also the status of the old event that we refine.
Okay? So let's go -- and now we are going to introduce a new state. So we are
going to introduce three value, A, B, and C. A is the number of cars to bridge
going from the mainland to the island. B is the number of cars on the bridge -- on
the island, and C the number of cars on the bridge going from the island to the
mainland, A, B and C.
And, of course, we have to relate A, B and C with N, the abstract thing we have
before, so we have a so-called gluing invariant, we are going to glue the concrete
state A, B, C with the abstract state N and we also have to take account of the
fact that the bridge is one-way.
So A, B, C are natural numbers.
>>: I thought N was the number of cars on the mainland. Oh it was outside
mainland.
Jean-Raymond Abrial: N is ->>: Okay.
Jean-Raymond Abrial: So here is the connection. A plus B plus C is equal to N.
And N is not a variable anymore of this refinement. It's a variable of the previous,
of the abstraction. But in the invariant we have the right to mention this and
precisely this is the connection. And we used to call it the gluing invariant. We
glue the concrete to the abstract. And here it's a one way bridge, A0 or C0.
They cannot be positive together. And that's it. This is the new -- this is the new
system. So here, again, invariant -- this invariant are the concrete invariant, and
this invariant is, again this is the gluing invariant between the abstract value N,
abstract variable N and the concrete variable A, B and C.
And now we have to propose some new things for the event that existed in the
abstraction. ML out. And here we propose this. When A plus -- when C is 0, if C
is not 0, we cannot go, because of the one-way of the bridge. And A plus B plus
C is smaller than D. So then we can enter, because we have not reached the
maximum, and then A, A plus 1, we just add one car here.
>>: So why were we able to read the previous updates to N and the previous car
on N.
Jean-Raymond Abrial: I'm going to explain that. And we have the same thing for
ML in if C is positive. So there are some cars here. Then C becomes C minus 1.
And of course the question you ask, you could also ask it here.
By the way, the before/after predicate now we have several variables. So the
before/after predicate, for example, for this is A prime is A plus 1 but we have to
incorporate B prime is B and C prime is C. But this is done behind the curtain,
behind the proof obligation generator that does this and the same thing here we
do that. So this is convenient to have this writing here because it's not necessary
to say when something is not mentioned it's like in programming, it is not
modified.
Intuition about refinement. So we come to your question. The complete model
behaves as specified by the abstract model. So the concrete model doesn't
exhibit any new behavior. Okay. It's a correct simulation. And to show this we
have to prove that every concrete event is simulated by its abstract counterpart.
I will define this.
And we have also the same sort of thing for the initial statement, for the initial
case. And we make these two conditions more precise in again as proof
obligation.
So let me here show precisely next to each other the abstractive ML out and the
concrete event ML out. So let's have sort of an intuition.
So here when A plus B is smaller than D C is 0, is it a case that we have N
smaller than D? Yes, because A plus B plus C is equal to N. So A plus B plus 0
is smaller than these, so we are happy here because this guard implies this
guard.
So it means that when this is true, when this event can occur, this was also the
case for the abstraction. And here, rather than having N, N plus 1 as in the
abstraction, we have A, A plus 1. And B and C are kept 0. So therefore,
because A plus B plus C is equal to N, clearly when we do this, that corresponds
to this. Yes, question?
>>: This can be, if N is equal to A plus B plus C you just assumed it, what's the
justification for it?
Jean-Raymond Abrial: The justification -- let me go back here. Here. Okay.
Before in the abstraction, we had N, which was on the so-called compound island
bridge. N was the number of cars in this. And now we cut N into pieces.
The cars that are here going here, the cars that are going here and here and the
cars that are here.
So the justification is that we have a situation where we have resumed we have a
situation which is more precise. We have A, B and C, but it must correspond to
the abstraction. So therefore certainly A plus B plus C is equal to N. I'm not
convincing you?
>>: No, I think there's a missing step. There must be a case where right after
you -- there must be a place where the program, there's just a program that
contains both M&A and B and C and the events are obtaining all these variables
and then you must have to show that N is equal to A plus B and C is maintained.
Jean-Raymond Abrial: Yeah, you could have that. But this is precisely the
refinement. It's not needed to have A, B and C and N together.
We can have -- we have N in the abstraction and A and B and C, and I will show
you in a minute the diagram that explains what refinement does.
So postpone a bit if you have any more problem, I will come to this.
>>: So just one more question. So you mentioned in the abstract and relation
that the enabling of the action is not changed by it going to A plus B, plus C,
right? But before you said we are allowed to strengthen guards.
Jean-Raymond Abrial: Yes.
>>: Cannot do both at the same time or is there some source of -Jean-Raymond Abrial: No, no, you can do -- I was not completely correct. You
can strengthen the guard -- the only thing you have to prove is that the concrete
guard implies the abstract one. Okay? So you have strengthened the guard.
But we will see that might pose some problem, we'll come back in a minute on
those problem.
But before I have to go here, to his problem. So here this is the diagram. We
have a concrete event. We have an abstract event. So this in our case the
abstract event was working with N, and the concrete event is working with A, B
and C and here we have the gluing invariant.
So the intuition of the refinement is that we -- it's exactly what you say. We
suppose that together the abstract and the concrete event are working together,
that the N and the ABC are on the same box. Okay. And what we have to prove
is that the gluing N equals A plus B plus C is maintained by these two people
going together are here.
>>: Okay. Now I see.
Jean-Raymond Abrial: Now you see?
>>: Yes.
Jean-Raymond Abrial: Fine. We will go back to the strengthening.
So the proof obligation of guard strengthening, guard strengthening is just this,
the axioms, abstract invariant, concrete invariant. So we have the concrete and
the abstract. The concrete guard and then the goal is to prove the abstract
guard.
So the concrete guard are stronger than the abstract guard. Now, there is a big
problem. They could be so strong that they could be false. Okay. And in this
case we have a deadlock in the concrete world.
Okay. So we have to do something about that in a minute. So we can prove
this. And then we can prove this. So we start to -- of course, in the more
detailed slides, this is proof and in the text that you have the possibility to read
everything is proof.
And we have the initialization, of course, they're all initialized to 0. And we have
a concrete, another proof obligation for initialization. I just go a little fast here.
And, ha, now we're going to add new events.
So new events is IL in and IL out. So we were dealing with ML in, ML out, the old
events, and now we have these new events. So what is the status of the new
events? What do they represent?
They represent the fact that we, from the abstraction, we see more things.
Therefore, there are more things that move, we have more transition now.
So we have to be extremely careful about ->>: I think I missed something. So we said we have to prove that the guard is
stronger than the abstract, correct? Did we say anything about the invariant? It
also just the abstraction invariant still hold after the step? Or is the N equals A,
plus B plus C.
>>: That was the refinement he was talking about.
>>: [inaudible].
Jean-Raymond Abrial: The goal ->>: Didn't have a separate slide on that?
Jean-Raymond Abrial: So are there new events. So new events are transition -they have no abstract counterpart. They are kind of internal steps with respect to
the abstract models they exist in reality, but they were not being able to be seen
in the abstract one.
And now the observer can see them by zooming. And we have a temporal
refinement, because now rather than having two transitions we'll have four
transitions so the system is a little more complicated.
So we have to see what we are going to prove for the new event. So let me just
show this event IL in. If A is positive, then A becomes A minus one and B, B plus
1 so the car moves from the bridge to the island.
And similarly, this one is when B is positive and A is 0. So there is no car coming
from the mainland to the island, then B, B minus one and C, C plus 1.
Okay. And yes here we have several actions. So the before/after predicate is
just this too.
So the idea of refinement, so this new event they refine something. They refine
something. What they refine is precisely some sort of implicit event that do
nothing. Because in the abstraction, it didn't exist.
So there was no change in the abstract variable by these events. And when we
make the refinement, we enter into the concrete state. So these events, this new
event, they should refine skip.
They should refine something that did nothing in the abstraction. So this is -- and
the guard strengthening is very obvious because skip, which is here, the
before/after predicate, has no guard. So there is no problem. And we are just to
prove the invariant.
So the refinement -- so the proof obligation for the new events -- so guard
strengthening is trivial. We need to prove invariant refinement but the new
invariant should not diverge you see when we introduce a new event we might
have funny pathology because these new events could take control forever never
allowing the old event to prove one coming from the abstraction to be file. So we
have to be sure that it is not possible for the new event to go forever.
So we have to prove that they somehow, if we stop the possibility of the new, of
the old event to be enabled, that the new event goes to deadlock. They cannot
go forever.
Okay. So for this we have to exhibit a variant, which is a natural number, or
anything more complex well funded thing and that each new event decreases
variant. And the variant is the same for all the population of the new event.
Because you know if -- otherwise they could play Ping-Pong. And we want to be
sure that the entire population of new events, they decrease this variant so that
eventually the old events could be executed.
Okay. And it's exactly what we need. The new events are some sort of
extension that were not possible to see in the abstraction and we want -- we
accept that this exists in the concrete. But, of course, they have to be polite and
they have to not to diverge. So this is the first pathology. The new events
diverge. And we will see later on another pathology. So we have to prove more
things.
So we have to define variant, which is a natural number. And we have to prove
that the variant is systematically decreased by some new events. So in that case
the variant is 2 A plus B and it is easy to prove that the variants are indeed
natural number and they are decreased.
And now we have to prove something important, which is notion of relative
deadlock freeness. And that corresponds to -- that corresponds to the second
pathology, which could happen. There is no new deadlock in the concrete model
that is all deadlock of the concrete model are already present in the abstract
model.
Okay. Which means that what we have introduced, because we have
strengthened the guard precisely, we have not strengthened so much that we
block the system in the concrete, whereas it was not blocked in the abstract. We
have to have the same behavior, global behavior of the system.
So it's called relative deadlock freeness because it might be possible -- it's not
the case here -- but it might be possible that in some occasion the abstraction
deadlocks, finish. Maybe there are some infinite paths but also some paths that
finish, and what we have to prove is that the concrete does exactly the same
thing.
So it does not deadlock more than the abstract.
>>: The abstraction is deadlock free, we checked that.
Jean-Raymond Abrial: We checked that.
>>: We know there are no deadlocks there. So when we refine we can just make
sure there are no deadlocks in the new system right.
Jean-Raymond Abrial: Absolutely.
>>: Relative deadlock now?
Jean-Raymond Abrial: Because I'll say something more general. In the present
case we have no deadlock in the abstraction but it might be in some other
system we might have some deadlock in abstraction.
>>: It may be desirable to have deadlock.
Jean-Raymond Abrial: Yes, if we have deadlock in the abstraction, then this is
relative deadlock freeness. Okay? And so what we have to prove is this, and I
agree with you that in our case, the concrete guards, the abstract guard are true
already. So there is no need for this one. Okay. So this is what we have to
prove, that essentially the junction of the abstract guard implies disjunction of the
concrete guard.
Now, what is interesting with this is that you remember guard strengthening,
guard strengthening was working the other way around. Concrete guard was
more -- was stronger than an abstract one, and here we are going the other way
around.
So in fact we describe this relative deadlock freeness, we describe the limit of our
strengthening. Because we could have strengthened the thing so much that we
put the false guard. But it is not allowed because if we have this, we have no
relative deadlock freeness.
>>: So this allows you, for example, to take an abstract event and refine it so that
the new concrete event is only enabled like half the time, you add another event
separately, which I guess is sort of what you did in the bridge, that sort of takes
over for the other half.
Jean-Raymond Abrial: Of course.
>>: And you get -Jean-Raymond Abrial: Of course, of course. Of course.
>>: It was not done in the case of the bridge, but is general.
Jean-Raymond Abrial: Yeah, yeah.
>>: But you couldn't --
Jean-Raymond Abrial: Yeah, and another possibility is here I've refined each
event by an event, but it's also possible to refine an event with two or three or
more. And then distribute the guard precisely exactly what you say.
>>: How do you introduce sequencing among [inaudible].
Jean-Raymond Abrial: Not now.
>>: Okay.
Jean-Raymond Abrial: Not now.
>>: One thing at a time.
Jean-Raymond Abrial: One thing at a time. But I can tell you a few things about
this. I have not introduced loop. I've not introduced semicolon. I've not
introduced if then else. But if I have time I will develop the way sequential
program loop if then else and things like this are defined. So how could we go
from a bunch of events to a program with this? Okay. That's the question.
>>: Yes, actually, that is the question.
Jean-Raymond Abrial: Yeah. Not now. Not now. A bit later. Okay.
Wait. So this is relative deadlock freeness here. So we -- yeah, disjunction of
the abstract guard, disjunction of the concrete guard. So it is not very difficult
to -- it's a bit boring because we have a goal with many disjunctions, but it's
doable by a decent prover. So we have proved everything. So summary of the
refinement for all events strengthening of the guard concrete invariant
preservation. For new events, refining implicit event skip, absence of
divergence, and for all events deadlock freeness. So we have now a bunch of
proof obligation. Again, they are part of the proof obligation generator, and the
proof obligation generator generates automatically all these things. And here is a
summary of the proof obligations.
So the state of the first refinement is just as you see. You recognize A, B, C, the
gluing invariant. The invariant about the fact that the bridge is one way only.
The variant. And the constant D and the A, B, C. And I've not copied here the
axioms for D, because they are implicit.
And here are the events of the first refinement. So we have the old events and
here the new events. Okay. And now we can go and we have some proofs at
the end, when is the end, by the way? It's now?
>>: Now. [laughter].
Jean-Raymond Abrial: Okay. So we stop -- we should stop now.
>> Rustan Leino: So we were going to continue next week with we think it's
going to be Tuesday and Friday. And we'll pick up right here.
Jean-Raymond Abrial: Yes. Okay. Thank you very much.
>> Rustan Leino: Thank you.
[applause]