ITPI20110105A1 - METHOD FOR THE OPTIMIZATION OF PROGRAM DEVELOPMENT PROCESSES BY PROCESSOR - Google Patents

Description

TITLE

METHOD FOR THE OPTIMIZATION OF THE PROCESSES OF

DEVELOPMENT OF COMPUTER PROGRAMS

TECHNICAL FIELD

The present invention relates to a method for optimizing the development processes of computer programs, in particular with regard to the simplification of the error tracing methods and the reliability of testing.

STATE OF THE ART

The development models of computer programs, that is to say the methods to be followed in designing and writing computer programs, are many and have the purpose of providing guidelines to arrive in the shortest possible time to produce a computer program that it works correctly, contains the least possible number of errors and meets the specifications and needs of both the end user and future maintenance technicians in the best possible way. Whatever the model used, during the development phases of analysis of the portions of the program created (manual or using debugging tools) and testing phases must necessarily be carried out (the analysis phase intended here must not be confused with the analysis of the customer needs carried out by IT analysts to define the specifications of a program).

The manual analysis of computer programs or portions of them always takes place during the writing of the program, looking for errors or other deficiencies, a bit like a writer who rereads his text several times before continuing to write it. . However, a computer program, especially when it is not in source code but is already at least partially compiled, contains a lot of information and lines of text that are of little interest to the programmer and which therefore unnecessarily slow down the work of rereading and checking.

Even when debugging a program in search of errors, the reduction of working times is essential: a rapid resolution of the error allows to reduce the development time of the computer program in the event that a new application is being designed. and to put the customer in a position to work again if maintenance is being carried out on an application already in use.

Modern computer program development environments are themselves programs that include three basic applications: a text editor for writing source code, a compiler that translates the sets of instructions written in the programming language (source code) in instructions of another language (machine language), and a debugger which is a program specifically designed for the analysis and elimination of programming errors present in other programs.

The main task of the debugger is to show the code snippet that is generating the problem. The code can be displayed in its native form, translated into assembly language or, much more profitably, as source code in the language in which the analyzed program was written.

Almost all debuggers allow the execution of the analyzed program in small steps, showing in the interruptions the code related to the current source instruction and the current state of the CPU and of the variables. The interruption of the execution can happen to every single instruction or in points explicitly assigned by the user (breakpoint or watchpoint).

Debugging usually takes place with rapid advances between one breakpoint and another until it is believed to be close to the error. When one feels that one is nearing the error, one prefers a circumspect advancement, education by education. Despite this, very often it happens that one or more times ends up in the error before being able to identify it.

An important phase of debugging is error handling. If the error is not handled, it is not possible to predict the behavior of the program when it stumbles upon the instruction that causes the error. Otherwise, the error can be handled by inserting specific routines into the program called "error handlers" or "error traps" in which the program is instructed to jump when an error occurs. However, even if the error is handled, and therefore it is identified which was the routine in which the error was generated, in spite of this all the information prior to the error is lost, so it is necessary, when starting with debugging, re-enter the necessary information. This obviously leads to a considerable waste of time on the part of the programmer. Some development environments, such as Microsoft's Visual Studio Ultimate 2010, are able to store the information of some important points of the program, facilitating debugging restarts. However, this does not completely eliminate the waste of time as no debugger is able to memorize and then restore the conditions present at the entry of the routine in which the error was generated.

Finally, even the software testing phase presents some critical points that it is necessary to try to overcome. The purpose of testing is to detect defects through malfunctions, in order to minimize the likelihood that the released software will malfunction in normal operation. No testing can reduce this probability to zero, as the possible combinations of valid input values are enormous, and cannot be reproduced in a reasonable time; however good testing can make the probability of failure low enough to be acceptable to the user. To detect as many defects as possible, the software is urged in testing to execute as much code as possible with a variety of input data. The need is therefore particularly felt to verify how accurately and scrupulously the code has been tested by means of utilities that make it possible to know which and how many times the individual instructions have been tested.

