Specification of Reactive Hardware/Software Systems - Electronic ...

326 Behaviour-Preserving Transformations
cluster class ElevatorMotorControlModule shaftNr
¡ ¡
shaftNr)§ OWS¡ ecem© OverweightSensor(¡ ecos ¢
communication channels osos emem ecem
message interface
behaviour specification
ElevatorMotorImage(¡ EMI¡ shaftNr)§ ecem© mhmi
Behaviour specification (OverweightSensor (¡ OWS¡ ¡ 0¡ ) § ecem© ecos ¢ ElevatorMotorImage
(¡ EMI¡ ¡ 0¡ ) § ecem© mhmi ) § emem0© emem¥ osos0© osos is now transformed
into ElevatorMotorControlModule (¡ 0¡ ) § emem0© emem¥ osos0© osos . The remaining instances
are clustered in an analogous way.
Here we end our sequence of transformations. Notice that we required each of the basic
behaviour-preserving transformations defined in Section 10.4. An Instance Structure
Diagram of the transformed elevator specification is presented in Figure 10.4. Observe
that its structure precisely matches that of the Architecture Structure Diagram of Figure
10.2.
The careful reader may have noticed that the performed modification of the initial elevator
specification is really a trivial one. Since the initial specification does not have
any observable communication channels, it can never perform observable communication
actions. Therefore any specification that is incapable of performing observable
communication actions is transformation equivalent to it! The problem is that in a strict
sense the elevator is wrongly modelled as a completely closed system. In reality, an
elevator system is not closed at all. For example, it is externally observable whether a
pair of elevator Doors (see Figure 10.1) is open or closed. It is also observable whether an
AudibleAlarm is ringing or not. Observations such as these can be modelled by messages
that are exchangable (with an external observer) through externally observable channels
5 . The sequence of transformations on the initial elevator specification is still valid if
this specification is extended with observable channels and messages. The resulting
modification of the initial elevator specification has then become far from trivial.
10.6 The Transformations as a Proof System: Soundness
and Completeness
In Subsection 9.5.5 we have defined transformation equivalence in terms of weak bisimulations.
Weak bisimulations provide a simple and elegant technique for proving POOSL
specifications transformation equivalent. An example of this was given in Section 9.6 in
which we proved the equivalence of a simple handshake protocol and a 1-place buffer.
Now that we have defined the system of 15 behaviour-preserving transformations in
Section 10.4 we have obtained another technique for proving transformation equivalence.
For system specifications SSpec1 and SSpec2 we let SSpec1 ¢
SSpec2 denote
¡
5 Modelling observations as communications is one of the key concepts of CCS [Mil80]. The idea is
that the only way to observe a system is to communicate with it.