Source code analysis device and source code analysis method

Abstract

Increasing the amount of source code that can be analyzed with large language models. [Solution] The source code analysis device 1 includes a static analysis unit 11 that analyzes each source code that constitutes a software project using a static analysis tool 2, an analysis unit 131 that analyzes the structured data of the source code analyzed by the static analysis unit 11 and written in the DOT language using a large-scale language model 7 based on prompts corresponding to this structured data, and outputs source code analysis information, and a documentation unit 132 that creates an integrated report from the source code analysis information.

Description

[Technical Field]

[0001] The present invention relates to a source code analysis device and a source code analysis method. [Background technology]

[0002] In recent years, there has been a demand for refactoring, which improves the internal structure and behavior of existing source code without changing its external input / output specifications. As a result, the importance of reverse engineering, which analyzes existing software and systems to understand their structure and functions, is increasing. For reverse engineering, there are static analysis tools that analyze source code without executing the program and measure the relationships between functions and metrics in the source code. Existing static analysis tools analyze software and systems using rules.

[0003] With the recent advances in generative AI technology, attempts have been made to analyze software and systems using large-scale language models. For example, Non-Patent Document 1 discloses analyzing source code itself using generative AI. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] Weizhi Wang et al., “Augmenting Language Models with Long-Term Memory”, University of California, Santa Barbara, Microsoft Research, Part of Advances in Neural Information Processing Systems 36 (NeurIPS 2023) Main Conference Track, Internet <URL: https: / / proceedings.neurips.cc / paper_files / paper / 2023 / file / ebd82705f44793b6f9ade5a669d0f0bf-Paper-Conference.pdf> Summary of the Invention [Problem to be solved by the invention]

[0005] In the technology of Non-Patent Document 1, it is difficult to input the entire source code due to the token limit of the generation AI. Therefore, the technology of Non-Patent Document 1 has the problem that the scale of the source code that can be analyzed is small, and only a fragmented analysis can be performed for a large source code. Therefore, an object of the present invention is to expand the scale of source code that can be analyzed by a large-scale language model. [Means for solving the problem]

[0006] In order to solve the above-mentioned problems, the source code analysis device of the present invention analyzes each source code constituting a software project using a static analysis tool. The source code is analyzed as a flowchart, and the flowchart is output as structured data written in a specified intermediate language. a static analysis unit; and a source code analyzed by the static analysis unit and written in a predetermined intermediate language. The aforementioned The system is characterized by comprising an analysis unit that analyzes structured data using a large-scale language model based on prompts corresponding to the structured data and outputs source code analysis information, and a documentation unit that creates an integrated report from the source code analysis information.

[0007] That is, in the source code analysis method of the present invention, a static analysis unit analyzes each source code constituting a software project using a static analysis tool. Analyze the source code as a flowchart and output the structured data in which the flowchart is written in a specified intermediate language. and a step of analyzing the source code written in a predetermined intermediate language by the static analysis unit. The aforementioned The method includes a step in which an analysis unit analyzes the structured data using a large-scale language model based on a prompt corresponding to the structured data and outputs source code analysis information, and a step in which a documentation unit creates an integrated report from the source code analysis information. Other means will be described in the detailed description of the invention. [Effects of the Invention]

[0008] According to the present invention, it is possible to increase the scale of source code that can be analyzed by a large-scale language model. [Brief explanation of the drawings]

[0009] [Figure 1A] 1 is a logical configuration diagram of a source code analysis device according to an embodiment of the present invention; [Figure 1B] FIG. 10 illustrates a prompt management unit. [Figure 2] FIG. 2 is a hardware configuration diagram of the source code analysis device. [Figure 3] FIG. 10 is a diagram showing an example of an analysis process of a comparative example. [Figure 4] FIG. 10 is a diagram illustrating the analysis results of a comparative example. [Figure 5] 10 is a flowchart of a source code analysis process. [Figure 6] FIG. 10 is a diagram illustrating an example of source code. [Figure 7] FIG. 10 is a diagram illustrating an example of source code. [Figure 8] FIG. 10 is a diagram illustrating an example of source code. [Figure 9] FIG. 1 is a diagram illustrating an example of structured data in which a class diagram is described in the DOT language. [Figure 10]FIG. 10 is a diagram illustrating an example of structured data in which a sequence diagram is described in the DOT language. [Figure 11] FIG. 1 illustrates an example of a class diagram. [Figure 12] FIG. 10 is a diagram illustrating an example of a sequence diagram. [Figure 13] FIG. 10 is a diagram illustrating an example of class diagram analysis information. [Figure 14] FIG. 10 is a diagram illustrating an example of sequence diagram analysis information. [Figure 15] FIG. 10 is a diagram illustrating an example of an integrated report. [Figure 16] FIG. 2 illustrates an operation of the source code analyzing apparatus. [Figure 17] FIG. 2 illustrates an operation of the source code analyzing apparatus. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. 1A is a logical configuration diagram of a source code analysis apparatus 1 according to this embodiment, and FIG. The source code analysis device 1 includes a static analysis unit 11, a storage unit 12, an information control unit 13, and a document management unit 14, and has a static analysis tool 2 installed. The source code analysis device 1 is a computer equipped with a CPU (Central Processing Unit), and statically analyzes an input project file group 3 in cooperation with a large language model (LLM) 7. According to this embodiment, it is possible to expand the range that can be analyzed by the large language model 7 and improve the accuracy of the analysis results.

[0011] The static analysis tool 2 is a software program that performs rule-based static analysis of a set of software project files 3. The static analysis unit 11 invokes the static analysis tool 2 to statically analyze the set of software project files 3, and receives the analysis results, that is, structured data written in a language such as DOT and code metrics information. The DOT language is a type of data description language used to express graphs as data structures in plain text. The DOT language describes graphs in a simplified format that is easy for computers to process and humans to read. Note that the structured data used by the static analysis tool 2 is not limited to data written in the DOT language, and may be written in formats such as XML (eXtended Markup Language) and JSON (JavaScript Object Notation).

