For reasons outlined below, conventional software has evolved into a morass of different languages and applications, as shown in FIG. 1. Visual programming of the present invention provides a way to unscramble the software puzzle because it is designed to support clear separation of intuitively separate functions; it is designed to support easy integration with almost all "foreign" applications. An iconic representation of the transformation of the software world that Visual Programming will provide may be seen in FIG. 2.
In the rest of this specification, the term "user" will be used to mean "developer" and "maintainer". The workstation user, then, is not the ultimate end user, but rather the person who is constructing or modifying software.
Up until 10 or 15 years ago, programs written for computers were usually prepared on punch cards and submitted to a system operator, and the results were usually returned to the user printed on paper. With this arrangement, the user had little or no direct interaction with the computer itself, but was forced to develop programs in "batch" mode. In the late 1960s and early 1970s, users began to be able to interact directly with computers, but primarily through typing characters at a keyboard on a teletypewriter and seeing the computer respond by typing results on the paper in the teletypewriter. This hardcopy-based human computer communication virtually forced humans to use character oriented means to program computers, resulting in computer languages being the only means to program computers.
It has been less than 10 years since the widespread use of CRT-based terminals and personal computers has allowed for the possibility of users interacting with computer generated graphics. To date, the possibilities of interaction with computer generated graphics at an interactive computer workstation as a means of generating computer programming has been explored to a very limited extent. Hence, the impact of new and emerging interactive computer graphics capabilities has not yet been felt in software development methods.
Conventional software development generally consists of four distinct stages: edit, translate, link, and test. The stages are repeated in sequence as necessary until the software has the desired functionality.
In the edit stage, the user generates executable statements in a computer language. A computer language is like a natural language such as English in that it involves expressing instructions with words using predetermined word sequence and word meaning rules. Typically, the user sits at a terminal or a small computer and enters a sequence of words into a text editor, and then saves his or her work to a file. The user thus starts with a basically blank screen and creates the program text by typing at the keyboard.
Once the user has entered and saved the language text, he or she invokes a translator. The translator converts the linguistic representation to binary instructions. The translation process is normally not visible to the user; the translator simply notifies the user when it is finished. The binary instructions serve as "masks" for the computer hardware to perform operations on data. If the translator detects an error in the syntax or an inconsistency in the semantics of the statements, it produces a warning or an error message and attempts to help the user locate the problem, although it may not be able to do so very well. If errors are detected, the user again edits the computer language text and submits the revised version to the translator again. Once the specific binary instructions are generated, the program may be loaded to computer memory and executed until the program statements are exhausted.
Typically, the user creates independent computer program components by alternating between the edit and the translate stages. The components accept data by a defined parameter passing mechanism. Usually, when an independent program component receives a parameter set it operates as if it were a stand alone program except that when it terminates it returns some or all of the internally calculated results to another independent program component. When independent program components are combined to form larger programs they are said to be "linked", that is, known to each other. The parameter passing mechanism is a property of the language translator, so that "foreign languages" may "communicate" with one another at the linkage step if the data interchange between foreign components has been appropriately defined.
In the debugging stage, the user loads the (linked) executable program to computer memory and exercises it to determine if the desired results are achieved. In most instances a new program fails to perform as originally intended. There are typically several methods at the user's disposal to determine the problem: to inspect the language statements, to insert diagnostics into the language statements via the editor and then retranslate, relink, and reexecute, or to use a debugging utility that helps show program status and the values of data at each step. Once the program has been identified, the user returns to the first step, alters the language statements, and repeats steps two through four. The process is repeated until the program performs as intended.
Computer scientists have attempted for some time to define principles of software development in order to simplify and clarify the construction of complex software systems. The output of this effort has been to develop computer languages whose constructs encourage clear representations for flow of control within program elements and well understood data interchange mechanisms between program elements.
One thrust of this effort has been to establish general design guidelines. Two complementary points of view emerged in the 1970's. The first, known as "top down structured programming", was made possible in 1964 with Bohm and Jacopini's (1964) discovery that every program can be rewritten using repeated or nested units of no more than 3 different kinds: sequence, conditional, and iteration. Specifically, this article showed that there was no logical necessity for the "goto" statement. Top down structured programming was developed and elaborated (e.g., McGowan & Kelley, 1975; Dijkstra, 1976; and many others), and was quickly accepted among the academics and industry practitioners.
The top down theory holds that design should start at the top of the problem and specify the major functional requirements that should be satisfied. The identified functions are selected as reasonable partitions based on "distance" from one another, such as "load a file" and "perform mathematical operations". When the high level functions are established the original principle is applied to each function at the next level. The method also requires that each defined module have a clear list of inputs and outputs. This "factoring" of the problem into a series of layers is not scientific, but at least provides guidelines in how to reduce a complex problem into groups of simpler ones.
Another significant definition as part of the "top down" strategy deals with how the flow of control proceeds within any given module. Each module has a single point of entry where execution begins and a single point of exit from execution, regardless of the purpose of the module. The flow of control thus begins at the top of the module and proceeds strictly downward. The only exceptions are the code segments which are repetitively executed. Conditional flow constructs define what is to be executed when given conditions are met.
The second modern view of software development produced a concept known as "object oriented programming" (Byte, 1981; Goldberg & Robson, 1983; Cox, 1986; SIGPLAN, 1986). Object oriented programming went largely unnoticed by the majority of computer scientists and software engineers in the 1970's. The top down approach was conceptually simple and attractive to most, and the object oriented method continued in the background strictly at the research level. The top down philosophy is still a strong force in current software development while the subtler object oriented approach is gaining wider acceptance due to a demonstrable increase in productivity.
The object oriented approach is subtler than the top down approach. It is based on the idea that the separation of data constructs from code constructs is not necessarily clear cut. Data are considered active in the sense that they have operations directly attached. For example, a number has "knowledge" (a built in property) of how to multiply itself by other numbers. As a result a "number" is a compound element consisting of a value plus the ability to perform operations such as multiply. In general, an object is an entity that accepts service requests from other entities. The object oriented approach gives a different flavor to software design since each object, when solicited for service, can in turn solicit services from other objects in order to complete the original service.
The dynamics of an object oriented system is primarily that of an information network where each node (object) may issue a message to any other node requesting one of the available services at that node. The receiver in turn issues messages to other receivers until the final service is complete at which point the original sender again takes control of the information network.
One of the major advantages of object oriented programming is embedded in the inseparability of code and data. The data internal to a module is totally hidden. That is, it is impossible for one object directly to access data internal to other objects, and thus data may be viewed as protected. This view, which is not explicitly enforced in the top down strategy, guarantees a clear separation of data between foreign modules.
In terms of code bulk (sheer number of lines), the object oriented methods have demonstrated considerable savings, especially for complex tasks. That translates directly to time and effort savings provided that the developer is sophisticated enough to master the messaging concept and to factor the problem into a judicious set of objects.
It has long been a formal part of any software design process that the user creates "block" functions in a hierarchical diagram that indicates what functions are to be performed by independent modules. Flow charting methods, which have also existed for a long time, are also sometimes created to indicate the operation of computer programs with more precision than hierarchical block diagram. There are now standards for flowchart symbols (ANSI, 1970) and the technique has been elaborated to encompass structured methods (Nassi & Schneiderman, 1973). The primary use of flowcharts and block diagrams is documentation. Unfortunately, neither block diagrams nor flowcharts provide a mechanism for a clear coordination and separation of data between modules. They also cannot guarantee that any of of the data interfacing requirements of foreign modules will be met. These remarks apply whether or not computer aids are used to create block diagrams or flowcharts: in the end, in conventional programming, computer language must be entered into the computer to create computer programs.
Research in parallel processing has discovered that sequential execution of instructions in programs as originally entered is not the only order in which the instructions can be executed correctly. This alternate view is based upon seeing the "data flow" requirements of the program (Karp & Miller, 1969; Backus, 1978; and many others). Operations are interdependent if and only if they access the same data. If modules share no data they may be executed concurrently with no loss of logical integrity, no matter what the form of the original program. Graphs which indicate the independent paths in which data must be accessed are termed "data flow graphs". Data flow graphs, obviously, show the flow of data (unlike block diagrams and flowcharts) but omit the flow of control (again unlike block diagrams and flowcharts). However, data flow graphs are no more sufficient to create computer programs in conventional environments than are block diagrams and flowcharts; conventional environments require that the program be expressed in computer language.
There have been several attempts to support the activity of software development with knowledge based systems, although most of them currently remain in the laboratory. A project at Xerox Palo Alto Research Center, called Programmer's Assistant, has attempted to support the programmer by providing a rich window-oriented environment, allowing access to many "power tools for programmers" and computer language editors that provide language templates for common functions (Teitelman, 1984; Brown, 1985). Similarly, a knowledge-based editor called DED attempts to provide programming knowledge to the user as the program is being constructed (Barstow, 1984). These efforts are aimed at helping users construct programs in INTERLISP, a dialect of a computer language.
A recent issue of IEEE Computer was devoted to reviewing the state of the art in visual programming (August, 1985). None of the systems reviewed in that issue incorporated any of the technologies claimed in this application, but a review of them is in order.
Raeder (1985) reviewed a number of generic programming techniques that involve diagrams, including flowcharts, structured flowcharts, Nassi-Schneiderman diagrams, Perti nets, state diagrams, and augmented transition networks. He found, generally, that each technique was inadequate to represent complete computer programs and program concepts in one or more ways: inability to represent control flow, inability to represent data flow, inability to represent structured program modules, and/or inability to represent complex data structures. In his review as well as the rest of the journal, several attempts at employing interactive graphics in support of software development are reviewed.
Program Visualization (Brow, Carley, Herot, Kramlich, & Souza, 1985) is one such system. Its intent is primarily the display of program dynamics after a program has been developed in some language, and as such, is not a means for actually programming computers. The Omega system (Powell & Linton, 1983) allows user to mix data structure icons and text to program computers, although the textual form clearly predominates. In PegaSys (Moriconi & Hare, 1985), users can develop design diagrams for programs graphically, but cannot develop executable programs directly. PECAN (Reiss, 1984) provides lots of graphical information about a program as it is being developed, including a program listing, its Nassi-Schneiderman diagram, the data-type schema, the program's parse tree, a control flow graph, the execution stack, and user input/output dialog displays; but development is still language oriented, and the system represents no new programming technologies. FORMAL (Shu, 1985) is a forms-oriented, visual-directed application development system, but it is focussed on database definition and manipulation, and still is primarily text oriented. The State Transition Diagram Language (Jacob, 1985) provides state transition diagrams after a program has been developed in a language, and Visual Simulation (Melamed & Morris, 1985) provides rich interactive graphics capabilities for building communications networks simulations but remains limited to that function.
Two systems (one reviewed in Computer) represent the closest approach to the invention claimed in this application: Programming in Pictures (PiP, Raeder, 1984) and the Programmer's Apprentice (Rich & Shrobe, 1978; Waters, 1982; Waters, 1985). PiP is based on functional programming (considering computer programs as a nested sequence of function calls) and provides four graphics-based editors: one for freehand drawing of pictures to represent data structures and functions, one for representing data types, one for combining the data structures, and one for combining functions. Data may be incorporated in functions, which may be nested to create computer programs.
The Programmer's Apprentice is a project taking place at the MIT AI Laboratory (Rich & Shrobe, 1978; Waters, 1982; Rich, 1985). The Programmer's Apprentice attempts to capture a plan for the software under development, and uses its knowledge based to automate portions of implementing the plan. In addition, some versions of the Programmer's Apprentice involve programming with diagrams that contain little computer language. The alternative visual programming methods differ significantly from the approach taken here because:
They do not incorporate both data and control flow explicitly.
They have no elemental unit of software such as the Softron, upon which Visual Programming of the present invention is based.
Their diagrams have no layers, as do Softrons in the Visual Programming Environment.
They have no way of nesting and reducing diagrams such as Logical Zoom, described below.
They provide no means for incorporating programming information as early as possible in the software development cycle (as does the process of specialization) to provide for a very flexible means of optimization of executable code.
They do not provide for the creation of new program modules by describing additions to, and especially subtractions from, either modules.
It is therefore a primary object of the Visual Programming Environment of the present invention to provide a clear unambiguous on-screen view of a computer program, to define a systematic mechanism for displaying the data interconnections and functional flow in the program, and to provide a means for automatically creating or modifying the program directly from the screen diagrams so created.
Yet another object of the present invention is the creation of a logical sequence of executable computer instructions expressed by grouping graphical, non-linguistic, descriptions for operators and data.
Still another object of the invention is a computer based work station in which all programming constructs are created by arranging lines and boxes on a display screen.