Data-flow design as a visual programming language

Data-flow design techniques and the functional programming style both decompose problems in a data-driven fashion. We propose a method based on data-flow diagrams which yields designs which can be mechanically translated into code written in a functional programming language. Users who specify or design systems with data-flow techniques can effectively execute their specifications or designs with a minimum of additional &sign decisions and without recourse to a programming language. Data-flow diagram elements behave as programming constructs in a “visual pmgramming” language. The paper solves a single problem to illustrate the methodology and show the kind of code produced. 1. A Functional Design Methodology The potential which a functional programming language has for producing programs capable of running on parallel hardware is beginning to be exploited by hardware designers looking to produce experimental parallel machines[l]. Ultimately these promise to turn into extremely fast, widely available computing engines on which many of the substantial processing tasks of the future will be performed. However most programmers would agree that a language like Hopc[2] imposes a “functional programming style” which may not very closely match the types of problems which they are trying to solve. The software crisis is happening in the commercial and industrial arcnas[3], not in research laboratories, and academics and rescarchcrs must be careful not to provide solutions to problems which pcople don’t actually have. What we thought was needed was a functional design methodology which decomposed typical problems in such a way that the functional programming style would suggest itself at the implementation stage. WC were attracted to the family of data driven design methodologies because there appear to be some similarities between the data driven design philosophy and the functional programming philosophy. A data driven design tcchniquc dccomposcs a problem into a network of processes linked by durujbws, this arrangement being represented pictorially as a “data-flow diagram”“, or more usually, a hierarchy of data-flow diagrams. In constructing these designs, no consideration is given to the flow of “control”. Likewise, functional programming languages are characterizcd by an absence of control-flow constructs dictated by the requirement for rcfcrcntial transparcncy[4]. Instead functions are invoked by the existence of their argumznfs (incoming flows) rather than by programmer initiation, and the evaluation model envisages the functional components of a program executing in parallel on a network of processors. A data-flow diagram can be thought of therefore as a circuit diagram for a configuration of processors built to execute the corresponding (functional) program. The problem is that a set of data-flow diagrams is an informal represenmtion of one particular aspect of a program’s design while the ultimate pmgram is formal at least in the sense that there can be no semantic ambiguity in the source-code whatever language it is written in. Traditional methodologies solve this problem by introducing more and more refined represenml&s of other design decisions via, for instance, entity-relationship. Permission to copy without fee all or part of this mate& is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publtcatron and its date appear, and notice IS given that copying is by perrruss~on of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specdic Permission. Data-Flow Design as a Visual Programming Language Department of Computing Mathematics and Statistics, Polytechnic of North London, Holloway Road, London. N78DB Great Britain diagrams or structure charts[S]. Eventually, if enough detail is supplied it is possible to transform the design into a program mechanically[6][7]. However the effort which must go into this, and the potential for introducing error, makes following the methodology practically indistinguishable from actual programming and many programmers prefer to follow their inclinations and plunge straight into code. If the target language is low-level the amount of detail required is correspondingly greater. By contrast. a very high-level language should meet the designer half-way and the transition to code could occur much carlier in the design process. We set out to find how early in the process coding could begin. We found that once the data-flow diagram stage is complete, the functions which it identifies must be specified and the structure of the data in flows and stores must be deftned. We do the former in pseudocode and the latter in a data dictionary. Together these provide enough information to generate code mechanically without any further design &xisions. To reap the benefits of automatic code generation some of the informality must be given up. For example we found it necessary to eliminate all consideration of input/output operations from the data-flow part of the design. We need to do further theoretical work to link data-flow semantics with programming constructs more formally before judging how crucial the loss of informality will be. In this paper we omit discussion of our approach to data stores which is currently rather ud hoc pending the development of facilities for pcrsistcnt data in Hope. Finally, we have not yet applied our method to as wide a range of problems as we plan to prior to refining our prototype tool. 2. Finding the Day of the Week A worked example is presented here to illustrate the application of the design technique and to show how Hope code can be mechanically derived. The problem is to read any date from (1800-2000) in the form dd/mm/yyyy and to compute the day of the week on which that date fell (or will fall). There is a concise algorithm which provides a solution to this problem@]. The day on which January 1 falls for any given year in the indicated range can be calculated from the formula: (4+Y+(Y+3)/4-(Y-17Ol/lOO+(Y-1601)/400+3)) MOD 7 where Y is the year and where Sunday corresponds to 0. The day of any date after January 1 is computed by brute force, adding up the days of the intervening months and date in the current month. This is not a complex problem but it is rich enough to demonstrate the different aspects of design and the underlying algorithm gives a fair illustration of the functional programming style 2.1. Data-flow Design Design begins with a data-flow diagram which shows the confext external inputs and outputs within which the program operates. The whole program is represented as a single process (a circle in the diagram see Figure 1) with the input “flowing” in from its source (Keyboard) and output data flowing to the sink (Screen). Decomposition consists of elaborating the functions (processes) which transform inputs into outputs in a hierarchy of diagrams. All flows and processes are named. Diagrams are constructed with the aid of a Design Editor. As a diagram is constructed simple consistency checks are applied to ensure the integrity of the diagram set. 281 01989 ACM O-89791 -305-1/89/0500/0281$00.75