Method, system, and program for performing an impact analysis of program statements in at least one source code file

Provided is a method, system, and program for performing an impact analysis of program statements in a source code file, wherein each program statement has at least one of an input parameter and output parameter. A selection is received of at least one program statement in the source code file. For each selected program statement, a determination is made of program statements in the source code file having as one input parameter one program artifact that is affected by the selected program statement.

RELATED APPLICATION

This application is related to the copending and commonly assigned patent application entitled “Method, System, And Program For Utilizing Impact Analysis Metadata of Program Statements in a Development Environment”, having Ser. No. 10/003,950, filed on the same date herewith, and incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method, system, and program for performing an impact analysis of program statements in at least one source code file.

2. Description of the Related Art

One of the challenges when editing code in a program is to understand the effect of changes to certain lines of code to other parts of the program. In the prior art, software developers use a debugging tool to “step” through the program and determine all the execution paths. Based on the information of the execution characteristics determined by “stepping” through the program, the developer can then analyze the execution path to determine the effect the proposed changes to certain statements may have on the current operation of the program including the program statements to change. This process is manually intensive and is based on the capabilities of the developer to properly observe all the effects the proposed changes will have on the execution characteristics.

Moreover, a change in one program may affect the operations of another external application by modifying the content of a shared resource, such as a global variable, memory, file, database record, etc. Currently there is no integrated approach for determining the effects of a proposed change to code on the operation of external applications. In fact, a debugger typically only is aware of the application currently executing, and not the effects on an external application.

In the current art, the software developer is often unable to ascertain the impact of code modifications to the application including the modified code and to external applications, until errors and bugs are detected. At such point, the developer may then have to spend considerable time tracking down the source of the problem to the code change that was made. This problem is further exasperated if the negative impact of a code change is realized in an external application, where the developer or system manager may be totally unaware of the changes made because they were made in a different application. In such case, time will be spent tracking the source of the error to another application, and then to a particular code change in the external application.

For these reasons, there is a need in the art for improved software development tools that assist developers in understanding the impact of modifications to a source program.

SUMMARY OF THE PREFERRED EMBODIMENTS

Provided is a method, system, and program for performing an impact analysis of program statements in a source code file, wherein each program statement has at least one of an input parameter and output parameter. A selection is received of at least one program statement in the source code file. For each selected program statement, a determination is made of program statements in the source code file having as one input parameter one program artifact that is affected by the selected program statement.

Further provided is a method, system, and program for performing an impact analysis of program statements in a source code file that is one of a plurality of source code files, wherein each program statement has an input parameter and output parameter. Selection is received of at least one program statement in one source code file. For each selected program statement, a determination is made of program statements throughout the source code files having as one input parameter one program artifact that is affected by the selected program statement.

In further implementations, the program artifact comprises a variable, Input/Output buffer or file.

Still further, one program statement has one input parameter that is affected by the selected program statement if the output parameter program artifact of the selected program statement is the input parameter program artifact to the program statement.

Yet further provided is a method, system, and program for maintaining data on a plurality of source code files. A data store is generated for each source code file and for each program statement in the source code file by generating information on the program statement and generating information on each program artifact referenced as an input parameter in the program statement. Information is further generated on each program artifact referenced as an output parameter in the program statement. The data store is then used to determine program artifacts throughout all of the source code files capable of being affected by any one program statement in any of the source code files.

The described implementations provide a technique for determining the impact that a change to a selected program statement in one source code file may have on program statements in the source code file including the selected statement and in other source code files. In this way, a software developer may have information on all program statements and program artifacts in one or more source code files that may be affected by changing a selected program statement.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1illustrates an enterprise computing system2which would be implemented across a network environment including one or more server and client computer systems, comprising any type of computing devices known in the art, e.g., workstations, servers, personal computers, mainframes, hand held computers, laptops, personal information managers (PIMs), telephony devices, etc. A plurality of source code files4a,4b. . .4nare maintained in the enterprise computing system2and available to a set of software development tools6that are implemented on one or more of the computer systems in the enterprise computing system2. The source code files4a,4b. . .4nwould comprise the source code of application programs used in the enterprise computing system2or being developed for deployment in enterprise computing systems.

