Problems of visual specification languages
E. Tyugu, A. Saabas
Institute of Cybernetics, Akadeemia tee 21, 12618 Tallinn, Estonia.
tyugu@ieee.org, ando@cs.ioc.ee
Abstract. There is a well-known conflict between the expressiveness and implementability (e.g.
compilation into a program form) of specification languages. This is a reason why numerous
software specification languages have no implementation, or have only partial implementation.
We consider a restricted class of visual languages that can be implemented efficiently by
constructing a compiler from a specification language into executable code. These languages
support object oriented software design and are extendable in a way that enables one to develop
problem-oriented specification languages, first of all, for various engineering domains and
simulation problems.
1. Introduction
The intentions of designers of specification languages have changed during the years: from
requiring maximal formality of symbolic specifications in early years of automated design to
striving to maximal user-friendliness of visual specifications at present. One can say that
requirements to specification languages at least in design area have been reversed: instead of
attempting to encode graphical representations in formal symbolic way we are inventing methods
and tools to express the meaning of specifications visually. This is true both for hardware and
software design. Plethora of visual specification languages exists, but only very few of them have
gained popularity in applications. In software engineering, the UML language has become a
standard. But there is a gap between the universality of UML and expressiveness of problemoriented specification languages (e.g. simulation languages).
2. Requirements
What we desire from a good specification language first of all is its precise semantics. But what
we mean by semantics? The authors of UML have claimed from the very beginning that it has a
precise semantics, meaning by this mostly that they understand precisely its notations. Even in
hardware design, one obtains precise semantics easily on the logical level, but gets into difficulties
on physical level. One should agree on the semantic language, i.e. on how the meaning of a
specification can be represented. Our proposition is that we leave open the semantic language, but
we shall require that everything that is considered as a meaning of a specification must be
representable in the semantic language, and it must be a formal language. (We strongly prefer
logical languages.) Another requirement is the implementability of a specification language – we
are not interested in languages we cannot use in practice for automated software or hardware
development. And finally, we are interested in an expressive language, one can say – as expressive
as possible. There is a well-known conflict between the expressiveness and implementability (e.g.
compilation into a program form) of specification languages. This is a reason why numerous
specification languages have no implementation, or have only partial implementation. The most
popular software specification language UML is not an exception – many of its features are quite
difficult to implement. But UML is still not sufficiently expressive for software practice of today.
It can not specify: system-actor interaction, rich context, use case structure and decomposition, use
case interaction, system state (persistency), information flow through the entire system, see [1].
3. Expressiveness versus efficiency
Here lies the most common pitfall of the language design – it is tempting to develop as expressive
language as possible, but this prevents its efficient implementation. One can restrict the
expressiveness in two different ways: by restricting the application area, i.e. developing narrowly
problem oriented languages, or by restricting the meaning of used concepts. The first is well used,
e.g. in simulation – we know excellent simulation languages. The second may lead to difficulties
in usage of the language. Specifications may become long and low-level, or even some important
features may be not expressible in a language.
Here we have the question: what is reasonable to expect to express visually? We have seen in
decades, and still see research in so called visual programming languages that attempt to encode
loops, if-statements, etc. in graphical form, using various shapes of blocks. This is obviously not
the promising research. Visual representation in general is good for expressing structure,
relatedness (bindings) and types of entities. It is less suited for representing quantitative
information, although the usage of sliders covers these needs to some extent. It can be used to
represent geometric and geographic information, but only in domain-oriented applications.
4. Schemes
Let us restrict our attention now to languages of schemes, and show, how to find a balance
between expressiveness and efficiency. Schemes are built from images of objects by connecting
them in various ways. A meaning of a scheme can always be considered to be a data structure
representing a graph marked with the types of its nodes and arcs. This is a very shallow semantics
of schemes (it does not open the real meaning of an artifact shown by the scheme). We make an
assumption that a scheme sch is always a kind of specification, and there is a specification
language L for representing this specification as a text spec in it. In other words – visual language
is just another specification language for expressing the same meaning. One has to be concerned
only about the exact translation from the scheme language into L (e.g. into VHDL in hardware
design). This can be called normal semantics of schemes.
a
x2
x1
x
*
b
112.4
Figure 1. A scheme
Figure 1 shows some basic features of a scheme language: 1) visual identification of type of a
component by shape of image, 2) connecting particular ports or variables (x1, x2, x) of
components, introducing names of components (a, b), assigning value to a field of a component
(112.4). The respective text of a specification language should be as follows:
a : typeQ; b : typeR; a.x1 = b.z; a.x2 = b.x; b.v = 112.4;
4. Deep semantics of schemes
We have an example of using schemes as specifications of programs. We define deep semantics of
a scheme as a set of classes (programs) automatically derivable from a scheme for solvable goals.
The process of generation of a new class is as follows. One extracts a specification from a scheme,
and also writes a top-level goal as an implication P -> R, where P is precondition and R is
postcondition of the main method of the new class to be synthesized. (We use an arrow -> for
denoting implications in the specification language just for convenience of typing.) The goal is to
find a realization for the implication P -> R in the form of a new method of the new class C.
This is achieved by a conventional method of the deductive program synthesis: derive P -> R
using logical formulae of specification as specific axioms, and extract the realization of the goal (a
program) from its derivation. New subgoals may appear during this derivation, hence, more
methods of the class C may be synthesized completely automatically. Also instance variables of
the new class may be introduced. In particular, any proposition with the meaning “the variable x
has a correct value” may get a realization as an instance variable of the new class. The synthesis
method used is ESSP – Extended Structural Synthesis of Programs [3]. This method is an
extension of structural synthesis of programs implemented in several older systems [4].
sch
Translator
Semantics of
images
spec
Synthesizer
Semantics of
types
class C
Figure 2. Deep semantics of schemes
Finally, we present in figure 2 the scheme of implementation of the deep semantics of schemes.
The figure shows that semantics of images is required for representing normal semantics of
schemes. And semantics of types of components used in a spec is needed for representing deep
semantics of schemes. This semantics is successfully used in simulation of complex hydraulic
systems [2].
References
[1] Glinz, M. Problems and Deficiencies of UML as a Requirements Specification Language.
Proceedings of the Tenth International Workshop on Software Specification and Design. San
Diego. p. 11-22.
[2] Grossschmidt, G., Harf, M.: Simulation of an electro-hydraulic servo-valve in NUT
programming environment. In: Proc. of the 13th European Simulation Symposium "Simulation in
Industry" ESS'2001, October 18-20, Marseille (2001) 229-233
[3] Lämmermann, S.: Runtime Service Composition. Ph.D. Diss. KTH, Stockholm, ISSN 14035286, ISRN KTH/IT/AVH, 02/03-SE (2002)
[4] G. Mints and E.Tyugu. Justification of structural synthesis of programs. Science of Computer
Programming, 2(3):215--240, 1982.