System and method for automated identification, remediation, and verification of computer program code fragments with variable confidence factors

[0002] The present invention relates to electronic data processing systems and more particularly to the discovery of computer code sequences that are candidates of interest without specific search criteria. Still more particularly, the present invention relates to apparatus and process for the identification of said computer code sequences and subsequent modification and verification.

[0003] As the year 2000 approaches, there has been a significant increase in concern over computer programs being “Year 2000 Compliant”. Many computer programs have been written using only the last two digits of the year in various ways such that these computer code fragments will fail or produce incorrect results when entering “00” or “0”. Such would be the case when calculating a person's age using the two digit birth year and subtracting from the current year, 0−75=−75. However, there are a near infinite number of ways that a two digit date could be used in a computer program such that incorrect results would be produced by entering only the last digits of the year at the turn of the century. The computer industry has reacted to this problem by allocating significant resources in terms of personnel and finances due to the extreme diversity of the problem. The problems encountered in the computing environment are very diverse due to many factors such as: the number of operating systems, computer languages, and types of applications in use. However, all of the factors associated with correcting the date related problem at the turn of the century could be divided into four categories: inventory, analysis, remediation, and verification.

[0004] The inventory is the list of all of the source code files of a particular system or sub-system that are required to rebuild the executing program(s). In some cases the original source code is missing or incomplete. The process of obtaining a complete set of files is subject to human error and not required by existing source code remediation solutions to begin the analysis.

[0005] The goal of the analysis is to detect only code fragments that are of interest because a date is manipulated within the computer program. This is particularly difficult since there is no way to be certain that all of the date manipulations can be located using only date related character strings. Attempts to automate the process of finding code fragments involve using a “seed list” of character sequences relating to date fields and sequentially scanning source code files. Usually, additional character sequences are discovered in the process of scanning all of the source code files. These newly discovered character sequences are then added to the seed list and re-applied against all of the source code in an iterative fashion of unpredictable duration. One of the major problems with this approach is that computer programs are typically written to assign a code fragment of interest to another variable, location or function. This could result in a failure to detect the redefined code fragments. Another problem is that this method does not verify that all of the source files are present before scanning the source files using the seed list. Hence, it is often late in the project when it is discovered that source code is missing or out of date.

[0006] Remediation is defined as the modification of a code fragment into a desirable result that corrects the identified problem. Once identified, a code fragment is subject to multiple forms of correction. This may be accomplished simply by presenting the code fragment visually or in report form and allowing manual correction one after another. Another method is to apply a set of rules particular to a specific code fragment automatically or provide one or more alternatives for user selection. However, none of the existing remediation methodologies have the capability to locate the optimal remediation points within the source code fragments. Hence, a variable named “date” may be in the comments, part of an assignment, or any one of dozens of computer constructs and all could be traversed before locating its definition which is most likely the best location to correct the problem. Worse, correcting a problem at the wrong location within the processing could compound the work effort required to actually remediate or correct the identified code fragment.

[0007] Verification of the remediated code fragment changes, which have been either manually or automatically generated, requires that said code fragments be executed in direct testing. Verification is generally overlooked in existing remediation methodologies. Currently, this requires comprehensive testing of all of the program functions since it unknown at the user level if the testing actually traversed all of the newly modified code fragments. However, in practice, the data entry fields associated with dates is all that is tested. Additionally, a modified code fragment could be traversed when no date was actually entered as in the case of program initialization. Computer programmers know this and generally do some level of additional testing to expose these hidden potential problems. Now the problem becomes to determine when to stop testing since there are no metrics regarding the percentage of completion other than the total of all possible tests that could be run. It is also possible that a code fragment modification could have been made without having a specific test case to traverse the newly modified code fragment. Inadequate or incomplete testing and verification has plagued a number of the year 2000 conversions after the systems were actually installed.

[0008] The technical challenge is to find an automated method to identify computer code fragments having only partially defined search criteria and the subsequent remediation and verification of said computer code fragments while minimizing the introduction of human errors and reducing the total effort required throughout the entire process.