The source code files4a,4b. . .4nmay also include a job control language (JCL) program that includes program statements that call and execute application programs in the system and associates logical and physical entities. For instance, within an application, a logical data set name may be used to reference or call a physical data set. The JCL program provides the association of the logical data set to the physical data set. In fact, the same logical name may be used to reference different physical data sets. The JCL association of physical and logical entities is examined when performing the impact analysis to determine how code modifications can affect a physical data set and, in turn, the statements that reference that physical data set. A set of JCL statements may specify the input data sets (files) to access, output data sets to create or update, resources to allocate for the job, and the programs that are to run using the defined input and output data sets.

The source code files4a,4b. . .4nmay be stored in specific file directories or maintained and managed by a source control management system known in the art, such as the International Business Machine Corporation's (IBM) Software Configuration and Library Manager (SCLM), Microsoft Visual SourceSafe, etc.** The source code files4a,4b. . .4nmay comprise component files of one or more application programs, where each application program is comprised of one or more source code files. A source control management system provides a library management system of source code and controls access and provides locking to prevent developer conflicts. An example of a source control management system that may be used to manage developer access to the source code files4a,4b. . .4nis described in the IBM publication “Using ISPF/SCLM for Automated and Controlled Software Development”, IBM publication no. SG24-4843-00 (IBM Copyright, October 1996), which publication is incorporated herein by reference in its entirety. **Microsoft and Visual SourceSafe are trademarks of Microsoft Corporation in the United States, other countries, or both; IBM is a registered trademark of International Business Machines Corporation in the United States, other countries, or both.

The enterprise computing system2further includes a set of software development tools6deployed on one or more systems to assist software developers in modifying and updating the source programs4a,4b. . .4n. The software development tools6include an inventory collection program8that scans and analyzes all the source programs4a,4b. . .4nand generates an artifact database12providing metadata on all the program statements and program artifacts referenced in the source programs4a,4b. . .4n. A program artifact may comprise a program statement, program variable, Input/Output buffers, files, data sets, or any other data structure known in the art manipulated by a computer program. Once the inventory collection program8generates the artifact database12, then an impact analysis tool10may be invoked to analyze any block of statements in any of the source programs4a,4b. . .4n. This analysis of the block of statements would generate a report on all the program statements and program artifacts across all of the source programs4a,4b. . .4nthat could possibly be affected by any change to the selected block of statements.

FIG. 2illustrates a relational database implementation of the artifact database12maintaining the artifact elements gathered from the source code files4a,4b. . .4n. The artifact database12includes a program statement table20, a variable table40, an I/O buffer table50, and a file table60. The program statement table20includes one record22for each program statement in each source code file4a,4b. . .4n. Each program statement record22includes a unique statement key24, a program identifier (ID)26uniquely identifying the source code file4a,4b. . .4nincluding the statement, the line number28in the source code file4a,4b. . .4nincluding the statement, and the statement command name or verb30. If a line of code includes multiple statements, i.e., verb and input and output parameters, then multiple statement records22would be generated for that line of code. The program ID26may comprise the file name of the source code file4a,4b. . .4nor, if the program is maintained in a source control management system, then the program ID26may comprise the identifier of source code file4a, b . . . nin the source control management system library.

The variable table40includes one variable record42for each instance a variable is referenced in a program statement in any of the source code files4a,4b. . .4n. Each variable record42includes a variable name44, the unique statement key46of the program statement in which the variable was referenced, and an input/output flag48indicating whether the variable was input to the program statement or the output/target of the program statement and possibly modified. The I/O buffer table50includes an I/O buffer record52for each instance of a read or write operation to an I/O buffer in a program statement in any of the source code files4a,4b. . .4n. Each I/O buffer record52includes the identifier of the allocated I/O buffer54, the unique statement key56of the program statement operating on the I/O buffer, and a read/write flag58indicating whether the program statement performed a read or write with respect to the I/O buffer. The file table60includes a file record62for each instance of a read or write operation to a file in a program statement in any of the source code files4a,4b. . .4n. Each file record62includes the identity of the effected file64, the unique statement key66of the statement operating on the file, an Input/Output flag67indicating whether the statement performed an input or output with respect to the source code file4a,4b. . .4n, and a read/write flag68indicating whether the statement performed a read or write with respect to the file.

