Source code analysis device and source code analysis method

Abstract

Expand the scale of source code that can be analyzed using large-scale language models. [Solution] The source code analysis device 1 comprises a static analysis unit 11 that analyzes each source code constituting a software project with a static analysis tool 2, an analysis unit 131 that analyzes the structured data of the source code, which has been 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 Art

[0002] In recent years, there has been a demand for refactoring that improves the internal structure and operation of existing source code without changing its external input / output specifications. Accordingly, the importance of reverse engineering, which analyzes existing software and systems to understand their structures and functions, is increasing. For reverse engineering, static analysis tools exist that analyze source code without executing the program to measure inter-function relationships and metrics of the source code. Existing static analysis tools analyze software and systems on a rule-based basis.

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

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

[0005] In the technology described in Non-Patent Document 1, the token limitations of the generating AI make it difficult to input the entire source code. Therefore, the technology in Non-Patent Document 1 has the problem that the size of the source code that can be analyzed is small, and only fragmentary analysis is possible for large source codes. Therefore, the present invention aims to increase the scale of source code that can be analyzed by a large-scale language model. [Means for solving the problem]

[0006] To solve the aforementioned problems, the source code analysis device of the present invention is characterized by comprising: a static analysis unit that analyzes each source code constituting a software project with a static analysis tool; an analysis unit that analyzes the structured data of the source code, which has been 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; and a documentation unit that creates an integrated report from the source code analysis information.

[0007] In other words, the source code analysis method of the present invention is characterized by comprising the steps of: a static analysis unit analyzing each source code constituting a software project with a static analysis tool; an analysis unit having a large-scale language model 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; and a documentation unit creating an integrated report from the source code analysis information. Other means will be described within the descriptions of embodiments for carrying out the invention. [Effects of the Invention]

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

[0009] [Figure 1A] This is a logical configuration diagram of the source code analysis device according to this embodiment. [Figure 1B] This is a diagram showing the prompt management unit. [Figure 2] This is a hardware configuration diagram of a source code analysis device. [Figure 3] This figure shows an example of the analysis process for a comparative example. [Figure 4] This diagram illustrates the analysis results of the comparative example. [Figure 5] This is a flowchart of the source code analysis process. [Figure 6] This figure shows an example of source code. [Figure 7] This figure shows an example of source code. [Figure 8] This figure shows an example of source code. [Figure 9] This figure shows an example of structured data where a class diagram is described in the DOT language. [Figure 10] This figure shows an example of structured data where a sequence diagram is described in the DOT language. [Figure 11] This is a diagram showing an example of a class diagram. [Figure 12] This is a diagram showing an example of a sequence diagram. [Figure 13] This is a diagram showing an example of class diagram analysis information. [Figure 14] This is a diagram showing an example of sequence diagram analysis information. [Figure 15] This is a diagram showing an example of an integrated report. [Figure 16] This is a diagram showing the operation of the source code analysis device. [Figure 17] This is a diagram showing the operation of the source code analysis device. [Modes for Carrying Out the Invention]

[0010] Hereinafter, modes for carrying out the present invention will be described in detail with reference to the respective drawings. FIG. 1A is a logical configuration diagram of the source code analysis device 1 according to the present embodiment. FIG. 1B is a diagram showing the prompt management unit 122. 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, with a static analysis tool 2 installed therein. This source code analysis device 1 is a computer equipped with a CPU (Central Processing Unit), and statically analyzes an input group of project files 3 in cooperation with a Large Language Model (LLM) 7. According to the present embodiment, it is possible to expand the analyzable range of the Large Language Model 7 and improve the accuracy of analysis results.

[0011] The static analysis tool 2 is a software program that statically analyzes the group of project files 3 of software on a rule basis. The static analysis unit 11 calls the static analysis tool 2 to cause it to statically analyze the group of project files 3, and receives the structured data described in a language such as the DOT language, which is the analysis result, and code metrics information. The DOT language is a type of data description language, and is a language for representing a graph as a data structure in plain text. The DOT language describes graphs in a simplified format that is easy for computers to process and easy for humans to read. Note that the static analysis tool 2 is not limited to structured data described in the DOT language, and may be data described in a format such as XML (eXtended Markup Language) or JSON (JavaScript Object Notation).

[0012] Here, the code metrics information is an index that quantifies the quality and complexity of software. Specific examples of code metrics information include the number of code lines, cyclomatic complexity, the degree of coupling and the degree of cohesion of classes and functions, and the like. The code metrics information is used for grasping improvement points in refactoring and code analysis.

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

