Indirect Use of Formal Methods in Software Engineering Position Statement Heinrich Hussmann Siemens AG, Public Communication Networks, Advanced Development Hofmannstr. 51, 81359 München, Germany Email:
[email protected]
Abstract: This position statement points out the advantages of using formal methods indirectly for the development of software. It is admitted that formal methods are not adequate for the daily use in large software development projects, except of a few specialised application areas. However, it is argued that formal methods are well-suited for the analysis of the notions and tools which are used in practice. So formal methods can be used indirectly in practice, keeping the formal notation invisible during the actual development work. Examples for indirect use of formal methods are given, including a recent case study on formal foundations for SSADM which was carried out by the author. Formal methods are also considered helpful in customising software development methods for specific software development cultures.
1
Introduction
Twenty-five years ago, when the term "Software Engineering" was coined, many researchers expected a revolutionary change for software production from mathematicallogical specification and derivation of programs. In the meantime, the theoretical problems of such an approach have been solved to an impressively large extent, leading to well-developed formal development methods. However, up to today most practicians of software development have almost completely ignored these results of research. The revolution has not taken place. This fact is not due to a lack of power of formal methods. There are numerous case studies where formal methods have been applied in an industrial context, as documented for instance in [Hay87] and, more recently, in [CGR93, BS93]. However, most of the case studies are either specific safety-critical applications or they have been carried out just for the purpose to demonstrate the abilities of formal methods. Safety-critical
applications seem to develop into one application area where the current state of the art in formal methods is accepted and successfully applied. However, for any other large practical software development project, say the development of a huge information system or a new kind of telecommunication services, nobody even thinks about using formal methods of mathematical rigour. Instead, more pragmatic ways for precise system specification are going to become common in industry. These methods (like SA/SD [You89], or OMT [RBP+91], to name two prominent examples) are mostly based on diagrammatic representations; they cannot be called formal, but semi-formal at most. This paper does not try to repeat or summarize all the arguments pro and contra formal methods. Instead, the attention of the reader is directed towards the possibility of applying formal methods only indirectly. The key idea is that formal methods can be utilised in practice without burdening the daily project work with mathematical formalism. In particular, it is proposed to use pragmatic methods with a hidden mathematical foundation. A more detailed explanation of this idea is given in section 2. Section 3 shows that formal methods have already been applied indirectly in various other areas, and refers to recent work which addresses pragmatic Software Engineering methods. In section 4, it is argued that indirectly used formal methods can help in customizing development methods for specific software development cultures.
2
Direct and Indirect Use of Formal Methods
2.1
Formal Methods
For the purposes of this statement, we call a software development method "formal" if it is a formal system in the sense of mathematical logic. This means that there is a formula language with a precisely defined syntax, there is a fixed meaning to the formulae, and there is a calculus to analyse or transform the formulae without recurring to the meaning. Obviously, classical formal specification and development frameworks like algebraic specifications or the specification language Z fulfil this definition. However, also a number of notations are very close to this definition which are often seen as purely pragmatic and application-oriented. For instance, if a modern CASE tool uses EntityRelationship diagrams to produce code fragments, then there is a precise syntax (in graphical form), there is a precise meaning (in relational algebra) and there is something similar to a calculus (normal form criteria, transformation into relational form). This already gives a hint that sometimes "hidden formality" exists which is not truely recognized as such by practicians.
2
2.2
Direct Use of Formality
By "direct use" of formal methods we mean that the software developer is confronted with the formal system of the method. This means that the syntax of the formal system shows up in the specifications, and that the developer has to use the calculus of the method, for instance to perform a consistency proof or a program verification. This approach is only realistic if powerful software tools like theorem provers are available. This way of using formal methods is generally rejected by project-experienced practicians. The exception to this rule are a few specialised applications, like safety-critical systems or verification of small but extremely difficult algorithms. For the purposes of this statement, we accept the position that formal methods are not adequate to most large projects. So we concentrate on a different way to profit from formal methods within practice.
2.3
Hidden Formality (Indirect Use)
The following scenario is oriented towards the needs of practical software development work. We identify two clearly separated work areas which are covered by completely independent groups of people: (1)
There is a formal theory of notations, which is developed for instance in an academic community or in a specialist group within a company. This work heavily involves formal methods, including mathematical proofs. The result of this work, however, is a set of notations which are intuitively understandable and applicable without knowing anything about the theoretical background. The notations are accompanied by precise rules for analysis and transformation of documents in these notations; ideally in the form of automatic tools.
(2)
There is the practical project work which is mainly concerned with the creative process of finding an effective software solution within the given restrictions of resources and time. This work is carried out by software engineers which are educated in the notations and rules which were produced during step (1). It is not necessary that these people have detailed background knowledge of the formal theory.
The case of the Entity-Relationship diagrams, which was already mentioned above, is an example for this kind of hidden formality. Application programmers can use EntityRelationship diagrams and the generator tools for them, without knowing the detailed background of relational algebra. Obviuosly, the indirect use of formal methods is as old as computer science itself. In the next section, we will mention a few successful historic examples for the indirect use of
3
formality. These historic examples just serve as the background to illustrate the novel aspects of a new direction of research which has started to develop quite recently.
3
Examples for the Indirect Use of Formal Methods
3.1
Historic Examples
There are various examples of tools which are frequently used in development practice and which are the result of formal specification and development. For instance, the whole area of syntax analysis has been revolutionised by theoretical investigations. It is quite convenient to apply compiler-generator tools like the UNIX tool yacc; and these tools are sucessfully applied by people without any knowledge on the theory of LALR parsing. Similarly, many concepts in programming languages come straight from mathematical logic, but can be taught and applied without knowing about this. A classical example is the principle of local binding of variables (scoping), which comes from λ-calculus. Other examples are recursive procedures, abstract data types, or logic programs. The common pattern among these historic examples is that new theoretical concepts slowly have found their way into practice through powerful software tools (compilers, compiler-generators). Interestingly, the theoretical investigations were carried out within the classical framework of mathematics; formal software development methods did not play a role in these examples. There are a few examples which deviate from this scheme. It is worth mentioning here the formal definition of a semantics for the programming language PL/I at the IBM Vienna laboratories, around 1970. Two facts are particularly interesting in this approach: First, the object of the investigation (PL/I) was a very pragmatic product aiming at the development of large commercial software, and the theory was adapted to fit these pragmatic needs. And second, the formal definition employed itself a formally defined method (VDL) which was supported by tools.
3.2
Formal Analysis of Pragmatic Specification Methods
The examples mentioned above referred to the direct production of program code which is one of the later phases of a software development project. Nothing comparable was done in the areas of systems analysis, requirements definition and software specification. Instead, there were parallel and almost unconnected developments: In the academic community, formal methods were brought to perfection, whereas the project practice started to experiment with pragmatic approaches to a systematic specification and development of software. Typical examples for these pragmatic approaches are Structured Analysis [DeM79, You89] or Object-Oriented Analysis [CY90, RBP+91].
4
Within single companies or regulatory bodies, quite complex guidelines for software development have evolved, for instance the British standard method SSADM [DCC92]. In the last few years, a number of researchers from the formal methods community gained interest in these pragmatic approaches. In particular, the well-established pragmatic method of Structured Analysis and its main notation, the Data Flow Diagram, has attracted attention. A first overview of these approaches has been given in [SFD92], and there is more recent work to be added to this [NW93, LPT94, PHP+94]. Also the integration of formal methods and complex pragmatic design methods has been addressed, for instance in the SAZ (SSADM and Z) project [PWK93]. The work mentioned above differs significantly from most other work in the area of formal methods by taking the pragmatic approaches seriously. It has been shown clearly that the semantic basis for the Structured Analysis method is in no way clear; there are several alternative choices for the semantics and many open questions [PHP+92]. This can be seen as an intermediate result which indicates that the formal analysis of pragmatic methods helps to improve these methods, in particular with respect to their preciseness. However, as far as the practical application of these approaches is concerned, most of the available literature proposes to translate pragmatic notations (like Data Flow Diagrams) into formal notation, possibly with the help of an automated tool. Generally, the pragmatic documents are taken as the starting point for another, formal development. So there is still a tendency to confront the actual software developer with formal notation.
3.4
Hidden Formal Semantics for Pragmatic Development Methods
The central thesis of this position statement is that it is advisable to analyse pragmatic development methods using formal frameworks, in such a way that this process is kept invisible for the actual software developer applying the methods. So we propose to apply the two-step scheme from section 2.3 to the case of formal semantics of pragmatic Software Engineering methods. There is a good chance that such an indirect use of formal methods will be taken over by practicians, as the successes in other areas (as programming languages, syntax analysis) have shown. Following this route, there are two classes of technical problems to be solved. First, a methodical way has to be found how to apply formal methods onto the notations and technical steps of a pragmatic development method generically, such that it can be brought into practical work simply, in the ideal case by a fully automatic tool. Second, it has to be investigated whether the benefits of this approach (measured in quality and costeffectiveness of software production) are big enough to justify the application of the new tools in development practice. In recent work by the author of this position statement [Hus94], a way has been shown how to solve the first one of these technical questions. Due to space limitations, the
5
technical content of this work cannot be reported here; only a short overview can be given. In [Hus94], a formal semantics for most of the notations of the pragmatic method SSADM [DCC92] has been given, using axiomatic specifications as provided by the language SPECTRUM [BFG+93]. This work uses SPECTRUM as a meta-language as the Vienna PL/I project has used VDL. The syntax of the SSADM documents is represented within SPECTRUM, and the semantics are defined generically for this syntax. So the semantics can be seen as parameterised by the actual SSADM documents which are produced in a specific software project. From an application point of view, there are two main results of this study: The analysis has shown a number of points in which SSADM is not very well-suited for achieving formal preciseness. Proposals have been made how to revise SSADM into a new, formally based version. Moreover, the logical consistency of the specification has been investigated, using the formal theory for SPECTRUM. This investigation was carried out in a completely generic way, on the meta-level of the formal semantics for SSADM. This has lead to a relatively small set of conditions which have to be tested for an actual SSADM specification to ensure its consistency in a mathematicallogical sense. Fortunately, these conditions are of a syntactical nature, so that they can be tested by an automatic tool. Altogether, this means that SSADM, in the version after the proposed revisions, can be applied in projects like any other pragmatic method, without any background knowledge of the formal semantics. Nevertheless, the whole effort invested into the formal consistency proof is carried over to the practical projects automatically. Another view of the SSADM-SPECTRUM study is that a very powerful general-purpose method (SPECTRUM) was specialised towards notations which are appropriate for a specific application area. This idea is followed in the next section in more detail.
4
Adapting to Software Development Cultures
4.1
Software Development Cultures
Practice of software development consists of an abundance of completely different practices. Software development is viewed differently depending on various circumstances, among them being: the application area, the organizational background, the kind of target system, the educational background of the involved developers, even the geographic location. It is claimed here that this cultural background cannot be ignored when introducing more precise, formally based development methods. Most pragmatic methods for the specification and development of software are oriented towards a specific culture of software development. For instance, SSADM aims at the development of information systems and therefore it partly uses a terminology which is specific for database systems, including Entity-Relationship diagrams. SSADM is a UK method, which explains the pominent role played by the Jackson notation, since this notation is more common in the UK than in other parts of the world. Finally, even the
6
fact may have had an influence that SSADM is a governmental standard, since it has some tendency towards bureaucracy. Examples for completely different development cultures are process-control systems, where often state transition approaches and variants of Petri nets are favoured, or the description and development of telecommunication software which quite commonly uses sequence charts and other constructs derived from the SDL language.
4.2
Applying Formal Methods to Specific Cultures
As the SSADM-SPECTRUM example has shown, an analysis of a specific development culture with the help of formal methods can help to bridge the gap between a specific culture and the quite general framework which is provided by formal methods. If formal foundations for the culture-specific notions and notations are found, it is much easier to integrate a more formal way of specification and development into the practical work of the specific area under consideration. Ideally, the analysis of a specific culture using a formal method is a process which leads to benefits for both involved sides (formal and pragmatic methods). The formal methods gain another layer on top of the pure formal notation, which is well-adapted to the cultural background, and which therefore enables communication with experienced practicians. Most of the pragmatic notations are graphical and encapsulate complex concepts which are commonly known among the respective developers. Therefore, enhancement with such notations makes a formal method more appropriate for overall discussions on the design of a system, and more adequate for the early phases of specification. The pragmatic methods, in turn, gain a much higher level of preciseness in specifications, which seems to be a key point in enabling powerful tool support for the early phases of development.
5 Conclusion This position statement has given arguments in favour of an indirect use of formal methods to improve software development, by analysis and semantic foundation of pragmatically proven methods and notations. As a demonstration of the theoretical feasability of such an approach, a study on formal foundations for SSADM has been mentioned. In an ongoing research project at Siemens, also the practical and economic aspects of the indirect use of formal methods are investigated. In this project, pragmatic methods for the functional description of telecommunication services (e.g., message flows, hierarchical state transition diagrams) are analysed with the help of a formal semantics. This analysis is expected to lead to a refined pragmatic specification method. Using practical application cases, the advantages and disadvantages of the new, formally based, method will be studied from the economical point of view. In particular it will be investigated how much additional effort has to be spent on a more precise (although still
7
pragmatic) specification, and to which extent this is compensated by savings in other development phases.
8
References [BFG+93] Broy, M., C. Facchi, R. Grosu, R. Hettler, H. Hussmann, D. Nazareth, F. Regensburger, O. Slotosch, K. Stølen, The requirement and design specification language SPECTRUM, An informal introduction. Reports TUM I9311+I9312, Technische Universität München, Munich 1993. [BS93]
Bowen, J., Stavridou, V., The industrial take-up of formal methods in safetycritical and other areas: A perspective. In: F. C. P. Woodcock, P. G. Larsen (eds), FME’ 93, Lecture Notes in Computer Science Vol. 670, Springer 1993, pp. 183-195.
[CGR93] Craigen, D., S. Gerhart, T. Ralston, Formal methods reality check: Industrial usage. In: F. C. P. Woodcock, P. G. Larsen (eds), FME’ 93, Lecture Notes in Computer Science Vol. 670, Springer 1993, pp. 250-267. [CY90]
Coad, P., E. Yourdon, Object-Oriented Analysis. Prentice-Hall 1990.
[DCC92] Downs, E., P. Clare, I. Coe, Structured systems analysis and design method (2nd ed). Prentice-Hall 1992. [DeM79] DeMarco, T., Structured analysis and systems specification. Prentice-Hall 1979. [Hay87]
Hayes, I. (ed.), Specification case studies. Prentice-Hall 1987.
[Hus94]
Hussmann, H.: Formal foundations for SSADM. Habilitation Thesis, Technische Universität München, June 1994.
[LPT94]
Larsen, P. G.; N. Plat, H. Toetenel, A formal semantics of data flow diagrams. Formal Aspects of Computing 3 (1994).
[NW93]
Nickl, F.; M. Wirsing, A formal approach to requirements engineering. In: D. Bjørner et al. (eds.), Proc. International Symposium on Formal Methods in Programming and their Applications, Lecture Notes in Computer Science Vol. 735, Springer 1993, pp. 312-334.
[PHP+94] Petersohn, C.; C. Huizing, J. Peleska, W.-P. de Roever, Formal semantics for Ward & Mellor’s Transformation Schemas. In: D. Till (ed.), Proc. of the Sixth Refinement Workshop of the BCS FACS Group. Springer 1994. [PWK93] Polack, F.; M. Whiston, K. Mander, The SAZ project: Integrating SSADM and Z. In: F. C. P. Woodcock, P. G. Larsen (eds), FME ’ 93, Lecture Notes in Computer Science Vol. 670, Springer 1993, pp. 541-557. [RBP+91] Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Objectoriented modelling and design. Prentice-Hall 1991. [SFD92]
Semmens, L. T.; R. B. France, T. W. G. Docker, Integrated structured analysis and formal specification techniques. The Computer Journal 35 (1992) 600-610.
9
[You89]
Yourdon, E., Modern Structured Analysis, Prentice-Hall/ Yourdon Press 1989.
10
