Information processing device, information processing method, and program

Abstract

To generate a call graph of a source code which is to be statically analyzed, in a more favorable mode.SOLUTION: An information processing apparatus includes: acquisition means which acquires a series of source codes to be analyzed; extraction means which extracts a first source code including a first annotation indicating generation of an object, for update, out of the series of source codes; and update means which adds, for a field in which the first annotation is presented, in the first source code extracted for update, one of a first code and a second code, the first code directly indicating generation of an object corresponding to the field, and the second code indirectly indicating generation of the object, to update the first source code, and generates an execution code for calling a process specified in the updated first source code. A call graph is generated on the basis of the updated first source code and the execution code.SELECTED DRAWING: Figure 7

Description

Technical Field

[0001] The present disclosure relates to an information processing apparatus, an information processing method, and a program.

Background Art

[0002] [[ID=1X]]In the development and maintenance of a program, in order to understand the target program, source code analysis may be performed on the program, and the results of the analysis may be used. As one of such source code analysis methods, a method called pointer analysis, which analyzes how objects generated in the program propagate, is known. As data output as a result of pointer analysis, for example, data showing the call relationship between objects called a call graph is known.

[0003] In recent years, in order to efficiently develop a program, the use of a template having a number of reusable program components, also called an application framework, has been increasing.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] On the other hand, in a program created using an application framework, a dependency relationship between objects is configured by the application framework at the time of program execution. Therefore, when a program is created using an application framework, the code indicating the generation of an object may not be explicitly defined on the source code. In such a case, with a so-called static analysis method such as pointer analysis, accurate analysis may be difficult.

[0006] To address the above-mentioned challenges, Patent Document 1 discloses an example of a technique for generating a call graph using information related to dependency injection (DI). However, since the technique disclosed in Patent Document 1 does not perform pointer analysis, it is not always guaranteed that an accurate call graph (a call graph that more closely reflects reality) will be created.

[0007] In view of the above problems, the present invention aims to enable the generation of a call graph of the target source code in a more suitable manner through static analysis. [Means for solving the problem]

[0008] The information processing apparatus according to the present invention comprises: an extraction means for extracting a first source code to be updated from a series of source codes to be analyzed, the first source code to be updated having a first annotation indicating the generation of an object added to it; and an update means for updating the first source code by adding either a first code that directly indicates the generation of an object corresponding to a field, or a second code that indirectly indicates the generation of the object, to the field in the first source code to be updated that has the first annotation indicated, and generating an executable code that calls the processing defined in the updated first source code. The update means, when the second code is added to the first source code, generates a second source code that, in association with the second code, specifies code that directly indicates the creation of an object corresponding to the field indicated by the first annotation, and generates the execution code such that it calls the process specified in the updated first source code by calling the process specified in the second source code. A call graph is generated based on the updated first source code and the execution code. [Effects of the Invention]

[0009] According to the present invention, static analysis makes it possible to generate a call graph of the target source code in a more suitable manner. [Brief explanation of the drawing]

[0010] [Figure 1] This is a diagram illustrating the general functions of an information processing device. [Figure 2]This diagram illustrates one example of how to update source code. [Figure 3] This diagram shows an example of the hardware configuration of an information processing device. [Figure 4] This is a functional block diagram showing an example of the functional configuration of an information processing device. [Figure 5] This is a flowchart illustrating an example of processing performed by an information processing device. [Figure 6] This diagram illustrates an example of an error that may occur when updating the source code. [Figure 7] This diagram illustrates one example of how to update source code. [Figure 8A] This diagram shows an example where the singleton is not applied. [Figure 8B] This diagram shows an example of when a singleton is applied. [Figure 9] This is a diagram to illustrate the considerations of singletons. [Figure 10] This diagram illustrates an example of a mechanism for determining whether or not a singleton can be applied. [Figure 11] This diagram illustrates an example of a mechanism for determining whether or not a singleton can be applied. [Figure 12] This diagram illustrates one example of how to update source code. [Figure 13] This is a diagram illustrating an example of how executable code is generated. [Modes for carrying out the invention]

[0011] Preferred embodiments of this disclosure will be described in detail below with reference to the attached drawings. In this specification and the drawings, components having substantially the same functional configuration are denoted by the same reference numerals, and redundant descriptions will be omitted.

[0012] <First Embodiment> The information processing apparatus according to the first embodiment of the present disclosure will be described below. First, referring to FIGS. 1 and 2, the outline of the functions of the information processing apparatus according to the present embodiment will be described. As described above, there are things such as programs created using an application framework, in which the dependency relationships between objects are configured by the application framework when the program is executed. In such a program, the code indicating the generation of an object may not be explicitly defined in the source code. For example, FIG. 1 shows an example where the code indicating the generation of an object is not explicitly defined in the source code.

[0013] Specifically, the source code C111 shown in FIG. 1(a) defines, within the code of class X, a field C112 of an object of class B and a code C113 for calling the processing (method) of the object held in the field C112. FIG. 1(b) shows an example of a call graph indicating the call relationship between objects when the program of the source code exemplified in FIG. 1(a) is executed under such a premise. On the other hand, in pointer analysis for analyzing the call relationship between objects based on the source code without executing the program, since the generation of an object for the field C112 is not explicitly defined, the field C112 is treated as Null. Therefore, when attempting to generate a call graph of the source code C111 by pointer analysis (static analysis), a call graph that does not conform to the actual situation, assuming that the object of class B is not generated, as shown in FIG. 1(c), may be generated.

[0014] In view of the above situation, the information processing apparatus according to the present embodiment updates the source code to a source code for pointer analysis (static analysis) by making partial modifications to the source code to be analyzed, thereby enabling the generation of a call graph that conforms more to the actual situation. For example, FIG. 2 is an explanatory diagram for explaining the outline of the functions of the information processing apparatus according to the present embodiment.