SUMMARY OF THE INVENTION

The aim of the present invention is therefore to propose a method for managing the process of creating computer programs which allows to reduce the overall time required for the development of computer programs while increasing their reliability.

According to an aspect of the present invention, the above objects are achieved by means of a method for optimizing the development processes of computer programs comprising steps of:

- opening / reading of a source code;

- automatic modification of the source code with the insertion of registration instructions in succession of the lines of source code that are executed during the execution of the program, in which the aforementioned instructions being such as not to alter the functionality of the source code and in which the registration some lines of code can be done by updating a specific variable, inserting it in a specific vector or inserting it in a specific log file; - saving of the modified source code â € œPâ €.

Advantageously, in the aforementioned modification step further steps are included:

- insertion, after recall instructions of certain routines included in the source code, of instructions for saving the recall parameters of these routines;

- insertion in error management routines associated with the aforementioned routines of instructions for reading the variable, vector or registration log file;

- insertion in the error management routines of recall instructions of the relative routines with the opening parameters saved by means of the aforementioned save instructions.

Again advantageously, when the modified source code â € œPâ € is executed in a debugger, break points are inserted in the aforementioned error handling routines.

Still advantageously, the step of automatic modification of the source code also includes a step of checking the presence of error management routines carried out by means of steps of: identification of routines in the source code; search in these identified routines for keywords that reveal the presence of error management routines; reporting of the absence of these keywords in certain routines.

Furthermore, in the event that missing routines of the relative error management routine are identified, the method also advantageously includes an automatic insertion phase of an error management routine associated with each routine for which the error has been reported. absence of a relative error handling routine, called error handling routine including read instructions of the variable, vector or log file and the instructions to call the routine associated with it with the saved opening parameters.

When a source code has been automatically modified in the manner described above, the computer program to be analyzed can be launched in a common debugger. The program can be run in fast forward and will stop only in the presence of an error at the break point of the related error handling routine. At this point the programmer will identify exactly the instruction that caused the error and will be able to insert a break point upstream of it. After this, continuing to advance the program from the stop point in the error handling routine the program will jump back to the routine where the error was generated with the recall parameters in the saved routine and will stop automatically to the breakpoint previously entered by the programmer allowing him to correct the error.

In a different embodiment, the method of the invention provides that the automatic modification step comprises a step of inserting instructions for the progressive automatic numbering of each line of the source code, and that the recording takes place through insertion in a specific log file , and in which, following n executions of the computer program, the n generated log files â € œlogP1â €, â € œlogP2, â € ¦â € logPnâ € are processed as follows:

- union of the n log files â € œlogP1â €, â € œlogP2, â € ¦â € logPnâ € in a single log file by appending the relative lines of code transcribed in them;

- manipulation of the merge log file by executing: grouping of identical lines, elimination of repetitions with counting of the number of repetitions and sorting of lines by line number, in order to obtain a log file â € œlogPâ €;

- Comparison, through a textual document comparison application, of the log file â € œlogPâ € with the modified source code â € œPâ €.

The result of the aforementioned comparison clearly and immediately shows which lines of source code have never been executed during the testing activity and how many times the remaining lines of code have been executed, providing clear information on completeness and efficiency of the testing activity.

In another embodiment, the method of the invention provides that the modification step includes a step of inserting instructions for the progressive automatic numbering of each line of the source code, that the recording takes place by inserting it in a specific log file, and in which the log file generated following an execution of said source code is manipulated by grouping identical lines and eliminating repetitions with counting the number of repetitions.

The log file manipulated in this way is particularly suitable for a manual visual analysis of the operating flows of the program following the insertion of certain input parameters.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other characteristics of the invention will be easier to understand from the following description of embodiments of the invention, provided as non-limiting examples, with reference to the attached figures in which:

- figure 1 shows a schematic flow diagram of a method according to the present invention and of the relative possible ways of use;