[0012] Code metrics information here refers to indicators that quantify the quality and complexity of software. Specific examples of code metrics include the number of lines of code, cyclomatic complexity, and the coupling and cohesion of classes and functions. Code metrics information is used to identify areas for improvement during refactoring and code analysis.

[0013] The structured data in the DOT language and the code metrics information analyzed by the static analysis unit 11 are stored in an analysis result database 121 in the storage unit 12.

[0014] The storage unit 12 is a storage unit that stores various data, and includes an analysis result database 121, a prompt management unit 122, and a project file group database 123. The analysis result database 121 is a database that stores structured data in the DOT language that is the result of static analysis of the project file group 3.

[0015] The prompt management unit 122 manages prompts for instructing the large-scale language model 7 to analyze structured data in the DOT language. As shown in FIG. 1B , the prompt management unit 122 includes a prompt 1221 for analyzing a class diagram, a prompt 1222 for analyzing a sequence diagram, a prompt 1223 for analyzing a flowchart, a prompt 1224 for analyzing code metrics, a prompt 1225 for analyzing a component diagram, and a prompt 1226 for analyzing a state transition diagram. The class diagram analysis prompt 1221 is an instruction to have the large-scale language model 7 analyze structured data in which a class diagram is described in the DOT language. The class diagram analysis prompt 1221 is transcribed below.

[0016] Written in the following DOT language <dotlanguage>Analyze the diagram in the tag and <perspective>Please clarify the content according to the point of view in the tag. The output format is <answer>Surround it with tags, <design>Please follow the rules in the tag. <dotlanguage> {{Put DOT language description of structured class diagram here}} < / dotlanguage> <perspective> - Analyze the purpose of the system and explain it to the extent possible. - Explicitly indicate relationships between classes (inheritance, dependency, aggregation, composition) and organize software structure. - Analyze whether the roles of each class are being properly divided and point out any problems. - If there are any violations of the Single Responsibility Principle (SRP), provide reasons and suggestions for fixes. - Identify and suggest redundant or consolidable classes or areas that should be abstracted. - Explain your proposal with specific examples of modifications. < / perspective> <design> - The purpose of the system as inferred from the class diagram - The overall structure of the class diagram - Class roles and responsibilities - Issues and fixes - Improvements and work steps after correction < / design>

[0017] The sequence diagram analysis prompt 1222 is an instruction to have the large-scale language model 7 analyze structured data in which a sequence diagram is described in the DOT language. The sequence diagram analysis prompt 1222 is transcribed below.

[0018] Written in the following DOT language <dotlanguage>Analyze the diagram in the tag and <perspective>Please clarify the content according to the point of view in the tag. The output format is <answer>Surround it with tags, <design>Please follow the rules in the tag. <dotlanguage> {{Put DOT language description of the sequence diagram here}} < / dotlanguage> <perspective> - Organize the flow of message exchange and explain the main objects (actors) and processing order. - Identify bottlenecks and inefficient process flows, and provide causes and suggestions for improvement. - Evaluate the appropriateness of exception handling and asynchronous calls. - If there are inconsistencies in the sequence diagram (undefined objects, inconsistent order, etc.), it will point them out and suggest corrections. - Present refactoring ideas (rearrangement of processes or splitting methods) and explain their effects. < / perspective> <design> - Overall flow and structure - Issues and their impact - Corrections and examples - Expected effects and implementation procedures after revision < / design>

[0019] The flowchart analysis prompt 1223 is an instruction for causing the large-scale language model 7 to analyze structured data in which a flowchart is written in the DOT language. The flowchart analysis prompt 1223 is transcribed below.

[0020] Written in the following DOT language <dotlanguage>Analyze the diagram in the tag and <perspective>Please clarify the content according to the point of view in the tag. The output format is <answer>Surround it with tags, <design>Please follow the rules in the tag. <dotlanguage> {{Put structured description of flowchart here}} < / dotlanguage> <perspective> - If the purpose of the processing is known, provide an explanation in natural language. - Organize the processing flow (from start to finish) and analyze conditional branching and loop structures. - Identify branching complexities and unnecessary steps and offer simplification suggestions. - If there are exception paths or unhandled states, it will point them out and suggest solutions. - Evaluate the efficiency of algorithms and suggest optimizations where necessary. - Provide concrete examples of refactoring and merging / splitting processes. < / perspective> <design> - A summary of the purposes of processing - Overview of flow and structure - Problems and improvement suggestions - Example of improved flow - Expected effects of the revision < / design>

[0021] The chord metrics analysis prompt 1224 is an instruction for causing the large-scale language model 7 to analyze the chord metrics information. The chord metrics analysis prompt 1224 is transcribed below.

