| Relation: |
Technical report (University of Alabama at Birmingham. Department of Electrical and Computer Engineering); 2018-07-ECE-021 Technical report (Southern Methodist University. Department of Computer Science and Engineering); 88-CSE-15; Technical Report 2018-07-ECE-021 Technical Report 88-CSE-15 Graphical Programming: An Introduction and a Graphical Pascal Teaching Tool Nirav Patel Murat M. Tanik This technical repmi is a reissue of a technical repmi issued March 1988 Department of Electrical and Computer Engineering University of Alaban1a at Birmingham July2018 [ I Technical Report 88-CSE-15 GRAPHICAL PROGRAKHING: AN INTRODUCTION AND A GRAPHICAL PASCAL TEACHING TOOL Nirav Patel Murat M. Tanik Department of Computer Science and Engineering Southern Methodist University Dallas, Texas 75275-0122 March 1988 r: rr. r r ~ r [ [ r. [ r. [j [ [ l~ [" L l l [ [ TABLE OF CONTENTS LIST OF FIGURES . iii ABSTRACT . iv I. INIRODUCTION . ~ . ! II. ~ Gttl\JPIIICALJ>R(){j~G? . 2 III. CLASSIFICATION OF THE TOOLS . .4 IV. SURVE~ OF Gttl\JPHICAL J>ROG~G TOOLS . 8 A. Diagramming Tools . 8 B. J>ECAN . 9 C. IconLisp . 11 D. J>ICT . 11 E. Hi Visual . 12 F. Jigsaw J>ascal . 14 1. Design . 14 2. Implementation Details . 17 3. Unimplemented Features . 21 V. CONCLUSION . 22 REFERENCES . 23 ii LIST OF FIGURES FIGURE 1: Programming Language Pyramid . 3 FIGURE 2: Hierarchical Classification of Graphical Programming Tools . 4 FIGURE 3: A Nassi-Shneiderman diagram . 6 FIGURE4: A PECAN execution display . 10 FIGURE 5: Example of a Hi Visual Program . · . 13 FIGURE 6: An Example of a Record Data Type in Hi Visual . 14 FIGURE 7: The Jigsaw Pascal Screen Layout . 15 FIGURE 8: The Jigsaw Pascal Pieces . 16 FIGURE 9: Unit Dependency Diagram . 18 FIGURE 10: A Program Tree . 21 iii r r [ L L [ [ [ [ [ l l t l [ [ [ ABSTRACT This paper surveys a fairly new pra,ctice in Computer Science -- programming with the aid of graphics tools. Although various diagramming tools have been used for a long time, the decrease in the cost of graphics hardware and memory is allowing the diagramming to be performed on the computer instead of on paper. This paper looks at some of the advantages of programming with graphics over conventional textual programming. Also, a simple classification scheme of the [. various tools which support graphics programming is introduced. Next, four tools which exemplify some of the aspects of graphics programming are surveyed. Details of their capabilities, l f l and differences from other tools are discussed. Also, some of their shortcomings are discussed. As a detailed example of a graphical programming tool, the implementation and design of Jigsaw Pascal, a Pascal teaching system currently being developed by the author, is discussed. IV ,. (~ r~ r r. r [ [ [ c [ c [ [ L L L l l f [ l l I. Introduction Since the beginning of Computer Science, a major problem has been in communicating a particular problem we want solved to the computer. People have worked hard to improve this human-computer interface so that the problem can be represented more naturally by a human. The most common way in which this problem has been approached is with programming languages. Various types of languages have been created to handle specific types of problems. For example, object oriented languages deal with the problem with "objects" and various actions that can be performed on that object. Some examples of other types of languages that have been developed are: Functional Programming Languages (Lisp), Logic Programming Languages (Prolog), and Procedural Languages (Pascal). A newer approach to building better user interfaces is based on artificial intelligence research. AI techniques allow users to communicate with computers by using a "natural language" such as English. However, the communication is still based on text. Another approach to man-machine communication is based on computer graphics. With these tools, users can program with graphics. As we will see later in this paper, programming with the aid of graphics offers many advantages over programming with textual languages. This paper is primarily intended to inform you about programming with the aid of graphics. By reading this paper, hopefully you will understand exactly what is meant by programming with graphics, why programming with graphics is helpful, and also be informed about some of the major systems which exemplify various aspects of graphical programming. Also, the in-depth discussion of the implementation and design of Jigsaw Pascal, a graphical programming system which we are currently developing, will help give a concrete example of how such tools may be realized on microcomputers. While there are many £/ aphics tools in the entire field of Computer Science, this paper deals only with tools which aid in software engineering. Of these, only the tools which aid in the implementation (programming) phase of the software life-cycle are covered in this paper. Other types of graphics such as Image Manipulation and CAD/CAM, since they do not deal with software engineering, are not covered in this report. Also, since there are many systems which support programming with graphics, only the major ones which exemplify the various approaches are surveyed in this report. We will first present several reasons for choosing graphical programming over textual programming. Next, a general classification of the tools is given. We shall then describe some of the tools in detail and discuss where they fit in the classification scheme. We will pay particular attention to Jigsaw Pascal and will describe the current implementation and design of the system. We will conclude by summarizing the various points of this paper. 1 II. Why Graphical Programming? In the past decade, there has been a strong movement toward using very high level programming languages to solve problems in Computer Science. While these conventional programming language provide a solution to the problem of man-machine communication, some problems do exist: • They always deal with text. Humans must learn the rules (syntax) of the language. • They are not very "natural" for humans. • They require an extra step of designing on paper with symbols (such as squares, circle, diamonds, etc.) and then converting the diagram to a program. It would be more efficient to create the diagram directly on the computer and have the computer convert the diagram into actual code. We would like to minimize the effort on the part of the human. In order to solve some of these problems, systems and techniques which allow programming with the aid of graphics tools have been developed. These systems provide the programmer and user the ability to solve problems through the use of icons and symbols. All such tools, whether they are used on a computer or not, share some of the following advantages over conventional text programming: • Learning Curve: It is commonly acknowledged that the human mind is strongly visually oriented and that people gather information at a higher rate by discovering graphical relationships in pictures than by reading ordinary text. When one programs in a textlanguage, one is forced to learn it syntax. On the other hand, programming with graphics and pictures is much more natural for humans. • Dimension of expression 1: Text can be thought of as a "me-dimensional stream of characters. We often use indentation and bold-facing of keywords in text to help make text multi-dimensional. Pictures, on the other hand, inherently provide two or three dimensions. In addition, other properties of pictures such as shape, size, color, texture, direction, etc. provide further information. So, the language of pictures is much more compact -- each piece of a picture may represent lots of information. • Concrete vs. Abstract: With the use of pictures, we can represent ideas so that they are much easier to comprehend. For example, the Xerox Star system uses the standard "desktop" analogy to do various tasks. So, if one wants to erase a file, one would pick up a picture of the document and place it in a pictorial trash can. Such actions are definitely more obvious then typing: "Erase fllename." When using text, we must tie what we want done with some string of characters. Unfortunately, this may require quite a bit of memorization of commands and their formats. • Animation: Programs written with ordinary text are static, whereas programs written in graphics environments can be dynamic. With visual programs, one can watch the execution of programs and see the results as they are being generated. This scheme of program and data animation greatly aids the testing phase of the software life-cycle. 2 [ I r r [ [ r ( l I [ l r [ [ [ l [ t Ease of Use 1\ Single Program I \ J I \ Menu Systems \ Higrh- level Non-procedu' ral languages High-level Procedural languages Assembly Machine Language t Level of Programming 1.,._.1 --- Domain --- !~ Figure 1: Programming Language Pyramid While all of the above are certainly advantages of graphical programming, there are some disadvantages. One can argue, for example, that as a programming language becomes more friendly and easy to use, it also becomes more specialized and its domain decreases.2 So, as Figure 1 shows, as the level of programming increases, the domain for which programs can be written decreases. For example, in a menu based system, the user has very few options (limited domain) but it is certainly very easy to use. On the extreme (the apex of the pyramid), a program can be executed by a single keystroke. In the next section we will discuss one way in which graphical programming tools try allow "the best of both worlds." For example, the user may, if he/she wishes, create his program using a normal text editor, but later view and manipulate that same program graphically. Thus, the user can write programs for a larger domain and still be able to use graphics as a utility to programming. 3 Ill. Classification of the Tools Graphical programming can be defined as any kind of visual interaction between a computer and a human in order to complete some programming task. This interaction, however, does not only involve manipulation of text or programs written in a linear string of characters, but rather, of pictures or symbols of two-dimensional objects such as graphs, maps, flow charts, etc. Thus, the two-dimensional picture or pictures are used to represent the program. In recent years, many tools which allow graphical programming have been developed. Figure 2 below shows one way of classifying some of these tools: Graphical Programming Tools Based on conventional languages New Graphical Programming Languages Control Aow I Program Structure Data Structures - IconLisp Operations - IconLisp Iconic Programming - PICT Data Aow - HiVisual Aow Charts - Pecan N assi-Shneiderman Diagrams - Pecan Pascal Blox Methodology - Jigsaw Pascal Figure 2: Hierarchical Classification of Graphical Programming Tools In actuality, the divisions among the various tools are not as discrete as the above diagram indicates. In practice, many of the tools share the qualities of other types of tools. The above diagram does, however, give a general way of classifying most of the tools. In general, the various systems which implement a graphical programming environment can be divided into two major groups: • Systems which are based on conventional programming languages: 4 f r I r I [ [ [ [ r [ ( r l I l [ [ l These tools implement a graphical programming "layer" on top of conventional programming languages like Pascal or Lisp. So, underlying the graphics environment is a textual programming language. The visibility of this textual language to the user depends on the particular tool. Some tools merely offer graphics as another way to view a fundamentally textual program. Other tools give more flexibility to the user by allowing him/her to completely create and debug a program graphically. The tools which are based on conventional programming languages can be further subdivided into the following categories: • Tools which show Control Flow I Program Structure graphically: Flow Charts.· The most common method of showing control flow of a program is by a flowchart diagram. Flowcharts were originally developed as a tool for assembly-language programming, which allows completely unstructured control transfers. While flowcharts do allow a graphical representation of the control mechanism, the disciplined control constructs, scoping, and data structures of present-day programming languages render them obsolete as a graphical programming tool. Nevertheless, systems such as PECAN allow the user to view their programs as flowcharts. Nassi-Shneid.erman diagrams: Nassi-Shneiderman diagrams allow the structure of a program to be displayed graphically. Figure 3 shows a simple NassiShneiderman diagram for a binary search procedure. These types of diagrams when combined with syntax-directed editors provide a systematic method for building programs. The PECAN system, in addition to viewing the program as a flowchart, allows users to view their program as a Nassi-Shneiderman diagr1.m. While these types of diagrams are useful for showing program structure they do not show expressions, procedure calls, types, and data graphically. 5 PROCEDURE BinSearch PARAMETERS A Array [l.n] of integer X Integer (V AR) Integer LOCAL j,k Integer i := 1; j := n; while i~ i := k + 1; l j := k r [ [ I I Figure 3: A Nassi-Shneiderman diagram L Pascal Blox Methodology: The Pascal Blox Methodology3 is a method developed r by Glinert represents program structure by using "jigsaw"-like blocks in an interconnected fashion. Each jigsaw piece represents a particular construct in the language. The pieces are designed in such a way that the only way to combine the [ various types of structures is according to the syntax rules of the language. Thus, the user creates entire programs in a manner analogous to constructing jigsaw puzzles. Jigsaw Pascal is a simple implementation of such a methodology on the Macintosh microcomputer. While the entire system is not complete, later sections f of this paper will discuss planned implemenation and design of the system. • The second major type of systems are those which show the data structures in the language graphically: Surprisingly, there has been very little work on ways to display data structures graphically. One of the reasons for this is that data is usually very complex compared to control flow. Another reason for this is that data is often represented at many different levels of abstraction. Thus, it is difficult for the computer to determine what exactly a given data structure represents. For example, a graph may be represented by an adjacency matrix. But, unless told explicitly, the computer has no idea that the adjacency matrix represents a graph. For this reason, it cannot represent this information graphically. Nevertheless, IconLisp is a system (based on Lisp) which does allow the data structures to be represented graphically. But, this is simple in the case of Lisp since all data structures (and the programs themselves) are all of the same type: lists. • The third major category are tools which show the actual operations in the language graphically: 6 [ I l l l 1 l r [ l IconLisp, in addition to ·representing data structures graphically, allows the actual operations to be performed graphically. So, the user uses a mouse attached to the computer to "drag" an icon of an input list on top of an icon of a function. The computer computes the output list and represents the list by creating a new icon for the output list. Thus, the actual operation of applying a function to some input is done graphically. Again, this is simple in the case of Lisp because of the functional nature of the language. Such a technique would be difficult with Pascal since the language is procedural. All of the tools described above are based on conventional programming languages like Pascal and Lisp. Other systems implement programming languages which are completely new and based completely on graphics (very little text is involved). Iconic Pro~ramming: Some tools allow complete programs to be written by symbols called Icons. By putting these icons together, a runnable program is created. The PICT system, for example, allows the user to arrange icons in a manner similar to creating a flowchart. Once the program is created, it can be run directly -- without being converted to another textual language. The method of creating programs is so free of text that according to the creators, once the system is started, the keyboard is never used! However, even though this may seem nice at first, one can imagine how cumbersome the process of creating programs may get if the mouse is used for everything. Data Flow Lan~uages: In a dataflow graph, the flow of data and control coincide. These languages allow the user to create dataflow graphs on the screen and then specify inputs which are fed to this graph to produce a set of outputs. HiVisual is a system which implements this type of scheme to create programs. An advantage of these types of languages is that they are well suited for program animation. The user can watch the data "flow" from one module to another. However, one problem this scheme shares with flowcharts is that the lack of high-level control constructs usually lead to messy diagrams. 7 IV. Survey of Graphical Programming Tools Graphical programming tools are now being utilized for the design, implementation, and testing phases in the software life-cycle. In this section, we will discuss some of the tools currently being used in the programming phase. First, we will introduce some of the diagramming tools that are often used by programmers. Next, we will discuss some of the systems which implement some subset of these diagramming tools. For each system, we shall discuss its overall capabilities, its place in the previously discussed classification scheme, and its overall advantages and disadvantages. A. Dia~:rammim: Tools Most programmers use some sort of diagramming technique to describe the overall structure of their programs. For example, a module inter-connection graph, where arrows are drawn between boxes, may be used to represent access to different code or data. Through the history of Computer Science, several such diagramming tools have been developed to aid the programmer in creating programs. Flowcharts: We have already discussed the use of flowcharts in a previous section. Flowcharts are nice for showing the control flow of programs. One of the problems that occurs, however, is that often times the diagram becomes too messy. When drawn on paper, this is obviously a problem. But, when implemented on a computer, the user may be given the capability to "hide" sections of the flowchart and thus keep only the section of current interest visible. Even with such features though, flowcharts cannot be used to display data structures of programs. They also need to be modified to allow common control constructs such as for/next loops, while loops, do/until loops, etc. Nassi-Shneiderman diagrams: As discussed earlier, these types of diagrams impose structure on program control and provide a systematic method (top-down) for building programs. But, these types of diagrams do not show the expressions, procedure calls, types, or data structures graphically; the diagrams still are mostly text State Transition dia(p"ams: These types of diagrams can be used for automaton-type program parts. These diagrams show the inputs and outputs of units very clearly. In a way, state transition diagrams are related to flowcharts and thus suffer from the same disadvantages -lack of graphical display of data structures and program control structures. Data Flow dia~ams: These types of diagrams show how data flows from one unit to another. In these types of graphs, data flow and control flow coincide, thus simplifying the diagrams. The simple structure of dataflow graphs encourages modular design and can be used at all levels of system description. Such diagrams are also useful in identifying potential units which can be executed in parallel. Data Flow graphs share the problems found in flowcharts: the diagrams can get very messy for large systems. Another problem with data flow graphs is that they do not convey any other information beyond the node and arc names and their connectivity. The above diagramming methods are often used by programmers to aid in designing and implementing systems. These diagrams are normally done on paper and can get very messy. Ideally, one would like to be able to enter these types of diagrams directly into the computer and then have the computer generate the program(s) from these diagrams. This would not only save the time and effort of creating diagrams on paper, but would also eliminate the need of converting the diagram into an actual program which the computer can execute. Some of the systems discussed in the next section implement some form of this approach. 8 [ r I f r l I l [ [ [ l l [ l [ l l B. PECAN The PECAN4 family of programs are program development systems developed at Brown University. PECAN provides users with a rich programming & run-time environment which allows graphical views of the user program, its semantics, and its execution. In PECAN, for example, users for the most part indicate the sequence of actions they wish to perform by pointing with a mouse to entries in fixed and/or popup menus. The built-in editor recognizes Pascal syntax and thus can immediately highlight erroneous statements. At runtime, users can follow the computer's progress through the program with each statement being highlighted as it is executed. The system was developed to run on APOLLO workstations. The main objective of the system is to provide a graphical programming environment for the novice and experienced programmers. PECAN contains many of the best features of other, similar systems. These include: • immediate feedback of semantic and syntactic errors while the user is editing the source program (syntax-directed editor), • an undo facility whereby the user can undo and redo any action back to the beginning of the session, • structured templates for building the program, • the flexibility to type text at any time instead of using templates, • the use of on-screen and pop-up menus as an alternative to typing most commands, • a multiple window display to make effective use of the screen, • incremental semantics that allows the program to be compiled as it is edited, • a framework that handles a variety of (algebraic) programming languages with the same commands. The PECAN system differs from other program development systems in its use of multiple r views of user programs. One such view is a syntax-directed editor. This view displays the user program in a "pretty-print" format-- automatic indentation and bold-facing of Pascal keywords. Another view displays the program as a N assi-Shneiderman diagram. A third view shows a module inter-connection diagram showing how the program is organized. Figure 4 shows the screen at some time in program development. Note that several views .may be displayed simultaneously, each in its own window. In addition to the different program views, PECAN allows the user program to be compiled incrementally. The user can also view the symbol tables, data types, expression trees, and the control-flow graph of the program in separate windows. According to the classification discussed earlier in this paper, PECAN fits into the category of programming environments which are based on conventional programming languages. This is due to the fact that the entire system is based on Pascal. In general, PECAN is a complete development system for Pascal programs. Actually, the system is modular enough to allow other languages to be supported. One of the drawbacks of the system, though, is that the actual data structures cannot be rendered graphically. Also, the user cannot create the program graphically; he/she must create the textual Pascal program first, and then may choose to view it in different ways. 9 !; lr.terpreter far exiiPl~ . . >>> Nor~al ter~ination >>> Continue execution >>> Nor~al ter~ination >>> Progra~ is ready to run >>> Begin execution ••• 135 63 Result is >>> User halted execution FUNCTION gcd; http://uab.contentdm.oclc.org/cdm/ref/collection/uab_ece/id/53 |
Nájsť tento článok vo Web of Science