JP7250223B2 - Method, program and apparatus for analyzing source code - Google Patents

Description

TECHNICAL FIELD This disclosure relates to analyzing source code, and more particularly to creating CRUD diagrams of global variables.

In recent years, the scale of source code in software development has increased. Along with this, the number of potential defects included in the source code tends to increase. In particular, global variables can be referenced from any function within a project, making it difficult to detect and analyze the extent of influence of global variables.

Regarding the analysis of the source code, for example, Japanese Patent Application Laid-Open No. 2020-119348 (Patent Document 1) describes, "Detecting the calling relationship between a plurality of modules included in the analysis target program. Get the query generated against the database by the activation of the first module, and determine whether the acquired query satisfies the predetermined format.If the query does not meet the predetermined format, if it does not satisfy the predetermined format, the The second module, which is the caller of the first module, is activated, and by tracing the modules to be activated toward the caller until a query satisfying a predetermined format is acquired, the query satisfying the predetermined format is obtained. outputs analysis results indicating which modules were invoked when the query was generated" (see [Abstract]).

JP 2020-119348 A

According to the technique disclosed in Japanese Patent Laid-Open No. 2002-200013, it is impossible to detect a location that may contain potential defects due to global variables in the source code. Therefore, there is a need for techniques for detecting locations in source code that may contain potential defects due to global variables.

The present disclosure has been made in view of the background as described above, and an object in one aspect is to provide a technique for detecting locations that may contain potential defects due to global variables in source code. It is in.

According to one embodiment, a method for analyzing source code by one or more processors is provided. The method includes the steps of obtaining a defect pattern of a program; obtaining source code of the program; extracting CRUD information about global variables from the source code; It includes identifying defects and outputting a CRUD diagram containing information of potential defects.

According to one embodiment, it is possible to detect locations in the source code that may contain potential defects due to global variables.

The above and other objects, features, aspects and advantages of this disclosure will become apparent from the following detailed description of the disclosure taken in conjunction with the accompanying drawings.

1 is a diagram showing an example of a functional configuration of a CRUD diagram generation device 100 according to an embodiment; FIG. 1 is a diagram showing an example of a hardware configuration of a CRUD diagram generation device 100; FIG. 3 is an example of CRUD information 300 according to one embodiment. It is an example of a potential defect pattern 111 according to an embodiment. 113 illustrates an example CRUD diagram 113 according to an embodiment; FIG. FIG. 10 is a diagram showing an example of a procedure of registration processing of the latent failure pattern 111 in the CRUD diagram generation device 100; FIG. 3 is a diagram showing an example of a procedure from acquisition of the source code 112 to generation of the CRUD diagram 113 in the CRUD diagram generation device 100; FIG. 3 is a diagram showing an example of a procedure of CRUD information extraction processing in the CRUD diagram generation device 100; FIG. 10 is a diagram showing an example of a procedure for specifying a potential defect location in the CRUD diagram generation device 100; FIG. 10 is a diagram showing an example of data 1000 of potential defect locations according to an embodiment; FIG. 11 is a diagram showing an example of the procedure of generation processing of the CRUD diagram 113 in the CRUD diagram generation device 100; FIG. 3 is a diagram showing an example of a functional configuration of a CRUD diagram generation device 1200 according to an embodiment; FIG. It is a figure which shows an example of a task. FIG. 12 is a diagram showing an example of a potential failure pattern 1211 for each task; 12 is a diagram showing an example of a task-based CRUD diagram 1215. FIG. FIG. 10 is a diagram showing an example of task combination processing in the CRUD diagram generation device 1200; FIG. 12 is a diagram showing an example of processing for identifying a latent defect location in the CRUD diagram generation device 1200; FIG. 13 is a diagram showing an example of a functional configuration of a CRUD diagram generation device 1850 according to an embodiment; FIG. FIG. 18 is a diagram showing an example of a procedure for extracting an inter-task dependency output file 1851. FIG. 18 is a diagram showing an example of an output file 1851 of inter-task dependencies; FIG. 18 is a diagram showing an example of the procedure of processing up to outputting an output file 1851 of inter-task dependencies in the CRUD diagram generation device 1850. FIG. 1 is a diagram showing an example of a functional configuration of CRUD diagram generation device 1800 according to the present embodiment; FIG. 18 is a diagram showing an example of a potential defect pattern 1811; FIG. FIG. 18 is a diagram showing an example of a difference file 1815 of the CRUD diagram; FIG. FIG. 18 is a diagram showing an example of a processing procedure for generating a CRUD diagram difference file 1815 in the CRUD diagram generation device 1800;

Hereinafter, embodiments of the technical concept according to the present disclosure will be described with reference to the drawings. In the following description, the same parts are given the same reference numerals. Their names and functions are also the same. Therefore, detailed description thereof will not be repeated.

Embodiment 1.
The CRUD diagram generation device 100 according to the present embodiment analyzes the source code of an arbitrary program, and finds places where there is a possibility of potential defects in the source code (hereinafter referred to as "potential defect places"). Identify. In addition, the CRUD diagram generation device 100 generates a CRUD diagram that highlights information on potential defect locations. Potential fault locations include locations where there is a possibility that faults caused by global variables are latent. First, the functions and hardware configuration of the CRUD diagram generation device 100 will be described with reference to FIGS. 1 and 2. FIG.

FIG. 1 is a diagram showing an example of the functional configuration of CRUD diagram generation device 100 according to the present embodiment. In one aspect, each functional block shown in FIG. 1 can be realized by the hardware shown in FIG. 2 cooperating with software.

The CRUD diagram generation device 100 includes a potential failure pattern input unit 101 , a static analysis unit 102 , a CRUD information extraction unit 103 , a potential failure location identification unit 104 , and a CRUD diagram generation unit 105 . The input/output files of the CRUD diagram generation device 100 include potential fault patterns 111 , source code 112 and CRUD diagrams 113 . The data accumulated by the CRUD diagram generation device 100 is stored in an analysis data DB (database) 121, a CRUD information DB 122, and a potential fault pattern DB 123, respectively. In one aspect, each DB may be saved in a storage device (not shown) inside the CRUD diagram generation device 100, or may be saved in an external device.

The potential defect pattern input unit 101 receives an input of the potential defect pattern 111 . Further, the potential defect pattern input unit 101 stores the acquired potential defect pattern 111 in the potential defect pattern DB 123 . The defect potential pattern 111 is, for example, the execution of global variable creation (Create), reference (Read), update (Update), and deletion (Delete) that may cause potential defects in the source code of a certain program. Contains a combination of conditions (hereinafter each referred to as "Create (C), Reference (R), Update (U) and Delete (D)").