[0015] FIG. 2(a) shows an example of the update result of the source code to be analyzed by the information processing apparatus 100 according to the present embodiment. Specifically, the source code C121 shows an example of the source code after being updated by being modified by the information processing apparatus 100 with respect to the source code to be analyzed. Further, the source code C122 is an execution code (a code in which a so-called Main class is defined) that calls the process defined in the updated source code C121. In some frameworks, annotations are added to parts where dependency relationships between objects are configured during execution. The information processing apparatus 100 according to the present embodiment identifies, based on the annotation, the source code to be updated and the code (for example, a field) to be updated in the source code from a series of source codes designated as analysis targets. Then, the information processing apparatus 100 modifies the code based on the definition regarding the code to be updated.

[0016] For example, in the example shown in FIG. 2(a), an annotation C123 indicated by the keyword "@Autowired", which means that a dependency relationship between objects is configured during execution, is added to the field C124. Therefore, the information processing apparatus 100 extracts the source code C121 to which the annotation C123 is added as the update target from a series of source codes designated as analysis targets. Then, the information processing apparatus 100 adds code indicating the generation of an object to the field C124 indicated by the annotation C123 according to the definition within the source code C121. Specifically, in the example shown in FIG. 2(a), code directly indicating the generation of an object (for example, code for creating an object with "new") is added to the field C124 indicated by the annotation C123. In this process, the information processing device 100 identifies the object to be generated based on annotations attached to the class that the framework treats as a managed component. For example, the object set in field C124 will be an object of class A or class B. In the example shown in Figure 2(a), class B has annotation C125, indicated by the keyword "@Component", which signifies that it is a managed component. On the other hand, class A does not have any annotations indicating that it is a managed component. Therefore, the information processing device 100 recognizes that the object set in field C124 is an object of class B and adds code that directly indicates the generation of a class B object. As described above, source code C121 is updated. Furthermore, the information processing device 100 generates source code C122, which corresponds to the execution code that serves as the starting point for call graph generation, based on the update results of the target source code. Specifically, the information processing device 100 generates source code C122 as the execution code that will be called by the code related to the call of at least the updated code. For example, in the example shown in Figure 2(a), field C124 in source code C121 is the target of the update, and the object held in field C124 is referenced in code C125. Therefore, the information processing device 100 generates an object of class X in which the field C124 to be updated is defined, and generates source code C122 which defines code C126 that calls the process defined as code C125 as the processing of said object. Furthermore, the method for generating executable code (code equivalent to source code C122) that satisfies the above requirements is not particularly limited, as long as it is possible. For example, it is possible to generate executable code that satisfies the above requirements by using the methods disclosed in the references listed below. ·Reference: Jens Dietrich, Francois Gauthier, and Padmanabhan Krishnan. 2018. Driver Generation for Java EE Web Applications. In Australasian Software Engineering Conference (ASWEC). IEEE, 121-25. Another example is the ability to generate executable code that satisfies the above requirements by utilizing annotations added by the framework to the source code being analyzed. Details of this method for generating executable code using annotations will be described separately as a variation of this embodiment. Furthermore, in Figure 2(a), annotation C123, indicated by the keyword "@Autowired" which signifies that dependencies between objects are established at runtime, corresponds to an example of a "first annotation" that suggests the creation of an object. In other words, source code C121 to which the annotation C123 is attached, i.e., the source code to be updated, corresponds to an example of a "first source code". Also, code added to field C124, to which annotation C123 is indicated, which directly indicates the creation of an object, corresponds to an example of a "first code".

[0017] The keywords added as annotation C123 may differ depending on the applicable framework. Therefore, the information processing device 100 may appropriately change the keywords extracted as annotation C123 depending on the applicable framework. Furthermore, the method by which the information processing device 100 can identify the applicable framework is not particularly limited, as long as it is possible for the information processing device 100 to do so. As a specific example, the information processing device 100 may recognize the applicable framework in response to instructions from the user and change the keywords extracted as annotation C123 according to that framework. As another example, the information processing device 100 may recognize the applicable framework by analyzing the information contained in the source code designated as the target of analysis, or configuration files associated with that source code.

[0018] Figure 2(b) shows an example of a call graph illustrating the call relationships between objects when the program with the source code before the update is executed. Figure 2(c) shows an example of a call graph generated by pointer analysis (static analysis) on the updated source code shown in Figure 2(a). As can be seen by comparing Figure 2(b) and Figure 2(c), the call graph shown in Figure 2(c) includes a call graph related to calls from execution code C122, but the other call graphs are the same as those shown in Figure 2(b). In other words, by updating the source code to be analyzed as shown in Figure 2(a), it becomes possible to generate a call graph that reflects the actual situation even when using pointer analysis. The information processing device 100 according to this embodiment will be described in more detail below.

[0019] (Hardware configuration) Referring to Figure 3, an example of the hardware configuration of the information processing device according to this embodiment will be described. As shown in Figure 1, the information processing device 100 according to this embodiment includes a CPU (Central Processing Unit) 910, a ROM (Read Only Memory) 920, and a RAM (Random Access Memory) 930. The information processing device 100 also includes an auxiliary storage device 940 and a network interface 970. The information processing device 100 may also include at least one of an output device 950 and an input device 960. The CPU 910, ROM 920, RAM 930, auxiliary storage device 940, output device 950, input device 960, and network interface 970 are interconnected via a bus 980.

[0020] The CPU 910 is a central processing unit that controls various operations of the information processing device 100. For example, the CPU 910 may control the operation of the entire information processing device 100. The ROM 920 stores control programs, boot programs, etc., that can be executed by the CPU 910. The RAM 930 is the main memory of the CPU 910 and is used as a work area or a temporary storage area for deploying various programs.