[0009] The present invention is directed to a process which: identifies computer code fragments within a computer program without having specific search criteria; corrects said computer code fragments; and verifies the corrections applied to said computer code fragments. The present invention is also directed to a process that reduces or eliminates human intervention by providing integrity checking within the process. The invention is directed to a process that comprises the following steps: reading into memory computer source code file or files; generating a symbol table containing related information; optionally verifying that all symbols are present for a given system or sub-system; identifying symbols of interest; repeating the following steps for a plurality of symbols;

[0010] checking for forward or backward related symbols and providing for automatic transformation of said symbols;

[0011] optionally manually or automatically modifying the code fragments so as to correct the identified problem;

[0012] assigning and dynamically modifying a confidence factor to each symbol;

[0013] inserting logging statements proximate to the manually or automatically inserted code fragments;

[0014] building and executing the modified program; logging the newly modified code fragments; verifying that all modified code fragments have been traversed during testing and verification.

[0015] The present invention has several advantages over the prior art of correcting code fragments and data relating to the year 2000 compliance. One advantage is due to the global symbol table generation. This provides an integrity check to insure that all files are present before the analysis begins. This eliminates multiple partial searches of the seed list against an incomplete source code base. The global symbol table also provides the advantage of forward and backward linking to other computer code fragments so that redefinition of positively identified code fragments can not escape detection. Once a symbol is recognized as a redefinition, an automatic transformation can be done as opposed to a manual code fragment modification as in the case of remediation. This eliminates the possibility of human error when a redefinition of a positively identified code fragment occurs.

[0016] Another advantage of the present invention is the assignment of a dynamic confidence factor to each of the symbols. This aids the person evaluating a specific symbol during the normal course of the analysis. Symbols that are determined not to be of interest will have their confidence level set to zero, which would effectively eliminate them from the search criteria. The value of the confidence factor is automatically adjusted based on the relationships within the symbol table construction. Symbols with varying levels of confidence found to match the proper criteria can be promoted to a confidence level of 100. This would allow both automatic and manual modification of the search criteria during the entire analysis. Thus, more efficient and fewer searches are needed to identify all code fragments of interest due to the automatic recognition of redefined code fragments and the dynamically modified confidence factor associated with the symbols.

[0017] Yet another advantage of the present invention is the automatic location of optimal remediation points due the structured ordering and execution of the remediation priority table. We can know for certain that all symbols that are elements of structures must be resolved before resolving the constants and other elements of the language as shown in FIG. 4. using the preferred embodiments of the present invention on the C language. We also know that randomly correcting the various symbols within a computer program can cause conflicts that are avoided by performing the remediation in the proper order. Therefore, not only does the present invention streamline the actual remediation process; it greatly reduces the total number of remediations needed to resolve all of the symbols.

[0018] Still another advantage of the present invention is that whenever a code fragment is modified, a logging or tracking event is placed proximate to the modification with an optional note field containing a description of how to test this particular remediation. This provides various metrics as well as reducing the final testing cycle. The final testing cycle is reduced because when all modified code fragment paths have been traversed, all logging or event statements will have been reported. This insures complete testing of the code fragment modifications without necessarily testing all of the programs functions. This also has the advantage of providing the percentage of completion based on the number of logging or events actually reported as compared to the total on record. If any logging or tracking events are remaining at the completion of testing, this method has the added advantage of describing how to test the remaining remediations if such a description was entered at the time of insertion.

[0019] It is therefore an object of the present invention to provide a method and apparatus that determines if all the source code is present by cross referencing the generated symbol table or allowing partial processing prior to commencing the initial analysis.

[0020] It is another object of the invention to provide a method and apparatus to track forward and backward references in an automated fashion so that the confidence factor of each symbol can be automatically or manually modified and then automatically propagated to the symbols that are redefined.

[0021] It is yet another object of the present invention to provide a method and apparatus to reduce the effort required to correct identified code fragments by determining the optimal remediation points.

[0022] It is yet another object of the present invention to provide a method and apparatus to eliminate human error in the case of redefinition by providing an automated method for remediation.

[0023] It is still another object of the invention to provide a method and apparatus to insert logging or tracking event statements into code fragments manually or automatically modified to verify execution of the modified code fragments and reduce the testing cycle time.

[0024] The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of a preferred embodiment of the invention. This is illustrated in the accompanying drawings wherein like reference numbers represent like parts of the invention.