[0022] <input> Analyze the code metrics data provided in the tag, <perspective>Please analyze the instructions written in the tags and provide suggestions for improving the quality of the software. The output is <answer>Surround it with tags, <design>Follow the tag format. <key-point>Please use the additional information in the tags as a perspective for analysis. <input> # Code clone - File A: Function foo() matches function bar() 80% - File B: The method baz() of class MyClass matches 95% with the method qux() of another file C # Cohesion - File A: Cohesion 0.4 (low) - File B: Cohesion 0.9 (high) - File C: Cohesion 0.3 (very low) # degree of coupling - Coupling between Module 1 and Module 2: 0.8 (high) - Coupling between Module 3 and Module 4: 0.2 (low) # Complexity - foo() in file A: cyclomatic complexity 12 - bar() in file B: cyclomatic complexity 4 - baz() in file C: Cyclomatic complexity 15 (very high) <perspective> # Code clone - Analyze why clones occur and present specific refactoring ideas to reduce clones (function extraction, common modularization, etc.). # Cohesion - Identify areas of low cohesion and explain the causes (dispersion of function responsibilities, mixing of loosely related processes, etc.). - Suggest improvements to increase cohesion (combining or repartitioning functions, modularizing them). # degree of coupling - Identify areas where coupling is too strong and explain the impact (reduced maintainability, reduced module independence, etc.). - Please suggest improvements to reduce coupling (introduce interfaces, reduce dependencies, apply dependency inversion, etc.). # Complexity - Identify functions with high complexity and explain why they are difficult to understand (e.g., too many conditionals, nested loops, etc.). - Please suggest refactoring ideas to reduce complexity (introduce guard clauses, return early, split processing, etc.). #Effects of improvement proposals - Please explain the specific effects of your proposed improvements (improved maintainability, fewer bugs, improved code reusability, etc.). # Work steps - Provide steps for improvement (priorities, phased implementation, etc.). < / perspective> <key-point> #Data explanation and key points ## Code clone - Points to look out for: Causes of duplicated code (copy and paste, reimplementation of common functions, etc.), possibility of refactoring (creating common methods, introducing class inheritance, etc.). - Goal: Reduce redundancy, improve maintainability. ## Cohesion - Focus: How well related processes are organized within a function or module. Low cohesion can mean that a function or module has too many responsibilities. - Goal: Organize so that each module / class has one clear responsibility. ## Associativity - Key point: If dependencies between modules are too strong, the impact of changes will be large. Introducing interfaces or abstract classes may be effective. - Goal: Keep coupling low, but design necessary dependencies explicitly. Complexity - Key points: Cyclomatic complexity (number of control flow branches and conditional expressions). If it is high, functions should be split or early returns should be introduced. - Goal: Reduce complexity and improve code readability and maintainability. <design> Please output the analysis results in the following format: - Code clone issues and improvement suggestions - Cohesion issues and improvement suggestions - Coupling issues and improvement suggestions - Complexity issues and improvement suggestions - Effects and work steps of improvement proposals < / design>

[0023] The component diagram analysis prompt 1225 is an instruction to have the large-scale language model 7 analyze structured data in which a component diagram is described in the DOT language. The component diagram analysis prompt 1225 is transcribed below.

[0024] Written in the following DOT language <dotlanguage>Analyze the diagram in the tag and <perspective>Please clarify the content according to the point of view in the tag. The output format is <answer>Surround it with tags, <design>Please follow the rules in the tag. <dotlanguage> {{Put your component diagram structured description here}} < / dotlanguage> <perspective> - Clarify dependencies and interfaces between components and organize the overall structure. - Identify areas of high coupling and redundant dependencies and suggest ways to reduce them. - Identify components that violate the Single Responsibility Principle and suggest redesigns. - Proposals for division and integration to improve future expandability and ease of modification are presented. - Provide additional information about any restrictions or precautions regarding external libraries and frameworks. < / perspective> <design> - Organizing the overall structure and dependencies - Issues and their impact - Proposed amendments and their rationale - Expected effects of the modifications and implementation procedures < / design>

[0025] The prompt for analyzing the state transition diagram 1226 is an instruction for causing the large-scale language model 7 to analyze structured data in which the state transition diagram is described in the DOT language. The prompt for analyzing the state transition diagram 1226 is transcribed below.

[0026] Written in the following DOT language <dotlanguage>Analyze the diagram in the tag and <perspective>Please clarify the content according to the point of view in the tag. The output format is <answer>Surround it with tags, <design>Please follow the rules in the tag. <dotlanguage> {{Put your component diagram structured description here}} < / dotlanguage> <perspective> - Clarify dependencies and interfaces between components and organize the overall structure. - Identify areas of high coupling and redundant dependencies and suggest ways to reduce them. - Identify components that violate the Single Responsibility Principle and suggest redesigns. - Proposals for division and integration to improve future expandability and ease of modification are presented. - Provide additional information about any restrictions or precautions regarding external libraries and frameworks. < / perspective> <design> - Organizing the overall structure and dependencies - Issues and their impact - Proposed amendments and their rationale - Expected effects of the modifications and implementation procedures < / design>

[0027] The project file group database 123 is a database that stores the input project file group 3.

[0028] The information control unit 13 includes an analysis unit 131 and a documentation unit 132. The information control unit 13 processes the analysis results of the static analysis tool 2 in the large-scale language model 7, making it possible to grasp the entire project file group 3.

[0029] A large-scale language model7 is a type of artificial intelligence that uses deep learning to understand and generate natural language based on large amounts of text data. Large-scale language models7 have billions to trillions of parameters that are adjusted during training, and understand the context of the text to generate appropriate responses and sentences. Large-scale language models7 are large-scale language models such as GPT-3 and GPT-4, and are used for text generation and understanding.

[0030] The analysis unit 131 analyzes the structured data of the source code, which has been analyzed by the static analysis unit 11 and written in a predetermined intermediate language, using the large-scale language model 7 based on prompts corresponding to the structured data, and outputs source code analysis information.

[0031] The documentation unit 132 documents an integrated report obtained by integrating the source code analysis information of each of the project files 3 through rule-based processing. The documentation unit 132 stores the documented integrated report in the document management unit 14.

[0032] FIG. 2 is a diagram showing the hardware configuration of the source code analysis device 1. As shown in FIG. The source code analyzing device 1 includes a CPU 101 , a memory 102 , a mass storage device 103 , an input / output interface 104 , and a network interface 105 .

[0033] The CPU 101 is one or more central processing units that control the source code analysis device 1. The memory 102 is a temporary storage device, such as a volatile storage device or a nonvolatile storage device. The mass storage device 103 is a mass storage device such as a hard disk or an SSD (Solid State Drive).

[0034] The input / output interface 104 is an interface for input signals from a keyboard / mouse and output signals to a display. The network interface 105 is an interface for connecting to a network and exchanging information with other devices.

[0035] Each functional module in the source code analyzing device 1 is loaded into the memory 102 as a computer program, and is executed by the CPU 101 .

[0036] The mass storage device 103 also stores various data managed by the source code analysis device 1 and a documentation program 107. The various data managed by the source code analysis device 1 may be stored in an external storage device connected via a network, rather than within the device.

[0037] The source code analysis device 1 may be implemented as a virtual machine instead of a physical machine. The source code analysis device 1 is connected to a facility or a device that controls the facility via a network. The source code analysis device 1 may be implemented in a cloud environment. In this case, the source code analysis device 1 is connected to an environment in which the facility is set via a network.