[0021] The auxiliary storage device 940 stores various data and programs. The auxiliary storage device 940 is implemented by a storage device capable of temporarily or permanently storing various data, such as an HDD (Hard Disk Drive) or non-volatile memory such as an SSD (Solid State Drive).

[0022] The output device 950 is a device that outputs various types of information and is used to present various types of information to the user. For example, the output device 950 can be implemented by a display device such as a display. In this case, the output device 950 presents information to the user by displaying various types of display information. As another example, the output device 950 may be implemented by an acoustic output device that outputs sounds such as voice or electronic sounds. In this case, the output device 950 presents information to the user by outputting sounds such as voice or telegraph. Furthermore, the device to which the output device 950 is applied may be appropriately changed depending on the medium used to present information to the user.

[0023] The input device 960 is used to receive various instructions from the user. In this embodiment, the input device 960 includes input devices such as a mouse, keyboard, and touch panel. As another example, the input device 960 may also include a sound collection device such as a microphone to collect the voice spoken by the user. In this case, various analysis processes such as acoustic analysis and natural language processing are applied to the collected voice so that the content of the voice is recognized as an instruction from the user. Furthermore, the device applied as the input device 960 may be changed as appropriate depending on the method of recognizing the user's instructions. In addition, multiple types of devices may be applied as the input device 960.

[0024] The network interface 970 is used for communication with external devices via a network. The device used as the network interface 970 may be changed as appropriate depending on the type of communication path and the applicable communication method.

[0025] The CPU 910 loads the program stored in the ROM 220 or auxiliary storage device 940 into the RAM 930 and executes this program, thereby realizing the functional configuration of the information processing device described later with reference to Figure 4, and the processing of the information processing device described later with reference to Figure 5.

[0026] (Functional Configuration) Referring to Figure 4, an example of the functional configuration of the information processing device 100 according to this embodiment will be described. As shown in Figure 4, the information processing device 100 according to this embodiment includes a control unit 110 and a call graph generation unit 120.

[0027] The control unit 110 receives a series of source code D210 to be analyzed as input, applies the updates described with reference to Figure 2 to the source code D210, and then outputs the updated source code D220 to a predetermined output destination. Specifically, the control unit 110 includes an analysis unit 111 and an update unit 112.

[0028] The analysis unit 111 performs a predetermined analysis on the series of source code D210 to be analyzed, thereby identifying the source code to be updated and the code within that source code that is to be updated. Specifically, as explained with reference to Figure 2(a), the analysis unit 111 extracts source code to be updated that has a predetermined annotation attached, and identifies the code within that source code that has that annotation as the code to be updated. Furthermore, if there are other source codes not included in the series of source codes D210 that are dependent on the series of source codes D210 being analyzed, the analysis unit 111 may also include those other source codes in the analysis. As a specific example, if the series of source codes to be analyzed is specified by a management unit used for managing source code, such as a project, the analysis unit 111 may use a configuration file or the like to identify the dependencies between such management units. Then, if other management units that are dependent on the management unit designated as the analysis target are not included in the analysis, the analysis unit 111 may also include those other management units in the analysis.

[0029] Based on the analysis unit 111's identification of the source code to be updated and the code within that source code, the update unit 112 updates the source code by adding code related to object creation (for example, code that directly indicates object creation) as explained with reference to Figure 2(a). The update unit 112 also generates executable code (code defining the so-called Main class) that serves as the starting point for generating a call graph, based on the update results of the source code to be updated, at least for that source code. The update unit 112 then outputs the series of source code to be analyzed, including the updated source code, and the generated executable code to a predetermined output destination as a series of source code D220 for generating a call graph. For example, in the example shown in Figure 4, the update unit 112 outputs the series of source code D220 for generating a call graph to the call graph generation unit 120, which will be described later.

[0030] The call graph generation unit 120 generates a call graph by static analysis, such as so-called pointer analysis, targeting a series of source code D220 for generating a call graph, which has been updated by the control unit 110 in part. The method of generating a call graph by analyzing the source code is not particularly limited, as long as it is possible to do so (for example, the method of analyzing the source code). In other words, known logic may be applied to generate the call graph. Therefore, for example, a known tool that analyzes a series of input source code to generate a call graph may be applied as the call graph generation unit 120. In this manner, the call graph generation unit 120 generates a call graph D230 using the series of source code D220 as input, and outputs the generated call graph D230 to a predetermined output destination.

[0031] Note that the configuration shown in Figure 4 is merely an example and does not necessarily limit the functional configuration of the information processing device 100 according to this embodiment. For example, the series of components shown in Figure 4 may be realized through the cooperation of multiple devices. As a specific example, the components corresponding to the call graph generation unit 120 may be realized by a device other than the information processing device 100. In this case, the information processing device 100, including the control unit 110, may transmit a series of source codes D220 for generating the call graph to the other device connected via a network. As another example, the control unit 110 may output a series of source codes D220 for generating the call graph to a predetermined storage device (for example, a server for data management). In this case, the other device, including the call graph generation unit 120, may obtain the series of source codes to be used to generate the call graph from the storage device. As another example, the processing load of at least some of the components shown in Figure 4 may be distributed across multiple devices. Furthermore, at least some of the components shown in Figure 4 may be implemented by so-called network services, such as cloud services.

[0032] (process) Referring to Figure 5, an example of the processing of the information processing device 100 according to this embodiment will be described. In S110, the control unit 110 receives input of a series of source codes D210 to be analyzed. At this time, the control unit 110 also checks whether there are other source codes that have dependencies on the series of source codes D210 to be analyzed, and may include such other source codes in the analysis.

