23.08.2013 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

322 Behaviour-Preserving Transformations<br />

One AudibleAlarmImage, one DoorsImage and one ElevatorPassengerImage is<br />

mapped onto each ElevatorCageControlModule.<br />

All ElevatorMechanismHandlers, all IndividualElevators and the CentralControl instance<br />

are mapped onto the ElevatorsControlModule.<br />

One FloorPassengerImage is mapped onto each FloorPassengerInterfaceModule.<br />

The modification <strong>of</strong> the initial POOSL specification presented in Figure 10.1 requires a<br />

large sequence <strong>of</strong> successive applications <strong>of</strong> basic behaviour-preserving transformations.<br />

In this chapter we will only present a global sketch <strong>of</strong> this sequence and show the result<br />

<strong>of</strong> its application in graphical form. In [Voe] the transformation sequence is described<br />

in more detail. [Voe] further presents a complete initial elevator specification as well<br />

as a complete transformed elevator specification. An Instance Structure Diagram <strong>of</strong> the<br />

transformed elevator specification is shown in Figure 10.4.<br />

The transformation sequence is explained in 12 steps. Each step uses one or more basic<br />

behaviour-preserving transformations defined in the previous chapter. Applications <strong>of</strong><br />

Proposition 4 (stating that ¢<br />

is a partial congruence) are not mentioned.<br />

¡<br />

¢<br />

1. First transformation 13 is applied to replace the ElevatorControlSystem cluster<br />

by its constituents. The remaining behaviour specification is then <strong>of</strong> the form<br />

K)) L), where BSpec1 contains the terminator instances and<br />

(BSpec1 (BSpec2<br />

where BSpec2 K is the behaviour specification <strong>of</strong> the ElevatorControlSystem class.<br />

This class is eliminated from the system <strong>of</strong> process and cluster classes by applying<br />

12.<br />

¢<br />

¢<br />

¢<br />

¢ ¦<br />

2. Since BSpec1 does not contain any channels that are in K, (BSpec1 (BSpec2 K)) L)<br />

can be transformed into ((BSpec1 K) (BSpec2 K)) L) by 7. Since BSpec1<br />

and BSpec2 do not communicate over channels in L, 11 can be applied to yield<br />

(BSpec1 BSpec2) K L. The two successive channel hidings are combined by 8.<br />

We then obtain (BSpec1 BSpec2) K L.<br />

¢ ¦<br />

¢ ElevatorMechanism(¡ 0¡ )§ ¢ ¦<br />

3. By repeatedly applying 2 and 3, (BSpec1 BSpec2) K L can be transformed<br />

into (BSpec1 f BSpec3) K L.<br />

ElevatorMechanism(¡ 0¡<br />

¢ ((AAI(¡ AAI¡ ¡<br />

¢ DI(¡ DI¡ ¡ 0¡ ¢ EMH(¡ EMH¡ ¡ 0¡ ¢ EMI(¡ EMI¡ ¡ 0¡ M)§ f ¢ BSpec3) ¦ 0¡<br />

4. Using transformation 13, cluster ) is replaced by its internals.<br />

We will use obvious abbreviations for their names: (BSpec1<br />

) ) ) ))<br />

K L<br />

5. Transformations 10 and 6 (with condition NoComChange¡ ) are applied to give<br />

the internal channels <strong>of</strong> the former ElevatorMechanism(¡ 0¡ ) cluster new and fresh<br />

names. The applied channel renaming function is g. (BSpec1 ¢ ((AAI(¡ AAI¡ ¡ 0¡ )§ g ¢<br />

DI(¡ DI¡ ¡ 0¡ )§ g ¢ EMH(¡ EMH¡ ¡ 0¡ )§ g ¢ EMI(¡ EMI¡ ¡ 0¡ )§ g )<br />

g(M))§ f ¢ BSpec3)<br />

K¦ L

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!