[0038] Comparative Example FIG. 3 is a diagram showing an example of an analysis process of a comparative example. In the past, project files of source code were analyzed manually or using a generative AI called GitHub Copilot (registered trademark). Here, we will explain an analysis process 52 that analyzes project files 51 using a large-scale language model 522.

[0039] In the analysis step 52, the large-scale language model 522 receives the project file set 51. The large-scale language model 522 then repeatedly analyzes the source code fragments 521 included in the project file set 51, and outputs the analysis results 53.

[0040] Large-scale language models process text input and output in token units. A token is the smallest unit that makes up a sentence, such as a word itself, part of a word, a symbol, or a space. Large-scale language models have a set number of tokens that can be processed at one time, and if this number is exceeded, they will no longer be able to process the entire input. Large-scale language models are also limited in the total amount of input and output information that they can process at one time. Therefore, the user must divide the project file group 51 to be input to the large-scale language model 522 of this comparative example into source code fragments 521 with the number of tokens that the large-scale language model 522 can process or less, and repeat the process.

[0041] FIG. 4 is a diagram illustrating the analysis results of the comparative example. The diagram shows the relationship between source code fragments 521a to 521e, which are the subject of analysis result 53, and the entire project file group 51. In other words, conventional analysis processes can only analyze fragmentary information. These source code fragments 521a to 521e also need to be specified by a human, so the user needs to have some understanding of the code.

[0042] Therefore, large language models cannot be efficiently used for reverse engineering for refactoring purposes. Large language models may perform incorrect analysis. The technical reason for this is that large language models often cannot read all the code in a project file due to the token limit.

[0043] In addition, projects often use configuration files other than the software to determine what to build and what the visibility range is, and various pieces of information that are not visible from the code, such as file storage locations, are intertwined.

[0044] <<Present Embodiment>> FIG. 5 is a flowchart of the source code analysis process of this embodiment. First, the user inputs the software project file group 3 into the static analysis unit 11 (step S10). Next, the static analysis unit 11 analyzes the input using the static analysis tool 2 and converts it into structured data such as an image of a UML expression and a DOT file (step S11). Specifically, it generates UML (Unified Modeling Language) diagrams and outputs structured data in the DOT language corresponding to these UML diagrams. UML diagrams include class diagrams, sequence diagrams, flowcharts, component diagrams, and state transition diagrams. The static analysis unit 11 may also output code metrics information that evaluates cohesion, coupling, and complexity.

[0045] Cohesion is an index that evaluates the relationship within a module. Redesigning a module with low cohesion can increase the unity within the module, improving readability and maintainability. Coupling is a measure of the dependency between modules. By separating highly coupled parts, the flexibility of the system can be increased and the scope of impact of changes can be reduced.

[0046] Complexity is an index that evaluates the complexity of a function or algorithm. It can identify areas with high error risk, calculate the number of test cases, and develop an appropriate test plan.

[0047] The analysis unit 131 inputs the converted structured data and metrics into the large-scale language model 7, analyzes the entire group of project files, and supplements the UML with natural language expressions (step S12). By inputting structured data in the DOT language into the large-scale language model 7, the token limitations of the large-scale language model 7 can be avoided, the software structure can be analyzed efficiently, and the overall structure of the software project file group 3 can be grasped. Then, by instructing the large-scale language model 7 to detect duplicate code such as code clones, the duplicate code can be deleted or unified, thereby improving the maintainability of the project file group 3. By instructing the large-scale language model 7 to detect redundant code, the overall quality of the project file group 3 can be improved.

[0048] Finally, the documentation unit 132 documents an integrated report based on the generated drawings and their analysis information (step S13). The documentation unit 132 generates a design document based on the analysis results of the large-scale language model 7. When the processing of step S13 is completed, the processing of Fig. 5 ends. Thereafter, the user fine-tunes and checks the design document, and the design document is completed.

[0049] The documentation process of this embodiment allows for the organization of information by converting software project files 3 into structured data in an intermediate language using a static analysis tool 2 as preprocessing before analyzing them with a large-scale language model.

[0050] The documentation process of this embodiment further converts a large-scale project with a large number of tokens into structured data in an intermediate language with a small number of tokens, and then analyzes this structured data using a large-scale language model. This makes it possible to avoid the token limitations of a large-scale language model, even if the scale of a large-scale project is relatively large, making it possible to grasp the overall picture of even a large-scale project.

[0051] Furthermore, the documentation process of this embodiment not only combines the source code of a large-scale project with structural data of the intermediate language that has been analyzed, and images, allowing the user to gain deeper insight.

[0052] 6 to 8 are diagrams showing examples of source code, which belong to the same project file group 3. 6 shows a portion of source code 31 written in the Python language. The file name of the source code 31 is "user.py."

[0053] Figure 7 shows a portion of source code 32 written in Python. The file name of the source code 32 is "transaction.py". 8 shows a portion of source code 33 written in the Python language. The file name of the source code 33 is "account.py".

[0054] By applying the source codes 31 to 33 to the static analysis tool 2, structured data 612 in the DOT language shown in Fig. 9 and structured data 622 in the DOT language shown in Fig. 10 are created as a by-product for expressing them as UML. This makes it possible to obtain only the necessary information compressed for each viewpoint as text.

[0055] FIG. 9 is a diagram showing an example of structured data 612 in which a class diagram is written in the DOT language. The static analysis tool 2 analyzes the source codes 31 to 33 and outputs this structured data 612. This structured data 612 is transcribed below.

[0056] digraph ClassDiagram { User -> Account [label="owns"]; Account -> Transaction [label="used by"]; User [label="User"]; Account [label="Account"]; Transaction [label="Transaction"]; User -> display_name [label="method"]; Account -> deposit [label="method"]; Account -> withdraw [label="method"]; Transaction -> execute [label="method"]; Transaction -> reverse [label="method"]; }

[0057] This allows only the necessary information compressed for each perspective to be obtained as text.