[0033] In S120, the analysis unit 111 performs a predetermined analysis process on the series of source codes D210 that it has received as input to be analyzed in S110, thereby identifying the source code to be updated and the parts of the source code that need to be updated (i.e., the code to be updated). Specifically, the analysis unit 111 extracts the source code to be analyzed that has a predetermined annotation C123 attached to it, and identifies the parts of the source code that have the annotation C123 indicated as the parts to be updated.

[0034] In S130, the update unit 112 updates the source code by adding code related to the generation of an object corresponding to the code indicated in the update location, based on the results of identifying the source code to be updated and the update location in S120. The update unit 112 also generates execution code that serves as the starting point for generating a call graph, based on the update results of the source code to be updated, at least for that source code. The update unit 112 then outputs the series of source codes to be analyzed, including the updated source code, and the generated execution code to a predetermined output destination as a series of source codes for generating a call graph. As described above, the series of source codes output from the update unit 112 are used, for example, to generate a call graph by the call graph generation unit 120.

[0035] (modified version) As a modification of this embodiment, an example of a method by which the information processing device 100 identifies the processes to be called within the executable code when generating executable code, by utilizing annotations added by the framework to the source code being analyzed. For example, Figure 13 is an explanatory diagram illustrating the overview of the functions of the information processing device according to this modification.

[0036] The source code C151 shown in Figure 13(a) is an example of source code to be analyzed. In source code C151, similar to source code C111 exemplified in Figure 1(a), the code of class X defines a field C154 of an object of class B and code C158 that calls the processing (method) of the object held in field C154. Furthermore, the above class X has the annotation C155, indicated by "@Controller". This annotation C155 is applied to the class that serves as the starting point for application execution, and may be called and applied to the class first in response to an HTTP request, for example. Furthermore, the above code C158 has annotation C156, indicated by the keyword "@RequestMapping", attached to it. This annotation C156 is defined in association with annotation C155 and is attached to a method that receives and processes HTTP requests, with the "method" attribute specifying which HTTP method request to process. Other annotations that can specify which HTTP method request to process, similar to annotation C156, include annotations indicated by the keywords "@GetMapping", "@PostMapping", "@PutMapping", "@DeleteMapping", and "@PatchMapping". In this modification, these annotations will also be treated in the same way as annotation C156. The @Controller annotation is an annotation that contains the @Component annotation. In other words, a class X annotated with @Controller is also managed as a component.

[0037] Figure 13(b) shows an example of the update result of the source code to be analyzed by the information processing device 100 according to this modified example. Specifically, source code C152 shows an example of the source code after it has been updated by the information processing device 100. Source code C153 is executable code that calls the process defined in the updated source code C152.

[0038] In source code C152, the update is made by adding code to field C154 that directly indicates the creation of an object of class B, similar to the example explained with reference to Figures 1 and 2. Note that the method for updating source code C151 to source code C152 is the same as the example explained with reference to Figures 1 and 2, so a detailed explanation is omitted.

[0039] Furthermore, the information processing device 100 according to this modified example identifies the process to be called in the execution code C153 based on annotations C155 and C156 when generating the execution code C153. Specifically, the information processing device 100 identifies the class to be called for processing based on the annotation C155 attached to the source code C151 to be analyzed. In the example shown in Figure 13, the information processing device 100 identifies class X as the target. Next, the information processing device 100 identifies the process to be called in the executable code from a series of processes of the identified class, based on the annotation C156 attached to the source code C151 to be analyzed. For example, in the example shown in Figure 13, annotation C156 is attached to the process indicated by code C158 in class X. Therefore, the information processing device 100 generates executable code C153 so that the process indicated by code C158 is called as the process of the object of class X.

[0040] The above describes an example of a modification of this embodiment in which the information processing device 100 uses annotations added by the framework to the source code being analyzed to identify the processes to be called within the executable code when generating the executable code.

[0041] (Effects and Benefits) As described above, the information processing device 100 according to this embodiment extracts source code with a predetermined annotation from a series of source codes to be analyzed as source code to be updated, and identifies the code with the annotation as the update location. Then, the information processing device 100 updates the source code by adding code related to the creation of an object corresponding to the code (for example, code that directly indicates the creation of an object) to the code (for example, a field) indicated at the update location in the source code to be updated. Furthermore, based on the update result of the source code to be updated, the information processing device 100 generates executable code that serves as the starting point for generating a call graph, targeting at least that source code. Then, the information processing device 100 outputs the series of source codes to be analyzed, including the updated source code, and the generated executable code to a predetermined output destination as a series of source codes for generating a call graph. By using the series of source codes generated in this manner, as explained with reference to Figure 2, it becomes possible to generate a call graph that is more in line with reality, even when static analysis such as pointer analysis is used to generate the call graph.

[0042] <Second Embodiment> A second embodiment of this disclosure will now be described. In the embodiment described above, the source code was updated by adding code that directly indicates the creation of an object (for example, code that creates an object using new). On the other hand, adding code that directly indicates the creation of an object to the source code in this way may cause an error during compilation of the source code (i.e., compilation may fail). In this embodiment, in consideration of this situation, another example of a method for updating the source code will be described. In this embodiment, the explanation will focus on parts that are particularly different from the first embodiment described above, and detailed explanations of parts that are substantially the same as the first embodiment will be omitted.