Generation of global variables (C) includes generation of class instances in object-oriented programs or dynamic allocation of memory areas to variables. Dynamic allocation of memory to a variable corresponds to, for example, execution of the "malloc( )" function in C language. A global variable reference (R) is a process of reading data stored in a variable. Updating (U) a global variable is the updating or overwriting of the data stored in the variable. Deletion (D) includes deleting an instance or releasing a memory area dynamically allocated for a variable.

The static analysis unit 102 acquires the source code 112, analyzes the source code, and generates analysis data including reference relationship information of global variables and functions. The static analysis unit 102 stores the generated analysis data in the analysis data DB 121 . In some aspects, source code 112 may include source code in any language. For example, the source code 112 may be source code in a language such as C that requires compilation, or source code in a language that is executed by an interpreter such as Python. In another aspect, the static analysis unit 102 may be realized by a static analysis tool using existing static analysis technology.

In one aspect, the potential failure pattern input unit 101 and the static analysis unit 102 may include an input interface that receives input from the user and/or a communication interface that acquires communication from other devices.

The CRUD information extraction unit 103 reads and analyzes the analysis data from the analysis data DB 121 to determine which functions create (C), reference (R), update (U), and Generate CRUD information including whether it was deleted (D) and its execution count. The CRUD information extraction unit 103 stores the generated CRUD information in the CRUD information DB 122 . Henceforth, creation (C), reference (R), update (U), and deletion (D) are collectively referred to as "CRUD operations". Also, "the number of CRUD processes executed (or CRUD information)" refers to the number of times each of creation (C), reference (R), update (U), and deletion (D) processes is executed. The CRUD information extracted by the CRUD information extraction unit 103 includes the number of CRUD processing executions (CRUD information) for each global variable of each function.

The potential fault location identification unit 104 acquires the potential fault pattern 111 from the potential fault pattern DB 123 and the CRUD information from the CRUD information DB 122 . The potential defect location identification unit 104 identifies a potential defect location based on the potential defect pattern 111 and the CRUD information. The potential fault point identification unit 104 outputs the information on the potential fault point and the CRUD information to the CRUD diagram generation unit 105 .

The CRUD diagram generation unit 105 generates and outputs a CRUD diagram 113 based on the potential defect point information and the CRUD information acquired from the potential defect point identification unit 104 . The CRUD diagram 113 contains information that highlights potential faults in the CRUD diagram 113 . In a certain aspect, the highlighting of the potential defect location in the CRUD diagram 113 is performed by changing the color of the column of the defect location, processing the ruled line of the column of the defect location, changing the character size, emphasizing the character, changing the character color, or Any highlighting such as combinations of these may be included. By referring to the CRUD diagram 113 in which the defect location is highlighted, the user can easily discover potential defects caused by global variables included in the source code 112 .

In one aspect, the analysis data DB 121, the CRUD information DB 122, and the potential defect pattern DB 123 may be relational DBs, or may contain data in any format such as JSON (JavaScript (registered trademark) Object Notation). . Further, in another aspect, the CRUD diagram generation device 100 may store data of latent failure points acquired or generated in the past and the CRUD diagram 113 in a memory (not shown).

FIG. 2 is a diagram showing an example of the hardware configuration of the CRUD diagram generation device 100. As shown in FIG. The CRUD diagram generation device 100 includes a CPU (Central Processing Unit) 201, a primary storage device 202, a secondary storage device 203, an external device interface 204, an input interface 205, an output interface 206, and a communication interface 207. including.

The CPU 201 can execute programs for realizing various functions of the CRUD diagram generation device 100 . The CPU 201 is composed of, for example, at least one integrated circuit. The integrated circuit may be composed of, for example, at least one CPU, at least one FPGA (Field Programmable Gate Array), or a combination thereof.

Primary storage device 202 stores programs executed by CPU 201 and data referred to by CPU 201 . In one aspect, the primary storage device 202 may be implemented by a DRAM (Dynamic Random Access Memory), an SRAM (Static Random Access Memory), or the like.

The secondary storage device 203 is a non-volatile memory and may store programs executed by the CPU 201 and data referred to by the CPU 201 . In that case, the CPU 201 executes the program read from the secondary storage device 203 to the primary storage device 202 and refers to the data read from the secondary storage device 203 to the primary storage device 202 . In one aspect, the secondary storage device 203 is implemented by a HDD (Hard Disk Drive), SSD (Solid State Drive), EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), flash memory, or the like. may

The external device interface 204 can be connected to arbitrary external devices such as printers, scanners and external HDDs. In one aspect, the external device interface 204 may be realized by a USB (Universal Serial Bus) terminal or the like.

Input interface 205 may be connected to any input device such as a keyboard, mouse, touchpad or gamepad. In one aspect, the input interface 205 may be realized by a USB terminal, a PS/2 terminal, a Bluetooth (registered trademark) module, and the like.

The output interface 206 can be connected to any output device such as a CRT display, a liquid crystal display, or an organic EL (Electro-Luminescence) display. In one aspect, the output interface 206 may be implemented by a USB terminal, a D-sub terminal, a DVI (Digital Visual Interface) terminal, an HDMI (registered trademark) (High-Definition Multimedia Interface) terminal, or the like.

The communication interface 207 is connected to wired or wireless network equipment. In one aspect, the communication interface 207 may be implemented by a wired LAN (Local Area Network) port, a Wi-Fi (registered trademark) (Wireless Fidelity) module, or the like. In another aspect, communication interface 207 may transmit and receive data using communication protocols such as TCP/IP (Transmission Control Protocol/Internet Protocol) and UDP (User Datagram Protocol).

Next, with reference to FIGS. 3 to 5, the CRUD information, potential fault pattern 111 and CRUD diagram 113 referenced or generated by the CRUD diagram generation device 100 will be described in detail.

FIG. 3 is an example of CRUD information 300 according to this embodiment. The CRUD information 300 indicates the execution count of CRUD processing for each global variable of each function. The CRUD information 300 can be stored in the CRUD information DB 122 in the form of a table shown in FIG. 3, for example. In some aspects, CRUD information 300 may be expressed in any other data format, such as JSON. CRUD information 300 includes global variables 301, functions 302, creation (C) 303, reference (R) 304, update (U) 305, and deletion (D) 306 as elements.

A global variable 301 indicates each global variable included in the source code 112 . Function 302 shows a function using global variables. In the example shown in FIG. 3, the function "funcA" uses global variables "g_val_01, g_val_02, g_val_03". Function "funcB" also uses global variables "g_val_01, g_val_02, g_val_03".

