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

10.7 On the Fundamental Limitations of Transformational Design 327
that SSpec1 can be transformed into SSpec2 by a finite sequence of behaviour-preserving
transformations6 . Such a finite sequence of transformations is called a proof of theorem
SSpec1 ¢
SSpec2. The system of transformations can thus be considered a proof system
¡
for proving transformation equivalence between system specifications7 . We know that
this system is sound in the sense that SSpec1 ¢
SSpec2 implies SSpec1 ¡ ¢
SSpec2 for ¡
all SSpec1 and SSpec2. In other words, the proof system can only produce true theorems.
But can all true theorems be produced by the proof system? Stated otherwise, is the
proof system complete? Does SSpec1 ¢
SSpec2 imply SSpec1 ¡ ¢
SSpec2 for all
¡
SSpec1 and SSpec2. Unfortunately, the answer to this question is negative. Although
the specifications of the handshake protocol and the 1-place buffer of Section 9.6 are
transformation equivalent, there exist no sequence of transformations that transforms
the former specification into the latter one8 . The problem of incompleteness is not simply
solved by adding more transformations to the proof system. Proposition 6 of Appendix
B states that the incompleteness result is fundamental; there just does not exist a sound
and complete proof system for transformation equivalence!
Of course we have constructed the system of transformations with a certain degree of
completeness in mind. The initial goal was to offer a complete system for the introduction,
modification and deletion of boundaries and channels in Instance Structure
Diagrams. Thus, the transformation of a 1-place buffer into a handshake protocol was
not part of this goal. Nevertheless, we found out that even this limited goal is not
attainable. More concrete, from Proposition 7 in Appendix B it follows that whatever
sound proof system we are using, there will always be transformations that are allowed
by 6 with uncomputable condition NoComChange but that can not be proved with the
chosen proof system 9 .
In a theoretical sense we have thus not been able to attain our initial goal. This is a
disappointing result. However, the initial goal could not be attained in the first place.
In a practical sense we feel that we have created a transformation system that is able
to tackle many complex real-life systems. The only practical shortcoming we have
discovered up till now is the absence of a computable predicate NoComChange¡ ¡ that
allows the application of 6 in (most descent) cases of weak distribution. The search for
such a predicate is still going on.
10.7 On the Fundamental Limitations of Transformational
Design
Transformational design [Cam89, Mid93, Pir92, Pav92, Bol92, Fea87, Par90] is a design
approach that starts from an initial abstract specification. From this abstract specification
an implementation model is derived by repeatedly applying behaviour-preserving
6 The congruence properties as stated in Proposition 4 may be applied too.
7 In this proof system we will only allow transformations with computable transformation conditions.
8 There does not exist a transformation that splits a single processes into two communicating ones.
9 Notice that the 6 with condition NoComChange is not allowed in any proof system.