Figure 2 shows a flow diagram representing a conventional debugging process;

figure 3 shows a flow diagram which represents a debugging process in application of the method of the present invention;

- figure 4 shows a flow diagram which represents a process of manual visual analysis of the operating flows of a source code in which the method of the present invention is applied;

- figure 5 shows a flow diagram which represents an evaluation process of the testing activity of a computer program in which the method of the present invention is applied.

DESCRIPTION OF THE PREFERRED MANUFACTURING FORMS

With reference to Figure 1, 100 indicates a flow chart which illustrates the fundamental steps of a method according to the present invention and the related possible fields of application. During a development phase of a computer program, the relative source code is opened, 110, and then modified, 120, automatically according to certain criteria which subsequently allow various operations such as debugging, to be performed more quickly and effectively. the manual visual analysis of the program code and its testing. The fundamental operation of the modification phase is that of inserting, 130, between the lines of source code of instructions that command the program to register in succession the program instructions that are executed during its execution. The recording of the instructions can take place through the enhancement of a certain variable which at each executed line of code is updated with the value of the line just executed, or it can take place by writing in succession the lines of code executed in a vector, or it can take place through writing the lines of code performed to a log file. For example, in the case of writing on a vector, this can remain temporarily in the RAM memory, or other temporary memory of the computer, which allows much faster access and write operations, and its contents can be periodically transferred to a file. of log. Obviously, the instructions inserted in the source code of the program must be such as not to alter the functionality and the normal logical flows of the program itself. In practice, after each line of the original source code is inserted a registration instruction of the contents of the previous line, however making sure that the inserted registration line does not alter the flow of the program defined in the original source code. To obtain the aforementioned non-interference with the program flow it will be necessary, in some cases and for some programming languages, to modify the syntax of the original source code.

Further changes to the source code can be made at this stage and are dedicated to optimizing the performance of certain activities, after which the source code is saved in its modified form, 140.

Modified source code can be used to perform various tasks associated with the process of creating a computer program more efficiently and with significant time savings. If the execution of the program, 150, takes place in a debugger, 160, that is to say in a program specifically designed for the analysis and elimination of bugs (i.e. programming errors inside the program) present in other programs, thanks With changes made to the program, the error detection and resolution process is much faster than a conventional debugging process. If, on the other hand, the execution of the program 150 does not take place in a debugger, and occurs, possibly following a compilation phase, 160, and with the insertion of certain input parameters, 170, thanks to the modifications 120 previously introduced, a log file is generated, 180, in which all the lines of source code executed are recorded. The aforementioned log file can be advantageously used for at least two types of activities: the manual and visual analysis of the operating flows, 300, of the program, and the evaluation of the testing activities, 400, of the program itself.

The processes of debugging 200, of manual and visual analysis of the operating flows, 300 and of evaluation of the testing activity 400 which can be carried out thanks to the advantages of the present invention and carried out according to the method of the present invention will be described below.

In fig. 2 shows a flow diagram of a conventional debugging process, while in fig. 3 a flow diagram of a debugging process according to the present invention is shown.

With reference to fig. 2, conventionally a source code is opened in a debugger, in order to track down and solve possible programming errors. Once the program has been opened, the programmer manually inserts BPs (break points), that is, the stopping points of the program execution, in the routines (methods, sub-routines, functions, procedures, program blocks, subroutines) in which it suspects that an error may be found. Once the BPs have been entered, it is necessary to enter a series of input parameters with which the examiner wants to test the program or which he believes may cause an execution error. Very often the phase of entering the input parameters is quite long as it may be necessary to manually enter a large amount of data. Once the above operation has been completed, the programmer launches the program in fast forward mode and the program may either fall into an error or stop at a previously entered BP. In the first case it is necessary to restart from the BPs insertion phase, while in the second case the programmer proceeds to a circumspect progress of the execution, line by line, analyzing the lines of code and making the corrections he deems necessary. Even during circumspect progress it is very likely that the programmer does not notice the presence of the error and therefore ends up in it. In this case it is necessary to restart from the phase of entering the input parameters (very long), possibly modifying the position of the BPs and then repeating the entire process with greater caution in the hope of identifying the error before ending up again inside. As it will be easy to understand, the aforementioned iterative procedure can also be very long, especially if the phase of entering the input parameters is time consuming and obviously depends a lot on the ability of the programmer.

