TL;DR: Vidoetaped protocols of experienced programmers as they enhanced a personnel data base program are analyzed and it is suggested that there are two strategies for program understanding, the systematic strategy and the as-needed strategy.
TL;DR: It is shown that the presented techniques can increase the number of detectable errors as compared with error detection through data flow analysis alone.
TL;DR: This paper presents strictness analysis, a semantics-based approach to program analysis that uses compile time evaluation of programs using simplified value domains that gives information about the run-time properties of programs and provides the basis for significant performance improvements.
Abstract: Recently there has been much interest in the abstract interpretation of declarative languages. Abstract interpretation is a semantics-based approach to program analysis that uses compile time evaluation of programs using simplified value domains. This gives information about the run-time properties of programs and provides the basis for significant performance improvements. A particular example of abstract interpretation is strictness analysis which allows the detection of the parameters in which a function is strict; these parameters may be passed by value without compromising the termination properties of the program.
TL;DR: The main objective in developing RNet is to investigate how high-level programming concepts and tools can be used to simplify the real-time programming task.
Abstract: RNet is a high-level programming system for building and executing distributed hard real-time programs. The main objective in developing RNet is to investigate how high-level programming concepts and tools can be used to simplify the real-time programming task. A distributed real-time program in RNet consists of a configuration specification that outlines the structure and real-time properties of the program, and a set of program modules written in a high-level programming language. The RNet configuration system performs a static feasibility analysis of the specifications and handles the construction, distribution, and execution of the program. A debugging and timing analysis system, currently under development and not described here, will be used to measure the real-time characteristics of network resources and the application program, and to perform a validation of the specifications via simulation. The distributed RNet kernel provides run-time support for message-passing and real-time scheduling. The RNet programming model, based on message ports having associated deadlines, provides the programmer with a direct means of expressing a variety of real-time behavioral effects in a way that can be validated. In particular, timing constraints can be used to obtain reliable event synchronization. Some properties that are considered desirable in a high-level distributed real-time programming system are identified. These address issues such as program moduilarity and reconfigurability, timing constraint specification, validation and enforcement, real-time event handling, I/O and exception handling, logical and physical structure specification, and program analysis. The degree to which RNet succeeds in possessing these properties is discussed.
TL;DR: The semantics of programs was a prelude necessary to make explicit exactly what programs do; the direction of this book now turns to the central issue: how to establish that a program does the right things.
Abstract: The semantics of programs was a prelude necessary to make explicit exactly what programs do. The direction of this book now turns to the central issue: how to establish that a program does the right things. It is assumed to begin with that programs are syntactically correct. The detection of syntax errors—missing parentheses and the like—belongs to the study of formal languages. Here the issue is detecting semantic errors incorrect loop initialization and the like.
TL;DR: A formalism, called the Plan Calculus, is defined and used to represent programming cliches in a convenient, canonical, and programming-language independent fashion.
Abstract: Inspection methods are a kind of engineering problem solving based on the recognition and use of standard forms or {\it cliches}. Examples are given of program analysis, program synthesis and program validation by inspection. A formalism, called the Plan Calculus, is defined and used to represent programming cliches in a convenient, canonical, and programming-language independent fashion.
TL;DR: For over a decade, major research efforts have been directed at developing and applying Program Verification Systems, including the Gypsy Verification Environment and Affirm-85.
Abstract: For over a decade, major research efforts have been directed at developing and applying Program Verification Systems. Particular examples are the Gypsy Verification Environment (at The University of Texas at Austin and Computational Logic, Inc.), and Affirm-85 (at General Electric, Schenectady, New York).
TL;DR: A small existing program was converted to perform finite element analysis by distributing substructure analysis over a network of four Apple IIe microcomputers connected to a shared disk, simulating a parallel computer.
TL;DR: A method for selecting test data that uses reasoning to derive test cases that show incongruence between assertions, i.e., what the programmer thinks the program does and what the program actually does is presented.
TL;DR: The trace method of software specification is extended to provide a natural semantics for procedural programming languages and is compared with other approaches for the giving program semantics and is seen to provided a method for proving program correctness that avoids the problems of those currently in use.
Abstract: : Traditional methods for proving program correctness the implementation-dependent specification methods. If abstract specifications are also used, these methods require a leap of faith to bridge the gap between an abstract specification and a program correctness statement. In this report the trace method of software specification is extended to provide a natural semantics for procedural programming languages. This extension is compared with other approaches for the giving program semantics and is seen to provide a method for proving program correctness that avoids the problems of those currently in use. Keywords: computer program verification; trace specification language.
TL;DR: The specification of a software repeater in a language known as Z is presented and then refined into an implementation in the C programming language, which ran successfully on a 68010 processor.
Abstract: : The specification of a software repeater in a language known as Z is presented. The specification is then refined into an implementation in the C programming language. The correctness of the implementation is shown by means of proof obligations and the program analysis tool Malpas. The C implementation was compiled and ran successfully on a 68010 processor.
TL;DR: A program which translates an algorithmic language such as ALGOL into the machine language of an electronic computer performs the following functions: Analysis.
Abstract: A program which translates an algorithmic language such as ALGOL into the machine language of an electronic computer performs the following functions: Analysis. From the program in algorithmic language are determined the operations which the computer must perform in the execution of the target program and the logical interdependence of these. Optimization. Of the many possibilities for optimization that exist, two are pertinent to this note: (2a) the elimination of superfluous operations, and (2b) the execution at translation time of those operations which do not depend on results produced by the target program. Synthesis. The sequence of operations which arise from steps 1 and 2 is expressed in the language of the computer and placed into the target program.
TL;DR: A novel approach which allows one to symbolically evaluate programs with respect to predicates denoting subsets of a user-defined data domain is focused on.
TL;DR: The verification procedure used by TUV Rheinland consists of program analysis and test, which consists in a “diverse back development” and gains step by step the specification of the solved problem.
TL;DR: In this paper, the source program is generated automatically by a program generating system based on the generated specification, and the program is analyzed to correct the specification in the program analysis system and the specification generation system.
Abstract: PURPOSE:To save the time and labor for maintenance by generating a specification automatically when the source program is desired to be corrected and changed. CONSTITUTION:A terminal equipment 2 and a tablet 3 are used, the specification of the program is generated in a specification analysis system 21 by forming a processing graphic and variables on a table. Based on the generated specification, the source program is generated automatically by a program generating system 22. At the time of desiring it to correct or change, the source program is analyzed to correct the specification in the program analysis system 23 and the specification generation system 24.
TL;DR: In this paper, the authors propose a system to facilitate the discovery of the error of input data and a program, and to improve the development and maintenance efficiency of the program by providing a means to compare the value of the data, a means of detecting the error from the comparing result and a mean to output the error information.
Abstract: PURPOSE: To facilitate the discovery of the error of input data and a program, and to improve the development and maintenance efficiency of the program by providing a means to compare the value of the data, a means to detect the error from the comparing result and a means to output the error information CONSTITUTION: When a system investigates the relation between the data and the relation is not satisfied, the value of the data, the relation between the data and the position in the user program are outputted and the checking result is returned to a user program Namely, the user describes the range obtained by the value of the variable and the size relation of the variable and the variable in a program 11, and at the time of executing the program, the system checks these relations by a checking instruction 12 Thus, the user knows the cause and place of the error of the logic of the input data and the program, facilitates the error countermeasure and can achieve the efficiency improvement of the program development and maintenance By checking at the time of the execution, the reliability of the calculation result of the program can be improved when these checking results are all normal COPYRIGHT: (C)1989,JPO&Japio
TL;DR: The Project aims at a prototype of an integrated Advanced Logical Programming Environment that shall incorporate tools for Program Construction and Transformation, Program Analysis and Program Debugging, Object and Function Handling, Editors Browsers and Graphical Interfaces.
Abstract: The Project aims at a prototype of an integrated Advanced Logical Programming Environment. It shall incorporate tools for Program Construction and Transformation, Program Analysis and Program Debugging, Object and Function Handling, Editors Browsers and Graphical Interfaces, Parallelism and Distributed Prolog, Metalevel Reasoning and Non-classical logics.
TL;DR: In this paper, an instrument's process is controlled by a computer which has two concurrently defined tasks: an operator task for running an instrument control program, and a compiler task for compiling new instrument control programs input by the instrument's user.
Abstract: of EP0270359An instrument's process is controlled by a computer which has two concurrently defined tasks: an operator task for running an instrument control program, and a compiler task for compiling new instrument control programs input by the instrument's user. The currently running program is suspended and a new program's execution is begun when (a) a new program has been successfully compiled by the compiler, and (b) the current program is about to perform a jump back at the end of an instruction loop. When a main instrument control program finishes executing, a new program is run if a new program has been successfully compiled; otherwise, execution of the most recently suspended program resumes. Thus a newly compiled program interrupts the currently running program only between instruction loops, and only as long as necessary to execute its instructions. If the newly compiled program merely resets a parameter, this interruption is generally so short as to be unnoticeable. If, on the other hand, the newly compiled program is designed to control the instrument's process for a period of time, the new program takes control until it finishes execution. Thus the instrument's user is provided not only with the feel of being able to reset parameter values on the fly, but also with a flexible tool for revising an instrument control program on the fly.
TL;DR: An interactive solution to the first major difficulty in designing a non- procedural modelling system is to specify the information to be derived from the non-procedural program, based on a purely structural analysis of the program.
TL;DR: This report applies some methods from the theory of group representation to the questions of program specification and knowledge about programs.
Abstract: This report applies some methods from the theory of group representation to the questions of program specification and knowledge about programs. The theory is that of a program as a transformation on a state space, and operators commuting with that transformation being symmetries of the program, means of specifying properties, and generators of program invariants. Because a program can simulate a system in the real world, there is a corresponding model of engineered artifacts, that is, manmade objects having a theory for their design.
TL;DR: In this paper, a tuning tool editing part 11 analyzes the option of tuning in response to a tuning indication specified by a source program 10 to perform editing according to the option and also output editing information to an editing information file 16.
Abstract: PURPOSE:To obtain information useful for a program analysis, etc., by finding the number of times of execution of an arithmetic IF statement of FORTRAN according to the evaluation result of an arithmetic expression in parentheses. CONSTITUTION:A tuning tool editing part 11 analyzes the option of tuning in response to a tuning indication specified by a source program 10 to perform editing according to the option and also output editing information to an editing information file 16. The edited source program 17 contains a source module in which statements for obtaining tuning information are incorporated. A translation execution part 18 compiles the edited source program 17 and a linkage editor edits it to the executable form and executes it. A tuning tool analysis part 24 is called by a CALL statement generated by the tuning tool editing part 11.
TL;DR: The approach enables a maintenance programmer to focus on a much less complicated piece of codes before dealing with more complicated ones, functions can be identified in a more manageable fashion especially when, in any particular slice, statements which implement the functions that have been identified from the other statements in that slice are distinguished.
Abstract: In this dissertation, we present an approach to assist a maintenance programmer to abstract a functional hierarchical structure of a given program In the maintenance phase, this piece of information, in turn, gives him a picture of the overall functionality of the program This is extremely useful in the situation when no or only inaccurate documentations are available for that program because it is necessary to have such information for redocumenting the program or modifying the program
The approach makes use of a software tool called program slicer which, given a slicing criterion based on a program statement and a set of program variables, will produce a slice of that program with only the statements having influence in computing the values of the given set of program variables observed at the time when the given statement has been completely executed The resulting slice of the program is itself an executable program, and has the property that any function that can be identified by looking at its source code, can also be identified in the code of the original program, whenever the latter terminates
The approach involves repetitive application of program slicer and results in a collection of slices This collection of slices are studied for identifying functions in the order defined by a topological sorting based on 'subset' relation on these slices Since our approach enables a maintenance programmer to focus on a much less complicated piece of codes before dealing with more complicated ones, functions can be identified in a more manageable fashion especially when, in any particular slice, we distinguish statements which implement the functions that have been identified from the other statements in that slice The ordering defined by the topological sorting based on 'subset' relation on the slices also makes it easier for the maintenance programmer to figure out which function is a sub-function of another