PROPLAN(ID:5971/pro063)for PROgram PLANning pseudo-algebra for detailing programs on paper Pengilly, Proctor and Gamble UK 1975 References: in The Computer Journal 19(3) 1976 view details in The Computer Journal 20(4) 1977 view details A proposed extension of APL as a softwzre design tool is presented. The approach of system specification using a programming language is compared to the non-programming language system PROPLAN presented by Pengilly (1975). Illustrative examples given by Pengilly are translated into the extended APL format. Advocating the adoption of a programming language in software design is not intended to exclude the use of natural language or other formalisms and documentation aids such as HIP0 which are commonplace in a software engineering environment. However, the importance and even necessity of specification languages which, when used in a design, can 'enhance the process of verifying correctness is increasing. This concern is further supported by the reliability that 'no programming philosophy will improve software reliability if the underlying system specifications are erroneous or have been incorrectly translated' (Belford and Taylor, 1976). Thus the selection or development of a software design language is inextricably intertwined with the specification verification problem. Falkoff (1976) has suggested the following criteria for the choice of a formal design language: 1. It should be easy to learn its basic use. 2. Formulations in the language should be suggestive and thought provoking. 3. It should allow meaningful formal manipulation of both expressions and larger program segments. 4. It should lead to the development of aesthetic criteria for judging the quality of a design. 5. It should be convenient for documentation. 6. It should be uncommitted to any particular technology or problem area. 7. It should be applicable in a consistent way to systems of any foreseeable complexity. 8. It should be executable on a machine. To this list we would add 9. Lends itself to some form of specification verification technique. 10. Desirable, although not mandatory, that the design language be useful in other contexts such as ordinary programming applications to motivate learning. The definition of a design specification language from the standpoint of the information systems analyst is 'a functional (non-procedural) programming language whose notation allows for quick, elegant and concise definition of the procedures used to input, store, process and output information'. The importance of a clean, rigorous specification to systems analysis is also becoming increasingly clear (Belford and Taylor, 1976; Liskov and Zilles, 1975). The clarity of software design must be well in hand before it can be assessed for correctness, efficiency, cost and other design constraints external to the system itself. A uniform, abstract notation is sorely needed for communication of the essentials of their design to other analysts independent of any particular implementation of the design. In view of the above, APL or an extension thereof as a specification language has a number of attractive features. First, APL is in widespread usage and has been implemented to varying extents on many machines. APL is also mathematically amenable, highly symbolic and expressions are easy to write without temporary storage variables as well as without bothersome loops that index on array variables. Its powerful array operators lend themselves to functional (as opposed to procedural) statements. These features provide a recognised powerful design facility which can be used in the problem formulation and early design phase of a software project. For example, the use of APL in the design stage, augmenting FORTRAN, eliminated errors in the logical formulation stage (Kolsky, 1969). The primary features contributing to its success were the mathematical consistency and the inherent explicitness of APL program statements from a mathematical point of view. All of the above listed criteria are met by APL. Objections to ease of learning with respect to software'design applications should also take into account the fact that APL is much more than a design tool. The skills developed in the use of this facility can be transferred to non-design applications. Criterion 8 relates to the need for machine testing of designs. A formal language capable of expressing the design of a system at various levels of detail can be used directly for simulating the system at any stage in the top-down design process. Appropriate tables can be substituted for functions not yet detailed. Thus the opportunity is provided for 'live' catalogues on interactive systems in which functional units can be displayed and executed for gaining understanding of their behaviour (Falkoff, 1976). Criterion 9 seems to be particularly important since a formal definition of the APL operators has been used to provide a base for a deductive system for informally proving assertions about APL programs (Gerhart, 1972). It may also, of course, be argued that APL has features which cause it to be undesirable as a software design language. An often mentioned fault is that of users taking advantage of the power of the language in the form of very complex statements or even perhaps complex single statement programs.These objections can be overcome by an extra measure of programming discipline which is required in the use of any high level language. In addition, however, the language, in its usual form, lacks the control structures that are known to enhance program design. The proposed extension of APL includes these needed features. in The Computer Journal 23(3) 1980 view details |