Software Assisted Program Design
Paul Vickers, John Pardoe & Stu Wade.
The Software Development Group (SDG) became aware that the teaching of program design could be enhanced by using the computer itself to aid in the task. The driving force behind the group's teaching is recognition that the industry needs to produce better-written, well-structured and more-maintainable software. It has been observed by many people for many years ([BROO72], [KNUT84]) that one way to help achieve this aim is to produce self-documenting programs; that is, programs in which the code, design and other documentation are not separated but exist together in a single document. Around the time that the SDG was writing a software tool to produce such `literate' programs, Knuth published his own ideas which were of a similar nature [KNUT84]. That such an idea had been thought of elsewhere greatly excited the group and motivated it to continue the development of the tool known as SWR-Pascal.
It is widely recognised that there are problems associated with software whose supporting documentation is separate from its source code: all too often, when the maintenance programmer updates the software he does not update the documentation; that is assuming he can even locate the documentation. The problem is not so severe when the programmer who wrote the code maintains it; the code is familiar to him, he knows where to look. But what happens when he is not required to make changes to it for six months? In the interim he has worked upon other programs; the code is not so familiar. Nevertheless, with perseverance he can refresh his memory. Perhaps. What happens when a different programmer has to maintain the code? If he cannot find any documentation the task is very difficult. Maybe even more exasperating is the case where documentation exists but no longer reflects the code. Even these problems would not be so terrible if it were not for the fact that up to 80% or 90% of programming effort is expended in the maintenance phase. Accurate and easy-to-find documentation would surely go some way to relieving the maintenance programmer's task.
The maintenance mountain may be further lessened by ensuring that the original program was well-designed. Too many times maintenance programmers must waste valuable time trying to navigate a path through badly written, ill- or even un-structured code. It is common sense that a well-structured, well-designed and well-documented program is more readily comprehensible than a morass of `spaghetti' code with half-written and inaccurate documentation.
It is in this environment then that SWR-Pascal was conceived. The SDG, in seeking to alleviate the maintenance workload, therefore adopted a teaching policy which would require students to write good programs; programs which are fully documented, sensibly designed, well-structured and easily comprehensible; programs which are inherently more maintainable.
It has been argued that great benefits are accrued from the self-documenting program [BROO72]. This is a piece of software in which the documentation and source code are held together in a single document. This idea was taken further by the SDG which used the computer to derive from this single document full supporting documentation in a variety of user-selectable formats (such as cross references, structure charts and so forth) and executable code. This style of programming was described by Knuth as 'literate programming' [KNUT84]. A fuller discussion of literate programming and SWR-Pascal can be found in Pardoe and Wades' original paper [PARD87].
Jackson once said that the beginning of wisdom for a computer programmer is to recognise the difference between getting a program to work and getting it right", [JACK75a]. The aim of the SDG by using SWR-Pascal in a teaching environment is to teach students this wisdom.
The output of the programming process with SWR-Pascal is a single document. This document is easy-to-read, being formatted as the reader requires. The document contains all information necessary for the tool to produce full documentation in a variety of formats. It contains well-commented code which is logically designed in a stepwise refinement manner. In short, the final deliverable is a maintainable program.
The basic program design method taught is the technique of stepwise refinement as espoused by Wirth [WIRT71]. This approach was seen by the SDG as being easily understood and simple to use. However, Jackson's criticism that the technique is more "design by direct onslaught" [JACK75b] (where complete understanding of the problem is assumed at the beginning) than careful thought about the underlying data structures and the implications of every design decision was considered to hold some weight. Therefore, the method used is akin to JSP in that it requires analysis of the underlying data structures to produce a program structure diagram. This structure diagram is translated by the programmer into a skeleton program using the process of stepwise refinement. The skeleton program is then coded in Pascal. It should be noted that students are required to have written the Pascal code prior to using the computer. This is to eliminate `hacking' and unnecessary thinking at the terminal which usually result in poor programs (and thus poor grades!). It is stressed that the terminal session should be primarily a mundane process of typing in a finished program which is executable within one or two compilation attempts.
SWR-Pascal has been used successfully since 1985 by the SDG in its teaching of programming. The tool brings students face-to-face with the concept of program design at an early stage. The very first program which a student is required to code is a pre-designed skeleton; thus, even when learning the syntax of the Pascal language they are meeting program design.
The tool discourages students from thinking in terms of pure code as it interweaves code with documentation and design. As there is no such thing as a monolithic program in SWR-Pascal it is very hard to view code in isolation as the code exists only in fragments, each fragment sitting alongside the relevant design. This forces the programmer to consider his program in the light of his design at all times; there is only a single document from which the technical documentation and the executable code are derived, thus code and documentation are inextricably linked and updated together.
The emphasis in the teaching and assessment of programming is placed upon the initial analysis of data structures and the program design. The actual Pascal code accounts for only a small percentage of the overall grade which a student receives. In this way, the students who learn to design programs will fare better than their colleagues who prefer to sit at the terminal, write code and then try to fit a design it later. Because SWR-Pascal forces the student to think in terms of the structure of sample data and, therefore, the structure of the program itself it has been a useful stumbling block to the 'unrepentant hacker'. Direct 'hacking' of the code is very difficult indeed as the code is fragmented and interspersed with design statements.
The SWR-Pascal tool possesses a monitoring facility which enables the staff members involved to review student performance in terms of the number of attempts made to compile and run programs. Coupled with the continual assessment of the students' initial progress [SDG91] this facilitates a fast system of feedback and quickly identifies problem cases.
SWR-Pascal is used by its authors for all software development carried out by them in the VAX environment. Early versions of SWR-Pascal were used to provide the development platform for later versions.
Experience has shown that the programmer who spends a few hours sketching sample data, producing a program structure and from that deriving SWR-Pascal code will be more likely to achieve first-time compilation and execution than the programmer who tries to use the screen editor as a thinking tool.
Although not a CAL product in the strictest sense, SWR-Pascal certainly uses the computer to help to teach program design. The tool itself imposes certain restrictions on the way in which a program must be presented to it so that compilation may be carried out. When errors are found in a program by SWR-Pascal it highlights where those errors are by inserting comments into the program as to the nature of the problem.
SWR-Pascal will check the syntax of a program's design to ensure that it is logical and consistent with the principles of design taught in the formal lecture and tutorial sessions.
SWR-Pascal promotes learning by providing a development environment which causes one to think naturally in terms of program design rather than in terms of writing code.
[BROO72]The Mythical Man-Month; F.P. Brooks; Addison Wesley, 1972.
[JACK75a] Principles of Program Design; M.A. Jackson; Academic Press, 1975.
[JACK75b] Data Structure as a Basis for Program Design: Fundamentals; M.A. Jackson; Proc. Infotech State of the Art Conference on Structured Prgramming, 1975.
[KNUT84] Literate Programming; D.E. Knuth; Computer Journal, May, 1984.
[PARD87] Knuth With Knobs On - Literate Program Development; J.P. Pardoe and S.J. Wade; in Automating Systems Development, ed. D.Benyon, S. Skidmore; Plenum, 1988.
[SDG91] Lecture notes and teaching scheme for an introductory program design course; J.P. Pardoe; Liverpool Polytechnic, 1991.
[WIRT71] Program Development by Stepwise Refinement; N. Wirth; CACM Volume 14, Number 4, April, 1971.