[0043] First, referring to Figure 6, let's explain an example of a case where an error occurs during compilation of the source code when code that directly indicates the creation of an object is added to the target source code. In the example shown in Figure 6, classes A and X are managed in Project 1, and class B, which inherits from class A, is managed in Project 2. In this disclosure, "inheritance" corresponds to inheritance as defined as one of the concepts that constitute object-oriented programming, and means that one object inherits the characteristics of another object. In other words, in this disclosure, inheritance means grouping the common parts related to the definition of classes into a separate class. Furthermore, class X is defined as having a field that holds an object of class B, and the code that is called as the processing of the object held in that field is shown. In such a case, similar to the first embodiment described above, code that directly indicates the creation of an object of class B (for example, code that creates an object of class B using new) is added to class X. Under these circumstances, when the source code is compiled targeting Project 1, class B is not defined in Project 1, and Project 1 does not depend on Project 2, so class X cannot refer to class B, resulting in an error and compilation failure.

[0044] Therefore, in this embodiment, we will describe an example of a mechanism that, even under the circumstances illustrated above, can generate a call graph of the target series of source code by static analysis such as pointer analysis while maintaining a compilable state for the said series of source code.

[0045] For example, Figure 7 is a diagram illustrating an example of how the information processing device 100 according to this embodiment updates the target source code. Specifically, Figure 7(a) shows an example of the content of the source code update by the information processing device 100 according to this embodiment.

[0046] In Figure 7(a), Project C331 schematically represents a project (management unit) for managing a series of source codes to be analyzed. For convenience, in the example shown in Figure 7(a), only a selection of key source codes from the series of source codes included in Project C331 are shown. The analysis unit 111 of the information processing device 100 extracts source codes with a predetermined annotation C333 attached as source codes to be updated, similar to the first embodiment, and identifies the code C335 (field) in the source code where the annotation C333 is indicated as the code to be updated (in other words, the part to be updated). Then, the update unit 112 of the information processing device 100 adds code that indirectly indicates the generation of the object indicated by code C335, based on the result of identifying the code C335 to be updated. Specifically, the update unit 112 adds an abstract class C334 corresponding to the code to be updated to project C331, and then adds code to call the object creation process for the abstract class C334. The update unit 112 also adds code to the code C335 to be updated that calls the above process of the created abstract class C334. In Figure 7(a), the code added to code C335 (field) with annotation C333, which indirectly indicates object creation (code that calls the processing of the separately added abstract class C334), is an example of "second code." Furthermore, the source code that defines class C336, which inherits from abstract class C334, is a different source code from the updated source code that directly indicates object creation. This is another example of "second source code."

[0047] Furthermore, the update unit 112 creates a project C332 separate from the project C331 being analyzed, and adds a class C336 that inherits from the abstract class C334, and execution code C337 which serves as the starting point for generating the call graph, to this project C332. Specifically, the update unit 112 adds code to class C336 for processes that are called by the code defined in the abstract class C334, and adds code within that code that directly indicates the creation of the target object (for example, code that creates an object using new). In addition, the update unit 112 defines code in execution code C337 that creates an object of class C336 and, as the processing of that object, calls code that has been added in association with the object indicated by code C335 in the source code being updated, which is the processing of the abstract class C334.

[0048] Figure 7(b) shows an example of a call graph illustrating the call relationships between objects when the program with the source code before the update is executed. Figure 7(c) shows an example of a call graph generated by pointer analysis (static analysis) applied to the updated source code shown in Figure 7(a). As can be seen by comparing Figure 7(b) and Figure 7(c), although the overall call graphs are different, the call graph shown in Figure 7(c) includes a partial call graph C338 that is substantially the same as the call graph shown in Figure 7(b). In other words, the call graph shown in Figure 7(c) includes a call graph C338 that is substantially the same as the originally expected call graph, and a call graph generated based on the code added for analysis. Under these conditions, in order to remove the extraneous parts and obtain a call graph that is substantially equivalent to the original call graph, for example, the call graph of the source code to be analyzed can be extracted from the series of call graphs shown in Figure 7(c) using the package name or other extraction conditions. Thus, even in this embodiment, it is possible to generate a call graph that reflects the actual situation (i.e., call graph C338) even when using pointer analysis. Furthermore, as illustrated in Figure 7(a), when the source code being analyzed is updated, the grammatical consistency of the programming language is maintained even after the update, so no errors occur when compiling the source code. Specifically, even when compilation is performed on Project C331 in the state illustrated in Figure 7(a), the compilation will complete successfully. In other words, the information processing device 100 according to this embodiment makes it possible to generate a call graph of a series of source codes by static analysis such as pointer analysis while maintaining the target series of source codes in a compileable state.

[0049] <Third Embodiment> A third embodiment of this disclosure is described below. In this embodiment, as an extended embodiment of the second embodiment, an example of a mechanism for generating a call graph of source code to be analyzed is described, taking into consideration the case where the source code is defined based on a design concept (design pattern) known as a singleton. In this embodiment, the explanation will focus on parts that are particularly different from the first and second embodiments described above, and detailed explanations of parts that are substantially the same as the first and second embodiments will be omitted.

[0050] First, to make the features of this embodiment easier to understand, we will briefly explain the difference between the case where singleton is not applied and the case where singleton is applied, referring to Figures 8A and 8B.

[0051] For example, Figure 8A shows an example where singleton is not applied. Specifically, Figure 8A(a) shows an example of the source code to be analyzed. In the example shown in Figure 8A(a), it is assumed that for each object x and y, a Dog class object is set in the pet field of a House class object (hereinafter also referred to as the house object). Under these circumstances, for object x, the object set in the pet field of the house object is replaced with a Cat class object (i.e., a Cat class object is created using new and assigned). For reference, Figure 9 shows an example of the source code of a series of objects defined in the source code shown in Figure 8A and Figure 8B, which will be described later. Figure 8A(b) shows an example of the result of applying pointer analysis to the source code shown in Figure 8A(a) when a singleton is not applied. When a singleton is not applied, a house object is created separately for each object x and y, so as shown in Figure 8A(b), different house objects are called from each other by objects x and y. That is, for object x, the process of creating a Cat class object is called from the house object, and for object y, the process of creating a Dog class object is called from the house object. Figure 8A(c) shows an example of a call graph output as a result of pointer analysis, as explained with reference to Figure 8A(b). Specifically, the call graph will output the `cry` method of the `Cat` class, which is called as processing for object x, and the `cry` method of the `Dog` class, which is called as processing for object y, from the `main` method of the `Main` class.

