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: extraction means which extracts a first source code, of a series of source codes, in which a first field of an object is specified, on the basis of at least one of an annotation indicating generation of an object in the source code and a definition of the object in a setting file associated with the series of a source code; and generation means which generates a second source code in which a code is specified for directly indicating generation of an object corresponding to the first field, the second source code being different from the first source code, and an execution code which calls a process to refer to the first field specified in the first source code by calling a process specified in the second source code. A call graph is generated on the basis of the first source code, the second 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] 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 a 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, it may be difficult to perform accurate analysis with a so-called static analysis method such as pointer analysis.

[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 includes an extraction means for extracting a first source code in which a first field of an object is defined, based on at least one of the following: annotations that suggest the generation of an object attached to a series of source codes to be analyzed, and a definition of the object to be generated in a configuration file associated with the series of source codes; An update means for updating the first source code by adding code that indirectly indicates the creation of the object to the first source code, The system comprises a generation means that generates a second source code, which is different from the first source code and contains code that directly indicates the creation of an object corresponding to the first field, and an executable code that, by calling the processing defined in the second source code, calls a process that references the first field defined in the first source code, The generation means generates a second source code that defines code directly indicating the generation of an object, associated with code that indirectly indicates the generation of the object, and generates the executable code such that it calls the process defined in the updated first source code by calling the process defined in the second source code. A call graph is generated based on the first source code, the second 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 shows an example of the source code being analyzed and its call graph. [Figure 7] This diagram shows an example of how to identify the source code and the code that will be updated. [Figure 8] This diagram shows an example of the updated source code. [Figure 9] This figure shows an example of a generated call graph. [Figure 10] This figure shows an example of source code to be analyzed. [Figure 11] This diagram shows an example of the source code that will be added. [Figure 12] This figure shows an example of the generated executable code. [Figure 13] This figure shows an example of a generated call graph. [Figure 14A] This diagram shows an example where the singleton is not applied. [Figure 14B] This diagram shows an example of when a singleton is applied. [Figure 15] This is a diagram to illustrate the considerations of singletons. [Figure 16] This diagram illustrates an example of a mechanism for determining whether or not a singleton can be applied. [Figure 17] This diagram illustrates an example of a mechanism for determining whether or not a singleton can be applied. [Figure 18]This is a diagram for explaining an example of a method for updating source code. [Figure 19] This is a diagram for explaining an example of a method for generating executable code. **Embodiments for Carrying Out the Invention**

[0011] Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In this specification and the drawings, for components having substantially the same functional configuration, the same reference numerals are given to omit redundant description.

[0012] <First Embodiment> An information processing apparatus according to a first embodiment of the present disclosure will be described below. First, referring to FIGS. 1 and 2, an outline of the functions of the information processing apparatus according to this embodiment will be described. As described above, there are programs created using an application framework, etc., in which the dependency relationships between objects are configured by the application framework at the time of program execution. 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 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 within the code of class X. FIG. 1(b) shows an example of a call graph indicating the call relationships 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, which analyzes call relationships between objects based on source code without executing the program, the creation of an object for field C112 is not explicitly specified, so field C112 is treated as Null. Therefore, when attempting to generate a call graph of source code C111 using pointer analysis (static analysis), an inaccurate call graph may be generated, as shown in Figure 1(c), which assumes that no object of class B has been created.

[0014] In light of the above circumstances, the information processing device according to this embodiment enables the generation of a call graph that more accurately reflects the actual situation by modifying the source code to be analyzed and updating the source code to be analyzed into source code for pointer analysis (static analysis). For example, Figure 2 is an explanatory diagram illustrating the overview of the functions of the information processing device according to this embodiment.

[0015] Figure 2(a) shows an example of the update result of the source code to be analyzed by the information processing device 100 according to this embodiment. Specifically, Project C331 schematically represents a project (management unit) for managing a series of source codes to be analyzed. In the example shown in Figure 2(a), the state after some of the source codes included in Project C331 have been modified by the information processing device 100 is shown. For convenience, in the example shown in Figure 2(a), only some of the key source codes from the series of source codes included in Project C331 are shown. Furthermore, Project C332 schematically represents a project generated by the information processing device 100 separately from Project C331, which is to be analyzed. Project C332 includes executable code (code defining the so-called Main class) that calls the processing defined in the updated source code included in Project C331.

[0016] Some frameworks add annotations to parts where dependencies between objects are established at runtime. Based on these annotations, the information processing device 100 identifies the source code to be updated and the code (e.g., a field) within that source code to be updated from a series of source codes designated for analysis. Then, the information processing device 100 modifies the code to be updated based on the definition of that code.

[0017] For example, in the example shown in Figure 2(a), an annotation C333, indicated by the keyword "@Autowired", is attached to field C335 of some source code included in project C331, meaning that dependencies between objects are established at runtime. The information processing device 100 extracts the source code with the predetermined annotation C333 attached as source code to be updated, and identifies the code C335 (field) indicated by the annotation C333 in that source code 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 information processing device 100 adds an abstract class C334 corresponding to the code to be updated to project C331, and then adds code to the abstract class C334 that calls the process for creating the target object. In addition, the information processing device 100 adds code to the code C335 to be updated that calls the above process of the created abstract class C334. 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 C335 will be an object of class A or class B. In the example shown in Figure 2(a), class B has annotation C339, 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 C335 is an object of class B and adds code that indirectly indicates the generation of a class B object.

[0018] Furthermore, the information processing device 100 creates a project C332 separate from the project C331 being analyzed, and adds a class C336 that inherits from the abstract class C334, and executable code C337 which serves as the starting point for generating the call graph, to project C332. Specifically, the information processing device 100 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 information processing device 100 creates an object of class C336 in executable code C337, and defines code that calls the process of the abstract class C334, which has been added in association with the object indicated by code C335 in the source code to be updated, as the processing of that object. In this disclosure, "inheritance" refers to the inheritance defined as one of the concepts that constitute object-oriented programming, meaning that one object inherits the characteristics of another object. In other words, in this disclosure, inheritance means consolidating the common parts related to the definition of classes into a separate class. Furthermore, the method for generating executable code (code equivalent to source code C337) that satisfies the above-mentioned requirements is not particularly limited, as long as it is possible to do so. For example, it is possible to generate executable code that satisfies the above-mentioned 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. In Figure 2(a), annotation C333, indicated by the keyword "@Autowired" which signifies that dependencies between objects are established at runtime, is an example of a "first annotation" that suggests the creation of an object. That is, the source code to which annotation C333 is attached, i.e., the source code to be updated, is an example of a "first source code". The object whose creation is suggested by annotation C333 is an example of a "first object", and the field in the first source code that corresponds to the first object (the field corresponding to code C335) is an example of a "first field".

[0019] The keywords added as annotation C333 may differ depending on the applicable framework. Therefore, the information processing device 100 may appropriately change the keywords extracted as annotation C333 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 C333 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.

[0020] 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) applied to the updated source code shown in Figure 2(a). As can be seen by comparing Figure 2(b) and Figure 2(c), although the overall call graphs are different, the call graph shown in Figure 2(c) includes a partial call graph C338 that is substantially the same as the call graph shown in Figure 2(b). In other words, the call graph shown in Figure 2(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, for example, by extracting the call graph of the source code to be analyzed from the series of call graphs shown in Figure 2(c) using the package name as an extraction condition, it becomes possible to generate a call graph that is more accurate to reality (i.e., call graph C338) even when using pointer analysis. The information processing device 100 according to this embodiment will be described in more detail below.

[0021] (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.

[0022] 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.

[0023] 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).

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] (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.

[0029] 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.

[0030] The analysis unit 111 performs a predetermined analysis on the series of source code D210 to be analyzed, thereby identifying the source code that is subject to processing for generating a call graph, and the code within that source code that is subject to that processing. For example, in this embodiment, the analysis unit 111 performs a predetermined analysis on the series of source code D210 to be analyzed, thereby identifying the source code that is subject to updating, and the code within that source code that is subject to updating. As a specific example, the analysis unit 111 may extract source code to be updated as source code to be updated, as explained with reference to Figure 2(a), and identify the code in that source code that has that annotation as code to be updated. As another example, the analysis unit 111 may extract the source code to be updated based on a configuration file that specifies the objects to be generated for each source code and the fields in which those objects are held, associated with the series of source code D210 to be analyzed. In this case, the analysis unit 111 may identify the code to be updated in the extracted source code based on the specifications in the configuration file for the objects to be generated and the fields in which those objects are held. For an example of how to extract the source code to be updated and how to identify the code to be updated in the source code based on the configuration file, please refer to Figure 7 and the details will be described separately later. 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 said 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 target, the analysis unit 111 may also include those other management units in the analysis target.

[0031] Based on the results of the analysis unit 111's identification of the target source code and the code within that source code, the update unit 112 executes processes related to generating and updating source code for generating a call graph for a series of source code D210. For example, based on the analysis unit 111's identification of the first source code to be updated and the code within the first source code, the update unit 112 updates the first source code by adding code that indirectly indicates the creation of an object, as explained with reference to Figure 2(a). The update unit 112 also generates a second source code, different from the first source code to be updated, which is associated with the code that indirectly indicates the creation of the object and defines code that directly indicates the creation of the object. Then, based on the update result of the first source code to be analyzed and the generation result of the second source code, the update unit 112 generates executable code (code defining the so-called Main class) that serves as the starting point for generating a call graph, targeting at least the first source code. Specifically, as explained with reference to Figure 2(a), the update unit 112 generates the executable code such that calling the process defined in the second source code calls the process defined in the updated first source code. In this case, the update unit 112 may manage the second source code and the execution code by associating them with a project (management unit) different from the project (management unit) used to manage the first source code to be updated. The update unit 112 then outputs the series of source codes to be analyzed, including the updated first source code, along with the generated second source code and executable code, to a predetermined output destination as a series of source codes D220 for generating a call graph. For example, in the example shown in Figure 4, the update unit 112 outputs the series of source codes D220 for generating a call graph to the call graph generation unit 120, which will be described later.

[0032] The call graph generation unit 120 generates a call graph by static analysis, such as so-called pointer analysis, on a series of source code D220 output from the control unit 110 for generating a call graph. 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.

[0033] 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.

[0034] (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.

[0035] In S120, the analysis unit 111 performs a predetermined analysis process on the series of source codes D210 that it 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). As a specific example, the analysis unit 111 may extract a source code to be updated that has a predetermined annotation C333 attached to it, and then identify the code in the first source code that has the annotation C333 indicated as the part to be updated.

[0036] In S130, the update unit 112 updates the first source code by adding code to the first source code that indirectly indicates the generation of an object corresponding to the code indicated in the update location, based on the results of identifying the first source code to be updated and the update location in S120. The update unit 112 also generates a second source code, which is a different source code from the first source code to be updated, and which defines code that directly indicates the generation of the object, in association with the code that indirectly indicates the generation of the object. Then, based on the update result of the first source code to be analyzed and the generation result of the second source code, the update unit 112 generates execution code that serves as the starting point for generating a call graph, targeting at least the first source code. Finally, the update unit 112 outputs the series of source codes to be analyzed, including the updated first source code, and the generated second source code and 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.

[0037] (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 19 is an explanatory diagram illustrating the overview of the functions of the information processing device according to this modification. Note that in the example shown in Figure 19, only some of the source code used for explanation is shown, and other source code is omitted from the illustration.

[0038] The source code C351 shown in Figure 19(a) is an example of source code to be analyzed. In source code C351, similar to source code C111 exemplified in Figure 1(a), the code of class X defines a field C354 of an object of class B and code C358 that calls the processing (method) of the object held in field C354. Furthermore, the above class X has the annotation C355, indicated by "@Controller". This annotation C355 is applied to the class that initiates the execution of an application, and may be applied, for example, to the class that is first called in response to an HTTP request. Furthermore, the above code C358 has annotation C356 attached to it, indicated by the keyword "@RequestMapping". This annotation C356 is defined in association with annotation C355 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 C356, 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 C356. 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.

[0039] Figure 19(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 C352 shows an example of the source code after it has been updated by the information processing device 100. Source code C353 is executable code that calls the process specified in the updated source code C352.

[0040] In source code C352, the update is made by adding code to field C354 that indirectly 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 C351 to source code C352 is the same as the example explained with reference to Figures 1 and 2, so a detailed explanation is omitted.

[0041] Furthermore, the information processing device 100 according to this modified example identifies the process to be called by the execution code C353 based on annotations C355 and C356 when generating the execution code C353. Specifically, the information processing device 100 identifies the class to be called for processing based on annotation C355 attached to the source code C351 to be analyzed. In the example shown in Figure 19, 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 among the series of processes of the identified class, based on the annotation C356 attached to the source code C351 to be analyzed. For example, in the example shown in Figure 19, annotation C356 is attached to the process indicated by code C358 in class X. Therefore, the information processing device 100 generates executable code C353 so that the process indicated by code C358 is called as the process of the object of class X.

[0042] 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.

[0043] (Effects and Benefits) As described above, the information processing device 100 according to this embodiment identifies a first source code to be updated and the code to be updated within the first source code from a series of source codes to be analyzed. For example, the information processing device 100 may extract a source code to be updated that has a predetermined annotation attached to it, and identify the code with the annotation attached as the update location. Then, the information processing device 100 updates the first source code to be updated by adding code that indirectly indicates the generation of an object corresponding to the code (e.g., a field) indicated at the update location in the first source code to be updated. The information processing device 100 also generates a second source code, which is a different source code from the first source code to be updated, and which defines code that directly indicates the generation of the object in association with the code that indirectly indicates the generation of the object. Then, based on the update result of the first source code to be analyzed and the generation result of the second source code, the information processing device 100 generates executable code that serves as the starting point for generating a call graph, targeting at least the first source code. The information processing device 100 then outputs the series of source codes to be analyzed, including the updated first source code, along with the generated second source code and 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 more accurately reflects the actual situation, even when static analysis such as pointer analysis is used to generate the call graph.

[0044] <Second Embodiment> A second embodiment of this disclosure will now be described. In the previously described embodiment, an example of a mechanism was described in which a more realistic call graph can be generated even when static analysis such as pointer analysis is used to generate the call graph, by updating a portion of the source code to be analyzed to add code related to object creation. In contrast, this embodiment will describe an example of a mechanism that can generate a more realistic call graph even when static analysis such as pointer analysis is used to generate the call graph, by adding other source code that calls the processing of the source code without updating the source code to be analyzed. 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.

[0045] First, referring to Figure 6, we will explain an example of source code to be analyzed in this embodiment and an example of a call graph showing the call relationships between objects for said source code. Specifically, the source code C611 shown in Figure 6(a) defines, within the code of class X, a field C612 of an object of class B and code C613 that calls the processing (method) of the object held in field C612. In addition, source code C611 defines code C614 to set the object specified by the caller to field C612 as code that references field C612. Figure 6(b) shows an example of a call graph showing the call relationships between objects when a program with the source code exemplified in Figure 6(a) is executed under these assumptions. Also, as with the example explained with reference to Figure 1, in pointer analysis, since the creation of an object for field C612 is not explicitly defined, field C612 is treated as Null. Therefore, when attempting to generate a call graph for source code C611 using pointer analysis (static analysis), a call graph that does not reflect reality may be generated, as shown in Figure 6(c), which assumes that no objects of class B have been created.

[0046] In light of the above circumstances, the information processing device 100 according to this embodiment enables the generation of a more realistic call graph by adding other source code that calls the processing of the source code being analyzed, without updating the source code being analyzed. For example, Figures 7 and 8 are explanatory diagrams illustrating the overview of the functions of the information processing device 100 according to this embodiment.

[0047] First, referring to Figure 7, an example of how the information processing device 100 according to this embodiment identifies the source code to be updated and the code within that source code to be updated from a series of source codes designated as the target of analysis will be described. Methods for identifying the source code to be updated and the code to be updated include using annotations added to the source code and using a configuration file associated with the series of source codes designated as the target of analysis.

[0048] For example, Figure 7(a) shows an example of a method for identifying the source code and code that are subject to processing related to the addition of source code for generating a call graph, using annotations attached to the source code. Depending on the framework, annotations may be attached to the code of the target class in order to bring the instances (objects) that are generated when the code defined in the source code is executed under control. For example, in the example shown in Figure 7(a), annotation C615, indicated by the keyword "@Component", is attached to the code defining class B, indicating that the object (instance) of class B generated when this code is executed is under the control of the framework. In addition, other annotations that contain annotation C615, indicated by the keyword "@Component", may be attached, and such annotations may be indicated by keywords such as "@Controller" and "@Service". For example, annotation C616 shown in Figure 7(a) is attached to the code defining class X, indicating that the object of class X generated when this code is executed is under the control of the framework.

[0049] In the example shown in Figure 7(a), the information processing device 100 according to this embodiment uses the annotations exemplified above to identify source code containing the annotated code as the target of processing for adding source code to generate a call graph. Furthermore, the information processing device 100 according to this embodiment identifies the code to be processed for adding source code to generate a call graph, based on annotations that indicate that dependencies between objects are established at runtime, similar to the example described in the first embodiment. For example, in the example shown in Figure 7(a), the information processing device 100 identifies code C614, which has the annotation indicated by the keyword "@Autowired" attached, as the code to be processed for adding source code to generate a call graph.

[0050] Figure 7(b) illustrates an example of how to identify the source code and code that are subject to processing related to the addition of source code for generating a call graph, using a configuration file associated with a set of source codes designated for analysis. The configuration file shown in Figure 7(b) is an example of a configuration file used by the framework to manage objects (instances) that are generated when the code specified in the source code is executed. This configuration file includes definitions of the class in which the managed objects are generated, and definitions of the fields in which those objects are set. As a concrete example, in the configuration file C621 shown in Figure 7(b), the tag indicated by the keyword "bean" specifies the class from which the managed objects will be generated. As a more concrete example, the attribute information indicated by the keyword "class" for tag C622 defines class B, from which the objects will be generated. As yet another example, the attribute information indicated by the keyword "class" for tag C623 defines class X, from which the objects will be generated. In other words, the example shown in Figure 7(b) indicates that objects of class B and class X are under the management of the framework. The information processing device 100 according to this embodiment uses the provisions of the configuration file as illustrated above to identify the source code of the class corresponding to the object under the management of the framework as the target of processing related to the addition of source code for generating a call graph.

[0051] Furthermore, within the tags related to the definition of the above class indicated by the keyword "bean," setter methods for setting an object (instance) to the target field are specified by tags indicated by the keyword "property." For example, within tag C623 related to the definition of class X, a setter method (setB) is specified for the name attribute "b" of tag C624 indicated by the keyword "property." In addition, within the tags relating to the above-mentioned fields, the keyword "ref" indicates which class of object will be set for the target field. For example, within tag C624 relating to the field b, tag C625 is defined, which indicates the class corresponding to the object to be set, as indicated by the keyword "ref". Furthermore, tag C625 contains identification information to identify the target class as attribute information indicated by the keyword "bean". For example, in the example shown in Figure 7(b), the identification information assigned to class B, as indicated by tag C622, is specified as such attribute information. That is, in the configuration file C621 shown in Figure 7(b), it is indicated that an object of class B will be set for field b defined in class X. The information processing device 100 according to this embodiment uses the field definitions in the configuration file exemplified above to identify the code specified by those definitions as the code to be targeted for processing related to the addition of source code for generating a call graph.

[0052] Next, referring to Figure 8, an example of additional source code (source code for generating a call graph) added by the information processing device 100 according to this embodiment to generate a call graph of a series of source codes to be analyzed will be described. In the example shown in Figure 8, for convenience, only a selection of key source codes from a series of source codes included in the project designated as the target of analysis (hereinafter also referred to as project prj1) are shown. Furthermore, in the example shown in Figure 8, the state of project prj1 designated as the target of analysis is shown after the source code of abstract class C631 has been added to project prj1 as additional source code for generating a call graph of the target source code C611. Abstract class C631 defines code that returns an object (instance) corresponding to a field identified as the target based on the example described with reference to Figure 7, in response to a call. For example, code C632 defines code that calls the processing of class C641, which inherits from abstract class C631, as code that returns an object of class X set in field x in response to a call. In other words, the actual processing of code C632 will be defined as the processing of class C641. The details of the processing of class C641 will be described separately later.

[0053] Furthermore, the information processing device 100 according to this embodiment separately creates another project (hereinafter also referred to as project main) used for managing other source code for generating the call graph of the source code to be analyzed, in addition to the project prj1 to be analyzed. Then, the information processing device 100 adds to project main a class C641 that inherits from the abstract class C631 and an executable code C651 that serves as the starting point for generating the call graph.

[0054] Specifically, the information processing device 100 defines a field for class C641 to hold an object returned by the code defined in abstract class C631, as a so-called static field that can be used without creating an instance. For example, field C643 is a field for holding an object of class X that is returned when code C632 defined in abstract class C631 is called. This field defined in class C641 is an example of a "second field". The information processing device 100 also adds code that directly defines the creation of an object corresponding to the above field. The above field is set to the object created by the process defined as that code. For example, code C642 defines the process of creating an object of class X. The field C643 is set to the object created by the process defined as code C642. The information processing device 100 also adds code that defines the concrete process of returning the object held in the above field, as code that is called from the code defined in abstract class C631. For example, code C644 is called from code C632 defined in abstract class C631, and specifies the process of returning an object of class X held in field C643. The source code of this class C641 corresponds to an example of the "second source code" in this embodiment.

[0055] Furthermore, the information processing device 100 specifies code to execute code C651 that calls the initialization process of class C641, and then calls code C632 of abstract class C631 to obtain the object held in field C643 of class C641. For example, in the example shown in Figure 8, the object of class X will be obtained by the process indicated by this code. Then, the information processing device 100 specifies code C652 to execute code C651 that calls the process of the object obtained by the above code, that is, the process that will be the target of call graph generation. The method for identifying the process that will be the target of call graph generation is the same as in the example explained with reference to Figure 1, so a detailed explanation is omitted.

[0056] The information processing device 100 then generates a call graph based on the first source code to be analyzed and a series of source codes including the generated second source code and executable code (for example, the series of source codes exemplified in Figure 8).

[0057] For example, Figure 9 illustrates an example of a call graph generated based on the series of source code examples shown in Figures 6 and 8. Specifically, Figure 9(a) shows an example of a call graph showing the call relationships between objects when the program of the source code to be analyzed is executed. Figure 9(b) also shows an example of a call graph generated based on the series of source code examples shown in Figures 6 and 8. As can be seen by comparing Figure 9(a) and Figure 9(b), although the overall call graphs are different, the call graph shown in Figure 9(b) includes a partial call graph C661 that is substantially the same as the call graph shown in Figure 9(a). In other words, the call graph shown in Figure 9(b) includes a call graph C661 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 circumstances, 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 9(b) using the package name, etc., as extraction conditions. Thus, even in this embodiment, it is possible to generate a call graph that accurately reflects the actual situation (i.e., call graph C661) even when using pointer analysis.

[0058] As explained above, the information processing device 100 according to this embodiment makes it possible to generate a call graph that more accurately reflects the actual situation, even when static analysis such as pointer analysis is used to generate the call graph, without updating the source code to be analyzed.

[0059] (modified version) Next, a modification of the second embodiment of this disclosure will be described below. This modification describes an example in which the series of source codes to be analyzed includes source code that has dependencies on source code belonging to other projects.

[0060] For example, Figure 10 shows an example of source code to be analyzed in this modified example. Note that, for convenience, the example in Figure 10 shows only a selection of key source code snippets from the series of source code included in the project designated for analysis. Specifically, in the example shown in Figure 10, source code C711, which defines classes A and X, is included in project prj1, and source code C712, which defines class B, which inherits from class A, is included in project prj2. Furthermore, the processing of objects of class X is called by the processing of objects of class B, which inherits from class A. In other words, in the example shown in Figure 10, the processing within class X applies objects of class B, which inherits from class A, as objects of class A. That is, in the example shown in Figure 10, the source code belonging to project prj2 (for example, the source code of class B) depends on the source code belonging to project prj1 (for example, the source code of class A). In such cases, it is advisable to add source code for generating the call graph for each management unit (for example, a project) that manages the source code to be analyzed. In this modified example, source code C711 corresponds to an example of the "first source code," and source code C712 corresponds to an example of the "third source code."

[0061] Figure 11 shows an example of additional source code (source code for generating a call graph) that the information processing device 100 according to this modified example adds in order to generate a call graph of a series of source codes to be analyzed. Figure 11 shows an example of additional source code added by the information processing device 100 to the series of source codes to be analyzed as illustrated in Figure 10, for the purpose of generating a call graph of the said series of source codes.

[0062] Specifically, the information processing device 100 adds the source code of abstract class C721 to project prj1, to which source code C711 belongs, as other source code for generating the call graph of source code C711. Abstract class C721 corresponds to abstract class C631 in the example shown in Figure 8, which targets source code C711. Abstract class C721 defines code C722, which returns an object corresponding to the field identified as the target based on the example explained with reference to Figure 7 (in this case, an object corresponding to class B which inherits from class A) in response to a call. Similarly, the information processing device 100 adds the source code of abstract class C731 to project prj2, to which source code C712 belongs, as other source code for generating the call graph of source code C712. Abstract class C731 corresponds to abstract class C631 in the example shown in Figure 8, which targets source code C712. Abstract class C731 defines code C732, which returns an object (an object corresponding to class B) corresponding to the field identified as the target based on the example explained with reference to Figure 7, in response to a call.

[0063] Furthermore, the information processing device 100 in this modified version separately generates another project (project main) used for managing other source code to generate the call graph of the source code to be analyzed, in addition to projects prj1 and prj2 which are to be analyzed. Then, the information processing device 100 adds to project main a class C741 that inherits from abstract class C721, a class C751 that inherits from abstract class C731, and an executable code C761 (described separately later, see Figure 12) which serves as the starting point for generating the call graph.

[0064] The information processing device 100 defines a field for class C741 to hold an object returned by the code defined in abstract class C721, as a so-called static field that can be used without creating an instance. For example, field C743 is a field for holding an object of class B that inherits from class A, which is returned when code C722 defined in abstract class C721 is called. Furthermore, in the example shown in Figure 10, in the processing of class X in source code C711, an object of class B, which inherits from class A, is applied as an object of class A. Therefore, code is defined to set an object in field C743 so that the creation of the object held in field C743 is executed as processing of class C751, which will be described later. Specifically, the code to set an object in field C743 is defined as calling code C732 defined in abstract class C731. As a result, code C754, which will be described later, is called via code C732, and the resulting returned object of class B is set in field C743. Furthermore, the information processing device 100 adds code C744, which defines an actual process to return the object held in field C743, as code called from code C722 defined in abstract class C721. In this modified example, the source code of class C741 corresponds to an example of the "second source code." Also, field C743 defined in class C741 corresponds to an example of the "second field" in this modified example, and the object held in field C743 corresponds to an example of the "first object" in this modified example.

[0065] Furthermore, the information processing device 100 defines a field for class C751 to hold an object returned by the code defined in abstract class C731, as a so-called static field that can be used without creating an instance. For example, field C753 is a field for holding an object of class B that is returned when code C732 defined in abstract class C731 is called. Furthermore, in the example shown in Figure 10, there are no other classes that depend on class B. Therefore, the information processing device 100 directly specifies the generation of an object (an object of class B) corresponding to field C753 and adds code C752. Field C753 is set to the object generated by the process specified as code C752. Furthermore, the information processing device 100 adds code C754, which defines an actual process for returning an object held in a field, as code called from code C732 defined in abstract class C731. In this modified example, the source code of class C751 corresponds to an example of the "fourth source code." Also, field C753 defined in class C741 corresponds to an example of the "third field" in this modified example, and the object held in field C753 corresponds to an example of the "second object" in this modified example.

[0066] Furthermore, the information processing device 100 adds execution code C761 to the project main, which serves as the starting point for generating the call graph. For example, Figure 12 shows an example of execution code related to this modified example. In the example shown in Figure 12, the information processing device 100 specifies code to call the initialization processes for classes C741 and C751 respectively, and then call the code for class C741 to obtain an object of class X held in a field of class C741. Then, the information processing device 100 specifies code to call the execution code C761 to process the object of class X obtained by the above code, that is, the process to be used to generate the call graph. The method for identifying the process to be used to generate the call graph is the same as in the example explained with reference to Figure 1, so a detailed explanation is omitted.

[0067] The update unit 112 then outputs a series of source codes (for example, the series of source codes exemplified in Figure 8) including the first source code to be analyzed, the generated second source code, and the executable code, to a predetermined output destination as a series of source codes for generating a call graph.

[0068] The information processing device 100 then generates a call graph based on a series of source codes (for example, the series of source codes exemplified in Figures 11 and 12) including the first and third source codes to be analyzed, the generated second and fourth source codes, and the executable code.

[0069] For example, Figure 13 illustrates an example of a call graph generated based on the series of source code examples shown in Figures 10, 11, and 12. Specifically, Figure 13(a) shows an example of a call graph showing the call relationships between objects when the program of the source code being analyzed is executed. Figure 13(b) also shows an example of a call graph generated based on the series of source code examples shown in Figures 10, 11, and 12. As can be seen by comparing Figure 13(a) and Figure 13(b), although the overall call graphs are different, the call graph shown in Figure 13(b) includes a partial call graph C771 that is substantially the same as the call graph shown in Figure 13(a). In other words, the call graph shown in Figure 13(b) includes a call graph C771 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 premises, in order to obtain a call graph that is substantially equivalent to the original call graph by removing the unnecessary parts, for example, the call graph of the source code to be analyzed can be extracted from the series of call graphs shown in Figure 13(b) using the package name, etc., as extraction conditions. In this way, even in this embodiment, it is possible to generate a call graph that reflects the actual situation (i.e., call graph C771) even when using pointer analysis.

[0070] As explained above, the information processing device 100 according to this modified example makes it possible to generate a call graph that more accurately reflects the actual situation, even when the series of source codes to be analyzed includes source code that has dependencies on source code belonging to other projects.

[0071] <Third Embodiment> A third embodiment of this disclosure is described below. In this embodiment, as an extended embodiment of the embodiments described above, 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.

[0072] 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 14A and 14B.

[0073] For example, Figure 14A shows an example where singleton is not applied. Specifically, Figure 14A(a) shows an example of the source code to be analyzed. In the example shown in Figure 14A(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 15 shows an example of the source code of a series of objects defined in the source code shown in Figure 14A and Figure 14B, which will be described later. Figure 14A(b) shows an example of the result of applying pointer analysis to the source code shown in Figure 14A(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 14A(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 14A(c) shows an example of a call graph output as a result of pointer analysis, as explained with reference to Figure 14A(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.

[0074] Figure 14B shows an example where a singleton is applied. Specifically, Figure 14B(a) shows an example of source code to be analyzed. The example shown in Figure 14B(a) is similar in code format to the example shown in Figure 14A(a), but differs from the example shown in Figure 14A(a) in whether or not a singleton is applied. Figure 14B(b) shows an example of the result of applying pointer analysis to the source code shown in Figure 14A(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 14B(b), the common house object is called from both objects x and y. Figure 14B(c) shows an example of a call graph output as a result of pointer analysis, as explained with reference to Figure 14B(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 14B, the house object is a singleton object. In contrast, in the example shown in Figure 14A, the house object is not a singleton object.

[0075] As can be seen by comparing Figures 14A and 14B, 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.

[0076] 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.

[0077] For example, Figure 16 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 16, 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 16(a) and 16(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 16(a), the annotation "@Scope" means that a singleton is not applied. In the example shown in Figure 16(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 16(c), there may be cases where no attribute value is specified for the annotation "@Scope", or as shown in Figure 16(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 16(c) and Figure 16(d), if it means that a singleton is applied as the default setting, the information processing device 100 will determine that a singleton is applied to the target source code.

[0078] As another example, Figure 17 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 17, 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 17(a) and 17(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 this 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 17(a), the "scope" attribute means that a singleton will not be applied. In the example shown in Figure 17(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 17(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 17(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.

[0079] Next, with reference to Figure 18, an example of how the information processing device 100 according to this embodiment updates the target source code will be described. In Figure 18, source code C501 schematically represents the source code to be analyzed. Although not shown in Figure 18, 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. Although not shown in Figure 18, 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.

[0080] 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 18, 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 generation 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 call the object creation process for the target object to the abstract class C503. In the example shown in Figure 18, for convenience, code C508 and code C509 are shown as examples for source code C503. Code C508 is code whose actual processing is defined as code C506 in source code C502 (described later) (code that is overridden). Similarly, code C509 is code whose actual processing is defined as code C507 in source code C502 (code that is overridden). If a singleton is applied, both code C508 and C509 are used. Conversely, if a singleton is not applied, only C509 is used. Based on the determination result of whether or not a singleton is applied to source code C501, the update unit 112 may selectively switch the output of code C508 and C509 as described above, 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 18 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.

[0081] 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 18, for convenience, a state in which both 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 generates 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 18, 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 explained with reference to Figures 2 and 8. Since this executable code is the same as in the examples shown in Figures 2 and 8, a detailed explanation is omitted.

[0082] 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.

[0083] <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.

[0084] 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.

[0085] 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 in which a first field of an object is defined, based on at least one of the following: an annotation attached to the source code that suggests the generation of an object, and a definition of the object to be generated in a configuration file associated with the series of source codes; a generation means for generating a second source code different from the first source code, which defines code that directly indicates the generation of an object corresponding to the first field; and an execution code that calls a process that references the first field defined in the first source code by calling a process defined in the second source code, wherein a call graph is generated based on the first source code, the second source code, and the execution code. (2) The information processing apparatus according to (1), comprising an update means for updating the first source code by adding code that indirectly indicates the generation of the object to the first source code, wherein the generation means generates a second source code that defines code that directly indicates the generation of the object in association with the code that indirectly indicates the generation of the object, and generates the executable code such that it calls the process defined in the updated first source code by calling the process defined in the second source code. (3) The code that indirectly indicates the creation of the object is the code that calls the processing defined in the abstract class of the class defined in the second source code, The information processing device described in (2), wherein the class is defined in the second source code so as to inherit the abstract class. (4) The information processing apparatus according to (1), wherein the generation means generates a second source code which defines a second field corresponding to the object, a code which generates the object and holds it in the second field, and a code which returns the object held in the second field in response to a call, and generates the executable code which calls the object generated by the processing defined in the second source code and calls the processing defined in the first source code as processing of the object. (5) When the generation means extracts the first source code which defines the first field of the first object, and the third source code which defines the second field of the second object which has a different management unit from the first source code and is defined in dependence of the first source code, it extracts the fourth source code which defines the third field corresponding to the second object, the code which generates the second object and holds it in the third field, and the code which returns the second object held in the third field in response to the call, the second field corresponding to the first object, and the fourth source code An information processing device according to (4), which generates: a second source code which defines a code which holds the second object as the first object in the second field based on a call to a code which returns the second object held in the third field defined in the code, and a code which returns the first object held in the second field in response to the call; and an executable code which calls an object generated by a process defined in the second source code and, as processing of the object, calls a process defined in the first source code and a process defined in the third source code. (6) 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, in which a first field of an object is defined, based on at least one of: an annotation that suggests the generation of an object attached to the source code, and a definition of the object to be generated in a configuration file associated with the series of source codes; a generation step of generating a second source code different from the first source code, in which code that directly indicates the generation of an object corresponding to the first field is defined, and execution code that calls a process that references the first field defined in the first source code by calling a process defined in the second source code, wherein a call graph is generated based on the first source code, the second source code, and the execution code. (7) A program that causes a computer to execute an extraction step of extracting a first source code from a series of source codes to be analyzed, in which a first field of an object is defined, based on at least one of the following: annotations added to the source code that suggest the generation of an object, and a definition of the object to be generated in a configuration file associated with the series of source codes; a generation step of generating a second source code different from the first source code, in which code that directly indicates the generation of an object corresponding to the first field is defined; and an execution code that, by calling a process defined in the second source code, calls a process that references the first field defined in the first source code, thereby generating a call graph based on the first source code, the second source code, and the execution code. [Explanation of symbols]

[0086] 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 in which the first field of an object is defined, based on at least one of the following: annotations that suggest the generation of an object attached to the source code, and the definition of the object to be generated in a configuration file associated with the said source code; An update means for updating the first source code by adding code that indirectly indicates the creation of the object to the first source code, A generation means that generates a second source code different from the first source code, which defines code that directly indicates the creation of an object corresponding to the first field, and an executable code that calls a process that references the first field defined in the first source code by calling a process defined in the second source code, Equipped with, The generating means is The second source code is generated, which defines code that directly indicates the generation of the object, in association with code that indirectly indicates the generation of the object. 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 first source code, the second source code, and the execution code. Information processing device.

2. The code that indirectly indicates the creation of the aforementioned object is code that calls the processing defined in the abstract class of the class defined in the 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.

3. The generating means is The second source code is generated which defines a second field corresponding to the aforementioned object, code that creates the object and holds it in the second field, and code that returns the object held in the second field in response to a call. The executable code is generated such that it calls the object generated by the processing specified in the second source code and calls the processing specified in the first source code as the processing of the said object. The information processing apparatus according to claim 1.

4. The generating means is When the first source code that defines the first field of the first object and the third source code that defines the second field of the second object, which has a different management unit from the first source code and is defined in relation to the first source code, A fourth source code that defines a third field corresponding to the second object, code that generates the second object and holds it in the third field, and code that returns the second object held in the third field in response to a call, The second source code defines a second field corresponding to the first object, code that holds the second object as the first object in the second field based on a call to code that returns the second object held in the third field defined in the fourth source code, and code that returns the first object held in the second field in response to the call, The executable code calls an object generated by the processing defined in the second source code, and as processing of that object, calls the processing defined in the first source code and the processing defined in the third source code. To generate The information processing apparatus according to claim 3.

5. An information processing method performed by an information processing device, An extraction step of extracting a first source code in which the first field of an object is defined, based on at least one of the following: annotations that suggest the generation of an object attached to the source code, and the definition of the object to be generated in a configuration file associated with the said set of source code; An update step to update the first source code by adding code that indirectly indicates the creation of the object to the first source code, A generation step that generates a second source code different from the first source code, which specifies code that directly indicates the creation of an object corresponding to the first field, and executable code that calls a process that references the first field specified in the first source code by calling a process specified in the second source code, Includes, The generation step is, The second source code is generated, which defines code that directly indicates the generation of the object, in association with code that indirectly indicates the generation of the object. 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 first source code, the second source code, and the execution code. Information processing methods.

6. On the computer, An extraction step of extracting a first source code in which the first field of an object is defined, based on at least one of the following: annotations that suggest the generation of an object attached to the source code, and the definition of the object to be generated in a configuration file associated with the said set of source code; An update step to update the first source code by adding code that indirectly indicates the creation of the object to the first source code, A generation step that generates a second source code different from the first source code, which specifies code that directly indicates the creation of an object corresponding to the first field, and executable code that calls a process that references the first field specified in the first source code by calling a process specified in the second source code, Make it run, The generation step is, The second source code is generated, which defines code that directly indicates the generation of the object, in association with code that indirectly indicates the generation of the object. 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 first source code, the second source code, and the execution code. program.

Images