With reference to fig. 3 according to the method of the present invention, the source code of a computer program is opened, 110, and modified, 120a, as described below. First, a check for the presence of r.g.e. (error handling routines), 121a, associated with the various routines present in the source code. The aforementioned control 121a takes place according to a series of phases which include the identification of routines in the source code, the search within each identified routines for keywords to reveal the presence of an associated r.g and, the signaling of the absence of the r.g.e. in the event that the aforementioned keywords are not found, and the possible inclusion of certain r.g and where they are missing from the aforementioned control. The aforementioned keywords will likely be reminder words of the r.g.e. which vary according to the programming language of the source code. For example, â € œtryâ € or â € œOn Error GoToâ € are examples of the above keywords. At the end of the aforesaid control step 121a there is the step of inserting, 130a, between the lines of source code of instructions which command the program to register in succession the program instructions which are executed during its execution. In this example of the invention method, dedicated to optimizing the debugging procedure, the recording takes place advantageously by enhancing and updating an appropriate variable â € œAâ € as it is not necessary to keep a log file of all the lines of code you execute but it is sufficient, and makes program execution much less burdensome, to keep the information relating to the last line of code executed. Another operation that is performed in the modification phase 120a is the insertion, after the call line of each routine, of a storage instruction, 122a, of the opening parameters of the routine itself. Further operations carried out in this phase consist in appropriately modifying the r.g.e. associated with the individual routines. A first modification consists in the insertion, in each r.g.e. of a reading instruction of the aforementioned variable â € œAâ €, 123a, in which the last executed line of code is stored, and another modification consists in the insertion in each r.g.e. of a recall instruction, 124a, of the routine that recalls it with the recall parameters equal to the parameters previously saved thanks to the storage step 122a. In this way, a recursive call of each routine is created with the relative r.g.e. in such a way that when an error occurs in a routine, it ends up first in the relative r.g.e. and then you automatically return to the routine with the saved routine recall parameters (and therefore without having to re-enter all the input parameters of the entire program execution). Finally the modified source code is saved, 140.

The modified source code can be opened in a common debugger, 201, in order to start an optimized troubleshooting process. Once the source code has been opened, appropriate BPs, 202, are inserted directly into the r.g.e. associated with routines that you suspect may contain errors. Then the input parameters of the entire execution of the program are entered, 203, similar to what happens in conventional debugging procedures. Once the input parameters have been entered, debugging can be advanced in rapid advance, 204. Since the BPs are inserted inside the r.g.e. the program will advance until it falls into error and will stop at the BP present in the r.g.e. associated with the routine in which the instruction that caused the error is located. In the r.g. and interruption, the programmer will be able to read the content of the variable â € œAâ €, 205, which will show the last line of code executed before the error occurred. At this point the programmer can easily insert an appropriate BP immediately above the instruction stored in the variable â € œAâ €, 206. Then, debugging is resumed from the breakpoint in fast forward mode, 207. The resume debugging from point of previous interruption, that is to say from inside the r.g.e. involves executing the routine recall instruction with the saved routine recall parameters inserted in the code in the previous step 124a, and then the program returns to the routine where the error is found with the recall parameters of the previous routines and stops at the BP entered by the programmer.

At this point the programmer just has to analyze the instruction that caused the error and solve the error, 208.