Creation (C) 303 indicates the number of times the global variable was created. References (R) 304 indicates the number of times the global variable has been referenced. Update (U) 305 indicates the number of times the global variable has been updated. Deletions (D) 306 indicates the number of times a global variable has been deleted. Taking the first row of the table of the CRUD information 300 as an example, the global variable "g_val_01" is created once, referenced once, and updated once by the function "funcA", but is never deleted. not Also, taking the fourth row of the table of the CRUD information 300 as an example, the global variable "g_val_02" is updated once and deleted once by the function "funcB", but is neither created nor referenced. .

FIG. 4 is an example of potential defect pattern 111 according to the present embodiment. The fault potential pattern 111 defines a combination of execution counts of CRUD processes that can cause problems in the CRUD diagram. The potential failure pattern 111 can be stored in the potential failure pattern DB 123 in the form of a table shown in FIG. 4, for example. In one aspect, the potential defect pattern 111 may be expressed in any other data format such as JSON. In another aspect, the potential failure pattern input unit 101 does not necessarily have to accept input of data in the format shown in FIG. may

The potential failure pattern 111 includes an ID (Identifier) 401, a classification 402, a target 403, and a condition 404 as elements. ID 401 uniquely indicates each fault. Classification 402 indicates the classification of the defect. In the example shown in FIG. 4, categories 402 include defects and warnings. Each failure can be classified based on its degree of risk and the like. Target 403 indicates the analysis target. Objects 403 may include, for example, global variables and functions. In one aspect, object 403 may include classes of object-oriented programs, and the like. A condition 404 indicates a condition for detecting a potential defect location. Conditions 404 may be defined by a combination of CRUD process execution counts.

Taking the first row of the table in FIG. 4 as an example, the CRUD diagram generation device 100 executes the condition 404 “C>0 && D==0 (creation (C) is executed one or more times in the target 403 “global variable”, and deletion (D) is never executed)" is confirmed, it is determined that there is a potential failure of the category 402 "Failure" in a certain global variable. The first row of the table in FIG. 4 indicates that a global variable instance has been created (or memory has been dynamically allocated to the global variable), but the global variable instance has not been destroyed (or the global indicates that the dynamically allocated memory for the variable has not been released). In such cases, memory leaks can occur.

Taking the second row of the table in FIG. 4 as an example, the CRUD diagram generation device 100 executes the condition 404 “U>0 && R==0 (update (U) is executed one or more times in the object 403 “global variable”, and the reference (R) is never executed)" is confirmed, it is determined that there is a potential failure of category 402 "Warning" in a certain global variable. The second row of the table in FIG. 4 indicates that the global variable has been updated but has never been referenced since. In such cases, the source code 112 may contain meaningless processing.

In a certain aspect, when a "function" is specified as the object 403, the CRUD diagram generation device 100 adds up CRUD information for all global variables in each function. The CRUD diagram generation device 100 determines whether the result of adding each function matches the pattern included in the condition 404 . The CRUD diagram generation device 100 determines that there is a potential problem in a function when the result of summation of a function matches the pattern included in the condition 404 .

FIG. 5 is a diagram showing an example of the CRUD diagram 113 according to this embodiment. The CRUD diagram 113 contains information on the number of CRUD processing executions for each global variable of each function. In addition, the CRUD diagram 113 highlights potential fault locations.

The CRUD diagram 113 includes a global variable 501 and functions 502 and 503 as elements. Note that the functions “funcA, funcB” shown in FIG. 5 are only examples, and in a certain aspect, the CRUD diagram 113 may include any number of functions, one or more, in the source code 112 as elements.

Taking the first line of FIG. 5 as an example, the global variable 501 “g_val_01” is created (C) once, referenced (R) once, and updated (U) once in the function 502 “funcA”. there is The global variable 501 "g_val_01" is referenced (R) twice and updated (U) once in the function 503 "funcB". The first line in FIG. 5 is highlighted because it matches the condition 404 “C>0&&D==0” in the first line in FIG.

Taking the second line in FIG. 5 as an example, the global variable 501 “g_val — 02” is created (C) once and updated (U) twice in the function 502 “funcA”. The global variable 501 "g_val_02" is updated (U) once and deleted (D) once in the function 503 "funcB". The second line in FIG. 5 is highlighted because it matches the condition 404 “U>0&&R==0” in the second line in FIG. Note that the highlighting of the CRUD diagram 113 can be changed as appropriate according to the classification 402 .

Row 3 in FIG. 5 is not highlighted because none of the conditions 404 in FIG. 4 are met. In this way, the CRUD diagram generation device 100 outputs the CRUD diagram 113 in which potential failure points are highlighted. By referring to the CRUD diagram 113, the user can easily find a location that may contain potential problems due to global variables in the source code 112. FIG.

Next, with reference to FIGS. 6 to 11, the procedure of processing by the CRUD diagram generation device 100 to analyze the source code 112 and output the CRUD diagram 113 will be described. In one aspect, the CPU 201 may load a program for performing each process of FIGS. 6 to 9, 11 and 12 from the secondary storage device 203 to the primary storage device 202 and execute the program. . In other aspects, part or all of the process may also be implemented as a combination of circuit elements configured to perform the process.

FIG. 6 is a diagram showing an example of a procedure for registering the latent failure pattern 111 in the CRUD diagram generation device 100. As shown in FIG. In step S<b>610 , the CPU 201 acquires a potential defect pattern file including one or more potential defect patterns 111 via the input interface 205 . In one aspect, CPU 201 may acquire a potential failure pattern file via external device interface 204 or communication interface 207 .

In step S<b>620 , the CPU 201 repeatedly executes the processing inside the loop until the registration processing of all potential defect patterns 111 is completed. In step S630, the CPU 201 acquires one potential defect pattern 111 from the potential defect pattern file.

In step S<b>640 , the CPU 201 determines whether the potential defect pattern 111 acquired in step S<b>630 has already been registered in the potential defect pattern DB 123 . When CPU 201 determines that latent failure pattern 111 acquired in step S630 is already registered in latent failure pattern DB 123 (YES in step S640), CPU 201 shifts control to step S620. Otherwise (NO in step S640), CPU 201 shifts the control to step S650. In step S<b>650 , the CPU 201 registers the potential defect pattern 111 acquired in step S<b>630 in the potential defect pattern DB 123 .