[0025] FIG. 1 is a block diagram of selected internal components of a personal computer, upon which the present invention can be practiced.

[0026] FIG. 2 is a block diagram depicting the relationship between the inventory, analysis, remediation, and verification stages of the preferred embodiment of the present invention.

[0027] FIG. 2ais a data processing diagram depicting the inventory and analysis interactions.

[0028] FIG. 2bis a data processing diagram depicting the remediation and verification interactions.

[0029] FIG. 3 is a flow chart of the method for determining if all of the source code files are present.

[0030] FIG. 4 is an exemplary table of the properties associated with the seed list.

[0031] FIG. 5 is an exemplary table of the properties associated with a sample of a symbol table entry.

[0032] FIG. 5ais an exemplary table of the properties associated with a parse table entry.

[0033] FIGS. 6, 7, and 7aare flowcharts of the iterative steps of the analysis component. FIG. 6 shows a method for constructing the symbol table. FIG. 7 shows a method for propagation of the symbols. FIG. 7ashows a method for calculating the confidence and distance.

[0034] FIG. 8 is an exemplary table of the remediation order.

[0035] FIG. 9 is a flow chart of the method used to generate the code changes database.

[0036] FIG. 10 is a flow chart of the method used to generate the new source code.

[0037] In FIG. 1, there is shown a block diagram of the internal components of a personal computer 10 upon which the present invention can be practiced. The computer 10 has a central processing unit (CPU) 12. In the preferred embodiment, the CPU is an Intel Pentium microprocessor, although the present invention can be used with other microprocessors as well. The CPU 12 is connected to the Memory 14. The memory 14 is typically Dynamic Random Access Memory (DRAM) or Synchronous Dynamic Random Access Memory (SDRAM) configured in Single Inline Memory Modules (SIMM). The CPU 12 is also connected to the I/O Controller 16 that is in turn connected to the Keyboard 20 and Display 22. Network 18 interface card is a common addition to many personal computers and is also connected to the CPU 12. Mass Storage Device 24 and removable media device 26 are similarly connected to the CPU 12. The present invention can be implemented on other types of computers besides the computer 10 shown and described in FIG. 1.

[0038] Referring now to FIG. 2 which is a data flow diagram of a high level overview of the major steps involved to identify, correct, test, and verify code fragments which have no discernible search criteria. FIG. 2 illustrates the structure and relationships between the various components. A computer program is composed of one or more source code files and a complete set of computer program source files makes up a full inventory 30. Such an inventory 30 should be all of the source code files required to regenerate a working computer program, system or sub-system. The preferred embodiment of the present invention is implemented on the Microsoft Windows NT operating system upon which source code files are written specifically to execute in that environment. Other operating systems and source code combinations can be employed. The analysis 32 consist of locating computer code fragments one after another relating to a date in which only two characters are processed in the preferred embodiment of the present invention. Other search criteria which are not clearly and explicitly defined can be employed. Once code fragments of interest have been located, a correction or remediation 34 to the said code fragment which modifies the source code fragment and corrects the problem is performed. Ideally, the analysis 32 finds all of the source code fragments before beginning the remediation 34. However, it is possible that additional symbols could be located proximate to symbols under examination and subsequently be added to the analysis during the remediation 34 in an iterative fashion. A return from remediation 34 to analysis 32 would also occur if any new symbol was discovered and it was deemed beneficial to restart the processes using the original symbol list and including the newly discovered symbol. Verification 36 occurs when all symbols have been found and all remediations have completed. Verification 36 is composed of running the final executable that has been regenerated or built using the modified source code of the remediation 34. The process of verification 36, remediation 34 and analysis 32 are iterative during the normal course of the entire process with the exception that verification 36 usually does not occur until all known symbols are processed in analysis 32 and all known remediations 34 have been completed. Verification 36 is completed when all modified code paths have been traversed and all date related entry fields have been tested.