FIG. 3illustrates logic implemented in the inventory collection program8to populate the artifact database12with program artifact metadata. The logic ofFIG. 3, as well as the logic ofFIGS. 4,5a,5b, and5cwould be executed by one or more computer systems on which the software development tools are installed. Control begins at block100by accessing all the source code files4a,4b. . .4nsubject to the analysis, either through the file directory or by accessing the source code files4a,4b. . .4nthrough a control management system. A loop is then performed at block102through block126for each source code file i to consider. At blocks104through124, the inventory collection program8performs a loop for every line j in the source code file i, from the top to bottom of the code. The inventory collection program8scans (at block106) line j for a program statement. If there are multiple program statements in the line, then the steps108through122will be performed for each statement in the line, where a statement comprises a command verb and an input and output program artifact, e.g., variable, I/O buffer, file, etc., acted upon by the program statement. A program statement record22is generated including fields having: the unique statement key24, which would be generated with the record; the program identifier26; line number j28; and the command verb30, which may comprise a command specifying a particular operation to be performed on the input and output parameters or a call to a subroutine within the source code file i or to a routine in an external source code file4a,4b. . .4n. Block110then inserts the generated program statement record22is then inserted into the program statement table20in the artifact database12.

For each variable referenced as an input or output parameter in the located program statement, the inventory collection program8generates (at block112) a variable record42including: the variable name44, the unique statement key46identifying the program statement referencing the variable as an input or output parameter, and sets the Input/Output flag48to indicate whether the variable is an input parameter or output parameter to the statement. The generated variable record42is inserted (at block114) into the variable table40. For each I/O buffer referenced in the program statement, an I/O buffer record52is generated (at block116) including an identifier of the I/O buffer54, the statement key56of the program statement operating on the I/O buffer as a parameter; and a read/write flag58indicating whether the program statement performs a read or write operation with respect to the I/O buffer. The generated I/O buffer record52is then inserted (at block118) into the I/O buffer table50. For each file referenced in the program statement, a file record62is generated (at block120) including an identifier of the file64(such as the physical location of the file in the file system), the statement key66of the program statement operating on the file, an Input/Output flag67, and a read/write flag68indicating whether the statement performs a read or write operation with respect to the file. The generated file record62is then inserted into the file table60.

At block124, control proceeds back to block104to process the next line of the source code file i. After processing all the lines in the source code file i, control proceeds (at block126) back to block102to process the next source code file4a,4b. . .4nbeing considered. The result of the logic ofFIG. 3is an artifact database12populated with metadata about all statements in the source code files4a, b . . . nand all program artifacts that are affected by the statements. The inventory collection tool8may update the artifact database12if one source code file4a,4b. . .4nis changed. This update may be performed by removing all records that reference the updated source code file4,b . . . nand then performing the logic ofFIG. 3to add the metadata on all the program artifacts back to the artifact database12.

FIGS. 4,5a,5b, and5cillustrate logic implemented in the impact analysis tool10to query the artifact database12to determine all program artifacts across all the source code files4a,4b. . .4nthat may be affected by a change to a selected one or more program statements in one source code file4a,4b. . .4n. As discussed, the user may select one or more lines of code in one source code file4a,4b. . .4nfor the impact analysis tool10to consider. Control begins at block150inFIG. 4upon receiving a call to the impact analysis tool10and selection of one or more program statements to subject to impact analysis. For each of the program statements subject to analysis, a loop is performed at blocks152through156. At block154, an impact analysis routine is called with statement i as an input parameter to determine all program artifacts directly and indirectly affected by statement iFIGS. 5a,5b, and5cillustrate the logic of the impact analysis routine.

At block200inFIG. 5a. a call is made to the impact analysis routine to analyze an input program statement. If (at block202) the input program statement does not call another routine within the same or external source code file4a,4b. . .4nand if (at block204) the input program statement affects a program artifact, then a determination is made at block206of whether the input statement modifies a variable. An input program statement would not affect a program artifact if it does not modify the program artifact, such as the case if the input program statement specifies that data be sent to a printer or other output device that does not modify any other variable, file or I/O buffer. If the input program statement modifies an input variable (from the yes branch of block206), then the impact analysis routine would query (at block208) the variable table40to determine all statements that reference the modified variable, i.e., have the same variable name44, as an input parameter, i.e., the Input/Output flag48is set to indicate input. An output data listing of all statements that reference the modified variable as an input parameter is produced (at block210). At blocks212through216, for each statement j referencing a modified variable as an input variable, the impact analysis routine makes a recursive call (at block214) to the impact analysis routine, which begins at block200, with statement j as an input variable to determine all program artifacts that statement j, which has as an input parameter a variable affected directly by the program statement i or indirectly by another program statement affected by the program statement i. After control is returned from the nested call to the impact analysis routine, control proceeds to block218to return control to the point in the program where the call to the impact analysis routine was made, which may be at block154inFIG. 4or within a nested call withinFIGS. 5a,5b,5cfrom where the impact routine was called. Control is returned with information output indicating all the directly and indirectly affected program statements.

