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

2.4 Specification Languages, Formality and Tools 21
and Ada. Further SDL tools are available for checking some given dynamic properties
of SDL specification, so (b) is partially supported. Estelle [D 89] has facilities (a),(b)
(except for equivalence and preorder checking), (c) and (d). Translations to Pascal, ML
and C are supported. The Statemate environment [H 90] supports (a),(c) and (d). It
further checks for several dynamic properties such as reachability, non-determinism and
deadlock. Translations into Ada and C are supported.
These advantages do not exist in informal languages. Tools that support such languages
are often sophisticated graphical editors. Beyond testing for syntactic consistency and
completeness and producing various kinds of output reports, these tools give limited
support [H
90]. A few informal methods (for instance [Rob92, BW95, R
91]) have
restricted compilation or simulation capabilities. The informal method with the most
extensive tool support is ROOM [SGW94]. This method supports (a), (c) as well as (d).
This is no surprise since ROOM has a quite well defined semantics.
A specification method for complex systems must support the
development of advanced software tools.
The Use of Formal Techniques
It is fair to say that the use of the formal description techniques in industry is exceptional.
In our view there are two reasons for this problem. First of all, most formal
techniques today focus on the creation of a single formal system model and pay little or
no attention to the necessary informal views. We think that especially the early phases of
analysis and design are necessarily informal and should therefore be supported by appropriate
informal languages. Secondly, because of their declarative, property-oriented
[C
86] character, formal description languages tend to be hard to understand. This
especially holds for abstract data typing languages that are part of a number of current
formal techniques (such as LOTOS and SDL). In practice designers have difficulties in
describing systems in an imperative-free way [Nar87]. In our view formal specification
languages should have an imperative character, to make them understandable and
readable. Methods that satisfy this requirement are Statemate [H 90] and Estelle [D 89].
To make a specification understandable and readable, a formal
specification language should have an imperative nature.
Overspecification
In our view the difficulty to understand current formal languages is no inherent result
of formality. Rather, it is caused by the strong avoidance of overspecification. One
tries to describe what a system does without describing how it is done. We feel that
the problem of overspecification is heavily overemphasised. We agree in principle that
the possible implementations should not be restricted by a specification. The ability of
designers to find an optimum solution in the huge space of possible solutions should
however not be overestimated. An imperative specification has an implementation bias,
though it should be interpreted as an example implementation that may be replaced by