[0039] Referring now to FIG. 2awhich is a data flow diagram of a high level description of the interaction between the inventory and analysis components. Original source code 40 serves as input into the inventory 41. Ideally, this contains all of the source code files for a particular system or sub-system. However, it may contain as little as a single source file of a multiple source program or even a source code fragment of a single source code file. Using the inventory 41, the analysis 42 produces the parse data 43. The seed list data 45 is used as input to build the symbol table 44. The analysis 42 processes the data to set the initial confidence for each symbol. Analysis 42 sequentially reads the original source 40 and builds the parse database 43 for each symbol. Starting with the first symbol of the parse database 43, a search is made in the seed list 45. When a match is found, parameters from the seed list are incorporated into the symbol's 44 definition. This process repeats until all of the symbols 44 have been processed for each symbol in the inventory 41.

[0040] Referring now to FIG. 2bwhich is a data flow diagram of a high level description of the interaction between the remediation and verification components. Remediation 50 commences when the user has entered all of the source code file or the particular file or code fragment to be processed and the inventory 30 and analysis 32 of FIG. 2ahave completed successfully. Remediation 50 reads parse data 52 and symbols 53 and then links to the original source code 51 to induce a manual source code change or an automatic source code change as in the case of transformation. The actual source code change is spooled to the code changes database 54. Once all of the source code changes have completed, the remediation 50 reads in the code changes data base 54 and outputs the new source 55 which is then used to generate or build the new executable 56. The newly generated executable 56 is run which begins verification 57. Running the executable produces the logging or tracking events 58. When all recorded logging or tracking events have been reported and all date-related fields have been entered with satisfactory results, the entire process is completed. If all of the logging or tracking events are not reported, then additional verification 57 is needed. If any date-related fields produce incorrect results then a return to the analysis 42 of FIG. 2ais indicated and additional symbols are required to be processed as needed.

[0041] Referring to FIGS. 3, 6, 7, and 7awhich contain flow charts illustrating the method of the analysis of the present invention will be described. In the flow charts, the following graphical conventions are used: a diamond is used to illustrate a decision and a rectangle is used to illustrate a process or function. These conventions are well understood by programmers who are skilled in the art of data processing systems, and the flow charts are sufficient to enable a programmer skilled in the art to write code in any suitable programming language such as C for a computer with an Intel or compatible CPU using an operating system such as Windows NT. Other computer program languages, operating systems and CPU's can be used.

[0042] Referring now to FIG. 3, the flow chart illustrates how the generated global symbol table can verify that a complete set of source files has been entered. Source code files are entered 70 with a query 72 for additional source code files and returning to entering the next source code file 70 iteratively until all source code files have been entered. A negative response to query 72 indicates that all source files have been entered and a global symbol table 74 is generated. The generated symbol table contains all of the referenced symbols including items such as structures, variables, pointers, and the like. The query at step 76 is made internally. If there is one or more missing forward or backward references or declarations then it is likely that all of the source code has not been entered. An exception is posted at step 78 and a query to continue using only a partial source code base is presented This provides an integrity check indicating that not all source code files have been entered or that the source code is out of date. In most cases, it is desirable to return to step 70 and complete the process of entering the source code files based on the symbols reported with missing declarations or identifiers. However, it is possible that the missing source code files do not contain any symbols of interest or use or modify a date field within the missing code files and the process can proceed to the analysis 80.

[0043] The table of FIG. 4 is an example of the seed list construction that contains character sequences that are likely to be encountered and is modifiable at the user level by adding more symbols. With each symbol in the seed list there is an associated attribute, such as structure, constant, typedef and so on, and confidence factor. The attribute field describes how the symbol may be used within the computer program code. The attribute definitions are a complete list of all possible cases. The confidence level is initially statically assigned based on the attribute. This allows the symbol to be significant or insignificant based on the way that it used within the context of the computer program code. This limits number of actual matches for a given symbol to the number of matches that are actually significant. In practice, this list is carefully checked and symbols may be added or confidence factors adjusted prior to constructing the symbol table.

[0044] The table of FIG. 5 is an example of the symbol table as a product of applying the seed list to the total list of all symbols to obtain the confidence factor associated with the attributes for each symbol. The symbols are extracted from the source code and are organized according to their attributes, confidence, source code location, and distance. An entry into the table is made for each usage or attribute so that the same symbol could occur multiple times with the database. The confidence and distance are dynamically modified in the course of the normal execution of the present invention.

