TL;DR: This paper attempts to provide more meaning to Visual Programming and Program Visualization terms by giving precise definitions, and then uses these definitions to classify existing systems into a taxonomy.
Abstract: 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.
TL;DR: A number of additional features dealing with modeling system resources, message passing, data collection and debugging which ease the task of building simulation models are added to CSIM.
Abstract: CSIM is a process-oriented simulation language which is implemented as a superset of the C programming language. Using CSIM, a simulation programmer is able to quickly construct concise models of systems and then to execute these models in an efficient manner. In addition to supporting process-oriented simulation, CSIM as a number of additional features dealing with modeling system resources, message passing, data collection and debugging which ease the task of building simulation models.
TL;DR: This book shows how to build production-quality programsprograms that are reliable, easy to maintain, and quick to modify with an emphasis on modular program construction.
Abstract: From the Publisher:
Written by a world-renowned expert on programming methodology, this book shows how to build production-quality programsprograms that are reliable, easy to maintain, and quick to modify. Its emphasis is on modular program construction: how to get the modules right and how to organize a program as a collection of modules. The book presents a methodology effective for either an individual programmer, who may be writing a small program or a single module in a larger one; or a software engineer, who may be part of a team developing a complex program comprised of many modules. Both audiences will acquire a solid foundation for object-oriented program design and component-based software development from this methodology.
Because each module in a program corresponds to an abstraction, such as a collection of documents or a routine to search the collection for documents of interest, the book first explains the kinds of abstractions most useful to programmers: procedures; iteration abstractions; and, most critically, data abstractions. Indeed, the author treats data abstraction as the central paradigm in object-oriented program design and implementation. The author also shows, with numerous examples, how to develop informal specifications that define these abstractionsspecifications that describe what the modules doand then discusses how to implement the modules so that they do what they are supposed to do with acceptable performance.
Other topics discussed include:
Encapsulation and the need for an implementation to provide the behavior defined by the specification Tradeoffs between simplicity and performanceTechniques to help readers of code understand and reason about it, focusing on such properties as rep invariants and abstraction functions Type hierarchy and its use in defining families of related data abstractions Debugging, testing, and requirements analysis Program design as a top-down, iterative process, and design patterns
The Java programming language is used for the book's examples. However, the techniques presented are language independent, and an introduction to key Java concepts is included for programmers who may not be familiar with the language.
TL;DR: This study investigated the planning and debugging strategies and group processes that predicted learning of computer programming in small groups and found that demographic characteristics, aptitudes, and cognitive style measures did not predict planning, debugging, or verbal interaction.
Abstract: This study investigated the planning and debugging strategies and group processes that predicted learning of computer programming in small groups. Thirty students aged 11 to 14 learned Beginners All-Purpose Symbolic Instructional Code (BASIC) in 2-person groups. Students showed little advance planning; their style of planning and debugging was opportunistic. Specific planning and debugging variables that predicted learning included high-level planning of chunks of the program, and low-level planning and debugging of single statements. Group interaction variables related to learning included giving and receiving explanations, receiving responses to questions, and verbalizing input aloud while typing at the keyboard. Student demographic characteristics, aptitudes, and cognitive style measures did not predict planning, debugging, or verbal interaction.
TL;DR: CARL as mentioned in this paper is a computer program that learns about the semantics of assignment statements for the BASIC programming language, and it is described as an illustration of causally driven analogical reasoning and learning.
Abstract: This chapter presents a model of learning by analogical reasoning. The model is based on two main ideas, namely, ( 1 ) that the analogies used in learning about an unfamiliar domain depend heavily on the use of previously formed causal abstractions in a familiar or base domain; (2) that these analogies are extended incremenrally to handle related situations. CARL is a computer program that learns about the semantics of assignment statements for the BASIC programming language. It is described as an illustration of causally driven analogical reasoning and learning. The model maps and debugs inferences drawn from several commonly used analogies to assignment in response to presented examples.
TL;DR: A new way to assess children's acquisition of debugging skills in a LOGO environment is proposed, based on an explicit and precise model (in the form of a computer simulation) of good debugging skills.
Abstract: In this article, we propose a new way to assess children's acquisition of debugging skills in a LOGO environment. The assessment procedure is based on an explicit and precise model (in the form of a computer simulation) of good debugging skills. The model has four stages: 1) evaluating the program's planned and actual outcomes to determine that debugging is necessary, 2) identifying the bug by using descriptions of the discrepancy between the planned and actual outcomes to propose potential bugs, 3) locating the bug by using clues about the structure of the program to narrow the search, and 4) correcting the bug and retesting the program. We describe model-based measurements of the LOGO debugging skills actually acquired by students in a “typical” LOGO graphics course. Nine seven- to nine-year-olds were given twenty-four hours of LOGO training over a three-week period. Students learned the editing and command generation skills prerequisite to debugging but were not able to interpret commands and use clues...
TL;DR: A set of desirable characteristics for a debugger for concurrent languages is deduced from a review of the differences between the debugging of concurrent programs and that of sequential ones and a debugger for concurrent language based upon CSP is described.
Abstract: The authors discuss issues related to the debugging of concurrent programs. A set of desirable characteristics for a debugger for concurrent languages is deduced from a review of the differences between the debugging of concurrent programs and that of sequential ones. A debugger for concurrent language based upon CSP is then described. The debugger makes it possible to compare a description of the expected program behavior to the actual behaviour. The description of the behavior is given in terms of expressions composed by events and/or assertions on the process state. The developed formalism is able to describe behaviors at various levels of abstraction. Lastly, some guidelines for the implementation of the debugger are given and a detailed example of program debugging is analyzed.
TL;DR: In this article, the authors use a model of distributed computation and measurement to implement a program monitoring system for programs running on the Berkeley UNIX 4.2BSD operating system, which describes the activities of the processes within a distributed program in terms of computation and communication.
Abstract: Writing and debugging distributed programs can be difficult. When a program is working, it can be difficult to achieve reasonable execution performance. A major cause of these difficulties is a lack of tools for the programmer. We use a model of distributed computation and measurement to implement a program monitoring system for programs running on the Berkeley UNIX 4.2BSD operating system. The model of distributed computation describes the activities of the processes within a distributed program in terms of computation (internal events) and communication (external events). The measurement model focuses on external events and separates the detection of external events, event record selection and data analysis. The implementation of the measurement tools involved changes to the Berkeley UNIX kernel, and the addition of daemon processes to allow the monitoring activity to take place across machine boundaries. A user interface has also been implemented.
TL;DR: In this article, a method and apparatus for debugging computer programs without recompiling them is described, which is based on the idea that the programmer can select or deselect the macros from the command line and run the program repeatedly without recompilation the program for different tests.
Abstract: A method and apparatus for debugging computer programs without recompiling them is disclosed. Marcos which may be called on to expand into operable code are inserted in the program at various locations. The programmer may select or deselect the macros from the command line and run the program repeatedly without recompiling the program for different tests. Marcos may also be deselected permanently and reversibly by recompiling with the marcos undefined so that they expand to empty code. Argument processing code and symbol table code are provided to control and track the debugging procedure.
TL;DR: Dbxtool is a window‐ and mouse‐based debugger for C, Pascal and FORTRAN programs running on Sun workstations that has been extended with the abilities to debug multiple‐process programs, already‐running processes, and the Sun Operating System kernel.
Abstract: Dbxtool is a window- and mouse-based debugger for C, Pascal and FORTRAN programs running on Sun workstations. Its use of the mouse as the primary input mechanism eliminates the need to type variables, line numbers, breakpoints and most commands. Its multiple windows provide several qualitatively different perspectives on the debugging problem. Compared to the Unix 4.2 BSD dbx from which it is derived, it has been extended with the abilities to debug multiple-process programs, already-running processes, and the Sun Operating System kernel.
TL;DR: The debugging strategies learned from explicit Instruction in the the first computer programming mini-course had a positive impact on children's debugging in both new programming and non-programming situations.
Abstract: The goal of thls dissertation is to determine the extent to which learning debugging in the context of LOGO programming improves children's debugging in other programming and nonprogramming contexts. The approach involves detailed task analysis of debugging (in the form of a computer simulation model), development of model-based instructional guidelines for teaching children debugging skills they do not learn "by discovery." and assessment of the debugging skills children are able to transfer to other programming and non-programming tasks. Twenty-tWo 8to I1-year-old students took two 25 hour LOGO courses. Halt of the students were taught debugging In the context of a LOGO graphics course first and then a LOGO list-processing course. The other half were taught debugging in the same two minicourses but In the reverse order. Debugging skills were tested at three times during each mini-course. The performance of children taking tests In the first mfrtl-course was compared with the performance of children taking the same tests in the seconFrmlni-course to reveal the transfer from one LOGO domain to the other. Debugging on no44-pregramming tasks was assessed prior to the first mini-course, between minl-courses, and after the last minicourse to assess more remote transfer of debugging skills. Assessments of students' debugging skill revealed large savings from the first to the second mini-course. Students' Increasing use of selective search strategies increased the accuracy. efficiency, and :peed of their debugging. Corresponding Improvements were demonstrated on a variety of tasks requiring debugging of non-computer directions. Children shifted from exhaustive to selectiVe search strategies which increased the accuracy. efficiency, and speed with which they debugged written directions; Thus; the debugging strategies learned from explicit Instruction in the the first computer programming mini-course had a positive impact on children's debugging in both new programming and non-programming situations.
TL;DR: An interactive Prolog debugger, Dewlap, is described, which is implemented in Prolog on relatively standard hardware with a central processor running Unix and remote workstations with bit-mapped displays and mice.
Abstract: An interactive Prolog debugger, Dewlap , is described. Output from the debugger is in the form of graphical displays of both the derivation tree and the parameters to procedure calls. The major advantage of such displays is that they allow important information to be displayed prominently and unimportant information to be shrunk so that it is accessible but not distracting. Other advantages include the following: the control flow in Prolog is clearly shown; the control context of a particular call is readily determined; it is easy to find out whether two uninstantiated variables are bound together; and very fine control is possible over debugging and display options. A high level graphics language is provided to allow the user to tailor the graphical display of data structures to particular applications. A number of issues raised by the need to update such displays efficiently and to control their perceived complexity are addressed. The Dewlap system is implemented in Prolog on relatively standard hardware with a central processor running Unix and remote workstations with bit-mapped displays and mice.
TL;DR: A program debugging system for a computer having an arithmetic/logic controller for implementing operations for data in accordance with a stored program and a program debugging device for issuing commands for correcting program errors to the arthmetric logic controller is described in this paper.
Abstract: A program debugging system for a computer having an arithmetic/logic controller for implementing operations for data in accordance with a stored program and a program debugging device for issuing commands for correcting program errors to the arithmetic/logic controller, the system comprising a readout data addressing unit incorporated in the program debugging device for specifying the address of data which has caused an error in the arthmetic/logic controller, an address setting memory for writing the address specified by the readout data addressing unit into the arithmetic/logic controller, a data readout commander incorporated in the program debugging device for commanding the readout of the error-causing data in response to the input command issued on an input console provided in the program debugging device, a data hold/transfer unit for reading out data in the address set in compliance with the detection by an error detector in the arithmetic/logic controller and delivering it to a data receive/edit unit in the program debugging device, the data receive/edit unit receiving data from the data hold/transfer unit, editing the received data, and displaying the edited data on a display unit via a display controller.
TL;DR: Meglos is a multiprocessor operating system that is ideal for real-time applications and provides the user with a distributed programming environment for developing, running, and debugging application programs.
Abstract: Meglos is a multiprocessor operating system that is ideal for real-time applications. It provides the user with a distributed programming environment for developing, running, and debugging application programs. Meglos allows a single application to span several processors. Further, unrelated programs may run independently of each other on the same processor. A simple, yet powerful, mechanism for communications between programs is provided. With the current hardware configuration, up to twelve Motorola 68000 Multibus computer systems and a DEC VAX host running the UNIX operating system can be connected via the S/NET interconnect. Meglos exhibits communications latencies of 750 μsec, sufficiently small for most real-time applications.
TL;DR: Failure times of software undergoing random debugging can be modelled as order statistics of independent but nonidentically distributed exponential random variables so that inferences can be made about current reliability and, if debugging continues, future reliability.
Abstract: Failure times of software undergoing random debugging can be modelled as order statistics of independent but nonidentically distributed exponential random variables. Using this model inferences can be made about current reliability and, if debugging continues, future reliability. This model also shows the difficulty inherent in statistical verification of very highly reliable software such as that used by digital avionics in commercial aircraft.
TL;DR: A distributed real‐time operating system, Fados, has been developed for an embedded multiprocessor system based on a host‐target approach and provides for communication between arbitrary processes on host and target machines.
Abstract: A distributed real-time operating system, Fados, has been developed for an embedded multiprocessor system. The operating system is based on a host-target approach and provides for communication between arbitrary processes on host and target machines. The facilities offered are, apart from process communication, access to the file system on the host by programs on the target machine and monitoring and debugging of programs on the target machine from the host. The process communication has been designed in such a way that the possibilities are the same as those offered by the Ada programming language. The operating system is implemented on an MC 68000 based multiprocessor system in combination with a Unix1 host.
TL;DR: The experiment investigated the effects of various high-level control strategies on the quality of the problem solution, the speedup of the overall system performance as a function of the number of processors in the grid, and some of the issues in implementing and debugging a knowledge-based system on a message-passing multiprocessor system.
Abstract: This report documents an experiment investigating the potential of a parallel computing architecture to enhance the performance of a knowledge-based signal understanding system. The experiment consisted of implementing and evaluating an application encoded in a parallel programming extension of Lisp and executing on a simulated multiprocessor system. The chosen application for the experiment was a knowledge-based system for interpreting pre-processed, passively acquired radar emissions from aircraft. The application was implemented in an experimental concurrent, asynchronous object-oriented framework. This framework, in turn, relied on the services provided by the underlying hardware system. The hardware system for the experiment was a simulation of various sized grids of processors with inter-processor communication via message-passing. The experiment investigated the effects of various high-level control strategies on the quality of the problem solution, the speedup of the overall system performance as a function of the number of processors in the grid, and some of the issues in implementing and debugging a knowledge-based system on a message-passing multiprocessor system. In this report we describe the software and (simulated) hardware components of the experiment and present the qualitative and quantitative experimental results.
TL;DR: Anna is a language for writing machine-processable annotations of Ada programs for consistency with its formal specifications written in Anna.
Abstract: Anna is a language for writing machine-processable annotations of Ada programs. One of the main applications of Anna is the runtime checking of an Ada program for consistency with its formal specifications written in Anna. On single-processor systems, Anna runtime checks are used during testing and debugging of software.
TL;DR: This debugger enables designers of kernels for distributed multinode systems to work in a Unix environment and to interact with the target nodes via a console.
Abstract: Intended for designers of kernels for distributed multinode systems, this debugger enables them to work in a Unix environment and to interact with the target nodes via a console.
TL;DR: In this paper, the authors present tools for interprocedural program analysis, able to analyze at high levels large FORTRAN programs composed of many subroutines and to perform an automatic high-level parallelism.
Abstract: The demand for very high computing performance has become increasingly common in many scientific and engineering environments. In addition to vector processing, parallel computing is now considered a useful way to enhance performance. However, parallel computing tends to be unpopular among users because, with presently available technology and software, it requires explicit programmer intervention to exploit architectural parallelism. This intervention can be minor in some cases, but it often requires a non-negligible amount of program restructuring, or even a reformulation of some of the algorithms used. In addition, it makes program debugging considerably more difficult. Tools for interprocedural program analysis, able to analyze at high levels large FORTRAN programs composed of many subroutines and to perform an automatic high-level parallelism could also be exploited automatically.
TL;DR: In parallel with these short-term and comparatively easy but effective improvements, technologies which are expected to produce larger gains but which are much more expensive to achieve are explored.
Abstract: While each of the efforts described above significantly improves some aspect of the programming environment on Sun workstations, it is obvious that today's technology allows us to go further. Thus, in parallel with these short-term and comparatively easy but effective improvements, we continue to explore technologies which are expected to produce larger gains but which are much more expensive to achieve. These include fine-grained incremental compilation integrated with editing and debugging, as exemplified by Fritzson's DICE system [Frit84], and an effort to better integrate version control, configuration management, release building and bug tracking more tightly with each other and with an underlying database.
TL;DR: A high-LEVEL DEBUGGING approach is developed in which DEBUGGing is viewed as a process of CREATING MODELS of ACTUAL BEHAVIOR, andTERN RECOGNITION in support of BeHAVIoral ABSTRACTION is shown to be more than a SIMPLE PARSING EXERCISE.
Abstract: DEBUGGING IS AN ACTIVITY THAT ATTEMPTS TO LOCATE THE SOURCES OF ERRORS IN THE SPECIFICATION AND CODING OF A SOFTWARE SYSTEM AND TO SUGGEST POSS- IBLE REPAIRS THAT MIGHT BE MADE TO CORRECT THE ERRORS. DEBUGGING COMPLEX DISTRIBUTED PROGRAMS IS A FRUSTRATING AND DIFFICULT TASK. THIS IS DUE PRIMARILY TO THE PREDOMINANCE OF A LOW-LEVEL, COMPUTATION-UNIT VIEW OF SYS- TEMS. THIS EXTANT PERSPECTIVE IS NECESSARILY DETAIL INTENSIVE AND OFFERS LITTLE AID IN DEALING WITH THE HIGHER LEVEL OPERATIONAL CHARACTERISTICS OF A SYSTEM OR THE COMPLEXITIES INHERENT IN DISTRIBUTED SYSTEMS. IN THIS DISSERTATION WE DEVELOP A HIGH-LEVEL DEBUGGING APPROACH IN WHICH DEBUGGING IS VIEWED AS A PROCESS OF CREATING MODELS OF ACTUAL BEHAVIOR. THE DIFFERENCES BETWEEN THE ACTUAL AND EXPECTED MODELS CAN BE USED TO CHARAC- TERIZE ERRORFUL BEHAVIOR. THE BASIS FOR THE APPROACH IS VIEWING THE ACTIV- ITY OF A SYSTEM AS CONSISTING OF A STREAM OF SIGNIFICANT, DISTINGUISHABLE EVENTS THAT MAY BE ABSTRACTED INTO HIGH-LEVEL MODELS OF SYSTEM BEHAVIOR. AN EXAMPLE IS PRESENTED TO DEMONSTRATE THE USE OF EVENT BASED MODEL BUILD- ING TO INVESTIGATE AN ERROR IN A DISTRIBUTED PROGRAM. BEHAVIOR ABSTRACTION AND SYSTEM UNDERSTANDING ARE CHARACTERIZED AS PROB- LEMS IN PATTERN RECOGNITION THAT MUST OPERATE IN A NOISY, UNCERTAIN ENVIR- ONMENT. PATTERN RECOGNITION IN SUPPORT OF BEHAVIORAL ABSTRACTION IS THUS SHOWN TO BE MORE THAN A SIMPLE PARSING EXERCISE. A FORMAL MODEL IS DEVELOP
TL;DR: A prototype of a realtime high level debugging system is introduced, which allows debugging of programs written in a high level language and based on an object oriented realtime multitasking kernel in the target microcomputer.
TL;DR: A number of simple modern software engineering techniques can be applied to simulation programs in a practical way to improve both the quality of the simulation and the productivity of the simulator.
Abstract: Developing simulation programs shows many similarities with classical system software development tasks. In simulation one is often concerned with allocating and deallocating resources. Two forms of deadlock — the 'deadly embrace' and 'apre-vous' — can be troublesome to simulators unless they know how to avoid them in the first place. Critical races and time dependent functions are other characteristics shared between simulation and systems programming. If simulation is viewed and taught as data processing, the simulator will be ill-prepared for writing simulation code.Most simulations in industry are not written by skilled software developers. There is good reason for this: the simulation writer must ultimately understand the problem, its features and the managerial concerns that lead to the requirement for the simulation. However, simulation writers with no software training are poorly equipped for developing simulation code that is easy to design, debug, verify, maintain and explain. A number of simple modern software engineering techniques which are described in this paper can be applied to simulation programs in a practical way to improve both the quality of the simulation and the productivity of the simulator.
TL;DR: The maximum likelihood estimator of the initial number of errors in a software is derived and inherent difficulties in estimating the correlation from standard debugging data are discussed.
Abstract: This paper identifies some essential features of any statistical model for analyzing software failure data. A model for incorporating dependence among the detection times of the errors is proposed and several reliability measures are calculated. The maximum likelihood estimator of the initial number of errors in a software is derived and inherent difficulties in estimating the correlation from standard debugging data are discussed.
TL;DR: A NMR programmer is described which is built around a logic idea and a set of specifications, rather than availability of special or new integrated circuits, to meet the requirements of recently suggested selective excitation and imaging experiments in liquids.
Abstract: A NMR programmer is described which is built around a logic idea and a set of specifications, rather than availability of special or new integrated circuits. We begin by discussing what a quintessential Touring machine can do to solve the problem of outputting words (or pulses) with the resolution of the system clock over arbitrarily long time intervals. We then illustrate a simple realization of this machine, with 4096 program lines, 25‐ns resolution, two 16‐bit output lines, the possibility of nesting loops down to the 256th level, and a component cost in the 102 $ range. A software ‘‘human’’ interface has been developed in an IBM‐PC compatible (MS‐DOS) environment, which simplifies the task of debugging the entire NMR spectrometer, and that of designing new experiments. While certainly overspecified for all traditional solid‐state NMR experiments, our programmer may meet the requirements of recently suggested selective excitation and imaging experiments in liquids.
TL;DR: An extension of attribute grammars is introduced that supports the generation of run-time environments and also supports thegeneration of interpreters, symbolic debugging tools, and other execution-time facilities.
Abstract: Attribute grammars have been used for many years for automated compiler construction. Attribute grammars support the description of semantic analysis, code generation and some code optimization in a formal declarative style. Other tools support the automation of lexical analysis and parsing. However, there is one large part of compiler construction that is missing from our toolkit: run-time environments. This paper introduces an extension of attribute grammars that supports the generation of run-time environments. The extension also supports the generation of interpreters, symbolic debugging tools, and other execution-time facilities.
TL;DR: This specialized hardware assists program debugging and testing and program performance evaluation and programperformance evaluation.
Abstract: This specialized hardware assists program debugging and testing and program performance evaluation. It is installed like any other peripheral device.