FIG. 7 is a diagram showing an example of the procedure from acquisition of the source code 112 to generation of the CRUD diagram 113 in the CRUD diagram generation device 100. As shown in FIG. In step S<b>710 , the CPU 201 performs static analysis on the obtained source code 112 . The CPU 201 stores the analysis data in the analysis data DB 121. FIG.

In step S720, the CPU 201 extracts CRUD information from the analysis data. The CPU 201 stores CRUD information in the CRUD information DB 122 . Details of the processing of step S720 will be described with reference to FIG.

In step S<b>730 , the CPU 201 identifies a potential defect location in the source code 112 based on the potential defect pattern 111 . In one aspect, the CPU 201 may store the data of potential defect locations in the secondary storage device 203 . Details of the processing in step S730 will be described with reference to FIG.

In step S740, the CPU 201 generates and outputs the CRUD diagram 113 from the CRUD information and potential defect locations. In one aspect, CPU 201 may store CRUD diagram 113 in secondary storage device 203 . Details of the processing of step S740 will be described with reference to FIG.

FIG. 8 is a diagram showing an example of a procedure of CRUD information extraction processing in the CRUD diagram generation device 100. As shown in FIG. The processing shown in FIG. 8 corresponds to step S720 in FIG. In step S810, the CPU 201 repeatedly executes the processing inside the loop until confirmation of all variables included in the analysis data is completed.

In step S820, the CPU 201 extracts variables from the analysis data. Variables here refer to all variables contained in source code 112 and may include both global variables and local variables. In some aspects, variables may include structures, arrays, pointers, classes, and the like.

In step S830, CPU 201 determines whether the acquired variable is a global variable. When CPU 201 determines that the acquired variable is a global variable (YES in step S830), control proceeds to step S840. Otherwise (NO in step S830), CPU 201 shifts the control to step S820.

In step S840, the CPU 201 repeatedly executes the processing of steps S850 to S870 until confirmation of all functions included in the analysis data is completed. In step S850, CPU 201 retrieves the reference function from the analysis data. A reference function is a function that executes CRUD processing on the variables acquired in step S820.

In step S860, the CPU 201 extracts CRUD information. More specifically, the CPU 201 extracts CRUD information for the variable obtained in step S820 of the reference function extracted in step S850.

In step S870, the CPU 201 registers the CRUD information extracted in step S860 in the CRUD information DB 122. FIG. If the same data has already been registered in the CRUD information DB 122, the CPU 201 does not have to execute the process of this step.

FIG. 9 is a diagram showing an example of a procedure for specifying a latent failure point in the CRUD diagram generation device 100. As shown in FIG. The processing shown in FIG. 9 corresponds to step S730 in FIG. In step S905, the CPU 201 repeatedly executes the processing inside the loop until confirmation of all potential failure patterns is completed. In step S<b>910 , the CPU 201 retrieves the potential defect pattern 111 from the potential defect pattern DB 123 .

In step S915, the CPU 201 determines whether the determination target is a global variable. The determination target here is the target for determination as to whether or not it matches the defect potential pattern 111 acquired in step S910. Objects to be determined may include global variables and functions. In one aspect, global variables may include structures, arrays, pointers, and the like. In another aspect, the determination target may include classes including variables and/or functions. When CPU 201 determines that the determination target is a global variable (YES in step S915), CPU 201 moves the control to step S920. Otherwise (NO in step S915), CPU 201 shifts the control to step S945.

In step S920, the CPU 201 repeatedly executes the processing within the loop until confirmation of all global variables is completed. In step S925, the CPU 201 extracts global variables from the CRUD information.

In step S930, the CPU 201 sums the CRUD information of the global variables. The sum here is the sum of the number of CRUD processing execution times of each function for the global variables acquired in step S925. For example, global variable "g_val_01" is assumed to have CRUD processing "C(1)R(1)U(1)D(0)" executed by function "funcA" (for example, C(1) is created means one execution of (C)). It is also assumed that the global variable "g_val_01" is subjected to the CRUD processing "C(0)R(2)U(1)D(0)" by the function "funcB". In this case, the CPU 201 executes CRUD processing “C(1)R(1)U(1)D(0)” by function “funcA” and CRUD processing “C(0)R(2)U” by function “funcB”. (1) D(0)” to obtain the sum result “C(1)R(3)U(2)D(0)”.

In step S<b>935 , the CPU 201 determines whether or not the result of summation matches the extracted defect potential pattern 111 . When CPU 201 determines that the result of summation matches potential defect pattern 111 extracted (YES in step S935), CPU 201 shifts the control to step S940. Otherwise (NO in step S935), CPU 201 shifts the control to step S925.

In step S940, the CPU 201 registers a global variable for which CRUD processing that matches the potential defect pattern 111 is executed as a potential defect location. In one aspect, CPU 201 may store the registration result in secondary storage device 203 .

In step S945, the CPU 201 repeatedly executes the processing in the loop until confirmation of all functions is completed. In step S950, the CPU 201 extracts functions from the CRUD information.

In step S955, the CPU 201 adds up the number of CRUD processing executions (CRUD information) of the functions extracted in step S950. For example, the function "funcA" performs CRUD processing "C(1)R(1)U(1)D(0)", CRUD processing "C(1) R(0)U(2)D(0)" and CRUD processing "C(1)R(1)U(1)D(0)" respectively. In this case, the CPU 201 obtains the result "C(3)R(2)U(4)D(0)" of the CRUD processing for each of the global variables "g_val_01, g_val_02, g_val_03" of the function "funcA".

In step S<b>960 , the CPU 201 determines whether or not the result of summation matches the extracted defect potential pattern 111 . When CPU 201 determines that the result of summation matches potential defect pattern 111 extracted (YES in step S960), CPU 201 shifts the control to step S965. Otherwise (NO in step S960), CPU 201 shifts the control to step S945.

In step S965, the CPU 201 registers a function that executes CRUD processing that matches the potential defect pattern 111 as a potential defect location. In one aspect, CPU 201 may store the registration result in secondary storage device 203 .

FIG. 10 is a diagram showing an example of data 1000 of potential defect locations according to the present embodiment. The data 1000 of potential defect locations is generated and registered by the process shown in FIG. Potential defect location data 1000 includes an ID 1001, a potential defect location 1002, a type 1003, and a classification 1004 as elements.

The ID 1001 uniquely identifies a potential defect location included in the data 1000 of the potential defect location. Potential fault locations 1002 indicate global variables or functions that may have potential faults. The type 1003 indicates the type of the latent defect location 1002 . Types 1003 may include global variables and functions. Classification 1004 indicates the classification of the defect. Categories 1004 may include defects and warnings.