[0052] Figure 8B also shows an example where a singleton is applied. Specifically, Figure 8B(a) shows an example of source code to be analyzed. The example shown in Figure 8B(a) is similar in code format to the example shown in Figure 8A(a), but differs from the example shown in Figure 8A(a) in whether or not a singleton is applied. Figure 8B(b) shows an example of the result of applying pointer analysis to the source code shown in Figure 8A(a) under the condition that a singleton is applied. When a singleton is applied, a common house object is applied to both objects x and y, so as shown in Figure 8B(b), the common house object is called from both objects x and y. Figure 8B(c) shows an example of a call graph output as a result of pointer analysis, as explained with reference to Figure 8B(b). Specifically, the `cry` method of the `Cat` class, which is commonly called from the `main` method of the `Main` class as a processing method for objects x and y respectively, is output to the call graph, while the `cry` method of the `Dog` class is not output to the call graph. For convenience, in the following explanation, an object to which a singleton is applied will also be referred to as a singleton object. That is, in the example shown in Figure 8B, the house object is a singleton object. In contrast, in the example shown in Figure 8A, the house object is not a singleton object.

[0053] As can be seen by comparing Figures 8A and 8B, even when common source code is applied, the program's behavior differs depending on whether or not a singleton is applied, and as a result, the output call graph also differs. In light of this situation, this embodiment describes an example of updating the source code to be analyzed so that a more realistic call graph is generated, taking into account whether or not a singleton is applied to the source code.

[0054] First, an example of a mechanism by which the information processing device 100 according to this embodiment determines whether or not a singleton is applied to the source code to be analyzed will be described. For example, some frameworks allow specifying the scope of the target program by annotations attached to the source code or configuration files associated with the source code. In such cases, for example, it may be possible to set whether or not to apply a singleton as a setting for the scope. Therefore, for example, the information processing device 100 may determine whether or not a singleton is applied to the target source code by utilizing the mechanism of such a framework.

[0055] For example, Figure 10 shows an example of a mechanism that determines whether a singleton is applied to source code based on annotations added to the source code by the framework. In the example shown in Figure 10, whether a singleton is applied is indicated by whether or not the annotation indicated by the keyword "@Scope," which means specifying the scope of the program implemented by the target source code, is added, and depending on the parameters specified in that annotation. Specifically, as shown in Figures 10(a) and 10(b), the annotation "@Scope" can specify an attribute value as a parameter, and the scope of the target source code is determined according to the attribute value specified as the parameter. Furthermore, if "singleton," which means the application of a singleton, is specified as the attribute value for this annotation "@Scope," it means that a singleton is applied to the target source code. In other words, in the example shown in Figure 10(a), the annotation "@Scope" means that a singleton is not applied. In the example shown in Figure 10(b), the annotation "@Scope" means that a singleton is applied. Therefore, the information processing device 100 may determine whether or not a singleton is applied to the source code based on the attribute value specified for the annotation attached to the target source code. Furthermore, as shown in Figure 10(c), there may be cases where no attribute value is specified for the annotation "@Scope", or as shown in Figure 10(d), there may be cases where the annotation "@Scope" is not attached. In such cases, the default setting will be applied as the scope. Therefore, in such cases, the information processing device 100 may determine whether a singleton is applied to the target source code depending on whether or not the default setting means that a singleton is applied. Specifically, in the examples shown in Figure 10(c) and Figure 10(d), if the default setting means that a singleton is applied, the information processing device 100 will determine that a singleton is applied to the target source code.

[0056] As another example, Figure 11 illustrates an example of a mechanism that determines whether a singleton is applied to a source code based on the scope settings defined in a configuration file associated with the target source code by the framework. In the example shown in Figure 11, whether a singleton is applied is indicated by specifying an attribute indicated by the keyword "scope," which means specifying the scope of the program implemented by the target source code, for the "bean" tag that defines various settings for each class, and according to the attribute value specified for that attribute. Specifically, as shown in Figures 11(a) and 11(b), an attribute value is specified for the "scope" attribute of the "bean" tag, and the scope of the target source code is determined according to that attribute value. Furthermore, if "singleton," which means the application of a singleton, is specified as the attribute value for this "scope" attribute, it means that a singleton will be applied to the target source code. In other words, in the example shown in Figure 11(a), the "scope" attribute means that a singleton will not be applied. In the example shown in Figure 11(b), the "scope" attribute means that a singleton will be applied. Therefore, the information processing device 100 may refer to a configuration file associated with the target source code and determine whether a singleton is applied to the class indicated by the "bean" tag (in other words, the source code of that class) based on the attribute value specified for the "scope" attribute of the "bean" tag in the configuration file. Furthermore, as shown in Figure 11(c), it is possible that the "scope" attribute is not specified for the "bean" tag. In such cases, the default setting will be applied as the scope. Therefore, in such cases, the information processing device 100 may determine whether a singleton is applied to the target source code depending on whether the default setting means that a singleton is applied. Specifically, in the example shown in Figure 11(c), if the default setting means that a singleton is applied, the information processing device 100 will determine that a singleton is applied to the target source code.