[0058] FIG. 10 is a diagram showing an example of structured data 622 in the DOT language of a sequence diagram. The static analysis tool 2 analyzes the source codes 31 to 33 and outputs this structured data 622. This structured data 622 is transcribed below.

[0059] digraph SequenceDiagram { rankdir=LR; # Node definition User [label="User"]; Account [label="Account"]; Transaction [label="Transaction"]; # Message flow User -> Account [label="create Account"]; Account -> Transaction [label="create Transaction"]; Transaction -> Account [label="execute (deposit)"]; Transaction -> Account [label="reverse (withdraw)"]; }

[0060] This allows only the necessary information compressed for each perspective to be obtained as text.

[0061] FIG. 11 is a diagram showing an example of the class diagram image 611. The class diagram image 611 is a display of structured data 612 of the class diagram in the DOT language on the screen.

[0062] In this class diagram image 611, a "User" class is drawn at the top level. The "User" class is related to the "Account" class through an owns relationship, and is related to the "display_name" class through a method relationship.

[0063] The "Account" class is related to the "Transaction" class and the "deposit" class by a used by method relationship, and to the "withdraw" class by a method relationship. The "Transaction" class is related to the "execute" class and the "reverse" class by a method relationship.

[0064] FIG. 12 is a diagram showing an example of the sequence diagram image 621. As shown in FIG. The sequence diagram image 621 is a display on the screen of structured data 612 in which a class diagram is written in the DOT language.

[0065] This sequence diagram image 621 lists three actors: a User, an Account, and a Transaction. First, User sends a Create Account signal to Account. Then, Account sends a Create Transaction signal to Transaction. After that, Transaction sends an Execute (deposit) signal to Account, and then a reverse (withdraw) signal.

[0066] FIG. 13 is a diagram showing an example of the class diagram analysis information 613. As shown in FIG. This class diagram analysis information 613 is the result of the large-scale language model 7 analyzing the structured data 612 in response to a prompt instruction. The class diagram analysis information 613 is transcribed below.

[0067] 1. Class diagram analysis results Class: OrderProcessor Purpose: This class is the core of the order processing, creating an order, checking inventory, processing payments, updating inventory, It oversees a series of operations such as sending notifications. Responsibilities: Receive order data from users and apply appropriate business logic. Manages interactions with other system components (e.g., InventoryManager, PaymentGateway, NotificationService). Process flow: Initialize order information with the createOrder() method. Check stock with the checkStock() method. If the required stock is not available, the order process will be aborted. Execute the payment using the processPayment() method. After successful payment, update the inventory data using the updateStock() method. Finally, the sendConfirmation() method sends a confirmation to the customer. Improvement suggestions: Stock check and update processes have been consolidated and code redundancy has been eliminated by adding a new checkAndUpdateStock() method. Direct reference to PaymentGateway class has been made into an interface to reduce dependency.

[0068] The class diagram analysis information 613 allows the static structure of the entire system (class attributes, methods, and relationships) to be understood, and inheritance and dependency relationships to be analyzed, enabling redesign and modularization to be considered.

[0069] FIG. 14 is a diagram showing an example of the sequence diagram analysis information 623. As shown in FIG. This sequence diagram analysis information 623 is the result of the large-scale language model 7 analyzing the structured data 612 in response to a prompt instruction. The sequence diagram analysis information 623 is transcribed below.

[0070] 2. Sequence diagram analysis results Scenario: Order Processing Flow Objective: Manage the order process in an orderly manner until the order is confirmed and notification is sent to the customer. Process flow: The user calls OrderProcessor.createOrder() to generate order data. OrderProcessor calls InventoryManager.checkStock() to check inventory. If the item is in stock, call PaymentGateway.processPayment() to process the payment. After successful payment, call InventoryManager.updateStock() to update the inventory information. Finally, call NotificationService.sendConfirmation() to send the notification to the customer. Problem: checkStock() and updateStock() are called separately, resulting in disconnected processing. Synchronous calls to NotificationService slow down overall performance. Improvement suggestions: Introduces checkAndUpdateStock() method to batch check and update stock. Change notification processing to asynchronous to improve performance.

[0071] This sequence diagram analysis information 623 allows you to understand the dynamic interactions between classes and objects (the order of method calls), check the flow in a specific scenario, and identify error locations and points for improving efficiency. In addition, the analytical information from the flowchart allows you to visualize the flow of algorithms and processes, making it possible to organize complex logic and processing procedures and derive improvement suggestions.

[0072] The analysis information from the component diagram can clarify the dependencies and interfaces between the modules that make up the system, providing a foundation for improving the reusability and modularity of modules. Analysis information from state transition diagrams allows you to understand state changes in systems and objects and the events that accompany them, detect inconsistencies in state transitions, and prevent design omissions.

[0073] FIG. 15 is a diagram showing an example of the integrated report 63. This integrated report 63 is created by the documentation unit 132 integrating the structured data generated by the large-scale language model 7. The integrated report 63 is transcribed below.

[0074] 3. Integrated Report Affected Systems: Overall overview of the order processing system: The order processing system accepts orders from customers, checks inventory, processes payments, It manages the entire process of sending notifications. The design of this system aims to clarify the responsibilities between modules and increase reusability and maintainability. Main components: OrderProcessor: Oversees the entire order processing. Calls each component and manages the flow. InventoryManager: Responsible for checking and updating inventory. PaymentGateway: Responsible for payment processing. NotificationService: Responsible for sending customer notifications. Improvement idea: Code clone reduction: Unify inventory-related logic that is repeatedly called within OrderProcessor. Introducing asynchronous processing: Notification services are now asynchronous, resulting in faster response times. Reduced dependencies: Reduced dependencies between components and introduced interfaces. Expected effects: Reducing redundancy and simplifying code, improving overall system performance. Improved maintainability due to greater independence between modules.

[0075] FIG. 16 is a diagram illustrating the operation of the source code analyzing apparatus 1. When the project file group 3 is input, the static analysis unit 11 executes a source code analysis process on the project file group 3 (step S20). Next, the analysis unit 131 extracts dependencies from the results of the source code analysis process (step S21). After executing step S21, the analysis unit 131 outputs structured data 612 in which a class diagram is described in the DOT language, structured data 622 in which a sequence diagram is described in the DOT language, and structured data 632 in which a flowchart is described in the DOT language. In parallel with the process of extracting the dependency relationships, the analysis unit 131 measures the code metrics and outputs the code metrics information 642 (step S22).

[0076] Next, the large-scale language model 7 analyzes the structured data 612, in which the class diagram is written in the DOT language, based on the class diagram analysis prompt 1221. The class diagram analysis prompt 1221 is a prompt that instructs the model to analyze the structured data 612, examine whether there is room for redesign or modularization, and output the examination results in natural language.

[0077] The large-scale language model 7 analyzes structured data 622, in which a sequence diagram is written in the DOT language, based on a sequence diagram analysis prompt 1222. The sequence diagram analysis prompt 1222 is a prompt that instructs the system to analyze the structured data 622, examine the structured data 622 to identify error locations and points for improving efficiency, and output the examination results in natural language.

[0078] The large-scale language model 7 analyzes structured data 632, in which a flowchart is written in the DOT language, based on a flowchart analysis prompt 1223. The flowchart analysis prompt 1223 is a prompt that instructs the system to analyze the structured data 632, organize complicated logic and processing procedures, and consider ways to derive improvement measures, and then output the results of the consideration in natural language.

[0079] Then, the large-scale language model 7 generates analysis information (step S23) based on the structured data 612, 622, 632 and the code metrics information 65. This analysis information enables the user to propose improvements to the project file group 3, which is source code.

[0080] The documentation unit 132 executes a process of merging and documenting the multiple pieces of analysis information generated in step S23 (step S24), thereby enabling the documentation unit 132 to create the integrated report 63.

[0081] FIG. 17 is a diagram showing the details of the operation of the source code analyzing apparatus 1. First, structured data 612 describing a class diagram in the DOT language and a class diagram analysis prompt 1221 are input to the large-scale language model 7. The large-scale language model 7 outputs class diagram analysis information 613 to the documentation unit 132.

[0082] The structured data 622 in which the sequence diagram is written in the DOT language and the sequence diagram analysis prompt 1222 are input to the large-scale language model 7. The large-scale language model 7 outputs sequence diagram analysis information 623 to the documentation unit 132.

[0083] The structured data 632 in which the flowchart is written in the DOT language and the flowchart analysis prompt 1223 are input to the large-scale language model 7. The large-scale language model 7 outputs flowchart analysis information 633 to the documentation unit 132.

[0084] The code metrics information 642 and the code metrics analysis prompt 1224 are input to the large scale language model 7. The large scale language model 7 outputs code metrics analysis information 643 to the documentation unit 132.

[0085] The documentation unit 132 merges the class diagram analysis information 613 , the sequence diagram analysis information 623 , the flowchart analysis information 633 , and the code metrics analysis information 643 and outputs the integrated report 63 .

[0086] This embodiment solves the problem of token limitations in generative AI by utilizing structured data, a by-product of static analysis tools, in generative AI. This makes software development, especially reverse engineering of legacy systems, easier and is widely applicable to the maintenance and updating of legacy systems.

[0087] Another example of the class diagram analysis information 613 generated by the large-scale language model 7 is transcribed below.

[0088] <answer> 1. System purpose as inferred from the class diagram This class diagram could represent a financial system that manages user accounts and processes transactions. Users own accounts and use those accounts to make transactions. 2. Overall structure of a class diagram - User class: Manage user information - Account class: Manages account information - Transaction class: Manages transaction information Between these classes there exists an ownership relationship (User -> Account) and a usage relationship (Account -> Transaction). 3. Class Roles and Responsibilities - User class: - Retention of user information - Display the username with the display_name method - Account class: - Retention of account information - Deposit using the deposit method - Withdraw using the withdraw method - Transaction class: - Retention of transaction information - Execute the transaction using the execute method - Reverse a transaction with the reverse method 4. Issues and fixes a) From a Single Responsibility Principle (SRP) perspective, it is problematic for the Transaction class to be responsible for both executing and canceling transactions. Fix: Create new TransactionExecutor and TransactionReverser classes to share the responsibilities of execution and cancellation, respectively. b) The relationship between the Account and Transaction classes is not clear. Fix: Add a transactions list to the Account class and set up an aggregation relationship between Account and Transaction. 5. Improvements and work steps after correction Improvement effect: - Separation of responsibilities makes the code more maintainable and extensible. - The relationships between classes are clearer, making the system easier to understand. Work steps: 1. Create a new TransactionExecutor class and a TransactionReverser class 2. Remove the execute and reverse methods from the Transaction class. 3. Add a transactions list to the Account class 4. Update the class diagram to reflect the new relationship. Revised class diagram (conceptual): ``` User -> Account [label="owns"]; Account -> Transaction [label="has many"]; User [label="User"]; Account [label="Account"]; Transaction [label="Transaction"]; TransactionExecutor [label="TransactionExecutor"]; TransactionReverser [label="TransactionReverser"]; User -> display_name [label="method"]; Account -> deposit [label="method"]; Account -> withdraw [label="method"]; Account -> transactions [label="attribute"]; TransactionExecutor -> execute [label="method"]; TransactionReverser -> reverse [label="method"]; ``` This modification gives the system a cleaner structure and better separation of responsibilities for each class. < / answer>