FIG. 11 is a diagram showing an example of the procedure of generation processing of the CRUD diagram 113 in the CRUD diagram generation device 100. As shown in FIG. The processing shown in FIG. 11 corresponds to step S740 in FIG.

In step S<b>1110 , the CPU 201 retrieves a list of global variables from the CRUD information DB 122 . In step S<b>1120 , the CPU 201 retrieves a function list from the CRUD information DB 122 . In one aspect, CPU 201 may simultaneously execute the processes of steps S1110 and S1120.

In step S1130, the CPU 201 repeatedly executes the processing in the loop until confirmation of all the global variables taken out is completed. In step S1140, CPU 201 repeatedly executes the processing in the loop until confirmation of all the extracted functions is completed. In step S1150, the CPU 201 generates a CRUD diagram 113 of global variables and functions retrieved from the CRUD information DB 122. FIG. In step S1160, the CPU 201 changes the display of the potential defect location in the CRUD diagram 113 to a highlighted display based on the data 1000 of the potential defect location. The CPU 201 outputs a CRUD diagram 113 in which potential fault locations are highlighted.

As described above, the CRUD diagram generation device 100 according to the present embodiment has the function of analyzing the source code 112 of the program and outputting the CRUD diagram 113 highlighting potential failure points caused by the processing of global variables. . This function makes it easier for the user to find defects caused by the processing of global variables, which are usually difficult to find.

Embodiment 2.
Next, Embodiment 2 will be described. This embodiment differs from the first embodiment in that a CRUD diagram is generated based on a task list. The same reference numerals are assigned to the same configurations as those of the first embodiment, and description thereof will not be repeated.

FIG. 12 is a diagram showing an example of the functional configuration of CRUD diagram generation device 1200 according to the present embodiment. In one aspect, each functional block shown in FIG. 12 can be realized by the hardware shown in FIG. 2 cooperating with software.

The CRUD diagram generation device 1200 includes a potential failure pattern input unit 1201, a static analysis unit 102, a CRUD information extraction unit 1203, a task combination unit 1206, a potential failure location identification unit 1204, and a CRUD diagram generation unit 1205. Prepare.

The task list 1214 includes task (function) names and function names that are entry points of the tasks. For example, tasks may include individual functions such as processing product purchases in online shop software. Also, the entry point function is a function that starts the processing of the task.

The task combiner 1206 groups the functions associated with the tasks included in the task list 1214 based on the obtained task list 1214 . Hereinafter, data in which functions related to a certain task are grouped will be referred to as "task information". The task combining unit 1206 saves the task information in the analysis data DB 121. FIG. The task information may be associated with analysis data output by the static analysis unit 102 .

The potential failure pattern input unit 1201 receives an input of a potential failure pattern 1211 for each task. The CRUD information extraction unit 1203 extracts CRUD information for each task based on the task information. In one aspect, the CRUD information extraction unit 1203 may extract CRUD information in units of functions from the analysis data. In that case, the potential fault point identification unit 1204 can add up the CRUD information of the functions so that each task is processed.

The potential fault location identification unit 1204 identifies whether or not there is a potential fault in the source code 112 on a task-by-task basis. In other words, the potential defect location identification unit 1204 identifies whether or not there is a potential defect in the source code 112 based on the sum of the CRUD information of the functions included in the task.

The CRUD diagram generation unit 1205 generates a CRUD diagram 1215 including CRUD information for each task in global variables. The defect identification location highlighted is also a task unit. The CRUD information for each task is the total value of the CRUD information of each function included in the task.

FIG. 13 is a diagram illustrating an example of tasks. In the example shown in FIG. 13, source code 112 includes task 1300 and task 1310 (tasks may be called functions). Task 1300 also includes functions "funcA, funcB, funcC, funcD, funcE, funcF." Task 1310 includes the functions "funcG, funcH, funcI". In this case, the CRUD information of the task 1300 is the sum of the CRUD information of the functions "funcA, funcB, funcC, funcD, funcE, funcF". Also, the CRUD information of the task 1310 is the sum of the CRUD information of the functions "funcG, funcH, funcI".

FIG. 14 is a diagram showing an example of a potential defect pattern 1211 for each task. The potential defect pattern 1211 includes an ID 1401, a category 1402, a target 1403, and a condition 1404 as elements. The potential defect pattern 1211 can be stored in the potential defect pattern DB 123 in the form of a table shown in FIG. 14, for example. In one aspect, the potential defect pattern 1211 may be expressed in any other data format such as JSON.

ID 1401 uniquely indicates each fault. Classification 1402 indicates the classification of the defect. In the example shown in FIG. 14, categories 1402 include "malfunction" and "warning." Each failure can be classified based on its degree of risk and the like. Target 1403 indicates the analysis target. Objects 1403 may include, for example, global variables (tasks), global variables and functions. A global variable (task) is a global variable whose CRUD information is analyzed for each task. A condition 1404 indicates a condition for detecting a potential defect location. In the example shown in FIG. 14, the conditions 1404 are "number of task references >= 4 (global variables referenced by four or more tasks)" and "number of task references == 1 (referenced by only a single task)". global variables)”.

For example, a global variable that is only referenced by a single task may be changed to a local variable. The CRUD diagram generation device 1200 can reduce man-hours for failure analysis of the source code 112 by presenting global variables that are referenced only by a single task to the user as refactoring indicators.

FIG. 15 is a diagram showing an example of a CRUD diagram 1215 for each task. The CRUD diagram 1215 includes global variables 1501 and tasks 1502-1505 as elements. It should be noted that tasks 1502-1505 are examples, and in some aspects, CRUD diagram 1215 may include any number of tasks as elements. In the example shown in FIG. 15, a plurality of functions are aggregated into tasks 1-4. The GRUD information of each task is the sum of the CRUD information of the functions included in each task (CRUD information for each task).

The first line of the CRUD diagram 1215 is highlighted because the global variable 1501 "g_val_01" is referenced by four or more tasks and matches the condition 1404 "number of task references >= 4" included in the defect potential pattern 1211. It is In addition, the third line of the CRUD diagram 1215 is highlighted because the global variable "g_val_03" is referenced from one task and matches the condition "task reference count == 1" included in the defect potential pattern. there is

Next, referring to FIGS. 16 and 17, the CRUD diagram generation device 1200 will describe the process of combining tasks and the process of identifying potential fault locations. In one aspect, CPU 201 may load a program for performing the processes of FIGS. 16 and 17 from secondary storage device 203 to primary storage device 202 and execute the program. In other aspects, part or all of the process may also be implemented as a combination of circuit elements configured to perform the process.