[0057] Next, with reference to Figure 12, an example of how the information processing device 100 according to this embodiment updates the target source code will be described. In Figure 12, source code C501 schematically shows the source code to be analyzed. Although not shown in Figure 12, it is assumed that classes A and B are separately defined, similar to the example described with reference to Figures 6 and 7. Furthermore, class X is defined with field b, which holds an object of class B that inherits from class A, and a predetermined annotation (@Autowired) is shown for this field. Also, although not shown in Figure 12, an executable code (Main class) that serves as the starting point when generating a call graph targeting the updated source code C501 will be added separately.

[0058] The analysis unit 111 of the information processing device 100 extracts source code C501 with a predetermined annotation (@Autowired) from a series of source codes designated as the target of analysis, and identifies the code (field) with the annotation as the code to be updated (in other words, the part to be updated). In the example shown in Figure 12, it is assumed that field b, where an object of class B that inherits from class A is set, is identified as the code to be updated. Then, based on the result of identifying the code to be updated, the update unit 112 of the information processing device 100 adds code that indirectly indicates the creation of the object indicated by that code. Specifically, the update unit 112 adds an abstract class C503 corresponding to the code to be updated to the same project as source code C501 (hereinafter referred to as Project 1), and then adds code to the abstract class C503 that calls the object creation process for the target object. In the example shown in Figure 12, for convenience, a state in which code C508 and code C509 have been added to source code C503 is illustrated. Code C508 is code whose actual processing is defined as code C506 in source code C502, which will be described later (overridden code). Similarly, code C509 is code whose actual processing is defined as code C507 in source code C502 (overridden code). If a singleton is applied, both code C508 and C509 are used. Conversely, if a singleton is not applied, only C509 is used. The update unit 112 may selectively switch the output of code C508 and C509 as described above based on the determination result of whether or not a singleton is applied to source code C501, or it may add both regardless of whether or not a singleton is applied. Furthermore, the update unit 112 adds code to the source code C501 that is to be updated (field b), which calls the above process of the generated abstract class C503. For convenience, the example shown in Figure 12 illustrates code C504 when a singleton is applied to source code C501 and code C505 when a singleton is not applied to source code C501. Based on the determination result of whether or not a singleton is applied to source code C501, the update unit 112 adds either code C504 or C505 to source code C501.

[0059] Furthermore, the update unit 112 generates a project (hereinafter also referred to as Project 3) separate from Project 1, which contains the source code C501 to be analyzed, and adds a class C502 that inherits from the abstract class C503 to Project 3. Specifically, the update unit 112 adds code to class C502 for processes that are called by the code defined in the abstract class C503. As mentioned above, depending on whether a singleton is applied to source code C501, either code C508 (if it is a singleton) or C509 (if it is not a singleton) is added to the abstract class C503. Therefore, the update unit 112 appropriately modifies the code to be added to class C502 according to the code added to the abstract class C503. In the example of source code C502 shown in Figure 12, for convenience, a state in which code C506 and code C507 have been added to source code C501 is illustrated. Specifically, code C506 adds code that returns an object of class B (a class that inherits from class A) held in field b. Field b also holds an object of class B created (newed) by code C507, which will be described in detail later. Code C507 adds code that creates an object of class B (a class that inherits from class A). When a singleton is applied, both code C506 and C507 are used. Conversely, when a singleton is not applied, only C507 is used. The update unit 112 may selectively switch the output of code C506 and C507 as described above based on the result of determining whether a singleton is applied or not, or it may add both regardless of whether a singleton is applied or not. It goes without saying that the switching of control related to the output of this code should ideally be applied in conjunction with the switching of control related to the output of codes C508 and C509 in source code C503. Furthermore, although not illustrated in the example shown in Figure 12, Project 3 includes executable code (Main class) that serves as the starting point for generating the call graph for the updated source code C501, based on the same technical concept as the example explained with reference to Figure 7. Since this executable code is the same as the example shown in Figure 7, a detailed explanation is omitted.

[0060] As described above, by updating the source code being analyzed, it becomes possible to output a call graph for that source code in a more realistic manner, depending on whether or not a singleton is applied to that source code. In the example described above, we explained an example in which the information processing device 100 determines whether a singleton is applied to the source code to be analyzed based on annotations attached to the source code and configuration files associated with the source code. On the other hand, the method by which the information processing device 100 can determine whether a singleton is applied to the source code to be analyzed is not particularly limited, as long as it is possible for the information processing device 100 to do so. For example, the information processing device 100 may determine whether a singleton is applied to the target source code based on instructions received from the user.

[0061] <Supplement> In the embodiments described herein, the focus has been primarily on cases where source code defined in a programming language known as Java is the target of analysis. However, the target programming language is not particularly limited, as long as it is a programming language that involves the creation of objects. As a specific example, it is also possible to apply the technology described herein to source code defined in languages ​​such as C++ or Objective-C. In such cases, it goes without saying that the way the code is written will differ depending on the programming language applied to the source code to be analyzed, and therefore, any code added or modified when updating the target source code will also be appropriately changed according to the rules of that programming language.

[0062] Furthermore, the embodiments described above are merely examples and do not necessarily limit the configuration or processing of the present invention. Various modifications and changes may be made without departing from the technical concept of the present invention.