[0089] An example of code metrics analysis information 643 generated by the large-scale language model 7 is transcribed below.

[0090] <answer> - Code clone issues and improvement suggestions There are concerns that duplicated code will reduce maintainability in areas where code clones exist (functions foo() and bar() in file A, MyClass.baz() in file B, and qux() in file C). These are thought to be caused by reimplementation of common functions or careless copying and pasting. Improvement idea: 1. Extract the common part between functions foo() and bar() in file A and extract it as a new function. 2. For MyClass.baz() in file B and qux() in file C, create a common base class or interface to consolidate common logic. - Cohesion issues and improvement suggestions The low cohesion of files A and C means that the functions and classes in these files may have too many responsibilities, which can make the code difficult to understand and modify. Improvement idea: 1. Clarify the responsibilities of each function or class in File A and File C and restructure them to focus on a single purpose. 2. Group related processes and extract them into new classes or modules. 3. Using the high cohesion of file B as a reference, aim for a similar structure for other files. - Coupling issues and improvement suggestions The high coupling between Module 1 and Module 2 (0.8) means that changes in one module may have a significant impact on the other, leading to poor maintainability. Improvement idea: 1. Introduce an interface between Module 1 and Module 2 to reduce the direct dependency. 2. Apply the dependency injection (DI) pattern to loosen the coupling between modules. 3. Create a common abstract class and have both modules inherit from it, reducing coupling while maintaining the necessary relationships. - Complexity issues and improvement suggestions The complexity of foo() in file A and baz() in file C is high, and baz() in particular has a very high complexity. These functions are difficult to understand and modify, and may be a breeding ground for bugs. Improvement idea: 1. Use guard clauses and early returns to simplify conditional branches and loops. 2. Break large functions into multiple smaller functions, each with clear responsibilities. 3. Use polymorphism to replace complex conditional branching with object-oriented design. - Effects and work steps of improvement proposals effect: - Improved code readability and maintainability, reducing the risk of introducing bugs. - Increased functionality reusability improves development efficiency. - It makes testing easier, leading to improved quality. Work steps: 1. Start with the most complex file, baz() in C, and split and refactor the function. 2. Next, we will eliminate code clones, extract common functions, and create reusable components. 3. Clarify responsibilities and reorganize functions to increase cohesion between File A and File C. 4. To reduce the coupling between Module 1 and Module 2, introduce interfaces and review dependencies. 5. Create and run unit tests for each step to ensure that the refactoring does not change functionality. 6. Conduct code reviews to verify the effectiveness of improvements and identify areas for further improvement. By implementing these steps incrementally, you can continuously improve the quality of your software. < / answer>