[0014] The storage unit 12 is a storage unit that stores various types of data, and is configured to include 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 DOT language, which is the result of static analysis of the group of project files 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 Figure 1B, the prompt management unit 122 includes prompts for class diagram analysis 1221, sequence diagram analysis 1222, flowchart analysis 1223, code metrics analysis 1224, component diagram analysis 1225, and state transition diagram analysis 1226. Class diagram analysis prompt 1221 is an instruction to have the large-scale language model 7 analyze structured data, which is a class diagram described in the DOT language. The class diagram analysis prompt 1221 is transcribed below.

[0016] The following is written in the DOT language: <dotlanguage>Analyze the diagram within the tag and the following <perspective>Please clarify the content according to the perspectives indicated in the tags. The output format is: <answer>Enclose in tags, <design>Please follow the rules within the tags. <dotlanguage> {{Insert the DOT language description of the structured class diagram here}} < / dotlanguage> <perspective> - Analyze the purpose of the system and explain it to the extent possible. - Clearly define the relationships between classes (inheritance, dependency, aggregation, composition) to organize the software structure. - Analyze whether roles are appropriately divided among the classes and point out any problems. - If there are any violations of the Single Responsibility Principle (SRP), explain the reasons and propose corrective actions. - Identify and suggest any redundant or unified classes, or parts that should be abstracted. - Explain the proposal as a specific example of modification. < / perspective> <design> - The purpose of the system as inferred from the class diagram - Overall structure of the class diagram - Roles and responsibilities for each class - Problems and proposed solutions - Improvements and work steps after the correction < / design>

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

[0018] The following is written in the DOT language: <dotlanguage>Analyze the diagram within the tag and the following <perspective>Please clarify the content according to the perspectives indicated in the tags. The output format is: <answer>Enclose in tags, <design>Please follow the rules within the tags. <dotlanguage> {{Insert the DOT language description of the structured sequence diagram here}} < / dotlanguage> <perspective> - Organize the flow of message exchange and explain the main objects (actors) and their processing order. - Identify bottlenecks and inefficient processing flows, and propose causes and solutions. - Evaluate the appropriateness of exception handling and asynchronous calls. - If there are inconsistencies in the sequence diagram (undefined objects, inconsistent order, etc.), point them out and propose corrections. - Present refactoring proposals (such as rearranging processing or splitting methods) and explain their effects. < / perspective> <design> - Overall flow and structure - Problems and their impact - Proposed revisions and specific examples - Expected effects and implementation procedures after revision < / design>

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

[0020] The following is written in the DOT language: <dotlanguage>Analyze the diagram within the tag and the following <perspective>Please clarify the content according to the perspectives indicated in the tags. The output format is: <answer>Enclose in tags, <design>Please follow the rules within the tags. <dotlanguage> {{Insert structured flowchart description here}} < / dotlanguage> <perspective> - If the purpose of the process is clear, explain it in natural language. - Organize the processing flow (from start to finish) and analyze conditional branching and loop structures. - Identify the complexity of branching and unnecessary steps, and propose simplifications. - If there are exception paths or unresolved states, point them out and suggest solutions. - Evaluate the efficiency of the algorithm and propose optimization options as needed. - Provide specific examples of refactoring and the integration / splitting of processes. < / perspective> <design> - Overview of the purpose of the process - Overview of flow and structure - Problems and suggested improvements - Example of the improved workflow - Expected effects of the correction < / design>

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

