Formal specification of visual languages
Introduction
Increasingly, diagrams are seen as an integral part of the software development process. The majority of so-called `structured' methods employ diagrams — examples are Yourdon 1, 2, Jackson [3], Mascot 3 [4]and the languages of STATEMATE [5], particularly statecharts 6, 7. Object-oriented methods such as OMT [8]also make use of diagrams.
There is increasing interest in visual programming languages. Here, we are not referring to modern GUI-builders such as Microsoft's Visual Basic, but rather to those languages where diagrams are used instead of textual code [9].
In order to use diagrams, we need to know whether a diagram is legal or not — i.e. we need to specify the syntax of the language. There are several approaches which may be employed with text-based languages; perhaps BNF and the syntax diagrams often used to describe the language Pascal are the most common approaches.
A number of techniques have been suggested for the specification of visual language syntax. These include picture clause grammars [10], picture layout grammars [11], relation grammars [12]and F-PATR, a unification-based grammar [13]. Perhaps the most familiar technique, however, employs sets of tuples. This technique is often used to describe Petri Nets [14]. It has also been employed by Nejad-Sattary [15]to specify data-flow and similar diagrams, but as he comments, it is also necessary to state the rules which determine whether a diagram is valid; he uses `logic predicates' for this purpose.
The specification languages Z [16]and VDM [17]include both a means of specifying data-types, based on sets, and a means of specifying constraints using predicate logic. It is thus attractive to consider their use in specifying visual languages.
The remainder of this paper is structured as follows. First, we consider some general points related to the use of Z in specifying visual languages — specifically, those forms of diagrams which are, mathematically speaking, graphs. Then, we look at the use of Z to specify two well-known forms of diagram, namely, Yourdon data-flow diagrams 1, 2and Jackson data structure diagrams [3]. We then consider how the techniques might be used to specify more complex visual languages — notably those with an idea of hierarchy (i.e. hypergraphs). These include Mascot 3 [4]and higraphs [7]. Finally, conclusions and suggestions for further work are presented.
Section snippets
Some general points
Many diagrams used in software development are graphs (a graph is a diagram comprising a set of nodes and a set of arcs which connect the nodes). They are usually also directed graphs — in other words, the arcs have direction (usually indicated by arrowheads). We could describe a diagram, therefore, as follows (using the Z notation):
What would the invariant be? We are not yet in a position to state it; we must now consider more carefully how nodes and arcs may be themselves specified.
Yourdon data-flow diagrams
There are various forms of data-flow diagram (DFD) associated with the Yourdon name. One of the earliest forms was that proposed by DeMarco [1]. Later, the original notation was extended to allow for the description of real-time systems by Ward and Mellor [18]; such diagrams are usually more complex. A different real-time extension to Yourdon was developed by Hatley and Pirbhai [19]. Data-flow diagrams have also been used in many other notations, for example OMT[8], and the system specification
Jackson data-structure diagrams
Jackson first introduced his data structure diagrams as part of the Jackson structured programming (JSP) methodology [3]. They are also employed in the later Jackson system development (JSD) methodology where they are used to indicate permissible sequences of events. They are also employed within SSADM for the depiction of entity life histories [20]. The characteristics of all these diagrams are similar; the description here refers to Jackson's original approach.
There are three types of box;
Formal specification of hierarchical diagrams
Many diagrams used in software engineering are of a hierarchical nature. Indeed support for hierarchical decomposition is a very useful feature 21, 22. Diagrams of such a nature include those used in Mascot 3 [4]and the diagrams used in statecharts 6, 7. The common feature of these diagrams is that one node can be the parent of other nodes. In this section, we outline the features of some such diagrams and illustrate how the approach described in this paper could be extended to them.
In Mascot
Usefulness of approach
Perhaps one of the first questions which ought to be asked is, is there any point to the formal specification of visual languages? It is this author's opinion that indeed there is; and for the same reasons that the formal specification of textual languages (e.g. BNF and the syntax diagrams used to describe Pascal) is useful: so that we know what is, and what is not, a valid construct in the language.
Indeed, in the area of text-based languages, the very existence of these formal specification
References (26)
Statecharts: a visual formalism for complex systems
Sci. Comput. Prog.
(1987)- et al.
Relational grammars and their application to multi-dimensional languages
J. Visual Lang. Comput.
(1991) - et al.
Unification-based grammars and tabular parsing for graphical languages
J. Visual Lang. Comput.
(1991) - T. DeMarco, Structured Analysis and System Specification, Yourdon Press,...
- E. Yourdon, Modern Structured Analysis, Prentice-Hall, Englewood Cliffs, NJ,...
- M. Jackson, Principles of Program Design, Academic Press, New York,...
- RSRE, The Official Handbook of Mascot, RSRE,...
- D. Harel, A. Pnueli, et al., STATEMATE: A working environment for the development of complex reactive systems, in:...
On visual formalisms
Comm. ACM
(1988)- J. Rumbaugh, M. Blaha, et al., Object-oriented Modelling and Design, Prentice-Hall, Englewood Cliffs, NJ,...