Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
2000-12-13
2004-11-16
Khatri, Anil (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S124000, C717S152000, C717S154000
Reexamination Certificate
active
06820256
ABSTRACT:
COPYRIGHT NOTICE AND PERMISSION
A portion of the disclosure of this patent document may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice shall apply to this document: Copyright© 2000, Microsoft Corp.
FIELD OF THE INVENTION
The invention relates generally to the analysis of computer programs. More particularly, the invention relates to the analysis of computer systems comprised of multiple programs.
BACKGROUND
A large amount of effort in the development of computer programs is spent ensuring the correctness of the completed program. The correctness of a computer program is the degree to which it is free from errors in its specification, design, and implementation. Three common methods for detecting errors in a computer program are compile-time checking, runtime checking, and simulated path execution.
Compile-time checking is the process of evaluating a computer program based on its form, structure, or content. Compile-time checking tests properties that can be established before the execution of a program. One form of compile-time checking, known as syntax checking, verifies compliance with structural or grammatical rules defined for a language. For example, in the context of a computer program written in the well-known C++ programming language, using the statement B+C=A would produce an error because the correct format is A=B+C. Syntax checking is discussed, for example, in Richard Conway and David Gries,
An Introduction to Programming
(Winthrop Publishers, Inc., 1979). Another form of compile-time checking, known as data flow analysis, analyzes the sequence in which data transfer, use, and transformation are performed in a computer program to detect programming errors. Data flow analysis includes the use of control information, which relates to the sequence in which statements are performed in the execution of a computer program. A control flow is also referred to as a control flow path or, more simply, a code path. Data flow analysis can detect such errors as the use of a variable before assignment, two consecutive assignments to a variable, or assigning a value to a variable that is never used.
Compile-time checking techniques are inherently limited in that they do not consider the consequences of actual execution of the computer program in question. Compile-time checking is thus limited to what can be determined without considering the dynamic effects of program execution. For example, the lint compile-time checker available in the SPARCworks™ 3.0.1 programming environment from Sun Microsystems of Mountain View, Calif., analyzes computer code without regard to the dynamic flow of control through the code. This shortcoming causes lint to falsely report values being used before they are initialized, when such is not the case.
Another type of false error reported by compile-time analysis methods is an “apparent” error in instructions through which control flow cannot go. The sequence in which statements are performed often depends on particular values associated with particular variables. Compile-time checking methods generally assume statements are always executed because they cannot determine whether a particular code path is executed or under what specific circumstances program control flows through the code path.
Runtime checking, the other primary type of programming error detection method, involves evaluating a computer program based on its behavior during execution. Runtime checking involves executing the computer program with a known set of inputs and verifying the program results against the expected outcome. The set of test inputs, execution conditions, and expected results is called a “test case.” Often, in order to help locate errors, a printout or trace showing the value of selected variables at different points in the program's execution is produced.
Although simple in principle, the usefulness of runtime checking is limited by the complexity of the computer program. A tremendous amount of effort is involved in designing, making, and running test cases. Even after such extensive effort, the error detection capability of runtime checking is limited to the code paths executed by the specific set of inputs chosen. In all but the most simple computer programs, it is generally impractical to execute all possible control flow paths. Furthermore, runtime checking requires that a computer program be complete and ready for execution. Since a function must be executed to be analyzed, testing a function apart from incorporating it into a complete program requires the additional effort of building a program shell that provides the function with the necessary environment for execution.
One method to overcome the deficiencies of typical programming error detection methods is described in U.S. Pat. Nos. 5,694,539 (issued Dec. 2, 1997); 5,857,071 (issued Jan. 5, 1999); 5,968,113 (issued Oct. 19, 1999); and U.S. Pat. No. 6,079,031 (issued Jun. 20, 2000), all entitled “Computer Process Resource Modeling Method and Apparatus,” issued on, respectively, and U.S. Pat. No. 5,790,778, entitled “Simulated Program Execution Error Detection Method and Apparatus,” issued on Aug. 4, 1998, and assigned to Intrinsa Corp. of Mountain View, Calif. The disclosures of the above-identified issued U.S. patents are hereby incorporated herein by reference. This programming error detection method analyzes components of computer programs by tracking the effect of program instructions on the state of program resources. Each resource has a prescribed behavior represented by a number of states and transitions between states.
The difficulties in detecting errors in computer programs is compounded in the case of systems that consist of several individual programs that interact with each other. In such systems, the operation of each individual program is potentially affected by events occurring in the other programs that interact with it. Existing program analysis techniques operate either on the entire code of a single program or a subset thereof; such techniques are known respectively as whole-program analysis and partial-program analysis techniques. Both types of techniques can automatically identify defects in some number of source files. Whole-program analysis techniques are more effective, but partial-program analysis techniques can give useful results on subsets of code.
However, most modem software is written as a collection of interacting programs. Since the programs interact, they cannot be analyzed independently—the behavior of one program influences the behavior of other programs in the system. Further, the order in which programs must be analyzed to give useful results is informed by the dependency relationships between the programs, i.e., the calling relationships between them. The results of the analysis of one program must be used as inputs for the analysis of other programs that interact with it.
Program analysis tools typically allow the developer to describe “external behavior” that can in practice be used to specify the behavior of another component. Certain program analysis tools allow the description of a specific component's external behavior to be generated automatically by analyzing the component in question. For example, the PREfix analysis tool uses models and provides a complex mechanism to allow users to specify which models are used and produced in an analysis. The PC-Lint analysis tool uses libraries known as “lint libraries” and provides a comparably complex mechanism. By invoking the tool on different parts of the code in a specific order and furnishing the appropriate specification of which external behavior to generate and use for the analysis of individual components, it is possible to use a whole-program analysis tool to perform cross-program an
Fleehart Timothy G.
Pincus Jonathan D.
Wallace Jeffrey S.
Khatri Anil
Merchant & Gould
Microsoft Corporation
Roche Trent J
LandOfFree
System and method for whole-system program analysis does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for whole-system program analysis, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for whole-system program analysis will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3306768