There has been great interest recently in systems that use graphics to aid in the programming, debugging, and understanding of computer systems. The terms 'Visual Programming' and 'Program Visualization' have been applied to these systems. This paper attempts to provide more meaning to these terms by giving precise definitions, and then surveys a number of systems that can be classified as providing Visual Programming or Program Visualization. These systems are organized by classifying them into three different taxonomies.

Taxonomies of visual programming and program visualization

There has been a great interest recently in systems that use graphics to aid in the programming, debugging, and understanding of computer programs. The terms “Visual Programming” and “Program Visualization” have been applied to these systems. Also, there has been a renewed interest in using examples to help alleviate the complexity of programming. This technique is called “Programming by Example.” This paper attempts to provide more meaning to these terms by giving precise definitions, and then uses these definitions to classify existing systems into a taxonomy. A number of common unsolved problems with most of these systems are also listed.

Visual programming, programming by example, and program visualization: a taxonomy

Mday finding that they are able to successfully use computers, especially personal and home computers, thanks to an abundance of well-designed \"canned\" software. Those who wish to progress beyond the canned software stage, however, discover that programming is painstaking work. Worse yet, learning to program is, for many, even more forbidding ; indeed, the attempt is often eventually abandoned in frustration. Frustration comes largely from inadequacies in common procedural, text-based programming languages. As Smith has pointed out, \"The representation of a problem in most programming languages bears little resemblance to the thought processes that occurred in its solution.\"' Why do programmers-especially novices-often encounter difficulties when they attempt to transform the human mind's multidimensional, visual, and often dynamic conception of a prob-lem's solution into the one-dimensional , textual, and static representation required by traditional programming languages? The groups of italicized antonyms in the preceding sentence may give one hint. Another reason may be that the type and variable names we use in our programs , such as \"x\" or \"root,\" are signs that bear no resemblance to their values (an integer, say, or a pointer to a binary tree of records of some type). Yet another explanation may be that the von Neumann paradigm of procedural programming is inherently unsuitable; some other method of programming, perhaps more functional, might prove easier to assimilate. Because of this general dissatisfaction , repeated attempts have been made to design \"new, im-proved\" programming languages. We believe that a radical departure from current programming styles is necessary if programming is to be made more accessible. Attempts to evolve new varieties of conventional languages will not suffice. With the cost of graphics displays decreasing and availability, most notably as integral components of personal computers, increasing-we believe it is time to take advantage of the human brain's ability to process pictures more efficiently than text. As Malone said, \"Perhaps the best use of sound and graphics ... is to represent and convey information more effectively than [is possible] with words or numbers.\"2 In this article we describe our work on developing a programming methodology called Pict that permits humans to use their native intelligence in programming. Our results represent but an imperfect collection of beginnings in a field now in its infancy. Still, our work straddles the interface of several established disciplines , the primary ones being (1) the design and implementation of programming systems (including languages) and …

Pict: An Interactive Graphical Programming Environment

A constraint describes a relation that must be maintained. Constraints provide a useful mechanism to aid in the construction of interactive graphical user interfaces. They can be used to maintain consistency between data and a view of the data, to maintain consistency among multiple views, to specify layout, and to specify relations between events and responses for describing animations of interactive systems and event-driven simulations. Object-oriented techniques for constraint representation and satisfaction are presented, and a range of examples that demonstrate the practical use of static and temporal constraints for such purposes is presented. These examples include animations of algorithms and physics simulations, and constructing user-interface elements such as file browsers, views onto statistical data, and an interactive monitor or a simulated operating system.

Constraint-based tools for building user interfaces

ion. A programming system should treat software as a hierarchical structure of neat abstractions. Conventional languages support this view syntactically by enforcing certain access rights within the program text. With standard editors and program listings, however, the programmer navigates through the program text in a sequential fashion. If the language were integrated into the programming system, though, the access path and the abstraction path would be unified and the system would embody the desired structure rather than merely support it. A pictorial system is the best vehicle for this, since it offers complete freedom in representing program navigation. For example, the depth dimension can be used to examine a piece of abstract data by enlarging its picture with a zoom effect, thus showing internal detail.

A Survey of Current Graphical Programming Techniques

This article describes a prototype program visualization (PV) enviromnent that we have developed. The prototype is an "umbrella" in the sense that it is not targeted to support any one software development methodology. Rather, it provides basic PV tools that can be used in the service of the programmer's chosen methodology. Our system was designed to support progmming in C, although large portions ofit are independent of the software development language. The prototype itself is implemented in C and runs on a VAX 11/780 under UCB Unix Version 4.2.

Kramlich

Papers

Program visualization: Graphical support for software development