[0045] The table of FIG. 5ais an example of the parse database as constructed on a per symbol basis. Each symbol is decomposed into its various constructs in the analysis and stored for use in the remediation to determine the optimum remediation point. This table is generated using standard parsing techniques and is well understood in the art of compiler theory relating to sibling order. Simply, the order of the symbols indicates how it is used. By example, if the expression was x=y, then the x would be listed first and followed by y. This is important information that is used during the processing of FIG. 7. Equally important are the parent and the location of the file, line and column of the symbol so that the symbol database can be constructed.

[0046] Referring now to FIG. 6, the flow chart illustrates how the symbol database is constructed. Processing occurs at the source code file level one after another until all have been processed as in the following description. In step 100, a symbol is obtained from the source code and in step 102 a search is made for this symbol in the seed list as shown in FIG. 4. Responsive to not obtaining a match in the seed list control is transferred back to step 100, which is to say that non-matching symbols are ignored. Responsive to obtaining a match in step 104, the confidence is copied from the seed list to the symbol database in step 106. In step 108 the new symbol, the associated confidence and location by way of file name, line number and row are written to the symbol database as also described in FIG. 2aat step 44. In step 110, a query is performed to determine if there are any remaining symbols and if there are more symbols remaining, then the process repeats by going back to step 100. When all symbols have been processed, the symbol, confidence and location fields as described in FIG. 5 will be fully populated.

[0047] Referring now to FIG. 7, the flow chart illustrates how the method of propagation is performed. Referring back to FIG. 5, propagation is the method in which the symbol database is further populated and dynamically modified during the normal course of remediation. In step 200, a symbol is obtained from symbol database. This symbol is located in the current source code file in step 202. Propagation follows redefinition as in the case of a=b, b=c, c=d and so on. Here we are only interested in redefinition so the query in step 204 is to determine if the symbol in the source code file is used as a data transfer. Data transfers are all types of redefinition including those passed by a function as follows:

[0048] X TodaysDate;

[0049] ProcessCurrentDate (A,B,X);

[0050] Now the actual function ProcessCurrentDate is defined:

[0051] ProcessCurrentDate (Employee, Rank, MiscInfo);

[0052] This is recognized as a data transfer from X to MiscInfo by virtue of the receiving functions third parameter with information from the parse data and source code. Thus, reducing all forms of redefinition to a form of data transfer prevents a symbol from escaping detection during the course of redefinition. This is referred to as swap-by-propagation. Referring back to the result of the said comparison at step 204 having a negative result, the next symbol is loaded in step 202. When the result of the comparison at step 204 is positive, the target of the transfer is obtained in step 206. If the new target symbol is not already located in the symbol data base at step 208, a new entry is made in the symbol database containing the said target symbol. Processing continues in FIG. 7aat this point and this will be addressed at the completion of the description of FIG. 7. At step 210 a query is made for additional references which means additional references to the current symbol. A negative result in step 210 returns to step 202 to repeat the process by obtaining the next symbol in the symbol database. A positive result in the query of step 210 results in another query at step 212 to determine if there are any more symbols remaining in the symbols database. A positive result to the query of step 212 results in repeating the process by returning to step 200. A negative result to the query at step 212 terminates the process. At the conclusion of the process described in FIG. 7 a return is made to repeat the entire process by returning the process described by FIG. 6.

[0053] Referring now to FIG. 7a, the flow chart illustrates how the confidence and distance is calculated which populates confidence and distance fields of the symbol data base as described by FIG. 5. In step 300, the original distance is obtained. The first time that this field is accessed the field will always be zero. In step 302, a query is made to determine if this is a new symbol. Responsive to the result of the query at step 302 being positive, the new symbol inherits the distance of the original symbol and adds one. Thus, it can be seen that the number of redefinition and the distance are the same. When the results of the query at step 302 are negative, a new query is made at step 304 to determine if the distance of the new symbol is less that the distance of the old symbol. Responsive to the results of the query at step 304 being negative, the new symbol's distance is calculated to be the old symbol's distance plus one. If the results of the query at step 304 are positive, the confidence of the new symbol is calculated by reducing the amount of the confidence by 10%. Note that any confidence greater than zero to start with will never actually get to zero no matter how many times that a positive value is reduced by 10%. The value of 10% is flexible and any value between 1% and 99% can be used. Processing continues now to step 308 where the new symbol's distance is set to the old symbols distance plus one. Finally, processing at this point returns to FIG. 7 at step 210.