[0022] <input> We analyze the code metrics data provided within the tags. <perspective>Please analyze the instructions provided within the tags and propose solutions for improving the software's quality. The output is, <answer>Enclosed in tags, <design>Please follow the tag format. <key-point>Please use the supplementary information within the tags as a point of analysis. <input> # Code clone - File A: Function foo() is 80% identical to function bar() - File B: The method baz() of class MyClass is 95% identical to the method qux() in another file C. # Cohesion - File A: Cohesion level 0.4 (Low) - File B: Cohesion level 0.9 (High) - File C: Cohesion level 0.3 (very low) # degree of coupling - Coupling degree between Module 1 and Module 2: 0.8 (High) - Coupling degree 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 are occurring and propose specific refactoring measures to reduce them (e.g., function extraction, common module creation). # Cohesion - Identify the parts with low cohesion and explain the reasons for this (e.g., dispersion of function roles, mixing of unrelated processes). - Please propose improvements to increase cohesion (function integration, subdivision, modularization). # degree of coupling - Identify areas where the coupling is too high and explain the impact (e.g., reduced maintainability, reduced module independence). - Please provide suggestions for improvements to reduce coupling (e.g., introducing interfaces, reducing dependencies, applying dependency inversion). # Complexity Identify functions with high complexity and explain why those parts are difficult to understand (e.g., numerous conditional statements, nested loops, etc.). - Please suggest refactoring measures to reduce complexity (e.g., introducing guard clauses, early returns, splitting the processing). # The effectiveness of improvement suggestions - Please explain the specific effects of the proposed improvements (e.g., improved maintainability, reduced bugs, improved code reusability). # Work Steps - Please outline the steps for implementing improvements (priorities, phased implementation methods, etc.). < / perspective> <key-point> #Data explanation and key points ## Code Clone - Key points to note: Causes of duplicate code (copy and paste, reimplementation of common functions, etc.), and whether refactoring is feasible (creating common methods, introducing class inheritance, etc.). - Goal: Reduce redundancy and improve maintainability. ## Cohesion - Key point: How well are related processes grouped together within a function or module? Low cohesion can result in a function having to perform too many roles. - Goal: Organize so that each module / class has one clear responsibility. ## Associativity - Key point: If dependencies between modules are too strong, the scope of changes will expand. Introducing interfaces or abstract classes may be effective. - Goal: Explicitly design necessary dependencies while maintaining low coupling. ## Complexity - Key point: Cyclomatic complexity (number of branches and conditional expressions in the control flow) is important; if it is high, function splitting or the introduction of early returns may be necessary. - Goal: Reduce complexity and improve code readability and maintainability. <design> Please output the analysis results in the following format. - Problems with code cloning and suggestions for improvement - Problems with cohesion and suggestions for improvement - Issues with coupling and suggestions for improvement - Problems with complexity and suggestions for improvement - The effects of improvement proposals and the work steps < / design>

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

[0024] The following is written in the DOT language: <dotlanguage>Analyze the diagram within the tag and the following <perspective>Please clarify the content according to the perspectives indicated in the tags. The output format is: <answer>Enclose in tags, <design>Please follow the rules within the tags. <dotlanguage> {{Insert structured description of component diagram here}} < / dotlanguage> <perspective> - Clarify the dependencies and interfaces between components and organize the overall structure. - Identify highly coupled parts and redundant dependencies, and propose ways to reduce them. - Identify components that violate the single responsibility principle and propose redesigns. - Present proposals for division and integration to improve future scalability and ease of modification. - Add any supplementary information regarding constraints or considerations related to external libraries and frameworks. < / perspective> <design> - Organizing the overall structure and dependencies - Problems and their impact - Proposed amendments and their rationale - Expected effects of the revisions and implementation procedures < / design>

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

[0026] The following is written in the DOT language: <dotlanguage>Analyze the diagram within the tag and the following <perspective>Please clarify the content according to the perspectives indicated in the tags. The output format is: <answer>Enclose in tags, <design>Please follow the rules within the tags. <dotlanguage> {{Insert structured description of component diagram here}} < / dotlanguage> <perspective> - Clarify the dependencies and interfaces between components and organize the overall structure. - Identify highly coupled parts and redundant dependencies, and propose ways to reduce them. - Identify components that violate the single responsibility principle and propose redesigns. - Present proposals for division and integration to improve future scalability and ease of modification. - Add any supplementary information regarding constraints or considerations related to external libraries and frameworks. < / perspective> <design> - Organizing the overall structure and dependencies - Problems and their impact - Proposed amendments and their rationale - Expected effects of the revisions and implementation procedures < / design>

[0027] Project file 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 into a large-scale language model 7, enabling it to grasp the entirety of the project file group 3.

[0029] Large-scale language models (GPT-7) are a type of artificial intelligence that uses deep learning to understand and generate natural language based on massive amounts of text data. These models have billions to trillions of parameters that are adjusted during training, allowing them to understand the context of a text and generate appropriate responses and text. Examples of large-scale language models include GPT-3 and GPT-4, which are used for text generation and comprehension.