As can be easily understood, the debugging procedure described above is much faster and more effective than the conventional procedure. In fact, the last line of code correctly executed remains stored in the variable â € œAâ € and is immediately brought to the attention of the programmer thanks to the reading instruction of the variable â € œAâ € itself placed in the r.g.e .. call of the routine are saved and the routine is called directly in the r.g.e. associated with the above saved parameters. This saving is useful as the call-up parameters of the routine may have been altered during the execution of the routine itself. All this allows you not to have to enter the input parameters in the program several times when you fall into the error and to return quickly and automatically to the routine in which the error is found, stopping immediately before the error in order to analyze it and correct. The whole procedure can be done in fast forward mode without having to waste time with circumspect line-by-line feeds.

In fig. 4 A flow chart is shown which represents an embodiment of the method of the invention implemented to optimize the processes of manual and visual analysis of the operating flows of a program 300.

According to the present invention the source code is opened, 110, modified, 120b and then saved in its modified form, 140. In this embodiment the modifications include the insertion of a progressive line numbering, 125b, for each line of code source, and then the insertion of the instructions for recording the lines of code that are executed on the log file, 130b. It should be noted that the above-mentioned memorization instructions for the executed lines of code do not necessarily have to be such as to command the punctual transcription of all the lines of code crossed during the execution of the program. For example, for some types of needs it may be useful to store in sequence only the instructions for recalling the routines present in the code, or other types of instructions. It will also be understood that it is quite simple for a person skilled in the art to study procedures that automate the insertion of memorization instructions in a conditional manner, for example, in the presence of certain keywords.

Once the modified program has been saved, it is compiled, 160 and executed, 150, with certain input parameters, 170. Following the execution, a log file will be generated, 180, in accordance with what is established by the inserted instructions in the modification phase 120b. At this point, the generated log file can be viewed and analyzed manually, 300. The manual visual analysis can be an excessively wasteful operation in the event that the log file includes a very large number of transcribed lines of code, in which some of them can probably be the same lines executed a multiplicity of times. In this case, before the manual analysis, according to the present invention, the log file is advantageously manipulated, 301, by carrying out a grouping of the identical rows and an elimination of the repetitions with counting of the number of repetitions, and finally a sorting of the rows. In this way the programmer will be faced with a very reduced list of instructions in which all instructions are different from each other. At this point, the programmer can perform a manual selection, 302, of lines of interest for the analysis to be performed (or vice-versa of those of no interest), after which the log file will be restored in the original sequence but without all the lines (and the relative repetitions) previously selected as â € œnot of interestâ €, 303. At this point the programmer, through the simplified log file, will be able to carry out the manual analysis of the working flow of the portions and lines of code of the program of your interest.

In fig. 5 A flowchart is shown which represents an embodiment of the method of the invention implemented to optimize the evaluation processes of the testing activity, 400, of the computer program.

According to the present invention the source code is opened, 110, modified, 120c and then saved in its modified form â € œPâ €, 140. In this embodiment the modifications include the insertion of a progressive line numbering, 125c, for each line of source code, and then the insertion of the instructions to log the lines of code that are executed, 130c. Once the modified program â € œPâ € has been saved, it is compiled, 160. As already mentioned in the testing procedures, the program is executed, 150, with numerous combinations of input parameters, 170, in order to stimulate as much as possible the program, possibly passing through all the lines of code with the highest possible number of different values of the related variables. At each execution of the program, thanks to the modifications previously made to the source code, a log file 180 is generated containing the succession of source code lines executed in the execution of the program. After a number n of program executions with n different combinations of input parameters we will have generated a series n of log files â € œlogP1â €, â € œlogP2â €, â € ¦, â € œlogPnâ €. At the end of all the tests provided, the log files â € œlogP1â €, â € œlogP2â €, â € ¦, â € œlogPnâ € are merged into a single log file, 401, simply by appending the lines in a single text file of â € œlogP1â € the lines of â € œlogP2â € and so on up to the lines of â € œlogPnâ €. The log file thus obtained is manipulated, 402, by performing a grouping of identical lines and an elimination of the repetitions with counting the number of repetitions, and finally a sorting of the lines by line number. The log file â € œlogPâ € thus obtained will contain a series of lines of code ordered by line number and each will be associated with an additional number indicating the number of times that particular line of source code has been executed during the n trial runs of the program. At this point, the log file â € œlogPâ € can be compared, by means of a textual document comparison utility, 403, with the modified source code â € œPâ €, in order to also highlight the source code lines with have never been performed in the n test runs of the program, 404. The utility for comparing text documents must guarantee the absence of false positives, i.e. lines shown as deleted or inserted in the compared text that are not actually modified. The method of the present invention, in the embodiment described above, provides a tool for obtaining, in a simple and immediate way, important information about the completeness and validity of the testing activity of the executed program.