If (at block206) the input program statement does not modify a variable and if (at block250) the input program statement does write to a target I/O buffer, then the impact analysis routine queries (at block252) the I/O buffer table50to determine all I/O buffer records52identifying the target I/O buffer and that indicate in the read/write flag58that the statement reads from the I/O buffer. From the determined I/O buffer records52, the impact analysis routine determines and generates output data (at block254) of all statements read from the target I/O buffer as indicated from the statement key56value in the determined I/O buffer records52. The routine generates output data indicating all program statements that read from the affected I/O buffer. A loop is then performed at blocks256through260for each program statement reading from an I/O buffer affected by the input program statement. At block258, the impact analysis routine is called (at block200inFIG. 5a) with one determined program statement that reads from the affected I/O buffer as an input parameter to determine all further program artifacts affected by the program statement reading from the affected I/O buffer.

If (at block250) the input program statement does not write to an I/O buffer, then the impact analysis routine assumes that the input statement writes to a file (at block280), which is the last program artifact to consider in the logic ofFIGS. 5a,5b, and5c. Those skilled in the art will appreciate that the logic ofFIGS. 5a,5b, and6ccan be extended to consider the effect on program artifacts other than variables, I/O buffers, and files. At block282, the impact analysis routine determines the physical location of the file in the file system if the statement operates on a logical file name. Such physical location may be provided by a declaration in the source code file i or an external job control language program defining a logical name associated with a physical file. At block284, the impact analysis routine queries the file table60to determine all file records62identifying the target file modified by the statement and that indicate in the read/write flag68that the statement reads from the file. From the determined file records62, the impact analysis routine determines statements that read from the target file from the statement key66value in the determined file records62. The routine generates output data indicating all statements that read from the affected I/O buffer. A loop is then performed at blocks286through290for each program statement reading from an I/O buffer affected by the input statement. At block288, the impact analysis routine is called (at block200inFIG. 5a) with one determined program statement that reads from the affected file as an input parameter to determine all further program artifacts affected by the program statement reading from the affected file. From blocks260or292, control proceeds to block218to return to the point in the program execution where the call to the impact analysis routine was made.

If (at block204) the input statement does not affect a program artifact, such as the case if the statement writes data to a printer, display monitor, etc., then control proceeds to block218to return control to the point in the program execution where the call to the impact analysis routine was made. If (at block202) the input statement calls a routine within the same or another source code file4a,4b. . .4n, then control proceeds to block300inFIG. 5cto determine the impact from modifying a program statement including a call to another program routine comprised of one or more program statements.