[0091] The configuration and effects of the present invention as originally claimed will be described below.

[0092] [1] a static analysis unit (11) that analyzes each source code that constitutes a software project using a static analysis tool (2); an analysis unit (131) that analyzes the structured data of the source code analyzed by the static analysis unit (11) and written in a predetermined intermediate language using a large-scale language model based on prompts corresponding to the structured data, and outputs source code analysis information; a documentation unit (132) that creates an integrated report (63) from the source code analysis information; A source code analysis device comprising:

[0093] This makes it possible to expand the size of source code that can be analyzed by a large-scale language model.

[0094] [2] The predetermined intermediate language is the DOT language. 2. The source code analysis device according to claim 1, wherein:

[0095] This allows the contents of the source code to be expressed using structured data with a smaller amount of data.

[0096] [3] The static analysis unit (11) causes the static analysis tool (2) to analyze the source code as a flowchart, and outputs structured data in which the flowchart of the source code is written in a predetermined intermediate language. 2. The source code analysis device according to claim 1, wherein:

[0097] Analysis of structured data allows for analysis of the entire source code.

[0098] [4] The static analysis unit (11) causes the static analysis tool (2) to analyze the source code as a sequence diagram, and outputs structured data in which the sequence diagram of the source code is described in a predetermined intermediate language. 2. The source code analysis device according to claim 1, wherein:

[0099] Analysis of the structured data describing the sequence diagram allows for an analysis of the validity of the sequences executed by the source code.

[0100] [5] The static analysis unit (11) causes the static analysis tool (2) to analyze the source code as a class diagram, and outputs structured data in which the class diagram of the source code is described in a predetermined intermediate language. 2. The source code analysis device according to claim 1, wherein:

[0101] By analyzing the structured data describing the class diagram, it is possible to analyze the validity of the class structure of the entire source code.

[0102] [6] The static analysis unit (11) analyzes code metrics of each of the source codes using the static analysis tool (2) and outputs code metrics information (642) of the source code. 2. The source code analysis device according to claim 1, wherein:

[0103] By analyzing the structured data describing the flowchart, the validity of the process flow of the entire source code can be analyzed.

[0104] [7] The analysis unit (131) analyzes the code metrics information (642) of each of the source codes analyzed by the static analysis unit (11) using a large-scale language model (15) based on a prompt corresponding to the code metrics information (642), and outputs code metrics analysis information (644). 7. The source code analysis device according to claim 6.

[0105] By generating this code metrics analysis information, the user can identify the location of a problem in the quality of the source code based on the code metrics information of the source code.

[0106] [8] The documentation unit (132) further creates an integrated report (63) from the source code analysis information (class diagram analysis information 613, sequence diagram analysis information 623, flowchart analysis information 633) and the code metrics analysis information (643). 7. The source code analysis device according to claim 6.

[0107] By incorporating this code metrics analysis information into the integrated report, the user can determine whether the source code meets a predetermined quality and identify where there are quality problems.

[0108] [9] A step in which a static analysis unit (11) analyzes each source code constituting a software project using a static analysis tool; an analysis unit that analyzes the structured data of the source code analyzed by the static analysis unit (11) and written in a predetermined intermediate language using a large-scale language model based on a prompt corresponding to the structured data, and outputs source code analysis information; A step in which a documentation unit (132) creates an integrated report (63) from the source code analysis information; A source code analysis method comprising:

[0109] This makes it possible to expand the size of source code that can be analyzed by a large-scale language model.

[0110] <<Variation>> The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those including all of the described configurations. It is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is also possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0111] The above-described configurations, functions, processing units, processing means, etc. may be realized in part or in whole by hardware such as an integrated circuit. The above-described configurations, functions, etc. may be realized by software by a processor interpreting and executing a program that realizes each function. Information such as the programs, tables, and files that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or on a storage medium such as a flash memory card or a DVD (Digital Versatile Disk).

[0112] In each embodiment, the control lines and information lines shown are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are interconnected. As modified examples of the present invention, for example, the following (a) to (d) are available.