[0054] Referring now to FIG. 8, the table represents a linked list of the constructs used in the determination of the priority order of remediation. The table represents the order that is used on standard C and C++ programs in the preferred embodiment of the present invention. This order is based on how rigid the definition is within the confines of the computer language. In this example, a structure is the most rigid because the definition does not change within the scope of the program. Variables are lower in the priority order because it is natural for them to be redefined within the scope of the program and so on. Other computer languages have similar constructs and all computer languages can be similarly decomposed. This priority order is used in step 400 of FIG. 9 as follows: all structures are processed one after another until no more structure are remaining; all constants are processed one after another until no more constants are remaining; and so on for all of the entries in FIG. 8. This table data is constructed to minimize remediation efforts by presenting the optimal remediation points for each symbol.

[0055] Referring now to FIG. 9, the flow chart illustrates how the code changes data base is populated during the remediation. In step 400, a define is obtained based on the data in FIG. 8 and a query at step 402 is made to determine if the user wants to change the definition of the symbol. Responsive to a negative result from the query at step 402 the current definition of symbol becomes default definition and is applied to all occurrences of the symbol in step 404. In step 406, any changes to the original source code required to insure that all occurrences of the symbol's definition are identical are entered into the code changes data base with a corresponding unique logging or event number and optional testing method description, then a return is made to step 400. Responsive to a positive result to the query at step 402, the various attributes of the symbol throughout the source code are obtained in step 408. A query is conducted at step 410 to determine if the new definition of the symbol is compatible with the manor in which it is being used in step 410. Responsive to a positive result to the query at step 410, the symbols new definition is spooled to the code changes data base with the corresponding file name, line number and column information and a unique logging or event number and optional testing method description. Now the method is automatically performing a transformation of the symbol as opposed to a manual remediation at step 412. This is followed by a return to step 408. Responsive to a negative result from the query at step 410, a warning message is generated. This should be a rare case in which a method other than redefinition is intended for resolving this particular symbol's definition. This may be the case when a larger fragment of the code is reworked due to the field length of a printout or display or the size of the item being output to data base when the original symbol size can not be altered. In step 416 a query is made internally to determine if there are any more occurrences of the symbol for additional attributes. Responsive to a positive result to the query at step 416, a return is made to step 408 for the next use of the symbol. Responsive to a negative result from the query at step 416, a query is made at step 418 to check for any remaining definitions. Responsive to a positive result to the query at step 418, a return is made to step 400 to get the next define. A negative result at step 418 means that all symbol definitions have been processed and that the remediated code can be rebuilt and tested. The actual code changes are in the form of an insert and delete at a specific line number for a specific file name.

[0056] Referring now to FIG. 10, the flow chart illustrates the method used to generate the new source database. This is a combination of the original source code and the source code changes in the code changes database. In step 500, a single source code file is obtained. In step 502, a check is made to determine if this particular source code file has any changes associated with it in the code changes database. Responsive to negative result for the query in step 502, the file is copied to the new source database in step 506. Responsive to a positive result from the query at step 502, the source code changes are applied one after another until the end of file is reached at step 504 and the new file is then written to the new source data base in step 506. In step 508, a query is made to determine if there are any source files remaining and if so, a return is made to step 500 to process the next file.

[0057] Finally, the new source code containing the remediations and logging or tracking events is used to build or regenerate the executables and begin the iterative process of entering dates that begin at the year 2000 and beyond. After all dates have been entered, the logging or tracking events are compared against the total on record. Although some of the events may occur multiple times, the test is to determine if each of the inserted logging or tracking events have occurred at least once. In the event that one or more of the previously recorded logging or event tracking statements failed to be reported after all of the testing was done, the file name and line number can be accessed. A description field of how to test the modified code may contain the testing method, if it was entered during the remediation. When all of the said events have occurred at least once and the results are satisfactory, testing and verification are completed.

[0058] The foregoing disclosure and the content of the drawings are merely illustrative of the principals of this invention and are not to be interpreted in a limiting sense.