22660
>> Rustan Leino: So welcome to the third in a series of lecture given by our
visitor Jean-Raymond Abrial. I mentioned -- I said a few words of introduction
last time also, just to recapitulate. He has worked on methods for top-down
refinement of software systems. And his contribution includes a SIMS like B,
event B and Rodin.
>> Jean-Raymond Abrial: Thank you very much. So as I told you last time, we
are going now to have another example, the mechanic price controller.
And we'll go into the notion of design patterns for formal development. And we
will see how this kind of patterns could be used in complex developments.
We'll see the pros and the cons of this. Now, more pros than cons. And then
we'll see a systematic development of an unbedded system.
So it's like the previous system, the car and a bridge, but it's a little more
complicated this time.
So the outline is, first of all, an informal presentation of the example. Then the
presentation of the design patterns. Then as you remember, this is very
important, we are going to write the requirement document, and then refinement
strategy. So this is absolutely systematic in all developments.
And then we'll do eventually our development, formal development of the model
using refinement and design pattern.
So the informal presentation of the example. So mechanic price controller, this is
adapted from a real system, and it's coming from an institution called INRST,
Institute Nationale Research Security [inaudible], it's a national institute in France
about the safety of work.
So these people study all sort of conditions by which works are not safe or are
safe. And a few years ago they were very afraid because lots of mechanical
devices are now controlled by computer.
And so they are afraid that some bugs or some problems arise from that. So
that's the reason why they study this price controller. And then I was in touch
with them and I was very pleased to study their system.
So mechanic price is a very simple device. You have a motor. Is there a pointer
there? Maybe this one? Oh, yeah. So you have a motor. And you have the rod
and you have a vertical slide. You have a tool and you have the part.
And so this engine turns like this, and then there is a clutch that makes the rod
connected to the motor or not connected to the motor.
And you have four buttons to start the motor. Stop the motor. Start the clutch or
engage the clutch. And disengage the clutch. So it's a very simple thing. It
looks very, very simple. But you will see that it will become more complicated.
So here is again the description, the vertical slide, with a tool like this lower
extremity, electrical rotating motor, a rod connecting the motor to the slide, this
was the one that was like this. Clutch engaging or disengaging the motor and
the rod. When the clutch is disengaged the, slides stops almost immediately.
Okay. So the basic commands I have said start motor. Stop motor. Engage the
clutch, or disengage the clutch. So you can push all these buttons.
And then the user can do changing the tool at the bottom of the vertical slide, put
a part to be treated on the bottom, under the slide, and remove the part. So this
is what the user is doing.
Okay. So here is a typical -- so the first schematic view is we have some
commands corresponding to the patterns. And we have the equipment. And the
typical user session is here. We have a -- we start the motor with button B-1.
We change the tool. We put a part, action two. So the blue are the user actions.
The red is what the system does.
Engage the clutch with button B-3 and the price now works. And then disengage
the clutch with button B-4, the price does not work. Then you can remove the
part with action three. And then you can repeat zero or more time steps zero to
six, so you can repeat these here you use the same tool but you change the part.
And at some point you decide to change the tool so you go back to here, change
the tool, and you look again. So this is a typical session for the user.
Okay. Clear? Fine. So now the problem is that there are some dangers. When
you change the tool, when you put the part or where you remove a part, if you
have not disengaged the clutch, then you hit your hand. And it is very -- it is very
well known that people using these kind of machines, they have some problems.
And this is the reason why this institute was afraid and wanted to do something
and see whether we can do something with a controller of this mechanism
governed by computer.
So the idea is to put a controller here in between the commands and the
equipment. And this is what we want to develop. But what we have done so far,
it's not enough. It's not enough to have a controller. What we have to have is
controlling the way the clutch is engaged or disengaged, because this is the very
moment where we engage, where the price goes up and down. And if you put
your hand you have a problem. And this is not enough. We need to have a sort
of front door so that when the system is working, you cannot -- you cannot put
your hand behind it. So we have an additional device, which is the front door,
which could be opened like this. And closed.
And, of course, we'll have some constraint when the system is working like this,
then the door must be closed, and when the system is not working, then the door
must be opened so that you can work under it.
So the front door behavior is this initially the door is open. When the user press
the button B-3 to engage the clutch, the door is first closed before engaging the
clutch really. And when the user press the button B-4 to disengage the clutch
then the door is open after disengaging the clutch. So we are absolutely certain.
Then there is no trouble for the user. And the door has no button. The door is in
fact controlled by engaging or disengaging the clutch.
Okay.
>>: And the door cannot hurt the user, right?
>> Jean-Raymond Abrial: Yeah.
>>: By closing.
>> Jean-Raymond Abrial: Yes, thank you very much. You can always -- you can
have a second door or something like that. You know that in a traumatic, in a
traumatic metro when you have no drivers you have two doors. You have a door
on the platform and you have the door of the train. Okay. And precisely for this
reason. But still there are some problems with ladies with a bag or things of that
sort. So, by the way, the most -- yeah, or people doing funny things.
And, by the way, the most difficult thing in a driverless train is opening and
closing the door. It's not driving the train. So the problem of doors, it's really a
big problem, yeah. Thank you.
Okay. So this is our system. We have the four buttons. And we have the motor
the clutch and the door, and they will receive some order from the controller, and
they send also by these wires, the motor, the clutch and the door, they send also
some information about the status back to the controller.
So let me give you a little demo. So we have this initial situation. Then we press
the button B-1 to start the engine. So we put -- we put the tool. And then, but
the thing doesn't work still. And then we continue. We put a part. Then we
continue.
And then we will at some point engage the clutch, so the door was closed. And
then this thing works until we press the button B-4 for disengaging the clutch.
And so that opens the door.
And we remove the part. We put a new part. We engage the clutch and then we
go again. And then we press a button B-4 to stop, to disengage the clutch. So
the motor is not stopped but we can open the door.
Then we remove the part. And then we remove the tool and then this is the final
situation. So you see this is a typical thing. So this is what we want to do. Okay.
It's simple. It's not very complicated. But there are some problems. So here is
another diagram showing the system. You have the controller. You have the
motor, with the two buttons, start/stop, and you have the motor or sorry the
button here, the motor, the door and the clutch. You have the motor actuator
which sends an order to the motor, the motor sensor, sending back the status of
the motor to the controller, the same for the door and the same for the clutch.
Okay? So now let's go to this notion of design patterns. So what is the idea
behind design patterns? Formal design patterns? The motivation is that we
might have in this system, but in many other systems, a number of similar
behaviors.
And we have some complex situations to handle. So the idea is to try to find out
whether within the similar behavior we can extract something which is the
essence of these behaviors and then repeat this in order to have a systematic
construction.
So, for example, here similar behavior. A specification action eventually having a
specific reaction, pushing button B 1 results eventually starting the motor.
Pushing button B-4 is eventually disengaging the clutch. So we have an action
pushing a button and we have a reaction, which is starting a motor or stopping
the motor or doing similar things with the clutch. So these are very, very similar.
We have the correlation between pieces of equipment. When the clutch is
engaged, then the motor must work. Okay. We do not want to engage the clutch
if the motor doesn't work, it's dangerous like this is the sort of thing you have only
automatic cars. So you have that in Europe there are lots of nonautomatic cars,
so you have to engage the clutch and it's dangerous to engage the clutch if the
motor is not turning, because then you start the motor, pllltt, all of a sudden your
car moves.
When the clutch is engaged and then the door must be closed. This is also the
correlation of pieces of equipment.
Making an action depending on another one. Engaging the clutch implies closing
the door first. Disengaging the clutch means opening the door afterwards.
So we have relationship between actions. Here is a complex situation. Let me
go into this. And just to show to you that it seems to be simple but it's more
complicated. The user pushed the button B-1 but the user keep its hand on the
button B-1. And then controller sends a starting command to the motor. The
motor starts and sends feedback to the controller. The controller is aware now
that the motor works.
The user pushed button B-2 to stop the motor. And the controller sends the stop
command to the motor. The motor stops and sends feedback to the controller.
The controller is aware that the motor does not work, but I still have my finger on
button B-1. Okay. And I don't want that the motor restart immediately. I have to
remove my finger and put it again. Okay. So this is something that shows that it
is not completely simple. Again, when I push the button, B-1 for starting the
motor, the motor starts, and then I do other things and I stop the motor with
another button, and I keep my finger, when the motor eventually stops, I have still
my finger again on this button B, when I don't want the motor to start
immediately, I want first to relieve my finger and then put it back.
>>: Why don't you want the motor to start again?
>> Jean-Raymond Abrial: Sorry?
>>: Why don't you want the motor, the motor to start again?
>> Jean-Raymond Abrial: Because I put my finger, or I put my hand, so that
might be a mistake. I don't want -- I want to have a specific action in order to
start.
>>: It's like the Toyota problem, when you press the gas and the brake at the
same time, they had accidents, because the ->>: So the brake went and ->> Jean-Raymond Abrial: That's exactly this, yes, thank you. So you see we
have to be careful. We do not want this to happen.
Another complex situation is this one. The user pushes a button B-1 for starting
the motor. The controller sends the starting command to the motor. The motor
starts and sends feedback to the controller. And the user pushes button B-2 to
stop the motor. Now, the problem is that this action 3-1 and 3-2 they're done in
their environment and they are done in parallel. And we don't know which one is
going to win first. If the controller treats 3-1 before 3-2, then the motor is
stopped. But if the controller treats 3-2 before 3-1 then the motor is not stopped.
So it depends on the raised conditions between these things.
Okay. So we want, again, we want again to control this and to know exactly what
we are doing. So design pattern. So the idea of design pattern is just this. We
want to be a system which is correct by construction. I hope you understand this.
I have hammered many, many times. And we want to have more method for
doing so. Last time I defined this car and a bridge system, and I started by
defining things, little by little, but now I want to have more method to be more
completely systematic.
And you will see that for a system like this, which looked like not too complicated,
it's very, very important, because if you do the formal approach or the formal
modeling as a kind of pseudo programming, this is not good.
We want to be completely sure. So design pattern as you know is an
object-oriented concept and we would like to borrow that concept for doing formal
development. So we will have a [inaudible] with reactive system developments,
and the advantage that the systematic development, and also which is also very
important and that doesn't exist for using design patterning in the case of OO.
We want to save proofs because we are going to have our design, some
patterns, and we have to have some proof of these patterns.
And because we are going to reuse this pattern many, many, many times, we will
not oblige to redo the proof because the proof has been done once and for all.
So we can keep the proof. Okay. So this is also another advantage. And at the
end you'll see how much we save.
So the personal view is that the design pattern is an engineering concept. It can
be used in a row, of course. And the role of a design pattern is to solve certain
categories of problems. But the design pattern should be adapted to the problem
at hand. So this is something that we have off the shelf and we have to adapt it.
And we ask the question is it compatible with formal development? So let's apply
it. But in fact what we can see here is that this approach is used in other
engineering disciplines. So the idea again and again is tried to borrow from other
engineering disciplines.
In Wikipedia if you take Wikipedia and you press design pattern, you will see that
this quotation are coming from Wikipedia. The design pattern is not a efficient
design, but can be designed transformed into code. It is a template for how to
solve the problem that can be used in many different situations. So it's a little
model that can be used in many different situations.
It has been originated by an architect and, of course, there's the famous book by
gamma and others for using design pattern in object oriented software
development.
More on the Wikipedia. Design pattern can speed up the development process
by providing tested and proven development paradigm and for us proven is very
important.
And the documentation for design pattern should contain enough information
about the problem that the pattern addresses. The context in which it is used,
and the suggested situations. So we are going to define very well our patterns.
And some feel that the need for pattern results from using computer with
insufficient abstraction. So you could, as you can imagine I was very pleased
when I saw that.
Okay. So here is our first design pattern. We have an action, which is this, for
example, is pushing a button.
And eventually after this we have a reaction. Okay. So it's also very simple.
This will be our first design pattern.
Okay. And immediately we see that there are two kind of action reaction design
patterns, there is one which are we call the weak reaction. This is typically what I
have in my toilet in France, when I turn on the lights then the fan starts. So I
have an action, turning the light, and then a fan.
But if I turn the light on and then pretty much off and then on and off, then the fan
doesn't move. This is exactly this one.
And the same way when the fan works and I turn the light off and then on, off, off,
on, off, et cetera, then the fan continue.
So this is something that you will encounter many, many times. And this is a
reaction and a reaction. The action in a strong reaction is one where the reaction
and the action are synchronized.
So we have the action here and after the action we have the reaction here and
the action can go down only when the reaction is up, okay? So we have a strong
synchronization.
And obviously this, the strong reaction pattern, is a refinement of the weak one.
So this is what we're going to study.
So we will build first a model for the weak reaction, and then the strong reaction
will be a refinement of it.
So let's do it. So we have two variables A and R, A for action and R for reaction.
And A is 01. R is 01. And so these are the variables, and these are the
invariants.
And then we introduce two things: CA and CR, the counter of R, A and R when
they are equal to 1. And the modeling of the weak reaction is exactly this that
CR is smaller than or equal to CA. Okay?
This is what models formalize the week reaction. So we have here defined just
the static part. So the dynamic part is now the following: For the action A on, the
action is off, and then it's on, and then we increment the counter. Here A off is
just doing this when we go down here.
And now the reaction, when R is 0 and A is 1, then we can have the reaction,
then we have the decrementation of this counter and then we have this when the
reaction goes down.
R is down. A is down. And R is up and then we go down. So this is really
simple. So now we have to prove that this is correct. So here are the four
events. And here is a sort of fuzzy diagram showing that we can do our on if we
have A on and if we have R off. So, for example, R on is here. It's when R is 0
and when A is 1.
So this is the connection we have between the values, and we can see here that
we can go back and forth here and we are not influenced by the reaction.
Okay. So now we have our complete system with initialization here. But, of
course, nothing guarantees that the invariants are preserved. And the invariant
is just this.
So let's do it and let me give you now a little demo about this.
Here I'm going to load the patterns. The weak one. So it's here. We see it. It's
exactly what we had on the slides. And let's go on the proofs. And we shall say
that one proof has not been done.
So let's go -- let's load this proof obligation here. Proving. And so you remember
we have the goal here. So we have to prove -- we have to prove this under this
hypothesis, which is the invariant and the two guards. And we can have a look at
exactly what is the situation by giving here. Here we have the event and we
have the invariant.
Okay. So clearly this is not possible to prove this. So what we have to have is
when R is 0 and A is 1, then CR should be strictly smaller than CA. Okay. And
that will prove the problem.
So let's do this. So we go back to the thing, and we add this invariant, which is ->>: It's not strong enough.
>> Jean-Raymond Abrial: Sorry?
>>: The invariant was not strong enough.
>> Jean-Raymond Abrial: The invariant was not strong enough, exactly. So
here we do this. We put this invariant here. Oops.
>>: [inaudible].
>> Jean-Raymond Abrial: Yeah, I did. Thank you. Okay. Let's do this. Okay.
And now we have the little star here. So we have to save. And have a look here.
So we save it. And that's it. Okay. So we have now solved this little problem.
And again this is very, very classical. You go into the proof. You figure out the
problem, and you transform your model.
So let's go now -- let's continue now and -- first of all, this is very important.
Once you have discovered something by doing the proof, it's nice to go back to
the problem. And here we see exactly what it means. R is 0 and A is 1. This is
exactly the situation. And then we have CR, which is certainly smaller than CA,
because we have incremented here CA.
Okay. So we understand really the problem. This is exactly like in mathematics,
when you solve a problem of geometry, for example, by doing some
computation, and then you go back to the geometric problem and you see
exactly the situation. So we have to do here -- we have to do the same sort of
thing.
Okay. So this is a summary of the weak reaction. And now, of course, we do not
need that anymore. This was just introduced in order to do the semantics of an
action and a weak reaction. So in the final model for this we can remove the
counters and this is our design pattern.
This is a pattern we put off the shelf and we are going to use it systemically for
building up the problem. So this is a weak synchronization. So let's go now to
the strong reaction.
So the strong reaction, again, is just that we cannot go down the -- the reaction
cannot go down if the action, if the reaction is not up.
So we have the following invariant. CA is smaller or equal to CR plus one. So if
we put this one and this one together, we have either CA or CR, which is here or
here or here. Or CA is just CA plus -- equal to CR plus one. So they just
alternate.
>>: Actually, I have a question from the previous slide. We remove the counter
side. And does the -- I mean, do you just go to the text and remove them, or do
you actually -- is this some sort of refinement step remove the counter?
>> Jean-Raymond Abrial: No, I just go in the text and remove them. I will not
need them in a problem. Because I have proved now that this has got the
property -- if you want to keep them, you could. Okay. But there are some kind
of ghost variable. They are not needed in the problem, because we were just
using them in order to prove that we had the action and reaction.
>>: Can't even state invariant now.
>> Jean-Raymond Abrial: You can even?
>>: You cannot state invariant anymore.
>> Jean-Raymond Abrial: No you cannot state the invariant anymore but we
have proved it.
>>: But we don't have any record of it.
>> Jean-Raymond Abrial: So if you want to keep it, you could keep it.
>>: I have another question about action/reaction, strong one. So the action
typically is a physical action. Right?
>> Jean-Raymond Abrial: Yes.
>>: You cannot prevent it from going back to 0 before the reaction has
happened, so it seems to me -- I don't understand why we're doing this.
>> Jean-Raymond Abrial: The strong one?
>>: Yes.
>> Jean-Raymond Abrial: You will see that in fact sometimes the action is done
by a computer.
>>: Right. But motivated by [inaudible].
>> Jean-Raymond Abrial: Yes. I'm motivated by -- you will see that in fact we
have a chain of action/reaction. When I push the button, then the computer
reacts. And the computer reacts in sending something to the motor. So we have
an action/reaction, that reaction is transformed into another action and it goes to
the motor.
So in that second case, the action is done by the computer. So we can
completely control it. You will see in a minute ->>: It's also the button press will have a weak reaction, but the motor control
commands will have a strong reaction?
>> Jean-Raymond Abrial: Yes, you got it. Okay. So we keep for the moment
the events like this, and we arrive at this. So nothing guarantees that the
invariant is preserved. And, again, we'll have some little problem that we can
see.
So what I'm going to do now is to remove this, remove this. And remove this.
Loads this one. Okay. So this is the strong where I have not -- I have not
modified at all nothing -- I have nothing modified for the moment. So let's have a
look at the proofs. There are not many proofs, but there is just one that fails,
which is A on path 1-1. So let me go this here. See what happens.
So here I have the hypothesis is CA smaller than CF plus 1, and the goal is C
equals CR. So, of course, I cannot prove, I cannot prove this from this. And so
the idea, the simplest idea, which is quite often the case, you add the invariant
that is missing. So you add when A is 0, you add that CA is equal to CR.
So let's do this. So we go to edit this time. We add this invariant, which is here.
Okay. And now I save. The situation is not so nice. We solve this problem. But
we find out another problem, of course, for this event. So let's go there.
>>: When you saved, you got a couple new proofs in there.
>> Jean-Raymond Abrial: Oh, yeah, yeah.
>>: So what does the specific show? Does it only show the proofs that were ->> Jean-Raymond Abrial: It shows -- when your proof has been done
automatically, and it is not redrawing some proof which were not impacted by the
modification. And then he figure out he cannot do this one automatically.
>>: But this one wasn't even there before.
>> Jean-Raymond Abrial: No, of course. It was not before because we have
added an invariant. And if we add an invariant, we have to prove it. That's the
price to pay. When you -- you have two solutions when you have a problem.
You can change action or change guard. Or, and we will see that later, or you
can modify the invariant. If you modify the invariant, then -- sorry, if you add an
invariant, then you have to prove it. Okay?
>>: That's true.
>> Jean-Raymond Abrial: So here we have -- so here we have this thing A-1
and CA is equal to CR. It seems that we are tempted to add A-1 implies CA
equal to CR, but we are a refinement of weak. And in weak let me go back to
weak here. And in weak we had already this invariant when A is equal to 1, then
CR is smaller than CA.
Okay. So we cannot do this. So we will do A-1 and R-1. Then CA is equal to
CR. So this is the one we are going to add here. So we do this. Okay. And
now we save. Now we have exactly the same problem as before. But we will
solve the problem, this problem here but we will have some other invariant to
prove. So let's do this. So you see here we have more things. But we still have
some problem here for A on and A off. So let's go there. So, again, this is the
typical work. So we go there. And -- that happens sometimes.
I'm sorry. I don't know what happens these days, but sometimes I have to reload
it. I need to complain to the people. Okay. So I was here, event B. Here we
are. So we are in this situation here where we have to prove this and we have
this hypothesis. So clearly it is not possible. So we should have something
which is the fact that the assumptions are contradictory.
Okay. And we have A 0 and R1. So it is very, very tempting here to put, as a
new guard, this time, in order to get the contradiction that A is equal to 1.
So let's do this. So we go on to back here. And we go on to A on events. A on.
And here we add -- no, this was not A on. This was A off.
>>: Looked at A on.
>> Jean-Raymond Abrial: Sorry?
>>: We looked at A on.
>> Jean-Raymond Abrial: So this is this one then. Right. And so now we do the
same. Here -- so we do -- we save. So this problem is solved. And now we
have to go to this one, and this is the situation is the same, is the same here. We
have to add R-1 for the very good reason that in, that in the invariant, we have
exactly what we need in the invariant. We have this. When A-1 is 1 and R is 1
then CA CR. We are tempted to do this to go on the second one here.
And to add R equals to 1 as an additional guard. So we'll do this. Okay. And
now we go to saving. And that's it. So you see what we have done, we have
either added some invariant or we have strengthened the guard. And now let's
go back to the slides. So we have added this. And what is nice here is that
these two can be put together because we have the same right on part of the
implications so we can take the disjunction of these two, and as A is 0 or 1, that
gives us this.
And now we have -- this was coming from the abstraction, and this is a new one
we have here. And so we can even further simplify by saying when A is 1 and R
is 0, then CA is CR plus 1, because this is one or the other. And when A is 0 and
R is 1, or R is 1, then we have CA is equal to CR.
So this is the final thing we get. And now we can go back to the problem and see
what it means. And it means exactly what we have here. In this portion here,
A-1 and A-1 and R 0 we have CACR plus 1 and in these two portions either A 0
or R is 1, we have CACR in both cases.
So of course we could have found this from the beginning. But we have help by
the computer to do this. And so what you see here is that the two conditions
here are just, are complementary to each other, because we have an N
transforming to an O and here we change the value.
Okay. And so this is nice to see exactly what is the situation. Okay? And so
again the better I will remove the counter, and now this is the new situation
where I have now just added these two guards, which is quite normal, because
now you see the situation is completely symmetric between the actions and the
reaction. And we have now the strong synchronization like this. For example, to
do an A on, you should have done before, and A off, of course, and also an R off
so these things are synchronized, are synchronized in this way.
Right. So what have we learned? We have learned that proof failures help us in
proving our model. When an invariant preservation proof fails on an event, we
have two solutions. And we have seen the two solutions, adding a new invariant
or strengthening the guard. What we have done at the end was precisely this,
strengthening the guard.
And modeling consideration help us choosing one or the other. And at the end
we have reached a stable situation, which is kind of a fixed point, because what
we have, we have introduced new things which generate new problems and we
introduce more things to generate more problems until the moment where we
reach a situation where the thing is all right. Okay. Now, again and again we
could have done that directly. We could have, you know, parachute the invariant
directly. But it's better to have done it with the proof, because it is, again,
completely systematic. And each time we control what we're doing.
So now eventually we write requirement document and we'll come to your
suggestion. The system has got the following pieces of equipment, a motor, a
clutch and a door. Four buttons are used to start and stop the motor and engage
or disengage the clutch. And the controller is supposed to manage this
equipment.
And now we have the buttons and the controllers are weakly synchronized and
the controls and equipment are strongly synchronized. So we will have a chain
reaction between the two.
Now when the clutch is engaged the motor must work. And when the clutch is
engaged the door must be closed. So we have these two things. Safe one and
safe two. And moreover, we have the following additional functional requirement.
When the clutch is engaged, the door cannot be closed several times. When the
clutch is engaged the door is closed once and then we cannot reopen it while the
clutch is engaged. So only once. And the same when the door is closed, the
clutch cannot be disengaged several times, only once.
>>: So the [inaudible] kind of open the door while the clutch is engaged, previous
problem says that the door has to be closed when the clutch is engaged, wouldn't
that be right?
>> Jean-Raymond Abrial: Yeah, it's related, yeah. I agree with that. It's related.
But it doesn't matter to have some redundant requirements.
And then opening and closing the door are not independent. It must be
synchronized with disengaging and engaging the clutch. And again this is not
completely independent.
So here again is the situation we have. And now I'm going to finish in 5, ten
minutes. So we are proposing refinement strategy. So the refinement strategy
we're going to propose is the following. We want to refine this. So we are not
going to start with the entire system at once. So the idea is to have an empty
controller at the beginning and then plug the motor. And then plug the buttons
and then connect the controller to the clutch and then constrain the clutch and
the motor. So little by little I'm building the system.
Connecting the controller to the door, constraining the clutch and the door. More
constrained between the clutch and the door, precisely where we will see them.
And then eventually connecting the clutch button to the controller.
So you see we are just plugging things, and each time, each time in each of
these processes we are going to use and define more design pattern. So that
there will be no invention in the construction. We are plugging and using the
values design pattern. So let me just show you the usage of the first button.
So we have -- we start this one. We start with a strong connection between the
controller, and now this is a strong -- where the action is here. And the motor.
Controller and equipment. Controller and equipment. This is a piece of
equipment, are strongly synchronized.
So let's take off the shelf our strong, our strong design pattern. And you'll
remember what we've seen in Wikipedia. This is a partial thing. So this is not
connected to the real problem. This is just a general design pattern. So what we
have to do now is to start defining the problem at hand. So we have status for
the motor. It is either stopped or working. So we just define this. And then we
have two variables, which is the motor sensor and the motor actuator, and they
are both static.
So here is the action. The motor actuator, there is a command going from the
controller to the motor. Then the motor reacts. It starts, and it sends a reaction
to, a strong reaction to the controller.
So what we are going to do is very simple and very systematic. We are going to
repaint the pattern. So AR 0 and 1 are repainted as motor actuator, motor
sensor stopped and working and the various action of the pattern are repaint to
treat start motor, treat stop motor, motor start and motor stop.
These are into the equipment and this is inside the controller and after taking the
conventions of all events inside the controller start with treat. This is written here.
So we do this painting. This is very systematic. We could do this with anything.
And then here it is in it of the design pattern and then in it of the first model. And
then we repaint what we have seen here A on treat start motor it's exactly this
with a new painting.
And the same here with a new painting. I could have at this point, I could add at
this point that the value counters, but we know that this works correctly. And the
same for A on and the same for R off. So we have -- so you remember this
diagram here. So now we have this diagram here for the first synchronization
between the controller and the motor.
We have two events in the environment. Motor start, motor stop. And we have
two events within the controller, which are just this one. Okay. So now the first
refinement. We are going to connect motor button. So these two here with the
controller. And we are going to take account of this functionality, that the buttons
and the controller are weakly synchronized. Okay. So we'll stop here and we'll
do that next time. But you will see here the most important thing that we will
have is that we will have a chain of action/reaction. We have an action pushing
the button, pushing the button goes into the controller. And the way the
controller reacts is precisely to send the order to the command to the motor.
Okay. So we will see this and we will see how we can compose two design
patterns, a weak one here on top and a strong one here on the right. Okay. So
we'll do that next time. Monday. So on Monday we'll finish this construction of
the price, and if I have enough time I will start then something totally different, the
definition of sequential program using event B. And maybe the week after, if you
are still willing to come, I could develop something also completely different
which will be the development of electronic circuits using event B, which is
another story also completely different. Okay. Thank you very much.
[applause]