[0063] Furthermore, the following configurations also fall within the technical scope of this disclosure. (1) An information processing device comprising: an extraction means for extracting a first source code from a series of source codes to be analyzed that has a first annotation indicating the creation of an object, to be selected as a target for update; and an update means for updating the first source code by adding either a first code that directly indicates the creation of an object corresponding to a field in the first source code extracted as a target for update, or a second code that indirectly indicates the creation of the object, to a field indicated by the first annotation, and generating an executable code that calls the processing defined in the updated first source code, wherein a call graph is generated based on the updated first source code and the executable code. (2) The information processing apparatus according to (1), wherein the update means generates the executable code such that when the first code is added to the first source code, it directly calls the processing defined in the updated first source code. (3) The information processing apparatus according to (1), wherein the update means generates a second source code in association with the second code, which contains code that directly indicates the creation of an object corresponding to the field with the first annotation, and generates the executable code to call the process specified in the updated first source code by calling the process specified in the second source code. (4) The information processing device described in (3), wherein the second code is code that calls a process defined in an abstract class of a class defined in the second source code, and the class is defined in the second source code to inherit the abstract class. (5) The information processing device according to any one of (1) to (4), wherein the update means determines whether a singleton is applied to an object corresponding to a field in which the first annotation is indicated in the first source code extracted as the target of update, and updates the first source code by adding the second code if a singleton is applied to the object. (6) The information processing device according to (5), wherein the update means determines whether a singleton is applied to the object corresponding to the field, based on the provision of a second annotation that indicates the scope of the object corresponding to the field, which is shown for the field indicated by the first annotation in the first source code extracted as an update target. (7) The information processing device according to (5), wherein the update means determines whether a singleton is applied to the object corresponding to the field, based on attribute information indicating the scope of the object corresponding to the field shown in the first source code in the configuration file associated with the first source code extracted as an update target. (8) An information processing method executed by an information processing device, comprising: an extraction step of extracting a first source code from a series of source codes to be analyzed, the first source code having a first annotation indicating the generation of an object, as a target for update; and an update step of updating the first source code by adding either a first code that directly indicates the generation of an object corresponding to a field in the first source code extracted as a target for update, or a second code that indirectly indicates the generation of an object, to a field indicated by the first annotation, thereby generating executable code that calls the processing defined in the updated first source code, wherein a call graph is generated based on the updated first source code and the executable code. (9) A program that causes a computer to perform an extraction step of extracting a first source code from a series of source codes to be analyzed that has a first annotation indicating the generation of an object, to be selected as a target for update; and an update step of updating the first source code by adding either a first code that directly indicates the generation of an object corresponding to a field in the first source code that has been extracted as a target for update, or a second code that indirectly indicates the generation of an object, to a field in the first source code that has been selected as a target for update, and generating executable code that calls the processing defined in the updated first source code, and generating a call graph based on the updated first source code and the executable code. [Explanation of Symbols]

[0064] 100 Information Processing Devices 110 Control Unit 111 Analysis Department 112 Update Department 120 Call Graph Generation Unit

Claims

1. An extraction means for extracting a first source code from a series of source codes to be analyzed, which has a first annotation indicating the creation of an object, as the source code to be updated. An update means that updates the first source code by adding either a first code that directly indicates the creation of an object corresponding to a field, or a second code that indirectly indicates the creation of an object, to a field in the first source code extracted as a target for update that is marked with the first annotation, and generates executable code that calls the processing defined in the updated first source code, Equipped with, The update means is, When the second code is added to the first source code, In association with the second code, a second source code is generated which specifies code that directly indicates the creation of an object corresponding to the field indicated by the first annotation. The executable code is generated such that calling the process defined in the second source code calls the process defined in the updated first source code. A call graph is generated based on the updated first source code and the execution code. Information processing device.

2. The update means is, When the first code is added to the first source code, The executable code is generated to directly call the process defined in the first source code after the update. The information processing apparatus according to claim 1.

3. The aforementioned second code is code that calls the processing defined in the abstract class of the class defined in the aforementioned second source code, The aforementioned class is defined in the second source code to inherit the aforementioned abstract class. The information processing apparatus according to claim 1.

4. The update means is, In the first source code extracted for updating, determine whether a singleton is applied to the object corresponding to the field indicated by the first annotation. If a singleton is applied to the object, the first source code is updated by adding the second code. The information processing apparatus according to any one of claims 1 to 3.

5. The update means determines whether a singleton is applied to the object corresponding to the field, based on the provision of a second annotation that indicates the scope of the object corresponding to the field, which is shown for the field indicated by the first annotation in the first source code extracted as the target of the update, The information processing apparatus according to claim 4.

6. The update means determines whether a singleton is applied to the object corresponding to the field, based on attribute information indicating the scope of the object corresponding to the field shown in the first source code in the configuration file associated with the first source code extracted as the target of the update, The information processing apparatus according to claim 4.

7. An information processing method performed by an information processing device, An extraction step in which, from a series of source codes to be analyzed, the first source code that has a first annotation indicating the creation of an object is extracted as the target for update, An update step of updating the first source code by adding either a first code that directly indicates the creation of an object corresponding to the field indicated by the first annotation in the first source code extracted as the target of the update, or a second code that indirectly indicates the creation of the object, thereby updating the first source code and generating executable code that calls the processing defined in the updated first source code; Includes, The aforementioned update step is: When the second code is added to the first source code, In association with the second code, a second source code is generated which specifies code that directly indicates the creation of an object corresponding to the field indicated by the first annotation. The executable code is generated such that calling the process defined in the second source code calls the process defined in the updated first source code. A call graph is generated based on the updated first source code and the execution code. Information processing methods.

8. On the computer, An extraction step in which, from a series of source codes to be analyzed, the first source code that has a first annotation indicating the creation of an object is extracted as the target for update, An update step of updating the first source code by adding either a first code that directly indicates the creation of an object corresponding to the field indicated by the first annotation in the first source code extracted as the target of the update, or a second code that indirectly indicates the creation of the object, thereby updating the first source code and generating executable code that calls the processing defined in the updated first source code; Make it run, The aforementioned update step is: When the second code is added to the first source code, In association with the second code, a second source code is generated which specifies code that directly indicates the creation of an object corresponding to the field indicated by the first annotation. The executable code is generated such that calling the process defined in the second source code calls the process defined in the updated first source code. A call graph is generated based on the updated first source code and the execution code. program.

Images