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

9.7 The Development of POOSL 291
is a weak bisimulation. Since (conf p
1 ¥ conf p ¡ ¡ 1 ) , we have that £
¢
x¥ y¦ ¥ Sys
(Sender Receiver)
p ¢
Buffer¥ ¥ ¥ Sys
Sysp ¥ Sys , and thus the protocol is observation equivalent
to the 1-place buffer. Further, since conf p
1 ,conf p ¡ ¡ 1 SSpecifications we deduce from
Lemma 1, given in Appendix B, that Reset(conf p
1 ) = conf p
1 and Reset(conf p
2 ) = conf p
2 . Hence
Reset(conf p
1 ) ¢ Reset(conf p
2 ). From the definition of transformation equivalence it then
follows that the protocol and the 1-place buffer are transformation equivalent.
One would expect that a similar result could be proved if the protocol and the 1-place
buffer were able to receive and deliver arbitrary data objects instead of only primitive
data objects. However, it is not hard to find out that transformation equivalence and
observation equivalence are too strong for this to be true. Developing equivalence
relations that do establish the equivalence will be subject of future research.
9.7 The Development of POOSL
Each specification or design method is based upon a collection of method concepts.
The development of a supporting formal specification language consists of selecting
and combining appropriate language primitives. Together these primitives should
be expressive enough to represent the method concepts in a natural way. Further,
the combination of primitives should be consistent (the primitives should coexist in
harmony). More precise, there has to exist a consistent interpretation of the primitives.
Selecting language primitives that allow the natural representation of the method concepts
is a complex task. The major problem is that in general there exists no one-to-one
relation between concepts and primitives. It may take a number of primitives to express
a single concept. On the other hand, a single primitive may be required to express
different method concepts.
Making sure that the selected primitives can be consistently interpreted is probably even
more difficult. Primitives or combinations of them which seem to have an intuitive clear
meaning, may appear to be a lot trickier than expected. During the development of
POOSL we found out that difficulties or obscurities often show up only at the moment
one tries to describe the meaning of language primitives in very precise and detailed, that
is formal, way. To solve encountered difficulties, alternative semantic interpretations
or possible alternative language primitives have to be evaluated. A formal language
description is then of great help. It provides a deep understanding of encountered
problems and it aids in evaluating design alternatives in a systematic way.
During the development of POOSL, lots of design problems were encountered and a
large number of design decisions were taken. In Subsections 9.7.1–9.7.5 five of the more
interesting problems are studied.