On the basis of the method of the present invention, further applications useful in the process of developing computer programs could be developed, without thereby departing from the inventive concept outlined.

Obviously, variations and modifications can be made to the method of the invention and to the procedures described above for its implementation in debugging activities, manual analysis of the operating flows of a program and evaluation of the testing activities of the program itself, always remaining within the scope of protection defined by the following claims.

Claims (8)

CLAIMS 1. Method for optimizing the development processes of computer programs characterized by the fact of including phases of: - opening / reading (110) of a source code; - automatic modification (120) of said source code with insertion of registration instructions (130) in succession of the lines of source code that are executed during the execution of the computer program, said instructions being such as not to alter the functionality of said source code, said registration being able to take place according to one or more of the following modalities: updating of a determined variable, insertion in a determined vector, insertion in a determined log file; - saving (140) of said modified source code â € œPâ €. 2. Method according to claim 1 characterized in that said modification step (120a) comprises steps of: - Insertion (122a), after recall instructions of certain routines included in said source code, of instructions for saving the recall parameters of said routines; - insertion (123a), in error management routines associated with said routines, of instructions for reading said variable, vector or log file; - insertion (124a) in said routines for managing the error of recall instructions of said routines with the opening parameters saved by means of said save instructions. 3. Method according to the preceding claim characterized in that when said modified source code is executed in a debugger, break points (202) are inserted in said error handling routines. 4. Method according to claim 2 or 3, characterized in that said automatic modification step (120) comprises a step for verifying (121a) the presence in said source code of error management routines. 5. Method according to the preceding claim characterized in that said verification step comprises steps of: identification of routines in said source code; search in said identified routines for keywords to reveal the presence of error management routines; reporting of the absence of these keywords in certain routines. 6. Method according to the previous claim characterized by the fact of comprising an automatic insertion step (121a) of an error management routine associated with each routine for which the absence of said keywords has been signaled, said routine error management including instructions for reading said variable, vector or log file and said instructions for recalling said routines with said saved opening parameters. 7. Method according to claim 1 characterized in that said automatic modification step (120c) comprises a step for inserting progressive automatic numbering instructions (125c) of each line of said source code, said registration taking place through insertion in a specific file of log, and in which, following n executions (150) of said computer program, the n log files generated â € œlogP1â €, â € œlogP2, â € ¦, â € logPnâ € (180) are processed as follows: - union (401) of the n log files â € œlogP1â €, â € œlogP2, â € ¦â € logPn into a single log file by appending the relative lines of code transcribed in them; - manipulation (402) of the merge log file by performing: grouping of identical lines, elimination of repetitions with counting of the number of repetitions and sorting of lines by line number, in order to obtain a log file â € œlogPâ €; - Comparison (403), through a textual document comparison application, of the log file â € œlogPâ € with the modified source code â € œPâ €. 8. Method according to claim 1 characterized by the fact that said automatic modification step (120b) comprises a step for inserting progressive automatic numbering instructions (125b) of each line of said source code, said registration taking place by inserting it in a specific file of log, and in which said log file generated (180) following an execution (150) of said source code is manipulated (301) by grouping identical lines and eliminating repetitions with counting the number of repetitions .