FIG. 16 is a diagram showing an example of task combination processing in the CRUD diagram generation device 1200. As shown in FIG. In step S<b>1610 , the CPU 201 reads the input task list 1214 and analysis data of the source code 112 . In one aspect, the CPU 201 may acquire CRUD information including function information instead of analysis data.

In step S1620, the CPU 201 repeatedly executes the processing in the loop until confirmation of all functions (functions serving as entry points) included in the task list 1214 is completed.

In step S<b>1630 , CPU 201 extracts the task name and entry point function from task list 1214 . In step S1640, CPU 201 retrieves all functions included in the analysis data.

In step S1650, the CPU 201 repeatedly executes the processing in the loop until confirmation of all call functions is completed. A "calling function" is a function that is directly or indirectly referred to by a function that is an entry point. In the example shown in FIG. 13, the function "funcA" is the entry point function, and the functions "funcB, funcC, funcD, funcE, funcF" are the calling functions.

In step S1660, if one of the functions included in the analysis data is a call function, CPU 201 registers it as a task function. In one aspect, CPU 201 may register a function for each of a plurality of tasks.

In step S1670, CPU 201 registers the created task information. In one aspect, the secondary storage device 203 may store task information including entry point functions, calling functions, and task names.

FIG. 17 is a diagram showing an example of processing for identifying a latent defect location in the CRUD diagram generation device 1200. As shown in FIG. In step S1710, the CPU 201 repeatedly executes the processing in the loop until confirmation of all potential failure patterns is completed. In step S<b>1720 , CPU 201 retrieves potential defect pattern 1211 from potential defect pattern DB 123 .

In step S1730, the CPU 201 determines whether the determination target is a global variable (task). When CPU 201 determines that the determination target is a global variable (task) (YES in step S1730), CPU 201 shifts the control to step S1740. Otherwise (NO in step S1730), CPU 201 shifts the control to step S1790. Objects to be judged can include ordinary global variables and functions in addition to global variables (tasks).

In step S1740, CPU 201 repeatedly executes the processing in the loop until confirmation of all global variables is completed. In step S1750, the CPU 201 extracts a global variable from the task-based CRUD information.

In step S1760, the CPU 201 acquires and stores the number of tasks that refer to the global variable extracted in step S1750 from the task-based CRUD information. In one aspect, CPU 201 may obtain and store information about any CRUD process, not just the number of tasks that reference global variables.

In step S1770, CPU 201 determines whether or not the information saved in step S1760 matches potential defect pattern 1211 extracted. When CPU 201 determines that the information saved in step S1760 matches potential defect pattern 1211 extracted (YES in step S1770), CPU 201 shifts the control to step S1780. Otherwise, CPU 201 transfers control to step S1740.

In step S1780, the CPU 201 registers a global variable for which CRUD processing that matches the potential defect pattern 1211 is executed as a potential defect location. In one aspect, CPU 201 may store the registration result in secondary storage device 203 . In step S1790, CPU 201 executes processing for other objects (global variables, functions, etc.). The processing for other objects includes the processing shown in FIG. 9 and the like.

As described above, the CRUD diagram generation device 1200 according to the present embodiment does not analyze all of the enormous source code 112, but narrows down the analysis targets to functions and global variables related to tasks (functions). Thereby, the CRUD diagram generation device 1200 can efficiently identify potential failures caused by global variables.

Embodiment 3.
Next, Embodiment 3 will be described. In this embodiment, the inter-task dependency extraction unit 1861 is added to the configuration of the second embodiment. , which is different from the first and second embodiments.

FIG. 18 is a diagram showing an example of the functional configuration of the CRUD diagram generation device 1850 according to this embodiment. In one aspect, each functional block shown in FIG. 18 can be realized by the hardware shown in FIG. 2 cooperating with software.

The CRUD diagram generation device 1850 includes an inter-task dependency extraction unit 1861 in addition to the configuration of the CRUD diagram generation device 1200 . The inter-task dependency extraction unit 1861 acquires CRUD information for each task included in the source code 112 to be analyzed from the CRUD information DB 122 . Next, the inter-task dependency extraction unit 1861 extracts the number of global variables shared between tasks as the degree of inter-task dependency. As an example, the inter-task dependency extraction unit 1861 extracts the number of global variables shared between task 1 and task 2 as the inter-task dependency of task 1 and task 2 .

The inter-task dependency extraction unit 1861 extracts the number of global variables shared between tasks (inter-task dependency) and outputs an inter-task dependency output file 1851 . If there are three or more global variables, the output file 1851 of inter-task dependencies contains a plurality of inter-task dependencies (for example, inter-task dependencies of global variables 1 and 2, inter-task dependencies of global variables 2 and 3, inter-task dependencies of global variables 3, 1, etc.).

FIG. 19 is a diagram showing an example of the procedure for extracting the inter-task dependency output file 1851. As shown in FIG. In the example shown in FIG. 19, the source code 112 to be analyzed includes tasks 1-4 and global variables "g_val_01", "g_val_02", "g_val_03", "g_val_04" and "g_val_05".

The inter-task dependency extraction unit 1861 extracts inter-task dependencies for each combination of all tasks, and includes these inter-task dependencies in the inter-task dependency output file 1851 . For example, tasks 1 and 2 share 'g_val_01', 'g_val_02' and 'g_val_04'. Therefore, the inter-task dependency extraction unit 1861 extracts the inter-task dependency of task 1 and task 2 "3".

FIG. 20 is a diagram showing an example of the intertask dependency output file 1851 . The inter-task dependency output file 1851 shown in FIG. 20 is generated from the CRUD information shown in FIG. As an example, referring to record 2051, task 1 and task 2 have an inter-task dependency of "3", task 1 and task 3 have an inter-task dependency of "2", and task 1 and task 4 have a degree of inter-task dependency of "3". The degree of interdependence is "1".

Basically, the higher the degree of dependence between tasks (the greater the number of shared tasks), the more complex the management of global variables and the more likely problems will occur. Therefore, the CRUD diagram generation device 1850 can reduce the number of man-hours for failure analysis of the source code 112 by presenting the degree of dependence between tasks to the user (by presenting global variables with large degree of dependence between tasks to the user). .

FIG. 21 is a diagram showing an example of the procedure of processing up to outputting the output file 1851 of intertask dependencies in the CRUD diagram generation device 1850 .

In step S2160, CPU 201 repeatedly executes the processing in the loop until all tasks are confirmed.