[0113] (a) The intermediate language of the structured data obtained by analyzing the source code is not limited to the DOT language, but may be XML (eXtended Markup Language), JSON (JavaScript Object Notation), etc. (b) The structured data generated by analyzing the source code is not limited to sequence diagrams, class diagrams, and flowcharts. (c) The large-scale language model 7 may be incorporated into the source code analysis device 1, but is not limited thereto. (d) Depending on the code metrics information, the prompts given to the large-scale language model 7 may be switched. For example, when the number of lines of code is large, the cyclomatic complexity is high, and the coupling and cohesion of classes and functions are high, the prompt for the class diagram may be used to consider detailed class division. [Explanation of symbols]

[0114] 1. Source code analysis device 11 Static analysis section 12 Storage section 13 Information Control Department 14 Document Management Department 2. Static Analysis Tools 3 Project files 7 Large-scale language models 121 Analysis Results Database 122 Prompt Management Department 123 Project File Database 131 Analysis Department 132 Documentation Department 101 CPU 102 memory 103 Mass storage 104 Input / Output Interface 105 Network Interface 107 Documentation Program 522 Large-scale Language Model 51 Project files 52 Analysis process 521 Source Code Snippets 521a Source code snippet 521b Source code snippet 521c Source code snippet 521d Source code snippet 521e Source code snippet 31 Source Code 32 Source Code 33 Source Code 612 Structured Data 622 Structured Data 632 Structured Data 642 Code Metrics Information 611 Class Diagram Images 621 Sequence Diagram Images 613 Class Diagram Analysis Information 623 Sequence Diagram Analysis Information 63 Integrated Report 1221 Class Diagram Analysis Prompts 1222 Sequence Diagram Analysis Prompts 1223 Flowchart Analysis Prompts 1224 Code Metrics Analysis Prompts 613 Class Diagram Analysis Information 623 Sequence Diagram Analysis Information 633 Flowchart Analysis Information 643 Code Metrics Analysis Information< / design> < / answer> < / perspective> < / dotlanguage> < / design> < / answer> < / perspective> < / dotlanguage> < / design> < / answer> < / perspective> < / design> < / answer> < / perspective> < / dotlanguage> < / design> < / answer> < / perspective> < / dotlanguage> < / design> < / answer> < / perspective> < / dotlanguage>

Claims

1. a static analysis unit that analyzes each source code constituting a software project as a flowchart using a static analysis tool and outputs structured data in which the flowchart of the source code is written in a predetermined intermediate language; an analysis unit that analyzes the structured data of the source code analyzed by the static analysis unit and written in a predetermined intermediate language using a large-scale language model based on prompts corresponding to the structured data, and outputs source code analysis information; a documentation unit that creates an integrated report from the source code analysis information; A source code analysis device comprising:

2. a static analysis unit that analyzes each source code constituting a software project as a sequence diagram using a static analysis tool and outputs structured data in which the sequence diagram of the source code is written in a predetermined intermediate language; an analysis unit that analyzes the structured data of the source code analyzed by the static analysis unit and written in a predetermined intermediate language using a large-scale language model based on prompts corresponding to the structured data, and outputs source code analysis information; a documentation unit that creates an integrated report from the source code analysis information; A source code analysis device comprising:

3. a static analysis unit that analyzes each source code constituting a software project as a class diagram using a static analysis tool and outputs structured data in which the class diagram of the source code is written in a predetermined intermediate language; an analysis unit that analyzes the structured data of the source code analyzed by the static analysis unit and written in a predetermined intermediate language using a large-scale language model based on prompts corresponding to the structured data, and outputs source code analysis information; a documentation unit that creates an integrated report from the source code analysis information; Equipped with the static analysis unit causes the static analysis tool to analyze the source code as a class diagram, and outputs structured data in which the class diagram of the source code is described in a predetermined intermediate language. A source code analysis device characterized by:

4. The predetermined intermediate language is the DOT language.

4. The source code analysis device according to claim 1, wherein the source code analysis device is a source code analysis device.

5. the static analysis unit causes the static analysis tool to analyze code metrics of each of the source codes and outputs code metrics information of the source code.

4. The source code analysis device according to claim 1, wherein the source code analysis device is a source code analysis device.

6. the analysis unit analyzes the code metrics information of each of the source codes analyzed by the static analysis unit using a large-scale language model based on a prompt corresponding to the code metrics information, and outputs code metrics analysis information.

6. The source code analysis device according to claim 5.

7. The documentation unit further creates an integrated report from the source code analysis information and the code metrics analysis information.

7. The source code analysis device according to claim 6.

8. a step in which a static analysis unit analyzes each source code constituting a software project as a flowchart to be analyzed by a static analysis tool, and outputs structured data in which the flowchart of the source code is described in a predetermined intermediate language; an analysis unit causing a large-scale language model to analyze the structured data of the source code, which has been analyzed by the static analysis unit and written in a predetermined intermediate language, based on prompts corresponding to the structured data, and outputting source code analysis information; a step of a documentation unit creating an integrated report from the source code analysis information; A source code analysis method comprising:

9. a step in which a static analysis unit causes a static analysis tool to analyze each source code constituting a software project as a sequence diagram, and outputs structured data in which the sequence diagram of the source code is written in a predetermined intermediate language; an analysis unit causing a large-scale language model to analyze the structured data of the source code, which has been analyzed by the static analysis unit and written in a predetermined intermediate language, based on prompts corresponding to the structured data, and outputting source code analysis information; a step of a documentation unit creating an integrated report from the source code analysis information; A source code analysis method comprising:

10. a step in which a static analysis unit causes a static analysis tool to analyze each source code constituting a software project as a class diagram, and outputs structured data in which the class diagram of the source code is described in a predetermined intermediate language; an analysis unit causing a large-scale language model to analyze the structured data of the source code, which has been analyzed by the static analysis unit and written in a predetermined intermediate language, based on prompts corresponding to the structured data, and outputting source code analysis information; a step of a documentation unit creating an integrated report from the source code analysis information; A source code analysis method comprising:

Images