With respect toFIG. 5c, at block300, the impact analysis routine determines the source code file including the called routine. The program statement table20is then queried (at block302) to determine all program statement records22that reference the input parameter of the called routine as input. This operation is performed to determine all statements in the called routine that may use the routine input parameter to affect other program artifacts. This determination of statements in the called routine that use the input parameter as input can be determined by a query of the variable table40, I/O buffer table50, and file table50of all table records42,52, and62having a statement key46,56, or66identifying a statement in the called source code file4a,4b. . .4n(previously determined by a query of the program statement table20for all program statement records22including the called source code file as the program ID26and whose input/output flag48,58, or68indicates that the input parameter is input to the program statement. Output is then generated (at block304) of all statements that use the called input parameter as input. For each determined statement j referencing the input parameter as input, a loop is performed at blocks306through310where the impact analysis routine is called (at block308) to determine all program artifacts affected by statement j.

The impact analysis program than determines at blocks312through320the impact on all program statements that reference the output parameter of the called routine as input, i.e., that may use the parameter affected by the called routine. At block312, the impact analysis routine queries the tables20,40,50,60to determine all program statement records22that reference the output parameter of the called routine as input. This can be determined by a query of the variable table40, I/O buffer table50, and file table50of all table records42,52, and62having a statement key46,56, or66identifying a statement in the called source code file4a,4b. . .4n(previously determined by a query of the program statement table20for all program statement records22including the called source code file as the program ID26) and whose input/output flag48,58,68indicates that the output parameter to the routine is input to the statement. Output is then generated (at block314) of all routine statements that use the called output parameter as input. For each determined statement j referencing the routine output parameter as input, a loop is performed at blocks316through320where the impact analysis routine is called (at block318) to determine all program artifacts affected by statement j.

The resulting output of a call to the impact analysis tool10to analyze one or more statements in a source code file4a, b . . . nis a list of all program statements that reference an input parameter that may be affected by a modification to the analyzed statement. This output lists statements referencing as input a program artifact that is directly affected by the analyzed statement as well as program artifacts indirectly affected, i.e., statements that reference an input program artifact that was affected by a statement referencing an input parameter affected by the analyzed statement, etc. From block320, control proceeds to block218inFIG. 5ato return control to the point in the program from where the call to the impact analysis routine was generated.

In further implementations, the impact analysis tool10may also generate extended information explaining the source of the affect on a listed program statement. As discussed, at block210,254,288, and314inFIGS. 5a,5b, and5c, the impact analysis tool10generates output data listing all program statements that reference a modified program artifact as an input statement. Thus, when generating information at this point, the impact analysis tool10may further generate extended information for an affected program statement identifying the previous program statement that modifies the program artifact used as the input statement by the affected program statement and also provide information on the exact transformation performed by the previous program statement that modifies the program artifact used as the input statement.

After the impact analysis tool10generates the output of affected source code files and program statements therein, the software developer may review the output listing of affected statements across all files4a,4b. . .4nto determine what impact the proposed changes will have on all the different application programs comprised of one or more of the source code files4a,4b. . .4nthat include the affected statements.

The resulting output of a call to the impact analysis tool10to analyze one or more statements in a source code file4a, b . . . nis a list of all program statements that reference an input parameter that may be affected by a modification to the analyzed statement. This output lists statements referencing as input a program artifact that is directly affected by the analyzed statement as well as program artifacts indirectly affected, i.e., statements that reference an input program artifact that was affected by a statement referencing an input parameter affected by the analyzed statement, etc. The software developer may review the output listing of affected statements across all files4a,4b. . .4n, which are part of one or more application programs, to determine what impact the proposed changes will have on all the different programs, including the application program source code file having the affected statement. The related application entitled “Method, System, and Program for Utilizing Impact Analysis Metadata of Program Statements in a Development Environment”, having docket no. SVL920010016US1, incorporated by reference above, provides further details on how the impact analysis tool10may be invoked and use as part of an integrated development environment.

Additional Implementation Details

In the described implementations ofFIG. 2, the database comprised a relational database having a separate program statement table and a separate table for each considered program artifact. Those skilled in the art will appreciate that the statement and program artifact data in the tables ofFIG. 2may be implemented in an any type of data store known in the art, such as a relational database having a different table and record structure, a database system other than a relational database as described herein (e.g., an object oriented database), a flat file or one or more files or data structures.

In further implementations, the records in the artifact database12may include additional fields concerning more detail on the format and structure of the program artifacts and their relationship to one another. Additionally, the tables and fields in the tables described with respect toFIG. 2may have additional fields or have the data implemented in tables in a different manner.

The described implementations discussed an impact analysis performed with respect to program artifacts comprising an affected I/O buffer, file and variable program. In further implementations, additional program artifacts or data structures known in the art may be subject to the impact analysis.

The described implementations discussed an impact analysis of a selected statement on program statements in the source code file including the selected statement and in other source code files. Additionally, the impact analysis of the present invention may be used to determine the impact of a selected program statements on program statements within the source code file including the selected program statements, and not in any other source code files.

The described implementations may be utilized to maintain metadata on the program artifacts on any number of designated programs. Further, the source code files4a,4b. . .4nand software development tools described herein do not have to be implemented in an enterprise computing system. Additionally, the source code files4a,4b. . .4nand software development tools6may be maintained at a single computer workstation, where the tools6are deployed when modifying any of the source code files4a,4b. . .4n.

The described logic ofFIGS. 3,4,5a,5b, and5cdescribes specific operations occurring in a particular order. In alternative implementations, certain of the logic operations may be performed in a different order, modified or removed. Morever, steps may be added to the above described logic and still conform to the described implementations. Further, operations described herein may occur sequentially or certain operations may be processed in parallel.