In step S<b>2165 , the CPU 201 extracts tasks from the CRUD information acquired from the CRUD information DB 122 .

In step S2170, CPU 201 repeatedly executes the processing in the loop until all tasks other than the task extracted in step S2165 are confirmed. For example, when the source code 112 to be analyzed includes tasks 1 to 5 and task 1 is extracted in step S2165, the CPU 201 repeats the processing from step S2175 until all tasks 2 to 5 are confirmed. loop.

In step S2175, CPU 201 counts the global variables shared by the two extracted tasks. For example, if task 1 is fetched at step S2165 and task 2 is fetched at step S2170, CPU 201 counts the global variables shared between task 1 and task 2. FIG.

In step S2180, CPU 201 saves the number of global variables shared by the extracted two tasks as inter-task dependency. In one aspect, CPU 201 may temporarily store inter-task dependencies in primary storage device 202 or secondary storage device 203 .

In step S2185, the CPU 201 outputs the result of the degree of dependence between tasks to a file (output file 1851 of degree of dependence between tasks).

Embodiment 4.
Next, Embodiment 4 will be described. This embodiment compares the CRUD diagram 113 before the source code 112 is modified with the CRUD diagram 113 after the source code 112 is modified, and emphasizes the places where there is a high possibility of latent defects. This differs from the first to third embodiments in that a differential file 1815 of the displayed CRUD diagram is generated. The same reference numerals are given to the same configurations as those of the first to third embodiments, and the description thereof will not be repeated.

FIG. 22 is a diagram showing an example of the functional configuration of CRUD diagram generation device 1800 according to the present embodiment. In one aspect, each functional block shown in FIG. 22 can be realized by the hardware shown in FIG. 2 cooperating with software.

The CRUD diagram generation device 1800 includes a potential failure pattern input unit 1801, a static analysis unit 102, a CRUD information extraction unit 103, a potential failure location identification unit 104, a CRUD diagram generation unit 105, and a CRUD diagram comparison unit 1807. Prepare.

The CRUD diagram generation device 1800 generates the CRUD diagram 113 by the same processing procedure as the CRUD diagram generation device 100 of the first embodiment. The CRUD diagram generation device 1800 stores the CRUD diagram 113 generated in the past in the CRUD diagram history DB 1824 . In one aspect, the CRUD diagram history DB 1824 may reside within the CRUD diagram generation device 1800 or within an external device.

The potential defect pattern input unit 1801 receives an input of a potential defect pattern 1811 for the difference between the source code 112 before and after the update, in addition to the normal potential defect pattern 111 .

The CRUD diagram comparison unit 1807 acquires the CRUD diagram 113 before the source code 112 is modified and the CRUD diagram 113 after the source code 112 is modified from the CRUD diagram history DB 1824, and outputs the difference. Then, the CRUD diagram comparison unit 1807 identifies potential fault locations caused by global variables included in the difference based on the potential fault pattern 1811 . The CRUD diagram comparison unit 1807 generates and outputs a difference file of CRUD diagrams in which potential defect locations are highlighted.

FIG. 23 is a diagram showing an example of the defect potential pattern 1811. As shown in FIG. The potential defect pattern 1811 includes an ID 1901, a category 1902, a target 1903, and a condition 1904 as elements.

ID 1901 uniquely indicates each failure. Classification 1902 indicates the classification of the defect. As an example, categories 1902 include "malfunction" and "warning." Each failure can be classified based on its degree of risk and the like. Target 1903 indicates the analysis target. Objects 1903 may include, for example, functions (compare), global variables (add). The function (comparison) is the updated function (which may also include additions or deletions) and the global variable (addition) is the newly added global variable.

A condition 1904 indicates a condition for detecting a potential defect location. In the example shown in FIG. 23, the condition 1904 includes "newly added variable reference", "reference count change" and "reference location change". Newly added variable reference indicates that a newly added variable is referenced, and reference count change indicates that the number of times the variable is referenced has changed. Also, the change in the reference point indicates that there is a function that newly references the variable or no longer references the variable.

FIG. 24 is a diagram showing an example of the difference file 1815 of the CRUD diagram. The CRUD diagram difference file 1815 includes, as elements, a difference type 2001, a global variable 2002, and functions 2003-2006. Functions 2003-2006 are examples, and in certain aspects, CRUD diagram difference file 1815 may include any number of functions as elements.

The difference type 2001 indicates the type of difference before and after the source code 112 is changed. “Added” indicates that a global variable has been added by updating the source code 112 . "Change" indicates that the update of the source code 112 has caused a change in the number of CRUD processing executions for global variables. "No change" indicates neither "change" nor "addition". In the example shown in FIG. 24, the number of CRUD process executions is changed in the global variable 2002 "g_val_02", and the global variable 2002 "g_val_03" is newly added. Also, in the global variable "g_val_04", the number of CRUD processing executions has changed, and the global variable "g_val_04" is newly referenced (read twice) from the function "funcB" and is no longer updated from the function "funcC". (no longer updated).

Taking the second line of the difference file 1815 of the CRUD diagram as an example, the function "funcB, funcC" is highlighted as a potential fault location because the number of CRUD processing executions for the global variable 2002 "g_val_02" has changed. be done.

Also, taking the third line of the difference file 1815 in the CRUD diagram as an example, the global variable 2002 “g_val_03” is added by updating the source code 112 . Since the functions "funcB, funcD" execute the CRUD processing for the newly added global variable 2002 "g_val_03", they are highlighted as potential fault locations.

Furthermore, taking the fourth line of the difference file 1815 of the CRUD diagram as an example, the function "funcB" has a new CRUD process for the global variable 2002 "g_val_04", and the function "funcC" has the global variable " g_val_04” is highlighted as a potential defect location because the CRUD processing has been deleted.

By clarifying the newly referenced (or no longer referenced) global variable and the new (or no longer referenced) function that references the global variable, confirmation of exclusion processing or confirmation of the scope of influence of the global variable etc. becomes easier. The CRUD diagram generation device 1800 can reduce the man-hours for failure analysis of the source code 112 by presenting the CRUD diagram difference file 1815 to the user.

FIG. 25 is a diagram showing an example of a processing procedure for generating the CRUD diagram difference file 1815 in the CRUD diagram generation device 1800 . In one aspect, CPU 201 may load a program for performing the processing of FIG. 25 from secondary storage device 203 to primary storage device 202 and execute the program. In other aspects, part or all of the process may also be implemented as a combination of circuit elements configured to perform the process. In step S2105, the CPU 201 acquires the CRUD diagram 113 before and after the update of the source code 112 from the CRUD diagram history DB 1824. FIG.