[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, and then has the large-scale language model 7 analyze it based on prompts corresponding to the structured data, and outputs source code analysis information.

[0031] The documentation unit 132 documents an integrated report that combines the source code analysis information of each project file group 3 using rule-based processing. The documentation unit 132 stores the documented integrated report in the document management unit 14.

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

[0033] The CPU 101 is one or more central processing units that provide overall control for the source code analysis device 1. The memory 102 is a temporary storage device, such as a volatile or non-volatile 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 the keyboard and mouse and output signals to the display. The network interface 105 is an interface for connecting to a network and exchanging information with other devices.

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

[0036] Furthermore, the large-capacity storage device 103 stores various data managed by the source code analysis device 1 and the documentation program 107. The various data managed by the source code analysis device 1 may be stored not within the device itself, but on an external storage device connected via a network.

[0037] Furthermore, the source code analysis device 1 may be implemented as a virtual machine rather than a physical machine. The source code analysis device 1 connects to the equipment or the device that controls the equipment via a network. The source code analysis device 1 may be implemented in a cloud environment. In that case, the source code analysis device 1 is connected via a network to the environment in which the equipment is configured.

[0038] Comparative Example Figure 3 shows an example of the analysis process for a comparative example. Traditionally, source code project files were analyzed manually or using the generative AI GitHub Copilot (registered trademark). Here, we describe the analysis process 52, which analyzes the project files 51 using a large-scale language model 522.

[0039] In the analysis process 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 contained 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. Tokens are the smallest units that make up a sentence, including words themselves, parts of words, symbols, and spaces. Large-scale language models have a limited number of tokens they can process at once; exceeding this limit prevents them from processing the entire input. Furthermore, large-scale language models have a limit on the total amount of input and output information they can process simultaneously. Therefore, the user needs to divide the project files 51 input to the large-scale language model 522 in this comparative example into source code fragments 521 that are less than or equal to the number of tokens that the large-scale language model 522 can process, and repeat the processing.

[0041] Figure 4 illustrates the analysis results of the comparative example. This shows the relationship between the source code fragments 521a-521e targeted by the analysis result 53 and the entire project file group 51. In other words, the conventional analysis process can only analyze fragmentary information. Since these source code fragments 521a-521e also need to be specified by a human, the user needs to have a certain level of understanding of the code.

[0042] Therefore, large-scale language models cannot be efficiently used for reverse engineering for refactoring purposes. Large-scale language models may also perform incorrect analyses. This is because, due to the token size limitations of large-scale language models, it is often impossible to load all the code in the project files.

[0043] Furthermore, projects often define build targets and visibility ranges using configuration files outside of the software itself, resulting in a complex interplay of various pieces of information that are not visible in the code, such as file storage locations.

[0044] This embodiment Figure 5 is a flowchart of the source code analysis process in this embodiment. Initially, the user inputs the software project files 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 images of UML representations and structured data such as DOT files (step S11). Specifically, it generates UML (Unified Modelling Language) diagrams and outputs structured data in 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 relationships within a module. By redesigning low-cohesion modules, it is possible to increase the unity within the module and improve readability and maintainability. Coupling is an indicator that measures the dependencies between modules. By separating highly coupled parts, the flexibility of the system can be increased, and the scope of impact from changes can be reduced.

[0046] Complexity is an index that evaluates the complexity of a function or algorithm. It makes it possible to identify areas with a high risk of errors, 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 to analyze the entire set of project files and perform UML supplementation using natural language representation (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 circumvented, enabling efficient analysis of the software structure and a grasp of the overall structure of the software's project file group 3. Furthermore, by instructing the large-scale language model 7 to detect duplicate code such as code clones, the maintainability of the project file group 3 can be improved by deleting or unifying the duplicate code. 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 from the large-scale language model 7. When the process in step S13 is completed, the process in Figure 5 is finished. After that, the design document is completed through fine-tuning and confirmation by the user.

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

[0050] The documentation process in this embodiment further converts large-scale projects 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 with a large-scale language model. This allows for the avoidance of the token limitations of the large-scale language model, even for relatively large-scale projects, thus enabling a comprehensive understanding of large-scale projects.

[0051] Furthermore, the documentation process in this embodiment combines not only the source code of a large-scale project, but also the structural data of the intermediate language analyzed from it, along with images, enabling users to gain deeper insights.

[0052] Figures 6 through 8 show examples of source code. These source codes belong to the same project file group 3. Figure 6 shows a portion of source code 31, written in the Python language. The filename of source code 31 is "user.py".

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

[0054] By running these source code files 31-33 through static analysis tool 2, the structured data 612 in the DOT language shown in Figure 9 and the structured data 622 in the DOT language shown in Figure 10 are created as a by-product for representation in UML. This allows us to obtain only the necessary information, compressed for each perspective, as text.

[0055] Figure 9 shows an example of structured data 612 in which a class diagram is described in the DOT language. Static analysis tool 2 analyzes source code 31-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 you to obtain only the necessary information, compressed for each perspective, as text.

[0058] Figure 10 shows an example of structured data 622 in the DOT language for a sequence diagram. Static analysis tool 2 analyzes source code 31-33 and outputs this structured data 622. This structured data 622 is transcribed below.

[0059] digraph SequenceDiagram { jobdir =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 you to obtain only the necessary information, compressed for each perspective, as text.

[0061] Figure 11 shows an example of a class diagram image 611. Class diagram image 611 displays the DOT language structured data 612 of the class diagram on the screen.

[0062] In this class diagram image 611, the "User" class is depicted at the top level. The "User" class is related to the "Account" class in terms of ownership and to the "display_name" class in terms of method.

[0063] The "Account" class is related to the "Transaction" and "deposit" classes through a used-by-method relationship, and to the "withdraw" class through a method relationship. The "Transaction" class is related to the "execute" and "reverse" classes in terms of method relationships.

[0064] Figure 12 shows an example of a sequence diagram image 621. Sequence diagram image 621 displays structured data 612, which is a class diagram described in the DOT language, on the screen.

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

[0066] Figure 13 shows an example of class diagram analysis information 613. This class diagram analysis information 613 is the result of the large-scale language model 7 analyzing the structured data 612 according to the prompt's instructions. This class diagram analysis information 613 is transcribed below.

[0067] 1. Analysis results of the class diagram Class: OrderProcessor Objective: This class is central to order processing, handling order creation, inventory checks, payment processing, and inventory updates. It oversees a series of operations, including sending notifications. Responsibilities: Receive order data from users and apply appropriate business logic. Manages integration with other system components (e.g., InventoryManager, PaymentGateway, NotificationService). Processing flow: The `createOrder()` method is used to initialize the order information. The checkStock() method is used to check inventory. If the required inventory is not available, the order processing is interrupted. The payment is executed using the processPayment() method. After the payment is successful, the inventory data is updated using the updateStock() method. Finally, a confirmation notification is sent to the customer using the sendConfirmation() method. Improvement suggestions: By integrating inventory check and update processes and creating a new method, checkAndUpdateStock(), code redundancy is eliminated. Direct references to the PaymentGateway class have been replaced with interfaces, reducing dependencies.

[0068] The class diagram analysis information 613 allows you to understand the static structure of the entire system (class attributes, methods, and relationships), analyze inheritance and dependencies, and consider redesign or modularization.

[0069] Figure 14 shows an example of sequence diagram analysis information 623. This sequence diagram analysis information 623 is the result of the large-scale language model 7 analyzing the structured data 612 according to the prompt's instructions. This sequence diagram analysis information 623 is transcribed below.

[0070] 2. Analysis results of the sequence diagram Scenario: Order Processing Flow Objective: To systematically manage the process from order confirmation to sending a notification to the customer. Processing flow: The user calls OrderProcessor.createOrder() to generate order data. The OrderProcessor calls InventoryManager.checkStock() to check the inventory. If the item is in stock, the payment process is executed by calling PaymentGateway.processPayment(). After the payment is successful, InventoryManager.updateStock() is called to update the inventory information. Finally, call NotificationService.sendConfirmation() to send a notification to the customer. Problem: The checkStock() and updateStock() methods are called separately, resulting in a fragmented process. Synchronous calls to NotificationService are degrading overall performance. Improvement suggestions: The `checkAndUpdateStock()` method has been introduced to process inventory checks and updates in a batch. We will improve performance by changing the notification process to asynchronous.

[0071] This sequence diagram analysis information 623 allows us 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 areas for improvement. Furthermore, the analysis information from flowcharts allows for the visualization of algorithms and process flows, enabling the organization of complex logic and processing procedures and the development of improvement proposals.

[0072] By analyzing component diagrams, the dependencies and interfaces between the modules that make up a system can be clarified, providing a foundation for improving the reusability and modularity of modules. By analyzing state transition diagrams, it is possible to understand the state changes of systems and objects and the events associated with them, detect inconsistencies in state transitions, and prevent design omissions.

[0073] Figure 15 shows an example of an integrated report 63. This integrated report 63 is the result of the documentation unit 132 integrating the structured data generated by the large-scale language model 7. The integrated report 63 is reproduced below.

[0074] 3. Integrated Report Target systems: Order Processing System Overview: The order processing system receives orders from customers, checks inventory, processes payments, and more. It manages the entire flow up to the point of sending notifications. The design of this system aims to clarify the responsibilities between modules and improve reusability and maintainability. Main components: OrderProcessor: Oversees the entire order processing. Calls each component and manages the flow. Inventory Manager: Responsible for checking and updating inventory. PaymentGateway: Responsible for payment processing. NotificationService: Responsible for sending customer notifications. Improvement idea: Reduced code cloning: Unified inventory-related logic that is repeatedly called within OrderProcessor. Introduction of asynchronous processing: By making the notification service asynchronous, response times are reduced. Dependency Reduction: Reduce the dependency between components and introduce interfaces. Expected effects: Simplifying code by eliminating redundancy. Improving overall system performance. Improved maintainability through increased independence between modules.

[0075] Figure 16 shows the operation of the source code analysis device 1. When the static analysis unit 11 receives the project file group 3 as input, it performs source code analysis on the project file group 3 (step S20). Next, the analysis unit 131 extracts the dependencies from the source code analysis results (step S21). When step S21 is executed, the analysis unit 131 outputs structured data 612 describing a class diagram in DOT language, structured data 622 describing a sequence diagram in DOT language, and structured data 632 describing a flowchart in DOT language. The analysis unit 131 measures code metrics in parallel with the dependency extraction process and outputs code metrics information 642 (step S22).

[0076] Next, the large-scale language model 7 analyzes the structured data 612, which describes class diagrams 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, consider whether there is room for redesign or modularization, and output the results of that consideration in natural language.

[0077] The large-scale language model 7 analyzes structured data 622, which describes sequence diagrams in the DOT language, based on sequence diagram analysis prompts 1222. The sequence diagram analysis prompts 1222 are prompts that instruct the model to analyze the structured data 622, consider identifying error locations and areas for improvement, and output the results of that consideration in natural language.

[0078] The large-scale language model 7 analyzes structured data 632, which is a flowchart described in the DOT language, based on flowchart analysis prompts 1223. The flowchart analysis prompts 1223 are prompts that instruct the model to analyze the structured data 632, consider organizing complex logic and processing procedures to derive improvement measures, and output the results of that consideration in natural language.

[0079] Then, the large-scale language model 7 generates analysis information based on these structured data 612,622,632 and code metrics information 65 (step S23). Based on this analysis information, the user can suggest improvements to the project files 3, which are the source code.

[0080] The documentation unit 132 performs a process to merge and document the multiple analysis information generated in step S23 (step S24). This allows the documentation unit 132 to create the integrated report 63.

[0081] Figure 17 shows the details of the operation of the source code analysis device 1. Initially, the structured data 612, which describes the class diagram in DOT language, and the class diagram analysis prompt 1221 are input to the large-scale language model 7. The large-scale language model 7 outputs the class diagram analysis information 613 to the documentation unit 132.

[0082] The structured data 622, which describes the sequence diagram in 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 the sequence diagram analysis information 623 to the documentation unit 132.

[0083] Structured data 632, which describes the flowchart in DOT language, and flowchart analysis prompts 1223 are input to the large-scale language model 7. The large-scale language model 7 outputs the 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 the 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 to output an integrated report 63.

[0086] This embodiment solves the token limitation problem in generative AI by utilizing structured data, a byproduct of static analysis tools, in generative AI. This facilitates software development, particularly reverse engineering of legacy systems, and is widely applicable to the maintenance and updating of legacy systems.

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

[0088] <answer> 1. The purpose of the system as inferred from the class diagram This class diagram can be seen as representing a financial system that manages user accounts and processes transactions. The structure is such that users own accounts and use those accounts to conduct transactions. 2. Overall structure of the class diagram - User class: Manages user information - Account Class: Manages account information - Transaction Class: Manages transaction information There are ownership relationships (User -> Account) and usage relationships (Account -> Transaction) between these classes. 3. Roles and responsibilities for each class - User class: - Retention of user information - Displaying the username using the display_name method - Account Class: - Retention of account information - Deposit processing using the deposit method - Withdrawal process using the withdraw method - Transaction Class: - Retention of transaction information - Execute a transaction using the execute method - Reverse the transaction using the reverse method 4. Problems and proposed solutions a) From the perspective of the Single Responsibility Principle (SRP), it is problematic for the Transaction class to be responsible for both executing and canceling a transaction. Proposed fix: Create new TransactionExecutor and TransactionReverser classes, assigning them the responsibilities of execution and cancellation, respectively. b) The relationship between the Account class and the Transaction class is unclear. Proposed fix: Add a transactions list to the Account class and establish an aggregation relationship between Account and Transaction. 5. Improvement effects and work steps after correction Improvement effect: - Separation of responsibilities improves the maintainability and extensibility of the code. - Relationships between classes become clearer, making it easier to understand the system. Work steps: 1. Create new TransactionExecutor and TransactionReverser classes. 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 relationships. 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 clarifies the system structure and properly separates the responsibilities of each class. < / answer>

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

[0090] <answer> - Problems with code cloning and suggestions for improvement The areas where code cloning has occurred (functions foo() and bar() in file A, MyClass.baz() in file B, and qux() in file C) raise concerns about reduced maintainability due to duplicate code. These are thought to be caused by the reimplementation of common functions or careless copy-pasting. Improvement idea: 1. Extract the common parts of functions foo() and bar() in file A and separate them into 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. - Problems with cohesion and suggestions for improvement The low cohesion between files A and C suggests that functions and classes within these files may be taking on too many roles. This could make understanding and modifying the code difficult. Improvement idea: 1. Clarify the responsibilities of each function and class in File A and File C, and restructure them to focus on a single purpose. 2. Group related processes together and extract them as new classes or modules. 3. Using the high cohesion of File B as a reference, aim for a similar structure in other files. - Issues with coupling and suggestions for improvement The high coupling between Module 1 and Module 2 (0.8) means that changes in one module could have a significant impact on the other, leading to reduced maintainability. Improvement idea: 1. Introduce an interface between Module 1 and Module 2 to reduce direct dependencies. 2. Apply dependency injection (DI) patterns to loosen the coupling between modules. 3. Create a common abstract class, and both modules will inherit from it, reducing coupling while maintaining necessary relationships. - Problems with complexity and suggestions for improvement The functions foo() in file A and baz() in file C are highly complex, with baz() being particularly complex. These functions are difficult to understand and modify and can be breeding grounds for bugs. Improvement idea: 1. To simplify conditional branching and loops, introduce guard clauses and early returns. 2. Divide a large function into several smaller functions and clearly define the responsibilities of each. 3. Leverage polymorphism to replace complex conditional branching with object-oriented design. - The effects of improvement proposals and the work steps effect: - Code readability and maintainability are improved, and the risk of bugs is reduced. - Functionality becomes more reusable, improving development efficiency. - Testing becomes easier, leading to improved quality. Work steps: 1. Start with the most complex file, file C, specifically the baz() function, and perform function splitting and refactoring. 2. Next, we will eliminate code clones and proceed with extracting common functions and creating reusable components. 3. To increase the cohesion between File A and File C, responsibilities will be clarified and functions will be reorganized. 4. To reduce the coupling between Module 1 and Module 2, implement interfaces and review dependencies. 5. Create and run unit tests for each step to ensure that there are no functional changes due to the refactoring. 6. Conduct a code review to verify the effectiveness of the improvements and identify areas for further improvement. By implementing these steps in a step-by-step manner, you can continuously improve the quality of your software. < / answer>

[0091] The configuration of the present invention as described in the original claims and its effects are explained below.

[0092] [1] A static analysis unit (11) analyzes each source code that makes up the software project using a static analysis tool (2), The static analysis unit (11) analyzes the structured data of the source code, which is written in a predetermined intermediate language, and the analysis unit (131) analyzes the structured data based on prompts corresponding to the structured data, and outputs source code analysis information. A documentation unit (132) creates an integrated report (63) from the source code analysis information, A source code analysis device characterized by being equipped with the following features.

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

[0094] [2] The aforementioned predetermined intermediate language is the DOT language. The source code analysis apparatus according to feature 1.

[0095] This allows the contents of the source code to be represented 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. The source code analysis apparatus according to feature 1.

[0097] Structured data analysis allows for the 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. The source code analysis apparatus according to feature 1.

[0099] By analyzing the structured data used to describe sequence diagrams, it is possible to analyze the validity of sequences that operate using 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. The source code analysis apparatus according to feature 1.

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

[0102] [6] The static analysis unit (11) analyzes the code metrics of each source code using the static analysis tool (2) and outputs the code metrics information (642) of the source code. The source code analysis apparatus according to feature 1.

[0103] By analyzing structured data that describes flowcharts, it is possible to analyze the validity of the overall processing flow of the source code.

[0104] [7] The analysis unit (131) analyzes the code metrics information (642) of each source code analyzed by the static analysis unit (11) by having the large-scale language model (15) analyze it based on prompts corresponding to the code metrics information (642), and outputs code metrics analysis information (644). The source code analysis apparatus according to feature 6.

[0105] By generating this code metrics analysis information, users can identify areas of source code that have quality issues based on the source code metrics data.

[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). The source code analysis apparatus according to feature 6.

[0107] By incorporating this code metrics analysis information into an integrated report, users can determine whether the source code meets the required quality standards and identify areas where quality issues exist.

[0108] [9] The static analysis unit (11) performs the step of analyzing each source code that makes up the software project using a static analysis tool, The static analysis unit (11) analyzes the structured data of the source code, which is written in a predetermined intermediate language. The analysis unit then has a large-scale language model analyze the structured data based on prompts corresponding to the structured data, and outputs source code analysis information. The documentation unit (132) creates an integrated report (63) from the source code analysis information, A source code analysis method characterized by having the following features.

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

[0110] Variant form The present invention is not limited to the embodiments described above, and includes various modifications. For example, the embodiments described above are described in detail to make the present invention easier to understand, and are not necessarily limited to those having all the configurations described. It is possible to replace parts of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add configurations from other embodiments to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations.

[0111] Each of the above configurations, functions, processing units, and processing means may be implemented in part or in whole by hardware, such as an integrated circuit. Each of the above configurations and functions may also be implemented in software by a processor interpreting and executing a program that implements each function. Information such as programs, tables, and files that implement each function can be stored in a recording device such as memory, a hard disk, or an SSD (Solid State Drive), or on a recording 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 deemed necessary for explanation and do not necessarily represent all control lines and information lines in the actual product. In practice, it can be assumed that almost all components are interconnected. Examples of modified versions of the present invention include the following (a) to (d).

[0113] (a) The intermediate language for the structured data obtained from analyzing the source code is not limited to the DOT language, but may also be XML (eXtended Markup Language), JSON (JavaScript Object Notation), etc. (b) Structured data derived from source code analysis is not limited to sequence diagrams, class diagrams, or flowcharts. (c) The large-scale language model 7 may, but is not limited to, be incorporated into the source code analysis device 1. (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 class diagram prompt may be used to prompt the model to consider class division in detail. [Explanation of symbols]

[0114] 1. Source code analysis device 11 Static analysis section 12 Storage section 13 Information Control Unit 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 Interfaces 105 Network Interfaces 107 Documentation Program 522 Large-scale language models 51 Project File Sets 52 Analysis process 521 Source Code Snippets 521a Source code fragment 521b Source code fragment 521c Source code fragment 521d Source code fragment 521e Source code fragment 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 Image 621 Sequence diagram image 613 Class Diagram Analysis Information 623 Sequence Diagram Analysis Information 63 Integrated Report 1221 Prompt for class diagram analysis 1222 Prompt for sequence diagram analysis 1223 Prompt for flowchart analysis 1224 Prompt for Code Metrics Analysis 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. The static analysis unit analyzes each source code that makes up the software project using static analysis tools, An analysis unit analyzes the structured data of the source code, which has been analyzed by the static analysis unit and written in a predetermined intermediate language, and then has a large-scale language model analyze it based on prompts corresponding to the structured data, and outputs source code analysis information. A documentation unit that creates an integrated report from the aforementioned source code analysis information, A source code analysis device characterized by being equipped with the following features.

2. The aforementioned predetermined intermediate language is the DOT language. The source code analysis apparatus according to feature 1.

3. The static analysis unit causes the static analysis tool 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. The source code analysis apparatus according to feature 1.

4. The static analysis unit causes the static analysis tool 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. The source code analysis apparatus according to feature 1.

5. 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. The source code analysis apparatus according to feature 1.

6. The static analysis unit analyzes the code metrics of each source code using the static analysis tool and outputs the code metrics information of the source code. The source code analysis apparatus according to feature 1.

7. The analysis unit analyzes the code metrics information of each source code analyzed by the static analysis unit, causes a large-scale language model to analyze the code metrics information based on prompts corresponding to the code metrics information, and outputs code metrics analysis information. The source code analysis apparatus according to feature 6.

8. The documentation unit further creates an integrated report from the source code analysis information and the code metrics analysis information. The source code analysis apparatus according to feature 7.

9. The static analysis unit performs the step of analyzing each source code that makes up the software project using a static analysis tool, The static analysis unit analyzes the structured data of the source code, which has been analyzed and written in a predetermined intermediate language. The analysis unit then has a large-scale language model analyze the structured data based on prompts corresponding to the structured data, and outputs source code analysis information. The documentation department creates an integrated report from the source code analysis information, A source code analysis method characterized by having the following features.

Images