In step S2110, the CPU 201 determines whether there is a difference in the number of global variables before and after the source code 112 is updated. When CPU 201 determines that there is a difference in the number of global variables before and after updating source code 112 (YES in step S2110), CPU 201 shifts control to step S2115. Otherwise (NO in step S2110), CPU 201 shifts the control to step S2120.

In step S2115, the CPU 201 extracts the global variable and the CRUD information with the difference as the difference part. In step S2120, the CPU 201 repeatedly executes the processing within the loop until confirmation of all global variables is completed.

In step S2125, the CPU 201 acquires global variables from the updated CRUD diagram 113 of the source code 112. FIG. In step S2130, the CPU 201 repeatedly executes the processing in the loop until the confirmation of CRUD information of all functions is completed.

In step S2135, the CPU 201 compares the CRUD information of the global variable acquired in step S2125 with the CRUD information of the same variable included in the CRUD diagram of the source code 112 before updating. Alternatively, the CPU 201 may compare the CRUD information of the function acquired from the updated CRUD diagram 113 of the source code 112 and the CRUD information of the same function included in the CRUD diagram of the source code 112 before the update.

In step S2140, CPU 201 determines whether or not there is a difference in the comparison in step S2135. When CPU 201 determines that there is a difference in the comparison in step S2135 (YES in step S2140), control proceeds to step S2145. Otherwise (NO in step S2140), CPU 201 shifts the control to step S2130.

In step S2145, the CPU 201 extracts global variables and functions related to the difference as difference points. In step S2150, CPU 201 executes defect extraction processing. More specifically, CPU 201 identifies potential defects included in the difference extracted in step S2145 based on potential defect pattern 1811 .

In step S2155, the CPU 201 generates and outputs a CRUD diagram difference file 1815 based on the difference extracted in step S2145. Based on the defect identified in step S2150, the CPU 201 highlights the potential defect portion of the difference file 1815 of the CRUD diagram.

As described above, the CRUD diagram generation device 1800 according to the present embodiment has a function of creating the CRUD diagram difference file 1815 based on the difference between before and after the source code 112 is updated. This function makes it easier for the user to identify the defect location based on the update of the source code 112 by referring to the difference file 1815 of the CRUD diagram. Note that the contents described in each embodiment may be used in combination as appropriate.

It should be considered that the embodiments disclosed this time are illustrative in all respects and not restrictive. The scope of the present disclosure is indicated by the scope of claims rather than the above description, and is intended to include all modifications within the meaning and scope equivalent to the scope of claims. In addition, it is intended that the disclosure content described in the embodiment and each modified example can be implemented singly or in combination as much as possible.

100, 1200, 1800, 1850 CRUD diagram generation device 101, 1201, 1801 Potential failure pattern input unit 102 Static analysis unit 103, 1203 CRUD information extraction unit 104, 1204 Potential failure location identification unit 105, 1205 CRUD Diagram generating unit 111, 1211, 1811 Potential failure pattern 112 Source code 113, 1215 CRUD diagram 121 Analysis data DB 122 CRUD information DB 123 Potential failure pattern DB 201 CPU 202 Primary storage device 203 2 Secondary storage device, 204 External device interface, 205 Input interface, 206 Output interface, 207 Communication interface, 300 CRUD information, 301, 501, 1501, 2002 Global variable, 302, 502, 503, 2003, 2006 Function, 303 Creation (R ), 304 reference (R), 305 update (U), 306 deletion (D), 401, 1001, 1401, 1901 ID, 402, 1004, 1402, 1902 classification, 403, 1403, 1903 target, 404, 1404, 1904 Condition 1000 Potential failure location data 1002 Potential failure location 1003 Type 1206 Task combination unit 1214 Task list 1300, 1310, 1502, 1503, 1504, 1505 Task 1807 CRUD diagram comparison unit 1815 CRUD diagram difference File 1824 CRUD diagram history DB 1851 Inter-task dependency output file 1861 Inter-task dependency extraction unit 2001 Difference type.

Claims (15)

A method of analyzing source code by one or more processors, comprising:
obtaining a program failure pattern;
obtaining the source code of the program;
extracting CRUD information about global variables from the source code;
identifying potential defects from the CRUD information based on the defect pattern;
and C. outputting a CRUD diagram containing information of said potential failure. 2. The method of claim 1, wherein outputting the CRUD diagram containing the potential defect information comprises highlighting the potential defect information contained in the CRUD diagram. 3. The step of identifying the potential defect from the CRUD information based on the defect pattern includes identifying the potential defect for each of the global variables included in the source code. The method described in . 4. The step of identifying the potential defect from the CRUD information based on the defect pattern includes identifying the potential defect for each function included in the source code. The method described in Crab. further comprising obtaining a task list containing one or more functions;
The method according to any one of claims 1 to 4, wherein extracting the CRUD information about the global variables from the source code comprises extracting the CRUD information of the global variables on a task-by-task basis. The step of extracting the CRUD information of the global variables for each task includes, if there is a global variable referenced from a single task, identifying the global variable referenced from the single task as a latent defect location . 6. The method of claim 5, comprising identifying. extracting dependencies between each task;
6. The method of claim 5, further comprising outputting the dependencies between each task as a file. a step of storing the CRUD diagram generated in the past in a CRUD diagram storage unit;
obtaining a first CRUD diagram in the source code before update and a second CRUD diagram in the source code after update from the CRUD diagram storage unit;
identifying differences between the first CRUD diagram and the second CRUD diagram;
and outputting information of said potential defects contained in said difference. 9. The method of claim 8, wherein identifying the difference between the first CRUD diagram and the second CRUD diagram comprises identifying changes in the number of global variables. wherein identifying the difference between the first CRUD diagram and the second CRUD diagram includes identifying a change in the number of Creates, Reads, Updates or Deletes in one of the global variables. Item 9. The method according to item 8. 11. The method according to claim 10, wherein said Create of said global variable includes a process of generating an instance of said global variable or a process of dynamically allocating a memory area for said global variable. 11. The method of claim 10, wherein said deleting said global variable comprises destroying an instance of said global variable or releasing a memory area reserved for said global variable. wherein the step of identifying a difference between the first CRUD diagram and the second CRUD diagram includes identifying a global variable whose number of times referenced by a function has changed as a fault latent location . Item 9. The method according to item 8. A program for causing one or more processors to execute the method according to any one of claims 1 to 13. a memory storing the program according to claim 14;
and a processor for executing the program.

Images