Software design information recovery system, its control method, and program

Abstract

This invention provides a software design information recovery system, a control method thereof, and a program that can suppress hallucination in large-scale language models to accurately recover design information from source code, and provide a basis for deriving performance target values ​​in subsequent conversion and generation processes. [Solution] System 2010 comprises a single source analysis unit that extracts static information, an inference unit that infers the design intent and processing overview of a source file, a verification unit that verifies the design intent and processing overview generated by the inference unit, an integration unit that stores the design intent and processing overview as an intermediate representation of the current state in a design information infrastructure, a multi-source summary analysis unit that integrates the relationships and call graphs of multiple source files constituting the target software into the design information infrastructure, and a static performance indicator extraction unit that extracts static performance indicators.

Description

Technical Field

[0001] The present invention relates to a software design information restoration system, its control method, and a program.

Background Art

[0002] Patent Document 1 describes an apparatus for generating a technical document of software. This apparatus determines a code path from repository information regarding a repository in which source code is managed, requests a generation AI model to generate a technical document corresponding to the code, and performs a process of storing the generated technical document.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The apparatus described in Patent Document 1 above generates a technical document using a generation AI model. However, there is a risk of hallucination in which non-existent APIs or functions are described in the output of a large language model, and it is difficult for a large language model alone to automatically derive the target values of non-functional requirements required for the code after conversion / generation. Therefore, it becomes difficult to accurately automatically restore the design information of software and link it to subsequent processes.

[0005] This disclosure has been made to solve the above problems, and aims to provide a software design information restoration system, its control method, and a program that can suppress hallucination of a large language model and accurately restore design information from source code, and can provide a basis for deriving performance target values in subsequent conversion / generation processes.

Means for Solving the Problems

[0006] To achieve the above objectives, the software design information recovery system disclosed below is a software design information recovery system for recovering software design information. The software design information recovery system includes: a single source analysis unit that performs syntactic analysis on a single source file constituting the target software, generates an abstract syntax tree corresponding to the source file, and extracts syntactically parseable static information, including at least the number of instructions, the number of branches, and call relationships, on a function or paragraph basis within the source file; an inference unit that applies inference using a large-scale language model to the single source file and generates a design intent indicating the purpose of the processing that the source file aims to realize and a processing overview summarizing the operation of the source file; a verification unit that compares the design intent and processing overview generated by the inference unit with the abstract syntax tree output by the single source analysis unit to verify whether at least one of the function name, argument structure, return type, and call relationships included in the design intent and processing overview logically corresponds to a node corresponding to the abstract syntax tree; a first design information layer that stores the results of analyzing the current structure of the target software; and software A design information infrastructure having a second design information layer that stores a conversion generation target including the target programming language, target execution environment, and performance requirements after conversion or generation of A, and a conversion generation strategy including the conversion rules, conversion order, and constraints to be applied, and a third design information layer that stores design information of the software system after conversion or generation of the software, comprising: an integration unit that stores the design intent and the processing overview, whose logical correspondence has been confirmed by the verification unit, as an intermediate representation of the current state in the first design information layer; a multiple source summary analysis unit that analyzes dependencies across multiple source files constituting the target software, derives relationships between modules and a call graph, and integrates the relationships and the call graph into the first design information layer; and a static performance indicator extraction unit that extracts a static performance indicator including at least one of cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses during the syntactic analysis process by the single source analysis unit.The estimated number of database accesses includes the number of code locations where, after retrieving a parent record, an inefficient access pattern is observed through static analysis, in which a database query for retrieving child records is repeatedly issued for each parent record.

[0007] Furthermore, the control method for the software design information restoration system disclosed below is a control method for a software design information restoration system that restores software design information. The control method performs syntactic analysis on a single source file constituting the target software, generates an abstract syntax tree corresponding to the source file, extracts syntactically parseable static information including at least the number of instructions, the number of branches, and call relationships for each function or paragraph in the source file, applies inference using a large-scale language model to the single source file, generates a design intent indicating the purpose of the processing that the source file aims to realize and a processing summary summarizing the operation of the source file, compares the generated design intent and processing summary with the abstract syntax tree to verify whether at least one of the function name, argument structure, return type, and call relationships included in the design intent and processing summary logically corresponds to a node corresponding to the abstract syntax tree, and stores the results of the analysis of the current structure of the target software in a first design information layer, and a conversion generation including the target programming language, target execution environment, and performance requirements after the conversion or generation of the software. In a design information infrastructure having a second design information layer that stores the objective, the transformation rules to be applied, the transformation order, and the transformation generation strategy including constraints, and a third design information layer that stores the design information of the software system after the transformation or generation of the software, the first design information layer stores the design intent and the processing overview for which a logical correspondence has been confirmed as an intermediate representation of the current state, analyzes dependencies across multiple source files constituting the target software, derives the relationships between modules and the call graph, integrates the relationships and the call graph into the first design information layer, and extracts static performance metrics that include at least one of the following during the parsing process: cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses, which includes the number of code locations where an inefficient access pattern of repeatedly issuing database queries for obtaining child records for each parent record after obtaining the parent record is recognized in static analysis.

[0008] Furthermore, the program disclosed below includes: a single source analysis process that performs syntactic analysis on a single source file constituting the target software on the processor of an information processing device, generates an abstract syntax tree corresponding to the source file, and extracts syntactically parseable static information, including at least the number of instructions, the number of branches, and call relationships, on a function or paragraph basis within the source file; an inference process that applies inference using a large-scale language model to the single source file and generates a design intent indicating the purpose of the processing that the source file aims to realize and a processing overview summarizing the operation of the source file; a verification process that compares the design intent and processing overview generated by the inference process with the abstract syntax tree to verify whether at least one of the function name, argument structure, return type, and call relationships included in the design intent and processing overview logically corresponds to a node corresponding to the abstract syntax tree; a first design information layer that stores the results of analyzing the current structure of the target software; and the target programming language, target execution environment, etc., after conversion or generation of the software. In a design information infrastructure having a second design information layer that stores a conversion generation goal including performance requirements, a conversion generation strategy including applicable conversion rules, conversion order, and constraints, and a third design information layer that stores design information of the software system after conversion or generation of the software, the following are performed: an integration process that stores the design intent and processing overview, for which a logical correspondence has been confirmed, as an intermediate representation of the current state in the first design information layer; a multiple source summary analysis process that analyzes dependencies across multiple source files constituting the target software, derives relationships between modules and a call graph, and integrates the relationships and the call graph into the first design information layer; and a static performance indicator extraction process that extracts static performance indicators, including at least one of the following during the syntactic analysis: cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses, including the number of code locations where an inefficient access pattern of repeatedly issuing database queries for obtaining child records for each parent record after obtaining the parent record is recognized in static analysis. [Effects of the Invention]

[0009] The above configuration suppresses hallucination in large-scale language models, enabling accurate recovery of design information from source code, and provides a basis for deriving performance target values ​​in subsequent transformation and generation processes by extracting static performance metrics. [Brief explanation of the drawing]

[0010] [Figure 1A] Figure 1A is a schematic diagram showing the configuration of the software conversion generation system 10 in the first embodiment. [Figure 1B] Figure 1B is a schematic diagram showing the configuration of the software conversion generation system 10 in the first embodiment. [Figure 2] Figure 2 is a flowchart showing the processing of the IR chain 200 in the first embodiment. [Figure 3] Figure 3 is a block diagram showing the configuration of the design information infrastructure 300. [Figure 4] Figure 4 is a diagram illustrating the operation of the scoring processing unit 403. [Figure 5] Figure 5 is a diagram illustrating the feedback flow 500. [Figure 6] Figure 6 is a diagram illustrating the asset registry structure 600. [Figure 7] Figure 7 shows a stepwise transition structure 700 using the Strangler Fig pattern. [Figure 8] Figure 8 is a block diagram showing the configuration of GPS Vector 800. [Figure 9] Figure 9 is a block diagram showing the configuration of the system vector 900. [Figure 10] Figure 10 is a conceptual diagram illustrating the six process paths. [Figure 11A] Figure 11A shows an overview of screen transitions 1100 in the UI server 130. [Figure 11B] Figure 11B shows the screen layout of the analysis results dashboard. [Figure 11C] FIG. 11C is a diagram showing the configuration of the quality issue list screen. [Figure 11D] FIG. 11D is a diagram showing the configuration of the traceability display screen. [Figure 11E] FIG. 11E is a diagram showing the configuration of the issue selection type conversion parameter screen. [Figure 11F] FIG. 11F is a diagram showing the screen transition of the administrator console. [Figure 11G] FIG. 11G is a diagram showing the screen configuration of the dynamic viewer. [Figure 11H] FIG. 11H is a diagram showing the screen transition of the modernization workflow. [Figure 12] FIG. 12 is a diagram showing the conversion dictionary system 1200. [Figure 13] ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ [Figure 24] Figure 24 is a diagram illustrating the processing of the forced resolution verification unit 2334. [Figure 25] Figure 25 is a diagram illustrating the processing of the missing code completion code generation pre-determination unit 2333. [Figure 26] Figure 26 is a schematic diagram of screen transitions. [Figure 27] Figure 27 shows an example of a screen displayed on the display unit of the user terminal 20. [Figure 28] Figure 28 shows an example of a screen displayed on the display unit of the user terminal 20. [Figure 29] Figure 29 shows an example of a screen displayed on the display unit of the user terminal 20. [Figure 30] Figure 30 shows an example of a screen displayed on the display unit of the user terminal 20. [Figure 31] Figure 31 shows an example of a screen displayed on the display unit of the user terminal 20. [Figure 32] Figure 32 shows an example of a screen displayed on the display unit of the user terminal 20. [Figure 33] Figure 33 shows an example of a screen displayed on the display unit of the user terminal 20. [Figure 34] Figure 34 shows an example of a screen displayed on the display unit of the user terminal 20. [Figure 35] Figure 35 shows an example of a screen displayed on the display unit of the user terminal 20. [Figure 36] Figure 36 is a diagram illustrating the processing of the design change approval unit 2336. [Figure 37] Figure 37 is a functional block diagram of System 2010. [Figure 38] Figure 38 is a diagram illustrating the screen displayed on the display unit of the user terminal 20. [Figure 39] Figure 39 is a diagram illustrating the conversion path. [Modes for carrying out the invention]

[0011] One embodiment of the present invention will be described below with reference to the drawings. Note that the present invention is not limited to the following embodiments, and design modifications can be made as appropriate within the scope of satisfying the configuration of the present invention. Furthermore, in the following description, the same reference numerals are used in common across different drawings for the same parts or parts having similar functions, and repeated explanations are omitted. Also, the configurations described in the embodiments and modifications may be combined or modified as appropriate. Furthermore, in order to make the explanation easier to understand, the configurations in the drawings referenced below are simplified or schematic, and some components are omitted.

[0012] [1. Overall configuration of the software conversion and generation system 10] Figures 1A and 1B are schematic diagrams showing the configuration of the software conversion and generation system 10 in the first embodiment. In this specification, "software conversion and generation" means converting a software system to operate on a target platform, generating a new software system for the target platform, or doing both. Hereinafter, when simply referred to as "conversion and generation," it means a concept that encompasses conversion, generation, or both conversion and generation. That is, the software conversion and generation system 10 is a system that generates and converts a software system to operate on a target platform. In this disclosure, "system" can employ any known hardware configuration (control circuits, memory circuits, and networks, etc.) other than those shown below. The control circuit includes a processor that executes each control process based on a program.

[0013] As shown in Figure 1A, the software conversion generation system 10 of the first embodiment includes a general management server 110, an analysis server 120, a UI server 130, an AI server 140, a relational database server 150, a document database server 160, an integrated knowledge base server 170, a message queue server 180, a storage server 190, and a dedicated design information infrastructure server 195. In the figure, "database" is abbreviated as "DB".

[0014] The integrated management server 110 performs orchestration of the entire system and oversees the issuance of analysis tasks, progress management of IR (Intermediate Representation) generation, quality gate judgment, approval control, initiation of feedback loops, and reprocessing instructions. Here, "quality gate" refers to a mechanism that performs pass / fail judgments on conversion generation results or analysis results based on predetermined quality standards. Quality gates may include judgments regarding functional accuracy, security robustness, and structural soundness, as well as judgments regarding analysis completeness score and object quality score. The integrated management server 110 may execute processing instructions to each server, for example, via a REST API, and for analysis tasks, quality feedback tasks, and reprocessing tasks requiring asynchronous execution, instructions may be issued via the message queue server 180.

[0015] The analysis server 120 analyzes the document and generates concrete syntax trees, abstract syntax trees, metadata, analysis data, and test information from the core assets (see Figure 14). The analysis server 120 is equipped with a group of parsers that support multiple programming languages ​​and integrates embedded languages ​​and related objects for analysis as needed. Here, "document" refers to source code files, design documents, requirements definitions, specifications, data definitions, screen definitions, configuration management information, API specifications, test specifications, operation procedures, or equivalent electronic data, and may include not only code snippets written in a programming language but also peripheral information useful for interpreting those code snippets. Furthermore, "core assets" refers to intermediate deliverables generated in the software conversion generation process and includes concrete syntax trees, abstract syntax trees, metadata, analysis data, test information, and design information (6 core asset elements).

[0016] The analysis server 120 may support, for example, 67 or more programming languages, and may have a configuration that combines a common analysis platform for each language family with analysis modules specific to each language. The analysis server 120 may perform detection of control flow graphs, data flow graphs, dependencies, metrics, and embedded language patterns. In detecting embedded language patterns, the boundary between the host language and the guest language may be identified, a syntax tree may be generated independently for each language, and then the dependencies between the two may be integrated. For example, SQL in COBOL, HTML in Java, or template descriptions in scripts may be treated as such embedded languages.

[0017] The UI server 130 provides a user interface and offers functions such as project registration, analysis condition setting, intermediate expression review, approval or rejection, quality report confirmation, and asset registry (asset management ledger) viewing. The UI server 130 may also include a quality issue list screen, a traceability display screen, an issue selection type conversion parameter screen, an administrator console, and multiple types of dynamic viewers.

[0018] The AI ​​server 140 is a platform for running multiple specialized AI agents, and it performs inference processing, knowledge extraction processing, quality evaluation processing, and improvement suggestion processing by integrating a large-scale language model and graph-based search extension generation (GraphRAG). Here, "AI agent" refers to a software program that provides answers to the user in order to satisfy the user's requests by repeatedly performing input and output on behalf of the user to the artificial intelligence system 30. Multiple specialized AI agents run by the AI ​​server 140 may use graph-based search extension generation as a common platform. Graph-based search extension generation may include, for example, the steps of (i) extracting graph patterns from input queries and searching the graph database 401 (see Figure 4), (ii) semantically extending the acquired subgraphs using a vector database 402, and (iii) inputting the extended context into a large-scale language model and performing inference.

[0019] The relational database server 150 constitutes at least a part of the language master database and stores syntax rules, semantic definitions, inter-language correspondences, type mappings, and management information for multiple programming languages. Here, "language master database" refers to a database that structures and manages the syntax rules, semantic definitions, and inter-language correspondences for multiple programming languages.

[0020] The document database server 160 constitutes a document database and stores analysis results, intermediate representation documents, design support documents, conversion dictionary support information, and improvement suggestion documents in an unstructured format. An "unstructured format" is a data format that does not have a predefined fixed data structure (row and column format), like a table in a relational database (RDB).

[0021] The integrated knowledge base server 170 includes a graph database 401 (see Figure 4) and a vector database 402 (see Figure 4), which manage the graph structure and vector embedding representations of transformation rules. The graph database 401 and vector database 402 provided by the integrated knowledge base server 170 constitute an integrated knowledge base that stores information on the characteristics of multiple programming languages ​​(including syntax rules, transformation patterns, semantic definitions, and their embedding representations). Here, "integrated knowledge base" refers to a logical knowledge base that includes at least the graph database 401 and the vector database 402, and which, as necessary, cooperates with a language master database and a document database.

[0022] The software conversion generation system 10 includes an intermediate representation generation unit 1, a conversion generation processing unit 2, and a scoring processing unit 403, by executing the program in the server described above. The intermediate representation generation unit 1 generates a first intermediate representation while referring to the integrated knowledge base. The scoring processing unit 403 performs structural and semantic searches on the integrated knowledge base and uses the results to determine the conversion generation pattern. The scoring processing unit 403 may be configured as part of the intermediate representation generation unit 1.

[0023] The message queue server 180 provides a message queue for asynchronously executing analysis tasks, quality feedback tasks, and reprocessing tasks.

[0024] Storage server 190 holds the documents to be converted, related files, generated products, validation results, and assets for the sandbox execution environment.

[0025] The Design Information Infrastructure Server 195 is a dedicated computing node that implements the Design Information Infrastructure 300 and is equipped with a Design Information Tree (DIT) dedicated graph database and a DIT dedicated vector database. The Design Information Infrastructure Server 195 manages the current structure before transformation, the transformation plan, the transformed design information, and the transformation generation history information in a hierarchical and chronological manner.

[0026] Here, the design information infrastructure 300 (see Figure 2) has a first design information layer 301 that stores the results of analyzing the current structure of the software to be transformed and generated, a second design information layer 302 that stores the transformation and generation goals and transformation and generation strategies, and a third design information layer 303 that stores the design information of the software system after transformation and generation. The design information infrastructure 300 refers to an infrastructure in which each layer is chained together in a time series. The design information infrastructure dedicated server 195 may have a local DIT-dedicated graph database and a local DIT-dedicated vector database. The DIT-dedicated graph database manages the nodes and relationships of each design information layer, and the DIT-dedicated vector database may perform similarity searches of the system vector 900 (see Figure 9) and GPS vector 800 (see Figure 8). The design information infrastructure dedicated server 195 may be configured as a computing node independent of the integrated knowledge base server 170, and the two may cooperate via an API.

[0027] Each of the above servers may be consolidated into a single chassis, or distributed across multiple physical or virtual servers. Furthermore, they may be implemented in an on-premises environment, a cloud environment, or a hybrid environment. The intermediate representation generation unit 1, the conversion generation processing unit 2, the scoring processing unit 403, and the update processing unit may be implemented on a single computer, or distributed across multiple servers connected via a network.

[0028] As shown in Figure 1B, the software conversion generation system 10 is configured to communicate with multiple user terminals 20 and an artificial intelligence system 30 via a network N. The network N is, for example, the Internet and a Local Area Network (LAN), but other networks may also be used. The software conversion generation system 10 includes a control unit 11, a storage unit 12, and a communication unit 13. The control unit 11 includes a processor that executes control processing by running program 12a. The storage unit 12 includes ROM (Read Only Memory) and RAM (Random Access Memory) where program 12a is stored. The communication unit 13 is a communication interface for connecting to the network N. The artificial intelligence system 30 shown in Figure 1B is, for example, a generative AI system. A large-scale language model (LLM) can be used in the artificial intelligence system 30. The artificial intelligence system 30 is connected to the network N. The artificial intelligence system 30 outputs a response in response to an input prompt. The user terminals 20 are information processing terminals used by users (administrators). The user terminal 20 is, for example, a personal computer, a tablet, or a smartphone. The user terminal 20 includes a control unit, an operation unit, a display unit, a communication unit, and a storage unit. The control unit includes a processor that performs control processing by executing a program. The operation unit is, for example, a keyboard, a mouse, and a touch panel. The operation unit accepts approval or rejection from the user. The display unit is, for example, an organic EL display or a liquid crystal display. The display unit displays the screens shown in Figures 11B to 11H. The communication unit is a communication interface and is connected to the network N. The storage unit includes ROM and RAM.

[0029] [2. Databases and Knowledge Management Structure] The logical knowledge base in the first embodiment may be implemented as a four-database integrated configuration. Specifically, the four-database integrated configuration includes a language master database, a graph database 401 (see Figure 4), a vector database 402 (see Figure 4), and a document database.

[0030] A language master database structures and manages the syntax rules, semantic definitions, and inter-language correspondences of multiple programming languages. For example, it may store token definitions, grammar rules, type systems, scope rules, exception handling rules, memory models, framework characteristics, and mappings to existing languages.

[0031] The graph database 401 stores source code conversion generation rules between multiple programming languages ​​in a graph structure of nodes and edges. The graph database 401 may also store conversion rule nodes, language nodes, architecture pattern nodes, conversion possibility relation edges, inverse conversion relation edges, improvement history edges, and the like.

[0032] The vector database 402 stores vector embedding representations of source code transformation generation rules. These vector embedding representations may be generated from at least an abstract syntax tree as input, and may also reflect control flow, data flow, dependencies, or design information.

[0033] The document database stores source code analysis results and intermediate representation data in an unstructured format. For example, it may store analysis logs, IR documents, requirements design documents, conversion reports, test reports, quality reports, etc.

[0034] Furthermore, as a physical implementation of the first embodiment, in addition to the 4-database integrated configuration, a 6-database implementation may be adopted, which includes a DIT-dedicated graph database and a DIT-dedicated vector database for implementing the design information infrastructure 300. The DIT-dedicated graph database manages the nodes and interrelationships of each design information layer, and the DIT-dedicated vector database stores the GPS vector 800 and the system vector 900. Here, "6-database implementation" refers to a physical implementation form that further includes a DIT-dedicated graph database and a DIT-dedicated vector database for implementing the design information infrastructure 300, in addition to the 4-database integrated configuration, and is consistent with the 4-database integrated configuration as a logical configuration, with the latter being an implementation form that encompasses the former. Also, "GPS vector 800" (see Figure 8) refers to a Graph Path Signature vector, which includes four sub-vectors representing structural paths, tenant boundaries, audit paths, and transformation generation history. Also, "the system vector 900" (see Figure 9) refers to a multidimensional integrated vector formed by representing multiple analysis viewpoints of the software as feature vectors of predetermined dimensions and combining these feature vectors with the GPS vector 800.

[0035] Furthermore, the above database may have a two-tiered knowledge management structure. The first tier is a language master database that manages language specification information, and the second tier is a conversion dictionary that manages conversion knowledge information. This separation allows for the management of language specification updates and conversion pattern additions without mutual interference. Here, "conversion dictionary" refers to a set of knowledge that manages conversion generation patterns, conversion rules, type mappings, architecture conversion rules, etc., between programming languages. The conversion dictionary may also include structure-preserving conversion rules that update a language or framework while maintaining existing architecture patterns, and architecture-driven conversion rules that perform conversions to new architecture patterns.

[0036] [3. Document Analysis and Intermediate Products] The analysis server 120 (see Figure 1A) analyzes the acquired document and generates intermediate products. These intermediate products include at least a concrete syntax tree, an abstract syntax tree, a symbol table, a data flow graph, and metadata. A control flow graph, a dependency graph, test-related information, and design metadata may also be generated as needed. The analysis server 120 may, for example, identify the start and end positions of the embedded language by pattern matching or rule-based detection and perform separate analyses for each section.

[0037] A concrete syntax tree is a syntactic representation that preserves the details of the source code, including comments, whitespace, delimiters, and lexical information. An abstract syntax tree is a syntactic representation that extracts the logical structure of a program. A symbol table holds the resolution results of variables, functions, types, scopes, and reference relationships. A data flow graph represents data dependencies and data propagation paths. Metadata includes attributes, annotations, comments, complexity, file information, etc.

[0038] As shown in Figure 2, the intermediate representation generation unit 1 integrates the above intermediate products to generate CS-IR201, which represents the current state of the software to be converted. Here, "CS-IR201" refers to an intermediate representation that represents the current state of the software to be converted, and is an intermediate representation in the preliminary stage after the analysis results have been organized. It may be generated prior to the generation of the first intermediate representation, P-IR202. CS-IR201 functions as a preliminary stage before the generation of the first intermediate representation, P-IR202, and is also used as a review target to correct any omissions or inconsistencies in the analysis results. Furthermore, "the first intermediate representation" refers to an intermediate representation that includes at least a conceptual intermediate representation that expresses the concept, including business objectives and constraints, in a graph structure, and in the first embodiment, is mainly embodied as P-IR202. Furthermore, "P-IR202" refers to a conceptual intermediate representation that expresses the concept, including business objectives, constraints, conversion generation objectives, and conversion generation strategies, in a graph structure.

[0039] The document analysis performed by the intermediate representation generation unit 1 is not limited to source code in a single language, but may also include the detection and isolation analysis of code fragments of other programming languages ​​embedded within parts of the document. For example, SQL embedded in COBOL source code, HTML embedded in Java source code, or template descriptions embedded in scripting languages ​​may be detected.

[0040] Furthermore, the document analysis by the intermediate representation generation unit 1 may include a process of integrating copybooks, include files, data definitions, screen definitions, setting definitions, or similar related objects referenced by the document. This improves the completeness of the analysis, even for systems that rely on external definitions.

[0041] In the first embodiment, analysis is performed using a group of parsers that support multiple programming languages. The number of supported languages ​​may be, for example, 38 or more, and may be extended to a larger group of languages. A "group of parsers" refers to a collection of parsers that support multiple programming languages ​​and analyze source code or related documents to generate concrete syntax trees, abstract syntax trees, symbol information, or dependency information.

[0042] [4. Step-by-step intermediate representation chain] Figure 2 is a flowchart showing the processing of the IR chain 200 in the first embodiment. As shown in Figure 2, the IR chain 200 in the first embodiment can take a six-stage configuration including CS-IR201, P-IR202, RD-IR203, I-IR204, CO-IR205, and DP-IR206. Here, "stepwise intermediate representation chain" or "IR chain" refers to a processing flow that sequentially generates multiple intermediate representations, and in the first embodiment, it can take a six-stage configuration including CS-IR201, P-IR202, RD-IR203, I-IR204, CO-IR205, and DP-IR206. Of the six-stage configuration, CS-IR201, P-IR202, RD-IR203, I-IR204, CO-IR205, and DP-IR206 may be understood as design information layer linked IRs that mainly cooperate with each layer of the design information infrastructure 300.

[0043] CS-IR201 primarily couples with the Reverse layer 301, which is the first design information layer, and represents the results of the current structure analysis of the software to be converted. As an intermediate representation that expresses the current state of the software to be converted "as is," CS-IR201 may also serve as the basis for the subsequent generation of P-IR202.

[0044] P-IR202 is a first intermediate representation that is primarily coupled with the Plan layer 302, which is the second design information layer, and is generated by referencing CS-IR201 and the business objectives, constraints, transformation generation objectives, and transformation generation strategies stored in the second design information layer. P-IR202 represents the concept, including the business objectives and constraints, in a graph structure. P-IR202 may also represent the transformation concept, which is what transformations to be performed on the current state.

[0045] RD-IR203 is an integrated requirements design intermediate representation that primarily connects with the Plan layer 302, the second design information layer, and integrally represents functional requirements, non-functional requirements, and architectural design in a single graph structure. RD-IR203 generates requirement nodes, non-functional requirement nodes, architecture nodes, and traceability edges. Here, "RD-IR203" refers to the integrated requirements design intermediate representation, which integrally represents functional requirements, non-functional requirements, and architectural design in a single graph structure, and maintains intrinsic traceability from requirements to design as edges. RD-IR203 may also function as an integrated requirements and design model.

[0046] In RD-IR203, an intrinsic traceability from functional requirements to architectural design is maintained as an edge, and a change propagation mechanism may be implemented that propagates changes to the architectural design in response to changes in functional requirements. This prevents inconsistencies between requirements and design. Specifically, the change propagation mechanism operates as follows: As input, the update difference for the requirements node of RD-IR203 (including the content of the changed functional requirements and the type of change) is given. As processing, traceability edges are traced from the requirement node by graph traversal to identify the affected architectural nodes. For the identified architectural nodes, a consistency check with the change content is performed, and if there is no consistency, a change candidate flag is assigned to the node and improvement suggestions are generated. As output, the group of flagged architectural nodes and improvement suggestions are output as targets for notification to the conversion generation processing unit 2 and the user.

[0047] I-IR204 is primarily coupled with the Plan layer 302, which is the second design information layer, and is an implementation intermediate representation that includes definitions of classes, methods, fields, exception handling, configuration items, and deployment prerequisites for the target platform. Here, "I-IR204" refers to the implementation intermediate representation, which includes detailed implementation definitions of classes, methods, fields, interfaces, configuration items, etc. for the target platform. I-IR204 may also function as a detailed implementation specification for the target platform.

[0048] CO-IR205 and DP-IR206 are primarily coupled to the Design layer 303, which is the third design information layer. CO-IR205 is an intermediate code output representation generated from I-IR204, and DP-IR206 is an intermediate deployment representation generated from CO-IR205. Here, "CO-IR205" refers to the intermediate code output representation, which is an intermediate representation immediately before code output that embodies I-IR204. "DP-IR206" refers to the intermediate deployment representation, which includes deployment information, execution configuration information, and deployment definition information corresponding to the code output result. Furthermore, "design intent" refers to business logic, regulatory compliance requirements, operational knowledge, architectural judgments, dependency constraints, or similar intentions or judgments inherent in the software system before conversion generation.

[0049] On the other hand, from the perspective of referencing and updating the design information layer, the 6-stage configuration may be understood as a 5-stage abstraction that bundles CO-IR205 and DP-IR206 as output generation stages. In this case, the first design information layer 301 is referenced or updated in accordance with the CS-IR201 of the first stage, the second design information layer 302 in accordance with the P-IR202 of the second stage, the RD-IR203 of the third stage, and the I-IR204 of the fourth stage, and the third design information layer 303 in accordance with the CO-IR205 of the fifth stage and the DP-IR206 of the sixth stage. Figure 2 shows the main direct coupling relationships and does not contradict the 5-stage abstraction.

[0050] During the generation of intermediate representations at each stage, user approval or rejection may be accepted via the approval gateway 230. In particular, approval of a design information layer linkage IR may be used as a trigger for recording in the corresponding design information layer. Here, "design information layer linkage IR" refers to an intermediate representation that has a primary reference or update relationship with each layer of the design information infrastructure 300, and in the first embodiment, CS-IR201, P-IR202, RD-IR203, I-IR204, CO-IR205, and DP-IR206 correspond to design information layer linkage IRs.

[0051] [5. Trial Transformation Process and Knowledge Accumulation] The intermediate representation generation unit 1 shown in Figure 2 executes a trial conversion process using the first intermediate representation, P-IR202. The trial conversion process is a preliminary execution preceding the actual conversion generation process and is used to explore conversion feasibility, extract difficulties, consider architecture candidates, and detect quality concerns. In other words, "trial conversion process" refers to a process that performs preliminary conversion generation using the first intermediate representation prior to the actual conversion generation process and extracts information related to the conversion generation. For example, it is executed as a Dry-Run method 211, a sampling method 212, a pattern analysis method 213, or an inference analysis 214, or a combination thereof. Furthermore, "trial conversion process" refers to a process (simulation process) for collecting and evaluating information necessary for the conversion process in advance without determining and applying the actual conversion process to the production environment for the software to be converted. Specifically, the trial conversion process may include the steps of (i) selecting a representative portion of the input source code, (ii) executing a conversion process on the selected portion, (iii) calculating a quality score from the execution results, (iv) comparing the calculated quality score with a predetermined threshold, (v) accumulating knowledge related to the conversion in a database, and (vi) discarding the trial results and executing the actual conversion generation process.

[0052] Examples of execution methods for the trial transformation process include a Dry-Run method 211 for representative modules, a sampling method 212 for parts with high difficulty, a pattern analysis method 213 for comprehensively searching for transformation patterns, or an inference analysis 214 by an AI agent.

[0053] The information regarding transformation generation extracted by the trial transformation process includes at least transformation generation pattern information, transformation difficulty information, dependency information, architecture information, and quality information. Furthermore, it may also include optimization parameters, quality improvement information, or the results of the candidate rule applicability evaluation. Here, "information regarding transformation generation" refers to information obtained by the trial transformation process, and includes at least one of the following: transformation generation pattern information, transformation difficulty information, dependency information, architecture information, quality information, optimization parameters, and quality improvement information.

[0054] The intermediate representation generation unit 1 shown in Figure 2 generates second intermediate representations, RD-IR203 and I-IR204, using the extracted transformation generation information. The extracted transformation generation information is also added to the database as knowledge storage 220. Here, "second intermediate representation" refers to an intermediate representation that reflects the transformation generation information extracted by the trial transformation process, and in the first embodiment, it includes RD-IR203, which is the requirements design integrated intermediate representation, and I-IR204, which is the implementation intermediate representation.

[0055] The process of adding to the database may be a non-destructive update that accumulates new transformation generation patterns, optimization parameters, and quality improvement information without erasing existing transformation generation patterns. This allows for the utilization of past knowledge in both subsequent processes within the same project and in subsequent projects.

[0056] The transformation rules stored in the graph database 401 may have a structure in which an edge indicating an inverse transformation generation relationship is attached between a forward transformation generation rule node from a first programming language to a second programming language and a reverse transformation generation rule node from a second programming language to a first programming language. Through this inverse transformation generation relationship, traceability between the source code before and after transformation generation is ensured.

[0057] Each transformation rule node in the graph database 401 may hold, for example, a source language identifier, a target language identifier, a code pattern, a transformation priority, a transformation performance score, a bidirectional flag, and attributes indicating that it was extracted in a trial transformation. The vector database 402 holds a vector embedding representation corresponding to the node.

[0058] Furthermore, the processing by the intermediate representation generation unit 1 is not limited to the above example, and may be performed in four stages, for example: (i) a stage of generating a first intermediate representation while analyzing the document and referring to the database; (ii) a stage of performing a trial conversion process using the first intermediate representation and extracting information related to conversion generation; (iii) a stage of generating a second intermediate representation using the extracted information; and (iv) a stage of adding the extracted information to the database. Alternatively, it may be performed in any other number of stages. In addition, the information related to conversion generation may be used not only for subsequent conversion generation processes within the same project, but may also be reused in subsequent projects. The knowledge obtained from the trial conversion process may be used directly to improve the quality of the second intermediate representation, or it may be used for subsequent scoring processes and conversion rule selection.

[0059] [6. Hybrid Scoring Process] Figure 4 is a block diagram showing the configuration of the hybrid scoring process 400. As shown in Figure 4, the scoring processing unit 403 performs a structural search 410 using the graph database 401 and a semantic search 420 using the vector database 402, and calculates an integrated score based on the results of each. Here, "scoring processing unit 403" refers to a processing unit that calculates a score by integrating the results of the structural search using the graph database 401 and the results of the semantic search using the vector database 402. Furthermore, "structural search" refers to a search that finds candidates based on the relationships, paths, adjacency, transformability relationships, inverse transform relationships, etc., of the graph structure represented by nodes and edges. Furthermore, "semantic search" refers to a search that finds candidates based on the similarity between vector embedding representations, for example, cosine similarity.

[0060] In structural search 410, the structural relevance of transformation rules is evaluated using graph queries, pattern matching, graph traversal, etc. In structural search 410, multi-stage transformation paths may be searched. For example, a path that transforms from a first language to a third language via a second language may be searched as a candidate. In semantic search 420, the semantic similarity of vector embedding representations is evaluated using cosine similarity, etc. In semantic search 420, high-precision matching may be performed using the system vector 900 or a similar multi-dimensional integrated vector.

[0061] The scoring processing unit 403 assigns a first weight to semantic search results and a second weight to structural search results, and combines both as an integrated score to rank the optimal transformation generation patterns. The score at this time may be calculated as, for example, Score = α × S_graph + β × S_vector. The weights α and β may be fixed values, or they may be dynamically changed based on the type of transformation target, the combination of source and target languages, the complexity of the code, or past performance. For example, they may be set to satisfy α + β = 1. As for the weight setting method, for example, fixed weights for each type of transformation, dynamic updates by machine learning based on past performance, manual settings by the user, or changes according to the language combination may be employed. For example, but not limited to this, the first weight = 0.6 and the second weight = 0.4. The cosine similarity threshold is 0.85, and values ​​of 0.85 or higher can be judged as similar.

[0062] The integrated score may be referenced when the intermediate representation generation unit 1 generates the first intermediate representation, and may also be used to determine the conversion generation pattern to be applied during the trial conversion process. Furthermore, the conversion generation processing unit 2 performs the actual conversion generation while referring to the integrated score.

[0063] The vector embedding representations stored in the vector database 402 may be generated based on at least an abstract syntax tree. If semantically equivalent transformation generation patterns are found through semantic search between different programming languages, the discovery is compared with the transformation rules stored in the graph database 401 and used to determine the optimal transformation generation path.

[0064] The scoring processing unit 403 may perform structural and semantic searches at each stage of the stepwise intermediate representation chain. In this case, the candidate patterns and execution results obtained at each stage are added to the database, and knowledge update processing is performed.

[0065] In the knowledge update process, the results of the conversion generation performed by the conversion generation processing unit 2 (see Figure 10) may be reflected in the conversion rule quality of the graph database 401, the embedded representation of the vector database 402, the correspondence of the language master database, or the auxiliary information of the document database.

[0066] In a database implementation, the scoring processing unit 403 may sequentially perform, for example, (i) a similarity search using the system vector 900 in the DIT-dedicated vector database, (ii) a semantic search in the vector database 402, (iii) a structural search in the graph database 401, (iv) an additional structural search in the DIT-dedicated graph database, and (v) integrated scoring of these results.

[0067] Furthermore, the conversion dictionary may include structure-preserving conversion rules that perform conversions while maintaining the existing architecture, and architecture-driven conversion rules that perform conversions to a new architecture.

[0068] [7. AI Agent Groups and Automatic Language Augmentation] The intermediate representation generation unit 1 and the scoring processing unit 403 may include multiple specialized AI agents that integrate a large-scale language model and graph-based search extension generation. The specialized AI agents search for existing transformation generation patterns in the trial transformation process and perform dynamic enrichment processing to non-destructively add new transformation generation patterns, optimization parameters, and quality improvement information based on the results of applicability inference by the large-scale language model.

[0069] Examples of specialized AI agents include knowledge retrieval agents, document analysis agents, report generation agents, test agents, language specification extraction agents 430, security audit agents, and architecture audit agents. These agents cooperate by sharing reference to the database. The specialized AI agents may include specialized AI agents that evaluate the quality of the transformation generation results on three axes: functional accuracy, security robustness, and structural soundness. These specialized AI agents may be configured to feed back the evaluation results on the three axes to the database, forming a learning loop that continuously improves the quality of subsequent transformation generation.

[0070] Among the specialized AI agents, the agent that searches the integrated knowledge base and supplies knowledge to other agents may be identified as a GraphRAGAgent. The agent that acquires and analyzes unstructured documents and supplies them to the intermediate representation generation unit 1 may be identified as a DocumentIngestionAgent. The agent responsible for verifying equivalence before and after conversion and generating test cases may be identified as a TestAgent. The agent that audits the architectural suitability or design consistency after conversion generation may be identified as an ArchitectureAuditAgent. The agent that audits the conversion generation results from the perspective of vulnerability or regulatory compliance may be identified as a SecurityAuditAgent. The agent that generates analysis results, quality evaluation results, and improvement suggestions as reports may be identified as a ReportGenerationAgent.

[0071] Knowledge retrieval agents may be responsible for searching from an integrated knowledge base, and document analysis agents may be responsible for analyzing unstructured documents. Test agents may be responsible for verifying equivalence before and after conversion and for automatically generating test cases. Architecture audit agents may be responsible for auditing design compliance, and security audit agents may be responsible for auditing from a vulnerability or regulatory compliance perspective. Report generation agents may be responsible for generating reports of analysis results, quality assessment results, and improvement suggestions.

[0072] Multiple specialized AI agents may collaboratively execute trial transformation processes and accumulate new transformation generation patterns and knowledge information acquired during these trial transformation processes in a database.

[0073] In the additional processing, existing transformation generation patterns are searched, the applicability of those patterns is inferred by a large-scale language model, and new transformation generation patterns, optimization parameters, and quality improvement information may be added based on the inference results. The additional processing is a dynamic enrichment process that searches for existing transformation generation patterns in the trial transformation processing, infers the applicability of those transformation generation patterns by a large-scale language model, and non-destructively adds new transformation generation patterns, optimization parameters, and quality improvement information based on the inference results.

[0074] The language specification extraction agent 430 may obtain and analyze the grammar specification of a new programming language from a document and generate a parser corresponding to the new programming language. It may also register the syntax rules, semantic definitions, and correspondences with existing languages ​​of the new programming language in the database. Specifically, the automatic language extension process by the language specification extraction agent 430 operates as follows: As input, a language specification document of a new programming language, a grammar definition file in BNF (Backus-Naur notation), or an electronic document equivalent thereto is provided. As processing, a large-scale language model analyzes the document to extract token definitions, grammar rules, type systems, and scope rules, and performs a difference comparison with the language specification stored in the existing language master database. Based on the results of this difference comparison, parser logic corresponding to the new language is generated. As output, a parser program corresponding to the new programming language and registration data for the language master database, including the syntax rules, semantic definitions, and correspondences with existing languages ​​of the new language, are obtained. The language specification extraction agent 430 may also be responsible for identifying the root cause and implementing improvements to the conversion rules, conversion dictionaries, and language specifications when a quality gate fails.

[0075] This allows for automatic extension of supported programming languages ​​without relying on manual configuration.

[0076] [8. Design Information Infrastructure (DIT)] Figure 3 is a block diagram showing the configuration of the design information infrastructure 300. As shown in Figure 3, the design information infrastructure 300 has a Reverse layer 301, a Plan layer 302, and a Design layer 303. The design information infrastructure 300 may also be understood as a DIT. As shown in Figure 3, the design information infrastructure 300 may also include DIT Reverse layer details 310, DIT Plan layer details 320, DIT Design layer details 330, Provenance self-replicating 340, and IR chain linkage 350.

[0077] The Reverse layer 301 is a first design information layer that stores the results of analyzing the current structure of the software to be transformed and generated. The Reverse layer 301 stores, for example, AST extraction results, CST extraction results, dependency graphs, control flows, data flows, design metadata, metrics, and related object integration results. In addition to cyclomatic complexity, the Reverse layer 301 may also store cognitive complexity, cross-dependency maps, and external reference relationships. The DIT Reverse layer detail 310 may represent the detailed configuration of the structural analysis information, dependency information, design metadata, metrics, and related object integration results stored in the Reverse layer 301.

[0078] The Plan layer 302 is a second design information layer that stores transformation generation objectives and transformation generation strategies. The Plan layer 302 stores at least business objectives, constraints, transformation generation objectives, transformation generation strategies, process path selection results, and strategy decision points. In addition to the transformation strategy, the Plan layer 302 may also store correspondences from source components to target components, risk assessments, and priorities. When forming strategies in the Plan layer 302, the current structure represented by CS-IR201 may be referenced. The DIT Plan layer detail 320 may represent the detailed configuration of the business objectives, constraints, transformation generation objectives, transformation generation strategies, process path selection results, strategy decision points, as well as the correspondences from source components to target components, risk assessments, and priorities stored in the Plan layer 302.

[0079] The Design layer 303 is a third design information layer that stores the design information of the software system after conversion generation. The Design layer 303 stores at least functional requirements, non-functional requirements, architecture design, class definitions, method definitions, field definitions, interface definitions, and design rationale tracking information for the target platform. The DIT Design layer detail 330 may represent the detailed configuration of the functional requirements, non-functional requirements, architecture design, class definitions, method definitions, field definitions, interface definitions, and design rationale tracking information stored in the Design layer 303.

[0080] Each design information layer is structured in a chain along the timeline of the transformation generation process. Specifically, a transformation generation strategy is formed in the Plan layer 302 based on the current structure identified in the Reverse layer 301, and the transformed design information is constructed in the Design layer 303 based on this strategy.

[0081] The update processing unit sequentially records the execution results from the conversion generation processing unit 2, associating them with each of the design information layers. For example, the Reverse layer 301 records the analysis completeness and current quality, the Plan layer 302 records the selected conversion strategy and approval history, and the Design layer 303 records the generated design information and quality audit results.

[0082] The results of the conversion generation process may be stored as conversion generation history information associated with the information of each design information layer. This conversion generation history information may include the results of quality gate judgments, the results of improvement processes performed in the event of failure, the applied conversion rules, the success or failure of design intent inheritance, and the results of reprocessing.

[0083] The Provenance Self-Replication 340 may represent a mechanism that stores the results of the conversion generation process, quality gate judgment results, improvement process results, and the success or failure of design intent inheritance as history information in chronological order, and updates it in a form that can be reused in subsequent projects. The IR Chain Linkage 350 may represent the correspondence and linkage relationships between CS-IR201, P-IR202, RD-IR203, I-IR204, CO-IR205, and DP-IR206 and the Reverse layer 301, Plan layer 302, and Design layer 303.

[0084] In the first embodiment, the design information infrastructure 300 may be implemented by a plurality of databases, including a graph database and a vector database. The graph database manages structural relationships, and the vector database stores embedded representations of the design information.

[0085] Furthermore, as shown in Figure 15, the design information infrastructure 300 corresponding to each of the multiple tenants may be managed in complete isolation. This prevents information leakage across tenant boundaries while allowing each tenant to continuously utilize historical information.

[0086] [9. GPS vectors and system vectors] Figure 8 is a block diagram showing the configuration of the GPS vector 800. As shown in Figure 8, the GPS vector 800 may include subvectors for structure path 801, tenant boundary 802, audit path 803, and transformation history 804. As shown in Figure 8, the GPS vector 800 is, for example, a 64-dimensional path signature vector. The structure path 801 is, for example, a 24-dimensional graph structure path vector as a first subvector. The tenant boundary 802 is, for example, a 16-dimensional tenant boundary vector as a second subvector. The audit path 803 is, for example, a 16-dimensional audit path vector as a third subvector. The transformation history 804 is, for example, an 8-dimensional transformation generation history vector as a fourth subvector. As an example, the structure path vector (24 dimensions) may be constructed by calculating Graph Distance (8 dimensions), Hierarchy Level (8 dimensions), and Connectivity (8 dimensions) using the FastRP algorithm or Node2Vec algorithm of a graph database. The tenant boundary vector (16 dimensions) may be constructed by splitting the SHA-256 hash value of the tenant identification information into Tenant Identity (8 dimensions), Boundary Distance (4 dimensions), and Isolation Level (4 dimensions). The audit path vector (16 dimensions) may be constructed by encoding the timestamp (6 dimensions), operator identification (6 dimensions), and path type (4 dimensions). The transformation history vector (8 dimensions) may include the number of versions (2 dimensions), stability score (2 dimensions), lineage depth (2 dimensions), and confidence level (2 dimensions).

[0087] The structure path 801 may represent graph distance, hierarchy level, and connectivity. The tenant boundary 802 may represent tenant identification information, boundary distance, and isolation level. The audit path 803 may represent timestamp, operator identification, and path type. The transformation history 804 may represent version number, stability score, lineage depth, and confidence level. The structure path 801 may be calculated by, for example, FastRP, Node2Vec, or a similar graph analysis algorithm. The tenant boundary 802 may be generated from a hash of tenant identification information, which may make it easier to separate nodes belonging to different tenants in the vector space.

[0088] Figure 9 is a block diagram showing the structure of the system vector 900. As shown in Figure 9, the system vector 900 may be configured as a multidimensional integrated vector with a total of 3840 dimensions, for example, including a 768-dimensional Legacy Code Vector and 12 feature vector blocks, each with 256 dimensions. The system vector 900 may consist, for example, a vector component representing the legacy code and feature vector blocks corresponding to multiple analysis perspectives. Each feature vector block may include a feature vector and a GPS vector 800. The system vector 900 may be understood as a multidimensional integrated vector corresponding to a MORPHic Embedding Composite.

[0089] The aforementioned 12 feature vector blocks correspond to the following analytical perspectives: syntax 901, semantics 902, dependencies 903, data flow 904, control flow 905, architecture 906, security 907, testing 908, performance 909, documentation 910, business logic 911, and infrastructure 912.

[0090] Each feature vector block may include a feature vector and a GPS vector 800. This allows structural paths, tenant boundaries, audit information, and transformation generation history information to be stored in association with each analysis perspective.

[0091] The GPS vector 800 and the system vector 900 may be stored in a vector database as vector embedding representations that include transformation generation history information at each layer of the design information infrastructure 300.

[0092] [10. Provenance self-replicating and history-referenced scoring] When the results of the transformation generation process are recorded in each layer of the design information infrastructure 300, the transformation history sub-vectors of the GPS vector 800 may be updated. Specifically, the number of versions, stability score, lineage depth, and confidence level may be recalculated. In other words, when the results of the transformation generation process are recorded in each design information layer, the number of versions, stability score, lineage depth, and confidence level included in the transformation history sub-vectors of the GPS vector 800 may be updated.

[0093] Provenance protects not only the technical results of the transformation, but may also include the design intent itself, accumulated over many years of operation. This structurally protects the business layer's goals, which should be inherited even as technology trends change. Here, "Provenance history" refers to transformation generation history information, which is accumulated chronologically from the execution results of the transformation generation process and used to improve the quality of subsequent transformation generation. Provenance history may include information on how well the design intent was inherited by which transformation rules.

[0094] In subsequent projects, new system vectors 900 and GPS vectors 800 may be generated, and similarity searches with past DIT nodes may be performed. Provenance information of similar transformation patterns may be reflected in the strategy formulation of the Plan layer 302 and the pattern ranking by the scoring processing unit 403.

[0095] The scoring processing unit 403 may perform scoring that reflects the Provenance information. For example, it may assign a higher score to conversion patterns with a higher Provenance confidence level, thereby improving the accuracy of conversion information extraction or conversion rule selection in subsequent conversion generation processes.

[0096] Thus, a cross-project autonomous learning loop may be formed by the organic integration of trial transformation feedback using the first intermediate representation, hybrid scoring, and history accumulation in the design information infrastructure. Specifically, this learning loop operates as follows: As input, the system vector 900 and GPS vector 800 generated at the start of the transformation generation process in a subsequent project are provided. As processing, the scoring processing unit 403 searches for similarity between these vectors and vectors from past projects stored in the DIT-dedicated vector database of the design information infrastructure 300, and extracts higher-ranking similar transformation patterns. The Provenance history (including quality gate judgment results and success or failure of design intent inheritance) related to the extracted transformation patterns is referenced, and hybrid scoring is performed. After the completion of the transformation generation process, the quality gate judgment results are reflected in the transformation history sub-vector of the GPS vector 800, and each layer of the design information infrastructure 300 is updated. As output, an improved transformation pattern selection accuracy in the subsequent transformation generation process and an updated design information infrastructure 300 are obtained, which are then cyclically used as input for subsequent projects. In other words, in subsequent projects, a similarity search with past DIT nodes is performed based on the newly generated system vector 900 and GPS vector 800, and past success and failure patterns may be referenced. The mechanism in which trial transformation feedback using the first intermediate representation, hybrid scoring, and history accumulation in the design information infrastructure 300 are cyclically linked may be understood as a cross-project autonomous learning loop.

[0097] [11. Quality Gates, Analysis Quality Gates, and Automatic Feedback Loops] As shown in Figure 5, the quality gate 501 may evaluate the conversion generation results on at least three axes: functional accuracy 511, security robustness 512, and structural integrity 513. The quality gate 501 may be understood as a three-axis quality gate that performs evaluation on three axes: functional accuracy, security robustness, and structural integrity.

[0098] Functional accuracy may be calculated based on, for example, test pass rate, line coverage, branch coverage, and function coverage. Security robustness may be calculated based on, for example, vulnerability detection results, compliance conformance, or penalty scores. Structural health may be calculated based on, for example, architecture conformance, anti-pattern absence, or deployment suitability. For example, functional accuracy (functional accuracy score) may be calculated as a weighted sum of test pass rate, line coverage, branch coverage, and function coverage; security robustness (security robustness score) may be calculated by subtracting a penalty corresponding to vulnerability severity from compliance conformance; and structural health score may be calculated as a weighted sum of architecture conformance, Twelve-Factor conformance, and anti-pattern absence. Each weight coefficient may be set such that, for example, for functional accuracy, the weight corresponding to test pass rate is greater than the weight corresponding to row coverage; for security robustness, the penalty for high-severity vulnerabilities is greater than the penalty for low-severity vulnerabilities; and for structural soundness, the weight corresponding to architectural compliance is greater than that of other elements. The sum of each weight coefficient may be 1.

[0099] If the quality gate 501 determines that the product is unacceptable, the feedback flow 500 is activated. The feedback flow 500 shown in Figure 5 may include F1 feedback 502 for analyzing the cause of the unacceptable product, F2 feedback 503 for suggesting and implementing improvements, F3 feedback 504 for verification in an isolated environment, F4 feedback 505 for risk-based approval, and F5 feedback 506 for reprocessing.

[0100] In F1 feedback 502, a cause analysis and identification of the root cause of quality gate failure may be performed.

[0101] In F2 Feedback 503, improvement suggestions may be generated and improvement processes may be implemented based on the identified causes. The targets for improvement in F2 Feedback 503 may include language specifications, conversion pairs, conversion rules, conversion dictionaries, type mappings, and language knowledge graphs.

[0102] In F3 Feedback 504, a comparison and verification of quality scores before and after improvement may be performed. In F3 Feedback 504, the quality scores before and after improvement may be compared in an isolated sandbox verification environment. In F3 Feedback 504, an appropriate verification test may be selected depending on the type of transformation generation path, and the quality scores before and after improvement may be compared. In F4 Feedback 505, the risk level may be determined based on the content of the improvement action, and approval control may be performed according to the risk level. In F5 Feedback 506, the original transformation generation process may be re-executed with the improvement applied. In F5 Feedback 506, the improvement implementation record may be persisted as a log.

[0103] The risk level in the approval application process may be treated as a first level, a second level, and a third level from the perspective of the claims. For example, the first level may be automatically applied without requiring approval, the second level may require approval from an administrator within the tenant, and the third level may require approval from a system administrator. More detailed classifications such as LOW, MEDIUM, HIGH, and CRITICAL may be used as operational labels in Figure 5. For example, the first level (low risk) may be when the scope of impact is within a single file, the second level (medium risk) may be when the scope of impact extends to multiple files, and the third level (high risk) may be when the scope of impact exceeds module boundaries.

[0104] The analysis quality gate may calculate the analysis completeness score and the object quality score separately. The scoring processing unit 403 calculates the analysis completeness score for the analysis results of the document. The analysis completeness score may be calculated by a weighted average of multiple analysis evaluation elements, including the parsing success rate, syntax tree generation rate, symbol resolution rate, dependency detection rate, and embedded language detection rate, each with a predetermined weight.

[0105] For example, the analysis completeness score may be calculated as analysis_completeness=parse_success_rate×a1+ast_generation_rate×a2+symbol_resolution_rate×a3+dependency_detection_rate×a4+embedded_lang_detection_rate×a5.

[0106] The object quality score is a score that indicates the quality of the source code itself of the document being analyzed, and may be calculated, for example, by a weighted average using the dead code rate, maintainability index, cyclomatic complexity, security vulnerability penalty, and test coverage.

[0107] For example, the object quality score may be calculated as subject_quality=1.0-dead_code_ratio×b1+maintainability_index×b2+1.0-cyclomatic_complexity×b3+1.0-security_penalty×b4+test_coverage×b5.

[0108] If the analysis completeness score falls below a predetermined threshold, an improvement process for the analysis system or database may be initiated. On the other hand, if the object quality score falls below a predetermined threshold, the object quality score may be provided to the conversion generation processing unit 2 as a basis for determining the subsequent conversion generation strategy.

[0109] If the object quality score is below a threshold, the transformation generation processing unit 2 may, in addition to normal transformation generation, apply a quality issue improvement transformation that includes at least one of the following: dead code removal, method splitting to reduce cyclomatic complexity, replacement of security vulnerability patterns with secure patterns, encapsulation of global variables, and addition of error handling. A transformation that includes at least one of the following, applied when the object quality score is below a threshold: dead code removal, complexity reduction, vulnerability pattern replacement, encapsulation of global variables, and addition of error handling, may be recognized as a quality issue improvement transformation.

[0110] Furthermore, the quality gate determination unit or the scoring processing unit may use the analysis completeness score to initiate database improvement processing. This allows for the automatic selection of different countermeasures by distinguishing whether the cause of quality degradation is a problem on the analysis side or a problem on the target object side. Specifically, the database improvement processing operates as follows: As input, the elements of the analysis completeness score (parse success rate, abstract syntax tree generation rate, symbol resolution rate, dependency detection rate, and embedded language detection rate) that fall below a predetermined threshold and their numerical values ​​are provided. As processing, the system refers to a matching table of evaluation elements that fall below the threshold and corresponding cause candidates to identify the cause. For example, a decrease in the parsing success rate may be identified as a parser malfunction or language version mismatch, and a decrease in the symbol resolution rate may be identified as a missing definition in the language master database. An improvement process corresponding to the identified cause (such as updating the parser, adding to the conversion dictionary, or updating the language master database) is selected. As output, an initiation command for the selected improvement process is sent to the integrated management server 110, and the corresponding database update process is executed.

[0111] Each of the above thresholds may be set according to the implementation. As an example, thresholds for functional accuracy T1, security robustness T2, structural soundness T3, overall quality T4, analysis completeness T5, and target item quality T6 may be set. Also, the relationship between the thresholds may be, for example, T2 > T1, T3 < T1 < T2, T5 > T4, and T6 < T3. As an example of each threshold, T1 may be 0.80, T2 may be 0.85, T3 may be 0.75, T4 may be 0.80, T5 may be 0.90, and T6 may be 0.60.

[0112] Note that the functional accuracy, security robustness, and structural soundness may each be calculated based on a predetermined weighted evaluation formula, and further, the final determination may be made based on an overall quality score obtained by integrating these. The overall quality score may be calculated, for example, as a weighted sum of the functional accuracy, security robustness, and structural soundness.

[0113] [12. Acceptance / Rejection Reception Unit and Judgment Processing Unit] In the first embodiment, the acceptance / rejection reception unit may be realized by the approval gateway 230 and the UI server 130. The acceptance / rejection reception unit accepts acceptance or rejection from the user with respect to the intermediate representation after the intermediate representation generation unit 1 generates the first intermediate representation and the second intermediate representation.

[0114] Also, the judgment processing unit may be realized as the control logic of the overall management server 110 or the control logic of the approval gateway 230. When the acceptance / rejection reception unit accepts approval from the user, the judgment processing unit permits the processing by the conversion generation processing unit 2, and when it accepts rejection, it does not execute the processing.

[0115] When rejection is accepted, an instruction to correct, an instruction to perform additional analysis, or an instruction to regenerate may be sent to the intermediate representation generation unit 1. Thereby, the user can proceed to the next step of conversion generation after confirming the content of the important intermediate representation. In addition to approval or rejection, the acceptance / rejection reception unit may accept partial approval that approves only a part, or conditional approval that is regarded as approval when a predetermined condition is satisfied.

[0116] [13.6 Process Path and Conversion Generation Path Control] Figure 10 is a conceptual diagram illustrating the six process paths. As shown in Figure 10, the transformation generation processing unit 2 may be capable of integrally executing six process paths, including full modernization 1001, direct transformation 1002, data transformation 1003, API transformation 1004, IaC transformation 1005, and container transformation 1006.

[0117] Full modernization 1001 is a path to generate a new system by reconfiguring an existing software system, and may include, for example, a Refactoring type, a Greenfield type, or a Hybrid type.

[0118] Direct conversion 1002 may also be a path that directly converts the source code of the source language to the source code of the target language.

[0119] Data conversion 1003 may be a path for converting a database schema, data definition, or data file.

[0120] API conversion 1004 may also be a path to convert an existing API to conform to, for example, REST, GraphQL, or gRPC.

[0121] IaC conversion 1005 may also be a path for converting infrastructure definition code.

[0122] Container conversion 1006 may also be a path for generating or converting container definition files and orchestration manifests.

[0123] As shown in Figure 13, the six process paths may share the first and second intermediate representations generated by the intermediate representation generation unit 1, as well as the database. Therefore, even if the conversion needs are different, they can be processed based on a consistent knowledge base and design information base.

[0124] In the first embodiment, the conversion generation path control unit may be implemented, for example, as an internal function of the conversion generation processing unit 2 or the integrated management server 110. The conversion generation path control unit switches the degree of involvement of the first design information layer 301, the second design information layer 302, and the third design information layer 303 depending on the type of conversion generation.

[0125] For example, in a direct conversion or refactoring type of full modernization that emphasizes the existing structure, the involvement of the first design information layer 301 may be set to a high level. In a Greenfield type that strongly reflects the new architecture, the involvement of the third design information layer 303 may be set to a high level. In a Hybrid type, the involvement may be dynamically switched according to the complexity or risk of each module.

[0126] In the six process paths mentioned above, parameters such as frameworks, build tools, and architectural patterns may be specified via a user interface. Analysis parameters such as analysis depth, complexity threshold, degree of parallelism, whether or not to perform comment analysis, whether or not to perform dead code analysis, and whether or not to generate reports may be set for the analysis server 120. In full modernization, a stepwise migration pattern may be adopted in which a routing layer is provided between the existing system and the new system, and traffic is switched for each migration phase. In the stepwise migration pattern, each migration phase is managed as a generated, operational, completed, or rollback state, and if it fails the quality gate, routing to the old system may be restored.

[0127] As a phased migration method in full modernization, a Strangler Fig pattern may be adopted, which involves establishing a routing layer between the existing system and the new system and switching traffic for each migration phase. The routing layer in the phased migration method may be understood as a Facade and may control the distribution of traffic to the legacy system and the new system. In the phased migration method, Phase management may be performed to manage the states of creation, operation, completion, and rollback for each migration target. In the phased migration method, the transition control, including the progress and rollback of each phase, may be understood as a Migration flow.

[0128] [14. Step-by-step transition using the Strangler Fig pattern] Figure 7 shows a stepwise migration structure 700 using the Strangler Fig pattern. As shown in Figure 7, the stepwise migration structure 700 may be a migration method in which a routing layer is interposed between the existing system and the new system, and the processing targets are gradually switched to the new system in each migration phase. The stepwise migration structure 700 includes a Facade 701, Phase management 702, and Migration flow 703.

[0129] Facade 701 is a routing layer placed between the legacy system and the new system, and may distribute requests to the appropriate backend based on a predetermined routing policy.

[0130] Phase management 702 may manage each stage of the migration as a lifecycle, for example, created, active, completed, and rolled_back. In each phase, the scope of modules to be migrated is defined, and the migration from the legacy system to the new system may proceed in stages.

[0131] Migration flow 703 may include a rollback mechanism. If the migration result of each phase does not pass quality gate 501, the phase may be transitioned to the rolled_back state to restore routing to the legacy system.

[0132] [15. Four-Asset Model, Core Assets, and Asset Registry] The first embodiment may employ a four-asset model consisting of input assets, functional assets, core assets, and output assets. Input assets include source code, design documents, data files, etc., while functional assets include a language master database, conversion dictionaries, rule sets, etc. Output assets include converted code, design deliverables, deployment definitions, reports, etc.

[0133] As shown in Figure 14, the core assets may consist of six elements: a concrete syntax tree, an abstract syntax tree, metadata, analysis data, test information, and design information. The first five elements are generated by the analysis server 120 and managed as analysis results confined to each project, while the design information is generated by the design information infrastructure server 195 and stored and referenced across projects. By storing and referencing design information across projects, this system may function as an engineering continuum in which knowledge is continuously maintained throughout the entire transformation generation process.

[0134] The asset registry structure 600 shown in Figure 6 may include an asset ID tree structure 601 for hierarchical management of assets and a lineage graph 602 for managing the history relationships between assets. The asset registry may be understood as an asset registry structure that includes a tree structure for hierarchical management of assets and a graph structure for managing the history relationships between assets. The asset registry structure 600 may include a source hash deduplication 620 to prevent duplicate registration of the same source.

[0135] The lineage graph 602 may define relationships such as converted_to, exposeds, and deployed_as. This enables cross-project asset history tracking.

[0136] Furthermore, the asset registry structure 600 may define inheritance categories such as business requirements 610, design intent 611, regulatory compliance 612, intellectual property 613, operational knowledge 614, external contracts 615, KPIs 616, and security 617. The asset registry structure 600 may also include AI-based provenance generation 630, in which an AI agent infers relationships between assets or between design information and automatically generates provenance relationships based on the results. The asset registry structure 600 may further hold deduplication information to prevent duplicate registration of the same source, and may also perform AI-based provenance generation, inferring provenance relationships between assets and automatically registering them. That is, the AI ​​agent may perform AI-based provenance generation, inferring relationships between assets or between design information and automatically generating provenance relationships based on the results.

[0137] Among the core assets, concrete syntax trees, abstract syntax trees, metadata, analysis data, and test information may be managed as analysis results confined to each project, whereas design information may be managed as a cross-project asset including the design information infrastructure 300 and its corresponding system vectors 900 and GPS vectors 800. Cross-project provenance tracking may be achieved by associating design information with asset provenance information.

[0138] [16. Conversion Dictionary System] Figure 12 shows the conversion dictionary system 1200. The conversion dictionary system 1200 may include multiple sets of conversion rules. The conversion dictionary may be understood as a conversion dictionary system consisting of multiple sets of conversion rules.

[0139] The structure-preserving transformation rules 1210 may include one-to-one mapping of language syntax, data type conversion, or control structure conversion, and may function as a set of rules that perform transformations while maintaining the existing architecture. In the transformation dictionary system, a set of rules that transform languages, syntax, types, or frameworks while maintaining the existing architecture may be understood as structure-preserving transformation rules. In the transformation dictionary system, a set of transformation rules that involve a transition to a new architectural pattern may be understood as architecture-driven transformation rules.

[0140] Architecture-driven transformation rule 1220 may function as a set of rules that perform transformations to new architectural patterns, including splitting from a monolith to microservices, reconfiguring a layered architecture, or redesigning a deployment configuration.

[0141] [17. Screen transition overview] Figure 11A shows a screen transition overview 1100 in the UI server 130. As shown in Figure 11A, the screen transition overview 1100 shows the transition relationships of a group of screens including the dashboard screen, project management screen, analysis result viewer screen, conversion execution screen, quality report screen, and asset registry browsing screen. The user interface may include, for example, the dashboard screen, project management screen, analysis result viewer screen, conversion execution screen, quality report screen, and asset registry browsing screen. Each screen of the user interface and its transition relationships may be understood as a screen transition overview. The user interface is realized by using the display unit and operation unit of the user terminal 20 to display screens to the user and accept input operations from the user.

[0142] Each of the aforementioned screens may be configured to allow transitions between them in response to operations such as project registration, analysis condition setting, intermediate representation review, approval or rejection, quality confirmation, and asset provenance confirmation.

[0143] [17.1 Quality Issues List Screen] As shown in Figure 11B, the UI server 130 displays a dashboard screen on the user terminal 20. The dashboard screen includes a 3-axis quality score widget. The "3-axis quality score widget" is a component placed on the UI dashboard that visually displays the quality of legacy code conversion and automatically generated code by the system using three evaluation axes. Specifically, it displays the current score for the following three quality axes using gauges, and is configured to allow users to see at a glance whether the pre-set quality gates (thresholds) are met or not with a "PASS / FAIL" judgment.

[0144] As shown in Figure 11C, the UI server 130 causes the user terminal 20 to display a quality issue list screen. The quality issue list screen displays a list of quality issues detected as a result of the quality evaluation by the analysis server 120 and the AI ​​server 140, along with visual identification displays according to their importance. The importance levels include, for example, at least four levels: first importance (Critical), second importance (High), third importance (Medium), and fourth importance (Low), and each level may be displayed in a visually identifiable manner using different colors or symbols.

[0145] The quality issue list screen may display the quality issues categorized by type. These categories may include at least security issues, structural issues, functional issues, and specification issues. The quality issue display unit may have filtering functions based on category, severity, and response status. In addition, depending on the individual selection of a quality issue, detailed information including the technical details of the issue, affected files, design items of the related design information layer, and recommended improvement actions may be displayed.

[0146] [17.2 Traceability Display Screen] As shown in Figure 11D, the UI server 130 displays a traceability display screen on the user terminal 20. The traceability display screen visualizes how each quality issue has been inherited and reflected through each stage of the stepwise intermediate representation chain, making it traceable. Specifically, the traceability display screen may display the progress of each issue at each stage of CS-IR201, P-IR202, RD-IR203, I-IR204, CO-IR205, and DP-IR206 as a flowchart, and visually display the issue resolution rate.

[0147] [17.3 Task Selection Type Conversion Parameter Screen] As shown in Figure 11E, the UI server 130 displays a problem selection type conversion parameter screen on the user terminal 20. The problem selection type conversion parameter screen provides an interface that allows the user to select the problem to be solved in the conversion generation process from among the quality problems.

[0148] The issue selection type conversion parameter screen may include a quality prediction display (quality gate impact prediction). The quality prediction display predicts and displays the quality score after conversion based on the selections made in the issue selection section (selection of issues to be resolved). The quality prediction display may recalculate the predicted score in real time in response to changes in the selections made in the issue selection section and update the display. If the predicted score falls below a predetermined quality gate threshold, a warning display may be provided suggesting additional issues to be selected.

[0149] The task selection type conversion parameter screen may further include a recommendation display section (optimal parameter recommendation). The recommendation display section dynamically generates and displays recommended target languages, frameworks, and architectural patterns, along with their suitability scores, based on the selected task combination.

[0150] [17.4 Administrator Console and Dynamic Viewer] The UI server 130 provides an administrator console to the user terminal 20. The administrator console may provide multiple management screens, including tenant management, user management, AI agent management, conversion dictionary management, language master database management, audit log management, and task queue management.

[0151] The UI server 130 may include multiple types of dynamic viewers. These dynamic viewers may include a core asset viewer, an analysis results viewer, a transformation results viewer, a data structure viewer, an API definition viewer, an IaC definition viewer, a container definition viewer, a test results viewer, and a code generation results viewer, and each viewer may apply different display logic and visualization methods depending on the type of object to be displayed.

[0152] [18. Verification Implementation Methods] As verification of the first embodiment, end-to-end verification of the API endpoint of the integrated management server 110, the user interface route, quality gate determination processing, multilingual analysis processing, and embedded language detection processing may be performed.

[0153] In this verification process, API testing, extension testing, browser testing, and quality gate pass / fail determination may be performed.

[0154] [19. Example 1: Conversion from COBOL to Java] This example describes the process of converting an existing system written in COBOL to a Java-based target platform.

[0155] First, the COBOL source code to be converted, along with related copybooks, data definitions, screen definitions, etc., are stored in the storage server 190. The integrated management server 110 issues an analysis task to the analysis server 120.

[0156] The analysis server 120 analyzes the COBOL source code to generate a concrete syntax tree, an abstract syntax tree, a symbol table, a data flow graph, a dependency graph, and metrics, and stores the current structure analysis results in the Reverse layer 301.

[0157] The intermediate representation generation unit 1 generates CS-IR201, and then generates a first intermediate representation, P-IR202. P-IR202 stores business objectives and constraints, such as preserving rounding processes, inheriting special conditional branching for end-of-month processing, and maintaining interfaces with peripheral batch systems.

[0158] The scoring processing unit 403 refers to the graph database 401 and the vector database 402 to rank the conversion generation patterns that are applicable to conversion from COBOL to Java.

[0159] Next, a trial conversion process using P-IR202 is performed. Here, for example, the difficulty of converting the ROUNDED clause, whether the batch interface can be maintained, whether external definition integration is successful, and the need for exception handling reinforcement are extracted.

[0160] The extracted information regarding transformation generation is reflected in the generation of RD-IR203 and I-IR204, and is also accumulated and added to graph database 401 and vector database 402.

[0161] In RD-IR203, report calculation requirements, performance requirements, disaster recovery requirements, security requirements, and architectural design are consolidated into a single graph structure. In I-IR204, classes, methods, fields, exception handlers, and transaction boundaries are defined.

[0162] Finally, the conversion generation processing unit 2 generates Java code, configuration files, test assets, and deployment definitions by referring to the first and second intermediate representations. After quality gate determination, the results are recorded in the design information infrastructure 300, and the conversion history sub-vector of the GPS vector 800 is updated.

[0163] More specifically, in this embodiment, a COBOL core system that has been in operation for a long period of time may be the target of the conversion.

[0164] The COBOL source code to be converted may be uploaded via the user interface and stored on the storage server 190. The integrated management server 110 may accept project registrations and issue analysis tasks via the message queue server 180.

[0165] The structural analysis information, dependency information, and design metadata generated by the analysis server 120 may be recorded in the Reverse layer 301 of the design information infrastructure 300. This allows for an objective recording of design intentions such as rounding processes, special conditional branching for end-of-month processing, and interface specifications with peripheral batch systems.

[0166] In the trial conversion process using P-IR202, a specialized AI agent may refer to the database to extract the difficulty of ensuring the accuracy of the ROUNDED clause, the difficulty of batch interface conversion, the success or failure of external definition integration, and the need for exception handling reinforcement.

[0167] Based on the extraction results, the Plan layer 302 may record the correspondence between which design intent is inherited by which transformation rule, and the Design layer 303 may record which class, method, or exception handler realizes each design intent in the transformed Java code.

[0168] In evaluating functional accuracy at quality gate 501, in addition to the equivalence test results before and after conversion, the degree to which the design intent is retained may also be evaluated.

[0169] If quality gate 501 fails, for example, a loss of design intent, such as accuracy differences in rounding, may be identified, and improvement actions, sandbox verification, approval control, and reprocessing may be performed sequentially.

[0170] After passing through the quality gate, the conversion results, quality score, and improvement history are recorded in each layer of the design information infrastructure 300 and may be reflected in the conversion history sub-vector of the GPS vector 800. This allows knowledge gained from similar COBOL to Java conversions to be reused in subsequent projects.

[0171] As an example of each threshold, thresholds corresponding to functional accuracy, security robustness, structural integrity, overall quality, analytical completeness, and object quality may be pre-set.

[0172] [20. Example 2: Reconversion and Application to Subsequent Projects] When further migrating a system that was converted from COBOL to Java three years ago to a cloud-native format, the Provenance accumulated during the previous project may be referenced.

[0173] The system vector 900 and GPS vector 800 generated in the new project may be searched for similarity with vectors stored in the past design information infrastructure 300, and successful and unsuccessful design intent inheritance patterns from the previous transformation may be extracted.

[0174] The scoring processing unit 403 may perform scoring that reflects the history and preferentially adopt patterns with high reliability. This makes it possible to improve the accuracy of inheriting the design intent and the efficiency of quality improvement with each re-conversion.

[0175] During re-conversion, a CS-IR201 file for the newly analyzed Java system may be generated, and a difference analysis may be performed with the information stored in the Reverse layer 301 of the previous project. This allows for a structural understanding of the changes since the last conversion.

[0176] In this embodiment, the re-conversion requirements may include not only cloud-native development but also support for Java version updates.

[0177] Furthermore, by performing a similarity search that reflects the transformation history sub-vector of GPS vector 800, successful design intent inheritance patterns and quality-improved patterns from the previous transformation may be extracted with high priority.

[0178] Furthermore, when formulating the transformation plan in Plan layer 302, history information regarding which design intents were appropriately inherited by which transformation rules may be referenced. After re-transformation, the lineage depth and confidence level of the GPS vector 800 may be updated.

[0179] [21. Example 3: Layer involvement control by conversion generation path] In a refactoring-type full modernization, the involvement of the Reverse layer 301 may be increased to maintain consistency with the existing structure. In the refactoring type, the weight α for structural search may be set greater than the weight β for semantic search, prioritizing transformation patterns that have high consistency with the existing structure.

[0180] In the Greenfield model, since emphasis is placed on the new architecture, the involvement of the Design layer 303 may be increased. In the Greenfield model, the weight β for semantic search may be set higher than the weight α for structural search, prioritizing semantically equivalent transformation patterns or transformation patterns that are highly suitable for the new architecture.

[0181] In the Hybrid type, the degree of involvement of the Reverse layer 301, Plan layer 302, and Design layer 303 may be dynamically switched depending on the complexity or business importance of the module. In the Hybrid type, based on the complexity evaluation or business importance evaluation for each module, the Refactoring type may be dynamically controlled to be applied to modules above a predetermined threshold, and the Greenfield type to modules below the predetermined threshold. This embodiment may be applied, for example, to the modernization of a large-scale financial system.

[0182] [22. Example 4: Inheritance of Design Intent in Source Splitting and Integration] This embodiment describes a case where the design intent is preserved when dividing a large monolithic module or integrating multiple distributed modules.

[0183] In the case of source partitioning, the business function units and dependencies within the module may be analyzed in the Reverse layer 301, and the partition boundary may be determined in the Plan layer 302 based on the design intent. The design information recorded in the Design layer 303 is inherited by each partitioned module, and the genealogical relationship with the original module may be recorded in the GPS vector 800 of each module.

[0184] In the case of source integration, the design intentions of multiple modules may be recorded in the Reverse layer 301, and then an integration plan may be formulated in the Plan layer 302. If there are conflicting design intentions, a quality feedback loop may propose a solution. [23. Synergistic effects of integrated configuration]

[0185] In the first embodiment, a cross-project autonomous learning loop may be formed by the mutual cooperation of trial transformation feedback using the first intermediate representation, hybrid scoring, and history accumulation by the design information infrastructure 300.

[0186] Specifically, information regarding the conversion generation extracted through the trial conversion process may be stored in the design information infrastructure 300 and the database, and the scoring processing unit 403 may perform history-referenced scoring by referring to the stored information, and the results may be reflected in improving the accuracy of the subsequent second intermediate representation generation and conversion generation processes.

[0187] Furthermore, by updating the results of the conversion generation process and the quality gate judgment results as proof history, the accuracy of conversion pattern selection in subsequent projects may be continuously improved.

[0188] [Second Embodiment] (Overall system configuration in the second embodiment) Next, the software design information recovery system 2010 according to the second embodiment will be described with reference to Figures 16 to 39. The software design information recovery system 2010 according to the second embodiment also functions as a software conversion generation system and a software quality issue management system. Figure 16 is a block diagram showing the configuration of the software design information recovery system 2010 according to the second embodiment. As shown in Figure 16, the software design information recovery system 2010 includes a control unit 2011 and a storage unit 2012. The control unit 2011 realizes the functions described below by executing the program 2012a stored in the storage unit 2012.

[0189] In the following description, "NFRNode" refers to the "Non-Functional Requirements Management Node," and "DRCG (Deficiency Remediation Code Generation)" refers to the "Deficiency Remediation Code Generation Unit." "ResponsibilityGuard" refers to the "Responsibility Boundary Control Unit." The Deficiency Remediation Code Generation generates code in the same language to fill in the missing or incomplete parts detected by reverse engineering. In the second embodiment, the code is rewritten in the converted language. This reduces the risk of quality issues caused by conversion (e.g., conversion by LLM) compared to rewriting in the language before conversion.

[0190] Figure 17 is a block diagram showing the configuration of the design information infrastructure 2300. As shown in Figure 17, the design information infrastructure 2300 of the software design information restoration system 2010 includes a first design information layer (Reverse layer) 2301, a second design information layer (Plan layer) 2302, a third design information layer (Design layer) 2303, CS-IR2201, P-IR2202, RD-IR2203, I-IR2204, CO-IR2205, and DP-IR2206. Although these are denoted by different reference numerals than those in the first embodiment for illustrative purposes, they realize at least the same functions as the first embodiment.

[0191] The design information infrastructure 2300 in the second embodiment is not simply a three-layer parallel structure, but a time-series chain structure in which the three layers are built in stages along the time series of the transformation generation process (reverse engineering process → planning process → design and implementation process). Specifically, (i) as the first stage in the time series, the first design information layer 2301 (Reverse layer) is built to hold the current structure analysis results (CS-IR2201) of the target software. (ii) As the next stage, the second design information layer 2302 (Plan layer) is built to hold the transformation generation goal and transformation generation strategy, and P-IR2202, RD-IR2203, and I-IR2204 are stored here. (iii) As the final stage, the third design information layer 2303 (Design layer) is built to hold the design information of the software system after transformation or generation, and CO-IR2205 and DP-IR2206 are stored here. Between these three layers, directed edges are created on the graph database 401a that represent time-series chains (for example, "(ReverseNode)-[:PRECEDES]→(PlanNode)-[:PRECEDES]→(DesignNode)"), and the time-series relationships are explicitly maintained.

[0192] Figure 18 is a schematic diagram showing the overall configuration of the software design information recovery system 2010 in the second embodiment. The software design information recovery system 2010 (hereinafter referred to as "System 2010") consists of the same physical or logical device as the integrated management server 2110, analysis server 2120, UI server 2130, AI server 2140, relational database server 2150, document database server 2160, integrated knowledge base server (including DIT server) 2170, message queue server 2180, storage server (including Docker Sandbox) 2190, and dedicated design information infrastructure server 2195.

[0193] In this disclosure, “reverse engineering” means the process of reconstructing the design information of a target software from source code files, related objects, design documents, requirements definitions, specifications, API specifications, or similar analysis targets through syntactic analysis, dependency analysis, data flow analysis, and referencing an integrated knowledge base. “Design information” may include at least design intent, processing overview, dependencies, architectural relationships, non-functional requirements, and design information after conversion and generation. In the second embodiment, the software design information reconstruction system means a system that analyzes a single or multiple source files constituting the target software, reconstructs design information relating to the current structure of the target software, design information relating to the software after conversion or generation, and design information relating to the goals or strategies used for said conversion or generation, and stores them in a design information infrastructure. In the second embodiment, the software design information restoration system stores a current intermediate representation in a first design information layer, stores a conversion and generation goal including the target programming language, target execution environment, and performance requirements after the software conversion or generation, as well as a conversion and generation strategy including the conversion rules, conversion order, and constraints to be applied, in a second design information layer, and stores the design information of the software system after the software conversion or generation in a third design information layer.

[0194] System 2010 may, for example, be configured as a group of multiple servers. The group of multiple servers may include an integrated management server 2110, an analysis server (syntactic analysis server) 2120, a UI server 2130, an AI server 2140, a relational database server (SQL database server) 2150, a document database server (NoSQL database server) 2160, a graph / vector database server 2170, a DIT server 2172, a task queue server (message queue server) 2180, a web storage server (storage server) 2190, and a dedicated design information infrastructure server 2195.

[0195] [Single source analysis unit, splitting unit, inference unit, verification unit, integration unit, multiple source summary analysis unit] Figure 19 is a functional block diagram of system 2010. The single source analysis unit 2211 shown in Figure 19 is implemented on the analysis server (syntactic analysis server) 2120. The single source analysis unit 2211 performs syntactic analysis on a single source file that constitutes the target software, generates an abstract syntax tree (AST) corresponding to the source file, and extracts syntactically parseable static information, including at least the number of instructions, the number of branches, and call relationships, on a function or paragraph basis within the source file. The single source analysis unit 2211 may be implemented using a syntactic analysis engine that extends the tree-sitter library. The target languages ​​for syntactic analysis in the second embodiment include COBOL, Java, Python, TypeScript, Go, Pascal, and multiple other languages. The single source analysis unit 2211 may be configured to perform parallel analysis processing to shorten analysis time by analyzing multiple source files in parallel.

[0196] In the second embodiment, the "single source file" that the single source analysis unit 2211 targets for syntactic analysis refers to individual source code files from the source code group that constitutes the target software input to system 2010, which are identified by a unique file identifier (path name and file name) on the file system, and are treated as a single logical analysis unit. A "single source file" includes, for example, a ".java" file in Java, a ".ts" file in TypeScript, a ".py" file in Python, a ".cob" or ".cbl" file in COBOL, and a ".pas" file in Pascal. If there are multiple source files that constitute the target software, the single source analysis unit 2211 processes them individually as a "single source file".

[0197] Furthermore, in the second embodiment, the phrase "as a unit of functions or paragraphs" from which the single source analysis unit 2211 extracts static information refers to structural subunits within a source file, which are the smallest or intermediate division units of processing logic in the source code. "Function" includes procedures in procedural languages, functions in functional languages, methods in object-oriented languages, and named code blocks equivalent thereto. "Paragraph" refers to a paragraph in the COBOL language, which is a unit in a procedure division that groups one or more procedural statements together with an identifier. For each of these units, the single source analysis unit 2211 independently extracts syntactically parseable static information, associates the extraction result with the identifier of the unit (function name, method name, or paragraph name), and stores it in the first design information layer 2301 of the design information infrastructure 2300.

[0198] In the second embodiment, "parsable static information" means information that can be extracted without executing the source file by performing syntactic analysis (static analysis) on the target source file, and which quantitatively or classificatively expresses the structural properties of the source file or its functions or paragraphs. The "parsable static information" extracted by the single source analysis unit 2211 includes at least the following three types: (i) Instruction count: The total number of statements contained in each function or paragraph, including assignment statements, conditional statements, iterative statements, input / output statements, function calls, and database access statements. (ii) Branch count: The number of conditional branch structures contained in each function or paragraph, expressed as the sum of branching points resulting from if / else statements, switch / case statements, and ternary operators. (iii) Call relationship: This refers to a relationship in which a function or paragraph calls another function, method, paragraph, or library API, and a relationship in which a function or paragraph is called by another function, method, or paragraph, and is expressed as a pair of identifiers for the caller and the called party. The single source analysis unit 2211 extracts the "parsable static information" as metadata derived from the nodes of the abstract syntax tree (AST), and stores the metadata in the first design information layer 2301.

[0199] The single-source analysis unit 2211 asynchronously submits analysis tasks to multiple source files constituting the target software via the message queue server 2180, and performs analysis (parallel analysis processing) in parallel using multiple worker threads or worker processes running on the analysis server (syntactic analysis server) 2120. Each worker independently performs syntax analysis, abstract syntax tree generation, static information extraction, and static performance metric extraction 2421 for each source file retrieved from the queue. When the processing results between workers are written to the first design information layer 2301, collision avoidance is prevented by a unique source file identifier and tenant identifier. Due to the parallel analysis processing, for example, for a source code group of 10,000 files, the processing time is reduced inversely proportional to the number of workers compared to single-thread execution.

[0200] In the second embodiment, "static information" refers to all information that can be extracted by lexical analysis and syntactic analysis (hereinafter collectively referred to as "syntactic analysis") of the source code of the target software without executing the source code. In contrast, in the second embodiment, "dynamic information" refers to information obtained by executing the target software, or artifacts after conversion or generation of the target software (including executable modules, container images, and other deployment components), in an execution environment and observing the behavior during execution, and includes measured response time, measured throughput, measured CPU usage, and measured memory usage. In the second embodiment, static information and dynamic information are used complementaryly in each phase of software conversion or generation.

[0201] In the second embodiment, “static information” shall include at least a portion of each of the following elements: (a) node, edge, and source code location information constituting the abstract syntax tree (AST), (b) number of instructions in a function, method, paragraph, or procedural unit (including the number of executable statements and declaration statements), (c) number of branches for conditional branching, iteration control, and exception handling, (d) call relationships of functions, methods, or procedures (including the correspondence between callers and calledes, the call graph, and the presence or absence of recursive structures), (e) identifier information (variable names, function names, class names, namespaces, and scope information), (f) type information (explicit type declarations, type inference results, and type hierarchy relationships), (g) information regarding loop structures (loop depth distribution, nesting relationships, and intra-loop call structure), (h) information regarding input / output structures (locations and number of file input / output, network input / output, and console input / output), ( i) Information regarding database access (locations and number of select queries, insert queries, update queries, and delete queries, and the number of code locations where an inefficient access pattern (N+1 query pattern) is observed in static analysis, where a database query for retrieving child records is repeatedly issued for each parent record after the parent record has been retrieved), (j) Data flow information (chains of variable definitions and usage, and results of live variable analysis), (k) Control flow information (basic blocks, and control flow graphs), (l) Dependency information (inter-module dependencies, inter-package dependencies, and dependencies to external libraries), (m) Cyclomatic complexity, Halsted index, nesting depth, and other complexity metrics, and (n) Other arbitrary information that can be extracted by syntactic and static analysis. The static information in the second embodiment does not necessarily have to include all of the above elements, and may be configured to select the extraction targets according to the language, scale, and use of the target software.

[0202] Figure 20 is a diagram illustrating the static performance index 2421. As shown in Figure 20, in the second embodiment, the static performance index 2421 refers to a specific subset of static information used to derive the performance target value 2422 for software-converted or generated artifacts. Specifically, the static performance index 2421 includes cyclomatic complexity, loop depth distribution, estimated number of I / O operations, and estimated number of database accesses (including the number of code locations where N+1 query patterns are recognized in static analysis), all of which are included in each element of the enumerated static information. Therefore, the static performance index 2421 is a true subset of the static information, and in particular corresponds to a performance-related subset extracted and stored as the basis for deriving the performance target value 2422.

[0203] Static information is extracted by the single-source analysis unit 2211 and / or the multiple-source summary analysis unit 2216. The single-source analysis unit 2211 extracts static information on a per-source-file basis by parsing the syntax of individual source files that constitute the target software. The multiple-source summary analysis unit 2216 extracts inter-module dependencies, call graphs, and other static information that should be understood across multiple source files that constitute the target software. The single-source analysis unit 2211 and the multiple-source summary analysis unit 2216 may be configured to use a syntax analysis engine that extends the tree-sitter library and to achieve language-independent static information extraction for COBOL, Java, Python, TypeScript, Go, Pascal, and multiple other languages ​​based on language-specific pattern dictionaries (e.g., config / io_patterns / *.yaml). The pattern dictionaries may be externalized in YAML format to allow maintenance by non-engineer operators.

[0204] In the second embodiment, the extracted static information is stored in the first design information layer 2301 of the design information infrastructure 2300 as a current intermediate representation CS-IR2201 by the integration unit 2215. In addition, the static performance index 2421, which forms part of the static information, is stored via the performance index storage unit 2218 in the non-functional requirements management node belonging to the second design information layer 2302 as the basis for deriving the performance target value 2422. Since the static information can be extracted without executing the source code of the target software, it has the technical significance of (i) enabling safe and high-speed information acquisition without placing and executing the target software in a sandbox environment, (ii) enabling non-destructive analysis that does not cause side effects to external systems such as network communication or database updates during execution, and (iii) providing highly reproducible analysis results that are not affected by the environment during execution (influence of OS version, library version, and load conditions during execution). Furthermore, by comparing the performance target value 2422 derived based on static information with dynamic information (actual response time, actual throughput, actual CPU usage, and actual memory usage) obtained by running the converted or generated artifacts in a sandbox environment (hereinafter referred to as "hybrid comparison"), it becomes possible to make a comprehensive performance determination that includes runtime bottlenecks (cache misses, garbage collection delays, I / O contention, and other runtime events) that are not detected at the parsing stage.

[0205] The splitting unit 2212 divides a single source file into units of a predetermined maximum number of tokens (e.g., 8000 tokens) or a predetermined maximum number of functions (e.g., 50 functions). The splitting unit 2212 may be implemented on the analysis server 2120 or the AI ​​server 2140. The splitting process performed by the splitting unit 2212 avoids the context length limitation when the inference unit 2213, described later, uses a large-scale language model, and also functions as a preprocessing step to enable parallel inference.

[0206] The inference unit 2213 uses a local large-scale language model running on the AI ​​server 2140 to generate a design intent indicating the purpose of the processing that the source file aims to achieve, and a processing summary that summarizes the operation of the source file, for each unit divided by the division unit 2212. The inference unit 2213 may be configured to perform inference using a local large-scale language model running within the system 2010 without transmitting data to external services. This prevents the leakage of source code or design information to the outside and can meet high security requirements (especially financial-grade confidential information protection requirements).

[0207] In the second embodiment, the "design intent" generated by the inference unit 2213 refers to information expressed in natural language about the business purpose, functional purpose, or technical purpose that the target source file or its function or paragraph is intended to achieve, and is information that indicates "why the code exists." For example, it may be given as "calculate the customer's monthly billing amount," "determine whether inventory allocation has been successful," or "verify the validity of the user authentication token."

[0208] Furthermore, in the second embodiment, the "process summary" generated by the inference unit 2213 refers to information that summarizes the content of the processing performed by the target source file or its function or paragraph as a chronological procedure including its input, intermediate processing, and output, in natural language, and is information that indicates "what the code does." The process summary is described, for example, as follows: "(i) receive a customer ID as an argument, (ii) search the transaction history table using the customer ID as a key, (iii) sum up the amounts of the acquired transaction details, and (iv) return the summation result as a return value." The inference unit 2213 provides the portion of the single source file that has been split by the splitting unit 2212 as input to the large-scale language model, and generates the design intent and the process summary as the inference output of the large-scale language model.

[0209] The local large-scale language model used by the inference unit 2213 is a large-scale language model deployed to operate within the AI ​​server 2140, and input prompts to the model and output inference results from the model are not transmitted outside the boundaries of system 2010, including the AI ​​server 2140. Examples of implementations include (a) an open-source large-scale language model deployed directly on the GPU resources of the AI ​​server 2140, or (b) an inference server deployed on an isolated network segment within the same data center, accessed by internal API calls from system 2010. In either implementation, the inference unit 2213 does not transmit any data to external cloud services. This satisfies the high security requirements of financial institutions and the like.

[0210] The verification unit 2214 compares the design intent and processing overview generated by the inference unit 2213 with the abstract syntax tree output by the single source analysis unit 2211, and verifies whether the function names, argument structures, return types, and call relationships included in the design intent and processing overview logically correspond to the corresponding nodes in the abstract syntax tree. This suppresses hallucination (such as the inclusion of non-existent APIs or functions) that may occur in the output of large-scale language models, and allows for the restoration of accurate design information. The verification unit 2214 may also be configured to perform an iterative verification process in which, if it detects an inconsistency between the design intent or processing overview generated by the inference unit 2213 and the abstract syntax tree output by the single source analysis unit 2211, it generates a re-inference instruction to the inference unit 2213 to identify the inconsistency and causes it to re-execute the inference. This allows for a gradual improvement in the logical consistency and accuracy of the restored design information.

[0211] The verification unit 2214 verifies the logical correspondence between the design intent and processing overview generated by the inference unit 2213 and the abstract syntax tree output by the single-source analysis unit 2211 by individually comparing the following four elements: (i) correspondence of function names, (ii) correspondence of argument structures, (iii) correspondence of return types, and (iv) correspondence of call relationships. The verification unit 2214 determines that the logical correspondence of the design intent and processing overview has been confirmed only if a match is confirmed for all of (i) to (iv), and permits the integration unit 2215 to store it in the first design information layer 2301.

[0212] The iterative verification process performed by the verification unit 2214 follows these steps: (i) The verification unit 2214 generates a reinference instruction to identify inconsistencies. (ii) The reinference instruction is sent to the inference unit 2213, which then performs reinference using the instruction as an additional context. (iii) The verification unit 2214 performs another comparison of the design intent and processing overview obtained through reinference. (iv) The iteration continues until a logical correspondence is confirmed for all verification items, or until a preset maximum number of iterations is reached.

[0213] The integration unit 2215 stores the design intent and processing overview, whose logical correspondence has been confirmed by the verification unit 2214, as a current intermediate representation CS-IR2201 in the first design information layer 2301 of the design information infrastructure 2300. The integration unit 2215 may also be configured to integrate the contents of existing design documents or business documents associated with the target software into the design information infrastructure 2300. This makes it possible to construct more comprehensive design information that includes not only the source code analysis results but also business requirements, etc. Furthermore, the integration unit 2215 may be configured to embed the design information stored in the design information infrastructure 2300 into a vector space and store it in the vector database 402a and graph database 401a. This makes it possible to search based on structural relationships and semantic similarities, and similar patterns can be efficiently utilized in subsequent software conversions. In addition, the integration unit 2215 may be configured to fill in 176 design elements defined in a predetermined template with the design intent and processing overview generated by the inference unit 2213. This allows for the standardization and structuring of the generated design information, enabling smooth information sharing to subsequent processes.

[0214] The "existing design documents or business documents" that the integration unit 2215 integrates into the design information infrastructure 2300 include, for example, requirements definition documents, functional design documents, detailed design documents, screen design documents, database design documents, infrastructure design documents, business flow diagrams, business regulations, business procedures, operation procedures, incident response manuals, API specifications, external interface specifications, etc. The integration unit 2215 reads these documents and adds the extracted business objectives, functional requirements, and non-functional requirements to the existing nodes of the first design information layer 2301, associating them with the existing nodes.

[0215] The integration unit 2215 embeds the design information stored in the design information infrastructure 2300 into a vector space by converting the natural language portion into real-valued vectors using a sentence embedding model or document embedding model, converting the structural information into a structural path representation, and then storing them in the vector database 402a and graph database 401a. This enables hybrid search that combines semantic similarity and structural similarity.

[0216] The "176 design elements defined in a predetermined template" that the integration unit 2215 fills in consist of the following categories: system components, business function elements, data elements, processing elements, screen elements, report elements, interface elements, non-functional elements, operational elements, migration elements, regulatory / compliance elements, and intellectual property elements. The integration unit 2215 extracts the relevant information from the design intent and processing overview generated by the inference unit 2213 and fills in the fields of each item.

[0217] The multiple source summary analysis unit 2216 analyzes dependencies across multiple source files that constitute the target software, derives relationships between modules and a call graph, and integrates these relationships and call graphs into the first design information layer 2301. The multiple source summary analysis unit 2216 works in cooperation with the single source analysis unit 2211 to form a two-tiered analysis structure, deriving design information step by step from the details of individual files to the overall system picture. The single source analysis unit 2211 and the multiple source summary analysis unit 2216 may be configured to comprehensively analyze multiple asset types, including source code, database schemas, API definitions, infrastructure description code, and container definitions. This allows for the comprehensive reconstruction of the overall system design information, encompassing a wide range of assets that constitute the software.

[0218] The single-source analysis unit 2211 and the multiple-source summary analysis unit 2216 form a two-tiered structure for progressively deriving design information for the target software. The single-source analysis unit 2211 obtains detailed design information at the individual source file level, while the multiple-source summary analysis unit 2216 performs dependency analysis across multiple source files, deriving and integrating the relationships between modules and the call graph.

[0219] The "multiple asset types" that the single-source analysis unit 2211 and the multiple-source summary analysis unit 2216 analyze in an integrated manner include source code, database schemas, API definitions, infrastructure description code, and container definitions. A dedicated analyzer is used for each asset type, and the analysis results are normalized into a common schema and integrated into the first design information layer 2301.

[0220] In the second embodiment, software design information reconstruction is achieved through structural analysis by a single-source analysis unit 2211 and a multiple-source summary analysis unit 2216, generation of inference units by a division unit 2212, generation of design intent and processing overview by an inference unit 2213, logical correspondence confirmation with an abstract syntax tree by a verification unit 2214, and storage in the design information infrastructure 2300 by an integration unit 2215. As a result, the second embodiment achieves structural design information reconstruction based on analysis results, rather than simply generating natural language.

[0221] [Static performance indicator extraction unit, performance indicator storage unit, non-functional requirements management node, performance target value] The static performance indicator extraction unit 2217 extracts static performance indicators 2421, including cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses, during the syntactic analysis process by the single-source analysis unit 2211. Here, the estimated number of database accesses includes the number of code locations where an inefficient access pattern (hereinafter referred to as the N+1 query pattern) is observed in static analysis, in which a database query for retrieving child records is repeatedly issued for each parent record after the parent record has been retrieved.

[0222] The static performance metric extraction unit 2217 extracts, more specifically, the following metrics: (a) cyclomatic complexity (per function and per module), (b) loop depth distribution (depth_1, depth_2, depth_3, depth_4_plus, and max_depth), (c) estimated number of I / O operations (file_io, network_io, console_io), and (d) estimated number of database accesses (sql_select, sql_insert, sql_update, sql_delete, nosql_read, nosql_write, and the number of potential N+1 query locations). The static performance metric extraction unit 2217 reads language-specific pattern dictionaries (e.g., config / io_patterns / *.yaml) and detects characteristic descriptions of I / O and database access for each language using a combination of regular expressions and abstract syntax tree node patterns. The pattern dictionaries are externalized in YAML format, which may allow maintenance by non-engineer operators.

[0223] The performance indicator storage unit 2218 stores the static performance indicators 2421 extracted by the static performance indicator extraction unit 2217 in a non-functional requirements management node (synonymous with NFRNode; hereinafter the same) belonging to the second design information layer 2302 of the design information infrastructure 2300, as the basis for deriving the performance target value 2422 after software conversion or generation. The non-functional requirements management node associates and holds the upper limit of response time, the lower limit of throughput, the upper limit of CPU usage, and the upper limit of memory usage. Specifically, the non-functional requirements management node has the following fields: (a) max_response_time_ms: upper limit of response time, (b) min_throughput_tps: lower limit of throughput, (c) max_cpu_usage_pct: upper limit of CPU usage, (d) max_memory_mb: upper limit of memory usage.

[0224] The performance target value 2422 can be referenced as a common target value in the conversion generation process across multiple iterations 2412, and is used as a basis for comparison with measured performance values ​​obtained by running the code, executable module, or deployment configuration obtained after software conversion or generation in a sandbox environment. The use of the performance target value 2422 as a basis for hybrid comparison is described in detail below. System 2010 runs the converted or generated artifacts in a sandbox environment (Docker Sandbox on storage server 2190, maintaining isolation with network=none and cap_drop=ALL) to measure response time, throughput, CPU usage, and memory usage, and performs performance defect detection and severity determination by comparing these measured values ​​with the performance target value 2422 obtained from the non-functional requirements management node of the second design information layer 2302. The performance target value 2422 used here is a theoretical upper or lower limit derived from the static performance index 2421. By comparing it with measured values ​​(hybrid comparison), it becomes possible to make a comprehensive performance determination that includes runtime bottlenecks (cache misses, garbage collection delays, I / O contention, etc.) that are not detected at the parsing stage.

[0225] "The performance target value being referable as a common target value in the transformation generation process across multiple iterations" means that the performance target value 2422 is associated with the unique identifier and version identifier of the non-functional requirements management node, and each iteration 2412 refers to the same identifier in principle. This makes it possible to compare parent and child iterations.

[0226] "Hybrid comparison" is achieved by deploying the converted artifact to a Docker Sandbox environment, having the performance audit unit 2319 acquire actual performance values, and having the target value comparison unit 2320 acquire performance target values ​​2422 from the non-functional requirements management node, comparing them item by item, and calculating the deviation rate.

[0227] As shown in Figure 20, an example of the derivation formula for the performance target value of 2422 in the second embodiment is shown below (see Figure FIG-D-6). max_response_time_ms=BASE_RT×(1+W_CC×(CC / CC_NORM)+W_IO×(IO / IO_NORM)+W_DB×(DB / DB_NORM)+W_LD×(LD / LD_NORM)). min_throughput_tps=BASE_TPS / (1+W_DB×(DB / DB_NORM)+W_NPO×(N+1 / NPO_NORM)). max_cpu_usage_pct=min(95,BASE_CPU+W_LD×(LD-2)). max_memory_mb=BASE_MEM×(1+W_IO×(file_io / IO_NORM)+W_LD×(depth_4+ / LD4_NORM)). Here, BASE_RT=200ms, BASE_TPS=100TPS, W_CC=0.5, W_IO=0.3, W_DB=0.7, etc., are coefficients determined by empirical rules. These coefficients and reference values ​​are examples and may be adjusted according to operational results.

[0228] The performance target value 2422 can be referenced as a common target value across multiple iterations 2412. Specifically, when the retry iteration management unit 2332, described later, manages both the parent and child iterations, the same performance target value 2422 is referenced in both. This makes it possible to determine that performance improvements in the child iteration have reliably resolved the failure judgment in the parent iteration.

[0229] In the second embodiment, the non-functional requirements management node belonging to the second design information layer 2302 is a node that holds non-functional requirements to be met after software conversion or generation, and holds a performance target value 2422 derived based on static performance indicators 2421 extracted by the static performance indicator extraction unit 2217. The performance target value 2422 is referenced as a common target value in the conversion generation process across multiple iterations and is used for comparison with measured performance values ​​obtained by running the code, executable module, or deployment configuration generated in each iteration in a sandbox environment.

[0230] In the second embodiment, the non-functional requirements management node belonging to the second design information layer is a node that holds non-functional requirements to be met after the conversion or generation of the software, and holds performance target values ​​derived based on static performance indicators extracted by the static performance indicator extraction unit. The performance target values ​​are referenced as common target values ​​in the conversion generation process across multiple iterations and are used for comparison with measured performance values ​​obtained by running the code, executable module, or deployment configuration generated in each iteration in a sandbox environment.

[0231] [Quality Evaluation Department (4-axis quality evaluation)] Figure 21 is a diagram illustrating four-axis quality evaluation. As shown in Figure 21, the system 2010 may further be configured to include a quality evaluation unit that performs four-axis quality evaluation, including functional quality, structural quality, security quality, and performance quality, on the information stored in the design information infrastructure 2300. The quality evaluation unit in the second embodiment is embodied as a multi-axis quality gate unit 2322, which will be described later, and ensures the objective quality of the restored design information from multiple perspectives. In contrast to the three-axis quality gates (functional accuracy 511, security robustness 512, and structural soundness 513) described in the first embodiment, the multi-axis quality gate unit 2322 in the second embodiment is configured to complement or embody the first embodiment in that it performs quality gate determination on four axes, adding a performance axis to these three axes.

[0232] In the second embodiment, the four-axis quality evaluation unit is embodied as a multi-axis quality gate unit 2322, and performs quality evaluation on each of the following axes: (a) functional quality, (b) structural quality, (c) security quality, and (d) performance quality. These four axes function as evaluation axes that comprehensively guarantee the objective quality of the information stored in the design information infrastructure 2300.

[0233] [Static Performance Metrics Viewer (Screen S-01)] Figure 22 is a screen transition diagram displayed on the display unit of the user terminal 20. Figures 27 to 35 are diagrams showing examples of screens displayed on the display unit of the user terminal 20. Figure 38 is a diagram illustrating the screens displayed on the display unit of the user terminal 20. The system 2010 may further include a static performance indicator display unit connected to the user terminal 20 and providing a static performance indicator viewer 2401 (hereinafter referred to as screen S-01; see Figure 27) to the display unit of the user terminal 20. Screen S-01 may display the cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses extracted by the static performance indicator extraction unit 2217 in parallel using multiple individual card-type user interface components (hereinafter referred to as metric cards), and may also highlight code locations where an inefficient access pattern (N+1 query pattern) is observed in static analysis, where a database query for obtaining child records is repeatedly issued for each parent record after obtaining the parent record, by adding a warning icon.

[0234] Each metric card on screen S-01 displays the following indicators: (a) Cyclomatic complexity: average and maximum cyclic complexity at the function and module levels, (b) Maximum nesting depth: max_depth of the loop depth distribution, (c) Estimated I / O count: breakdown and total of file_io, network_io, and console_io, (d) Estimated database access: breakdown and total of sql_select, sql_insert, sql_update, sql_delete, nosql_read, and nosql_write, as well as the number of potential N+1 queries (with a warning icon). Each metric card is displayed with a gradual color or symbol (e.g., normal, caution, and warning) depending on the indicator value, and is clearly shown as the basis for deriving the performance target value 2422 stored in the non-functional requirements management node. Screen S-01 allows the user to get an overview of the relationship between the static indicators before conversion and the performance target value 2422 after conversion.

[0235] Screen S-01 consists of a header area at the top of the screen, a metrics card area in the center of the screen, a code location list area at the bottom of the screen, and a side panel on the right side of the screen, allowing for an overview of static performance metrics 2421, potential N+1 query locations, and converted performance target values ​​2422 on a single screen.

[0236] In the second embodiment, an iteration refers to each execution unit of a software transformation or generation. Each iteration may be assigned an iteration identifier, a parent iteration identifier, and a chain sequence number. Also in the second embodiment, a quality issue 2411 is detected during a transformation or generation process related to at least one of the first design information layer 2301, the second design information layer 2302, and the third design information layer 2303, and is recorded in association with the design information layer corresponding to the detected transformation or generation process.

[0237] [Issue Record Section: 5 categories and 9 statuses of quality issues] The issue recording unit 2311 operates on the DIT server 2172 and records quality issues 2411 detected during a transformation or generation process related to at least one of the first design information layer 2301, the second design information layer 2302, and the third design information layer 2303 in the design information infrastructure 2300, associating them with the design information layer corresponding to the detected transformation or generation process. The issue recording unit 2311 may classify the quality issues 2411 into multiple categories, including at least specification violations (spec_violation), functional defects, structural problems, security vulnerabilities, and performance defects, and may be configured to record each category in the first design information layer 2301, the second design information layer 2302, or the third design information layer 2303. This enables integrated issue management, including performance issues.

[0238] "Recording each category in the first design information layer 2301, the second design information layer 2302, or the third design information layer 2303" includes assigning the recording layer for each category of specification violation, functional defect, structural problem, security vulnerability, and performance defect, according to the detected process or related intermediate representation stage.

[0239] Each quality issue 2411 has the following fields: (a) issue_id: an identifier that uniquely identifies the quality issue (in UUID format), (b) category: one of the five categories mentioned above, (c) subcategory: a detailed classification within the category (e.g., n_plus_one_query, missing_cache, inefficient_loop, etc.), (d) severity: a five-level severity scale (critical, high, medium, low, minor), (e) status: one of nine states (detected, recorded, inherited, selected_optional, selected_forced, addressed, verified) d (Verified), final_verified (Final Verification), mandatory (Required), (f)tenant_id: Tenant identifier (common to all tables, ensures tenant isolation), (g)project_id: Project identifier, (h)iteration_id: Identifier of iteration 2412 where the issue was detected, (i)originating_gate_fail_id (Cause gate identifier 2415), (j)must_resolve_flag (Forced resolution flag 2413), (k)mandatory_until_iteration_seq (Continuance instruction information 2414), (l)design_change_required: Design change required flag, (m)design_change_approved: Design change approved flag.

[0240] The configuration that "manages version information for each quality issue and records changes before and after resolution" includes the issue recording unit 2311 and the issue resolution determination unit 2314 managing issue_version, version_history, pre_resolution_snapshot, post_resolution_snapshot, and change_diff for each quality issue 2411, in order to comply with financial-grade audit requirements.

[0241] In the second embodiment, each quality issue 2411 may be uniquely identified by issue_id and managed in association with the asset ID of the target asset in the asset registry structure 600. This allows quality issues 2411 to be traceable within and across projects, with their history linked to individual source code files, design information, products, or related assets.

[0242] [Challenge Inheritance Department] The issue inheritance unit 2312 operates on the DIT server 2172 and inherits the quality issue 2411 to a node in the design information infrastructure 2300 that belongs to the design information layer corresponding to the downstream conversion or generation process, so that the quality issue 2411 can be referenced by the conversion or generation process downstream in the time series of the conversion or generation process. Specifically, the issue inheritance unit 2312 inherits the quality issue 2411 from the first design information layer 2301 (holding CS-IR2201) to the second design information layer 2302 (forming an IR chain in the order of P-IR2202, RD-IR2203, and I-IR2204), and from the second design information layer 2302 to the third design information layer 2303 (holding CO-IR2205 and DP-IR2206), following the flow of the IR chain 200. When an issue is inherited, an edge "(QualityIssue)-[:INHERITED_FROM]→(QualityIssue)" is created on the graph database 401a. The issue inheritance unit 2312 has a DIT3 layer propagation function for the continuation instruction information 2414 and merges the "(QualityIssue)-[:MANDATORY_UNTIL{until_seq}]→(Iteration)" edge.

[0243] Regarding the configuration for "distinguishing the necessity of inheritance according to severity" and "continuing inheritance until resolution," the issue inheritance unit 2312 distinguishes between essential inheritance, conditional inheritance, and information sharing inheritance according to the severity of the quality issue 2411. Critical or high quality issues are continued to be inherited to the subsequent design information layer until they are resolved.

[0244] [Assignment Selection Department, Recommendation Engine Department] The issue selection unit 2313, through a screen provided by the UI server 2130, selects, based on user input or mechanical determination, the quality issues 2411 inherited by the issue inheritance unit 2312 that are to be resolved during conversion or generation.

[0245] The issue selection unit 2313 selects, based on user input or mechanical determination, the quality issues 2411 inherited by the issue inheritance unit 2312 that are to be resolved during conversion or generation.

[0246] The recommendation engine unit 2316 may be configured as part of the issue selection unit 2313, and it presents recommended selections to the user, taking into account the severity of the quality issue 2411, the scope of its impact, and the degree of relevance, which indicates the closeness of the correspondence with the code elements targeted by the quality issue 2411. This helps in determining the optimal conversion parameters for resolving the issue and reduces the burden on the user.

[0247] The recommendation engine 2316 makes its recommendations based on a recommendation score that is derived from severity, scope of impact, and relevance to code elements. The recommendation engine 2316 highlights quality issues 2411 with a recommendation score above a predetermined threshold as "recommended selections" on screen S-03.

[0248] In the second embodiment, “iteration” means each execution unit of software conversion or generation. Each iteration may be assigned an iteration identifier, a parent iteration identifier, and a chain sequence number. Also in the second embodiment, quality issues are detected during the conversion or generation process associated with at least one of the first, second, and third design information layers and recorded in association with the design information layer corresponding to the detected conversion or generation process.

[0249] In the second embodiment, "parent record" and "child record" are a pair of terms defined based on a one-to-many (1:N) relationship existing between any two data items in a data structure (including a relational database, an object-oriented data model, a graph database, or a document-oriented database) that permanently stores data. Among the one-to-many relationships, the record located on the "one" side (the referenced side) is called the "parent record", and the record located on the "many" side (the referencing side) is called the "child record". In the present disclosure, the one-to-many relationship includes, but is not limited to, the following cases. (a) In a relational database, when the foreign key stored in the child record refers to the primary key of the parent record (for example, a record (order) in the orders table is the parent record, and a record (order details) in the order_items table that refers to the primary key (order_id) of the order as a foreign key is the child record). (b) A relationship defined by a one-to-many relationship between entity classes in an object-relational mapper (hereinafter referred to as an OR mapper), where the record on the side referenced from an instance of the related entity class is the parent record, and the record on the side referenced as an instance of the related entity class is the child record. (c) Among two nodes connected by a directed edge in a graph database, the record corresponding to the start-side node of the directed edge is the parent record, and the record corresponding to the end-side node is the child record. (d) In an embedded array or reference type field in a document-oriented database, the document record on the side holding the embedded array or reference type field is the parent record, and each element of the embedded array or the document record pointed to by the reference type field is the child record.

[0250] In the second embodiment, the "N+1 query pattern" refers to an inefficient access pattern in which, when retrieving parent and child records, one database query (hereinafter referred to as the first query) is first executed to retrieve N parent records, and then, for each of the retrieved N parent records, a database query (hereinafter referred to as the second query) is repeatedly executed N times to retrieve the child records associated with that parent record. Specifically, the N+1 query pattern requires issuing a total of N+1 queries to the database server, and compared to retrieving parent records and associated child records in bulk with one or two queries using an SQL JOIN clause or subquery, or an eager loading mechanism provided by an ORM mapper, it results in an increased number of round trips to the database server, extended occupancy time of the database connection pool, and unnecessary consumption of network bandwidth, ultimately leading to increased response time and decreased throughput.

[0251] The single-source analysis unit 2211 detects, by static analysis of an abstract syntax tree generated from a single source file constituting the target software, a code location where an inefficient access pattern corresponding to the above N+1 query pattern is recognized in static analysis. Specifically, the single-source analysis unit 2211 (a) identifies an iteration control statement (e.g., for statement, while statement, foreach statement, or a node representing stream processing of a collection) in the abstract syntax tree, (b) identifies a method call that performs a database access (e.g., a function call that issues a SELECT statement, a call of a find method or query method provided by an OR mapper, or a call of an execute method of a database connection object) existing in the body of the iteration control statement, and (c) when it recognizes, as a dependency relationship on the abstract syntax tree, that a control variable or an iteration target collection of the iteration control statement depends on the result of another database access executed immediately before the iteration control statement, it detects the location as a location corresponding to the N+1 query pattern. The static performance index extraction unit 2217 calculates the total number of the detected locations as an element constituting the estimated number of database accesses.

[0252] [Problem Solving Judgment Unit] The problem solving judgment unit 2314 determines the resolution status of the quality problem 2411 selected by the problem selection unit 2313 for the code, executable module, configuration file, or deployment construct output by conversion or generation. The determination is carried out in the following three steps. (a) Static verification: Re-analyze the code after conversion and confirm that it does not match the detection rules. (b) Dynamic verification: Execute the code after conversion in a Docker Sandbox on the storage server 2190 and confirm the test pass rate and achievement of the performance target value. (c) Consistency verification: Confirm the consistency between the design information of the CO-IR 2205 and DP-IR 2206 stored in the third design information layer 2303 and the implementation artifacts (generated source code and deployment products).

[0253] "Defining the indicators and thresholds used for resolving issues individually for each category" means setting indicators and thresholds for each category of specification violations, functional defects, structural problems, security vulnerabilities, and performance defects, such as the match rate with the original specification, the pass rate of automatically generated tests, the architecture audit score, the security audit score, and the achievement rate of measured values / performance targets.

[0254] In the second embodiment, the main conversion or generation process is performed as rule-based processing based on a conversion dictionary, conversion rules, and design information infrastructure 2300, and the completion by the missing code generation unit 2317 may be applied in a limited manner at a later stage to resolve issues with the code, executable module, configuration file, or deployment components output as a result of the rule-based processing. Furthermore, the missing code generation unit 2317 may be activated only if the pre-determination unit 2333 determines that the cause of the quality issue 2411 is a defect that can be resolved by missing, insufficient, or local completion in the design information layer or generated code.

[0255] The issue resolution determination unit 2314 may include a missing information completion code generation unit 2317 (synonymous with DRCG; hereinafter the same) that uses a large-scale language model to generate local completion code for missing parts in the design information layer, on a unit basis of functions, methods, or classes that include the missing parts, for quality issues 2411 selected as targets for resolution.

[0256] [Missing Code Generation Unit (DRCG) and Responsibility Boundary Control Unit (G1~G7)] The missing information completion code generation unit 2317 is implemented within the graph-based search extension generation agent (GraphRAGAgent) on the AI ​​server 2140 and uses a large-scale language model to generate local completion code for missing locations in the design information layer, on a unit basis of functions, methods, or classes containing the missing locations. In the second embodiment, the operating range of GraphRAGAgent is limited by the responsibility boundary control unit 2318.

[0257] With respect to "a limited code range equivalent to these," the scope of application of the completion code generated by the missing code completion code generation unit 2317 is treated as a limited code range that includes functions, methods, and classes, as well as COBOL paragraphs and sections, Pascal procedures or functions, Python module-level functions or classes, and Go package-level functions or methods.

[0258] The responsibility boundary control unit 2318 has a responsibility boundary control function that limits the scope of operation of the completion code generated by the missing code generation unit 2317 to local additions to existing code. The responsibility boundary control unit 2318 includes several responsibility guards (G1 to G7) listed below: (G1) Difference line limit guard: Limits the number of difference lines of the completion code to a predetermined ratio (20% in the first embodiment) of the total number of lines of the existing implementation. (G2) Existing test non-destructive guard: Ensures that all tests remain PASS. (G3) Framework change prohibition guard: Prohibits changes to the framework. (G4) DB engine change prohibition guard: Prohibits changes to the database engine. (G5) External interface change prohibition guard: Prohibits changes to the external interface. (G6) Architecture change prohibition guard: Prohibits changes to the architecture. (G7) Design information layer (DIT) structure modification prohibition guard: Prohibits modifications to the structure of the design information infrastructure 2300.

[0259] For the simultaneous application of G1 (maximum number of differing lines) and G2 (non-destructive testing of existing tests), the responsibility boundary control unit 2318 calculates the difference in the number of lines before and after the generation of the supplementary code. If the difference exceeds a predetermined ratio, it rejects the supplementary code. It also executes all existing test cases, and if either fails, it rejects the supplementary code. Only supplementary codes that pass both G1 and G2 are officially adopted.

[0260] The quality assurance in the second embodiment may be implemented based on at least three axes: functional quality, structural quality, and security quality, and may also be implemented as a four-axis quality gate by adding performance quality. Even when completion is performed by the missing code generation unit 2317, the completed deliverable is required to pass through the quality gate.

[0261] The upper limit on the number of differential lines in G1 described above is an operational and structural invariance constraint, and is a configuration unique to the present invention in that it guarantees the non-reproducibility of changes (reproducibility and audit trail) and non-destructive addability of implementations necessary for providing financial-grade SaaS. Specifically, if the missing code generation unit 2317 attempts to add a new class, G3 and G6 are activated to check the impact on the architecture, and if the consistency with the existing layer structure is broken, the addition is rejected. Such guard activations are recorded in the DIT audit log (audit_log) and are subject to subsequent quality gate determination and history tracking by the traceability unit 2315.

[0262] [Traceability Department] Figure 37 is a functional block diagram of system 2010. The traceability unit 2315 (see Figure 37) tracks the entire state transition of quality issue 2411, including recording, inheritance, selection, and resolution decisions performed after detection, as well as re-recording performed when it is detected again as a quality issue based on the same or corresponding cause, across multiple intermediate representation stages of the conversion generation process. Specifically, the traceability unit 2315 tracks the state of quality issue 2411 across six stages of the IR chain, which consists of CS-IR2201, P-IR2202, RD-IR2203, I-IR2204, CO-IR2205, and DP-IR2206.

[0263] For state transitions including "re-recording," the traceability unit 2315 records a new issue with a new issue_id and creates an edge indicating a recurrence relationship between the new issue and the original issue if a new quality issue related to a quality issue that was previously determined to be resolved is detected again in a subsequent iteration.

[0264] Tracking quality issue states across the intermediate representation chain is achieved by recording the pre-transition state, post-transition state, the intermediate representation stage in which the transition occurred, the iteration identifier, the transition timestamp, the actor, and the reason for the transition as a single integrated record.

[0265] In the second embodiment, the intermediate representation chain refers to a structure in which the current intermediate representation, conceptual intermediate representation, requirements design integration intermediate representation, implementation intermediate representation, code output intermediate representation, and deployment intermediate representation are linked together in a time-series manner along the transformation generation process. The traceability unit 2315 tracks the entire state transition of the quality issue 2411 in the intermediate representation chain, including recording, inheritance, selection, and resolution decisions performed after detection, as well as re-recording performed when the quality issue is detected again based on the same or corresponding cause.

[0266] The issue selection unit 2313 selects, based on user input or mechanical determination, the quality issues 2411 inherited by the issue inheritance unit 2312 that are to be resolved during conversion or generation. The traceability unit 2315 tracks the entire state transition of the quality issues 2411, including recording, inheritance, selection and resolution determination performed after detection, and re-recording performed when the same or corresponding quality issue is detected again, across multiple intermediate representation stages of the conversion generation process. In the second embodiment, the intermediate representation chain refers to a structure in which the current intermediate representation, conceptual intermediate representation, requirements design integration intermediate representation, implementation intermediate representation, code output intermediate representation, and deployment intermediate representation are chained together in chronological order of the conversion generation process. The traceability unit 2315 tracks the state of the quality issues 2411 in the intermediate representation chain.

[0267] The intermediate representation trace display unit displays the state transitions of quality issues 2411 in the intermediate representation chain, which consists of the current intermediate representation, conceptual intermediate representation, requirements design integration intermediate representation, implementation intermediate representation, code output intermediate representation, and deployment intermediate representation, in a table format in which the intermediate representation divisions are arranged horizontally and the individual quality issues 2411 are arranged vertically. In addition, each iteration 2412 managed by the retry iteration management unit 2332 may be overlaid in the table format as a time hierarchy that can be switched and displayed.

[0268] [Performance Audit Department, Target Value Comparison Department, Severity Determination Department] The performance audit unit 2319 is implemented in the PerformanceAuditAgent on the AI ​​server 2140. The PerformanceAuditAgent is positioned as an eighth agent, symmetric to the existing specialized AI agents (GraphRAGAgent, DocumentIngestionAgent, ReportGenerationAgent, TestAgent, Language Specification Extraction Agent 430, ArchitectureAuditAgent, and SecurityAuditAgent) described in the first embodiment. The performance audit unit 2319 executes the converted code in a Docker Sandbox on the storage server 2190 (maintaining isolation with network=none and cap_drop=ALL) and measures response time, throughput, CPU usage, memory usage, and I / O volume. Load patterns defined in perf_profile (five profiles: idle, low, normal, peak, and stress) are applied to the measurements.

[0269] Regarding "performance metrics including predetermined resource utilization rates," the Performance Audit Unit 2319 measures response time, throughput, CPU utilization, memory usage, I / O volume, and database access volume, and records the relevant quality issue 2411 as a performance defect if any of them exceeds or falls below the performance target value 2422.

[0270] The target value comparison unit 2320 compares the performance target value 2422 obtained from the non-functional requirement management node (a component of RD-IR2203) in the second design information layer 2302 with the measured value measured by the performance monitoring unit 2319. The target value comparison unit 2320 calculates the deviation rate according to the following rules and determines the subcategory within the category. (a) When the response time exceedance rate exceeds 100%: subcategory = slow_response (severity = critical), (b) When the throughput shortage rate exceeds 50%: subcategory = insufficient_throughput (severity = critical), (c) Memory exceedance: subcategory = memory_leak, etc., (d) Potential N+1 measured confirmation: subcategory = n_plus_one_query.

[0271] Regarding the "predetermined judgment formula", the target value comparison unit 2320 determines the subcategory and severity based on the response time deviation rate, throughput shortage rate, CPU usage exceedance rate, memory usage exceedance rate, and N+1 query measured confirmation formula.

[0272] Regarding the requirement of "referable when selecting conversion parameters", the issue inheritance unit 2312 inherits the quality issue 2411 related to the performance defect to the non-functional requirement management node and makes it referable as a basis for judgment such as switching the conversion path in subsequent iterations, setting the application parameters of the defect completion code generation unit 2317, or temporarily relaxing the performance target value 2422.

[0273] The severity determination unit 2321 assigns a severity in five levels (critical, high, medium, low, minor) according to the deviation rate.

[0274] Regarding the assignment of the "highest severity level" and the "lowest severity level", the severity determination unit 2321 assigns the highest "critical" when the deviation rate exceeds the predetermined threshold, assigns the lowest "minor" when it falls within the predetermined range, and assigns high, medium, or low step by step for the intermediate region.

[0275] [Multi-axis quality gate section (4-axis quality gate section)] The multi-axis quality gate unit 2322 is implemented on the integrated management server 2110 and performs quality gate judgment on the following four axes: (a) Functional axis: TestAgent result (pass_rate≧0.80), (b) Structural axis: ArchitectureAuditAgent result (score≧0.75), (c) Security axis: SecurityAuditAgent result (score≧0.85), (d) Performance axis: PerformanceAuditAgent result (all performance target values ​​2422 achieved). If any axis fails, the forced correction marking unit 2331 is activated. The above values ​​are examples.

[0276] In a configuration that performs 4-axis quality gate judgment based on the "results of the performance audit unit 2319," the multi-axis quality gate unit 2322 integrates the functional test results, structural quality score, security quality score, and the sandbox measurement results and target value comparison results from the performance audit unit 2319 to determine whether all four axes meet the threshold requirements.

[0277] [Forced Removal Marking Section] The mandatory resolution marking unit 2331, when the multi-axis quality gate unit 2322 fails a 4-axis quality gate, assigns a mandatory resolution flag 2413 (must_resolve_flag) to the quality issues 2411 that caused the failure and whose severity is critical, high, or medium. At this time, the mandatory resolution marking unit 2331 records the following metadata: (a) originating gate identifier 2415 (originating_gate_fail_id): identifier of the 4-axis quality gate judgment job that was judged to have failed, (b) continuation instruction information 2414 (mandatory_until_iteration_seq): upper limit sequence number of the child iteration 2412 for which mandatory resolution is required. The default values ​​for severity in the continuation instruction information 2414 are critical: 3 (requires guaranteed resolution for 3 consecutive iterations), high: 2, and medium, low, and minor: 1.

[0278] In the "record together" configuration, when the forced resolution marking unit 2331 assigns the forced resolution flag 2413, it records the cause gate identifier 2415 and the continuation instruction information 2414 inseparably within a single transaction.

[0279] [Retry Iteration Management Department] The retry iteration management unit 2332 is implemented on the integrated management server 2110. Each iteration 2412 is assigned the following identifiers: (a) iteration_id: a unique identifier in UUID format, (b) parent_iteration_id: the parent iteration identifier (null for the first iteration), (c) seq: the sequence number (1, 2, 3, ...). The default retry limit is 5 times.

[0280] In a configuration where "the continuation instruction information determines the upper limit of the number of iterations for inheritance according to the severity of the quality issue," the continuation instruction information 2414 specifies the upper limit of the iteration sequence number for continuing the forced resolution flag 2413 for the quality issue 2411, and the higher the severity, the longer it is inherited.

[0281] [Pre-determination unit for generating missing code] Figure 25 is a diagram illustrating the processing of the missing code generation pre-determination unit 2333. The missing code generation pre-determination unit 2333 pre-determines whether the missing code generation unit 2317 (DRCG) is applicable based on the subcategory, impact scope, and structural scope of the quality issue 2411. In the second embodiment, the subcategories determined to be compatible with DRCG are as follows: Applicable: n_plus_one_query, missing_cache, inefficient_loop, excessive_io, memory_leak, db_connection_leak, excessive_db_access, slow_response. Not applicable: framework_change, db_engine_change, external_if_change, architecture_change. Only quality issues 2411 whose impact scope falls within function, method, or class are determined to be compatible with DRCG. Quality issue 2411, which was determined to be unsuitable for DRCG (Design Change Computation), is marked with "design_change_required=true" and is managed separately as a mandatory design change issue.

[0282] Regarding "structural scope," the structural scope used by the missing code generation pre-determination unit 2333 is classified into function_level, class_level, module_level, cross_module_level, architecture_level, and infrastructure_level, with the former being judged as DRCG-compatible and the latter as requiring design changes.

[0283] In the second embodiment, quality issue 2411 may be broken down into multiple sub-issues as needed. For example, sub-issues A1, A2, and A3 may be generated for a parent issue A, and the resolution status of each sub-issue may be managed individually. In this case, the traceability unit 2315 may display or record the correspondence between the parent issue and the sub-issues, the resolution status of each sub-issue, and the partial resolution status of the parent issue as a whole.

[0284] [Forced Resolution Verification Unit, Severity Level Automatic Upgrade Unit] Figure 24 is a diagram illustrating the processing of the forced resolution verification unit 2334. Prior to the 4-axis quality gate determination of the child iteration 2412, the forced resolution verification unit 2334 re-verifies the quality issue 2411 with the forced resolution flag 2413 inherited from the parent iteration 2412. If resolution is not confirmed, the forced resolution verification unit 2334 executes the following processes in parallel: (a) Calls the automatic severity promotion unit 2335 and increases the severity of the quality issue 2411 by one level in the order of minor → low → medium → high → critical (with critical as the upper limit). (b) Extends the continuation instruction information 2414 (mandatory_until_iteration_seq) by one level. (c) Fixes the 4-axis quality gate of the child iteration 2412 as a failure. As a result, quality issue 2411, which has not been resolved as required, will have its severity increased over time, and warnings to operators will be gradually strengthened.

[0285] The forced resolution verification unit 2334, if the issue remains unresolved, simultaneously executes the following actions within a single transaction: calling the severity automatic promotion unit 2335, extending the continuation instruction information 2414, and fixing the multi-axis quality gate judgment as unsuccessful.

[0286] As described above, the automatic severity promotion unit 2335 increases the severity level of quality issue 2411 by one level in response to a call from the forced resolution verification unit 2334. Promotion is not performed for quality issue 2411 that has already reached the highest level (critical), and this is recorded in the audit log.

[0287] [Design Change Approval Department] Figure 36 is a diagram illustrating the processing of the design change approval unit 2336. The design change approval unit 2336 accepts approval input from a user with the prescribed authority (SystemAdmin or TenantAdmin) for quality issues 2411 that have been distinguished as essential design change issues by the missing code generation pre-determination unit 2333, via a screen on the UI server 2130 (screen S-09 described later). Upon approval, the following information is recorded as the design change approval record 2416: (a) approver identifier, (b) approval time, (c) target issue ID, (d) reason for approval (user input), (e) conversion path switching destination or requirement relaxation details, and (f) audit log (audit_log table). The start of execution of the corresponding child iteration 2412 is suppressed until approval is obtained. After approval, the retry iteration management unit 2332 starts the next child iteration 2412.

[0288] Regarding the configuration that "prevents the start of the corresponding iteration until approval is obtained," the design change approval unit 2336 sets an approval pending state when there is a mandatory design change issue, and the retry iteration management unit 2332 stops the startup of the child iteration 2412 until that state is resolved.

[0289] [Forced Resolve Closed-Loop (FB-1~FB-8)] Figure 22 shows the overall flow of the forced resolution closed loop. As shown in Figure 22, the overall flow of the forced resolution closed loop is as follows: (FB-1) 4-axis quality gate judgment is performed by the multi-axis quality gate unit 2322. (FB-2) The forced resolution marking unit 2331 is activated when a FAIL is detected. (FB-3) A list of quality issues is displayed on the UI server 2130 (distinguishing between forced resolution and voluntary resolution). (FB-4) DRCG pre-judgment is performed by the missing code generation pre-judgment unit 2333. (FB-5a) For quality issues 2411 that are judged to be DRCG-compatible, the missing code generation unit 2317 executes the generation of completion codes. (FB-5b) For quality issues 2411 that are judged to be DRCG-incompatible, branching is performed to the design change approval unit 2336. (FB-6) Retry is executed after approval (retry iteration management unit 2332). (FB-7) Forced resolution is verified by the forced resolution verification unit 2334. (FB-8) When the issue is confirmed to be resolved, the system transitions to the final_verified state; if it is not resolved, the severity is increased by the automatic severity upgrade unit 2335 and the system returns to FB-2.

[0290] [State transitions of quality issues] Figure 23 is a diagram showing the state transitions of quality issue 2411. As shown in Figure 23, the state transitions of quality issue 2411 in the second embodiment are as follows: detected → recorded → inherited → (mandatory → selected_forced) or (→ selected_optional) → addressed → verified → final_verified. The mandatory state corresponds to quality issue 2411 to which the mandatory resolution flag 2413 has been assigned by the mandatory resolution marking unit 2331, and the selected_forced state corresponds to quality issue 2411 to which the mandatory resolution flag 2413 has been assigned and which has been selected as a target for resolution by the issue selection unit 2313.

[0291] [User Interface Screens S-01~S-09] The UI server 2130 provides a user interface that enables operation of the system 2010 and viewing of results via the display and operation units of the user terminal 20. The user interface in the second embodiment consists of the following screens (screens S-01 to S-09; see the screen transition overview in Figure 26). (a) Screen S-01 (code 2401, equivalent to Figure 27): Static performance indicator viewer, (b) Screen S-02 (code 2402, Figure 28): Performance target value viewing and editing, (c) Screen S-03 (code 2403, Figure 29): Issue selection (distinguishing between forced resolution and voluntary resolution), (d) Screen S-04 (code 2404, Figure 30): Performance measurement progress monitor, (e) Screen S-05 (code 2405, Figure 31): 4-axis quality gate dashboard, (f) Screen S-06 (code 2406, Figure 32): Performance audit result viewer, (g) Screen S-07 (code 2407, Figure 33): Performance issue IR chain full stage trace, (h) Screen S-08 (code 2408, Figure 34): Retry status dashboard, (i) Screen S-09 (code 2409, Figure 35): Design change approval screen.

[0292] Screen S-02 (View / Edit Performance Target Values) displays the maximum response time, minimum throughput, maximum CPU usage, and maximum memory usage for the performance target value 2422 in a comparative table format. Each item consists of three columns: "Item," "Target Value," and "Source (Manual / Automatic Derivation)." Only users with the appropriate privileges (system administrator or corresponding privileges) are allowed to access editing mode.

[0293] Screen S-03 (Issue Selection) presents the inherited quality issues 2411 to the user and allows them to select which ones to resolve during conversion. Screen S-03 consists of two sections, upper and lower. (a) Mandatory Resolution Section: Displays only quality issues 2411 that have been assigned the mandatory resolution flag 2413. The selection checkbox for each quality issue 2411 is disabled (checked and unresponsive) and cannot be deselected. A lock icon, cause gate identifier 2415, continuation instruction information 2414, severity, and subcategory are also displayed for each quality issue 2411. Whether DRCG compliance is possible is indicated by either a "DRCG possible" or "design change required" badge. (b) Optional Resolution Section: Displays quality issues 2411 that have not been assigned the mandatory resolution flag 2413. The checkboxes are operable, and the user can switch between selecting and deselecting at their discretion. At the bottom of screen S-03, if quality issue 2411, which has been determined to require a design change, exists, a message and link stating "Design change approval is required (proceed to S-09)" will be placed. The retry button at the bottom of the screen will be disabled until design change approval is obtained.

[0294] In the configuration where a checkbox is disabled and cannot be unchecked, the selection checkbox in the forced resolution section is implemented with `checked=true` and `disabled=true`, and is maintained as unremovable even by server-side validation. On the other hand, the checkbox in the optional resolution section is operable.

[0295] Screen S-04 (Performance Measurement Progress Monitor) displays the progress of performance measurement jobs running on storage server 2190 in real time. The screen displays the measurement_id, progress rate (0-100%), execution status (accepted / running / completed / failed), start time, estimated completion time, and the perf_profile of the measured job (idle / low / normal / peak / stress).

[0296] Screen S-05 (4-axis quality gate dashboard) visualizes the judgment results of the multi-axis quality gate unit 2322 in the following configuration: (a) Top: Displays the score (0.0~1.0), threshold, and pass / fail judgment (PASS / FAIL) for each of the four axes (function / structure / security / performance) in an axis-specific card format. (b) Center: Displays the overall judgment (PASS / WARN / FAIL) in large font. (c) FAIL feedback panel: Displayed only when any axis is FAIL. Provides the number of quality issues 2411 that caused the failure (number of issues to be forcibly resolved / number of issues to be resolved voluntarily), a breakdown by severity, and a "Transition to issue selection screen (to S-03)" button. Pressing the transition button in the FAIL feedback panel on screen S-05 transitions to screen S-03 (issue selection). The screen (display unit) may display the state transitions of quality issues in an intermediate representation chain consisting of a current intermediate representation, a conceptual intermediate representation, a requirements design integration intermediate representation, an implementation intermediate representation, a code output intermediate representation, and a deployment intermediate representation, in a table format with the intermediate representation categories arranged horizontally and individual quality issues arranged vertically. Alternatively, each iteration managed by the retry iteration management unit may be overlaid as a time hierarchy that can be switched and displayed in the aforementioned table format.

[0297] Regarding the "display by axis" configuration, screen S-05 displays the scores and pass / fail status for the four axes—function axis, structure axis, security axis, and performance axis—as separate axis-specific cards arranged horizontally in a list. If a product fails, a FAIL feedback panel is displayed, allowing the user to proceed to screen S-03.

[0298] Screen S-06 (Performance Audit Result Viewer) displays the detailed results from the Performance Audit Unit 2319. The screen includes the following sections: (a) Measured Performance Metrics: P50, P90, P95, and P99 of response_time_ms, mean and standard deviation of throughput_tps, and time-series graphs of CPU, memory, and I / O utilization. (b) Deviation from Performance Target Values: Deviation rate (%) and severity of each indicator. (c) Subcategory-by-Subcategory Summary: Number of items for each subcategory such as n_plus_one_query, missing_cache, and inefficient_loop. (d) DRCG Compatibility: Judgment result of the Missing Data Completion Code Generation Pre-Determination Unit 2333.

[0299] Regarding the configuration that "provides at least one of the first screen, the second screen, and the third screen," the performance audit result display unit in the second embodiment is configured to provide three screens: a comparison table format screen, a progress rate display screen, and a subcategory-based summary screen, and all or part of these may be selectively provided depending on the operational purpose.

[0300] Screen S-07 (Performance Issue IR Chain Full Stage Trace) displays the state transitions of quality issue 2411 tracked by the traceability unit 2315 in a tabular format. Screen S-07 has a three-axis configuration: (a) Horizontal axis (6 stages of IR chain): CS-IR2201, P-IR2202, RD-IR2203, I-IR2204, CO-IR2205, and DP-IR2206. (b) Vertical axis: Individual quality issues 2411, identified by issue_id. (c) Third axis (layer): Switchable every 2412 iterations. Each cell displays the status (detected / inherited / mandatory / selected_forced / addressed / verified / final_verified) in color or symbol.

[0301] Regarding the configuration that "overlays the display as a temporal hierarchy," screen S-07 places the six stages of the IR chain on the horizontal axis and quality issue 2411 on the vertical axis, and displays each iteration 2412 as a temporal hierarchy that can be selected by dropdown or tab switching as a third axis.

[0302] Screen S-08 (Retry Status Dashboard) visualizes the status of multiple iterations 2412 managed by the Retry Iteration Management Unit 2332. Screen S-08 includes a list of iterations arranged in chronological order and the following information: (a) Each iteration 2412: iteration_id, parent_iteration_id, seq, trigger_reason (initial / retry_gate_fail / retry_force_resolve), status, number of forced resolution issues / number resolved issues, time taken. (b) Remaining retries: the remaining number obtained by subtracting the current seq from max_retry (default 5). (c) Severity escalation history: displays the history of when the forced resolution verification unit 2334 activated the automatic severity escalation unit 2335, broken down by issue. (d) Continuation instruction information extension history: the history of when the continuation instruction information 2414 was extended.

[0303] Regarding the "List display in chronological order" and "Display of progress until the upper limit is reached," screen S-08 displays all 2412 iterations vertically in ascending order of sequence, and also displays the remaining number of retries, the deadline for forced resolution requests, the history of automatic severity escalation, and the history of extensions of continuation instruction information.

[0304] Screen S-09 (Design Change Approval Screen) accepts approval input from a designated authorized person (SystemAdmin or TenantAdmin) for quality issues 2411 that have been distinguished as mandatory design change issues by the missing code generation pre-determination unit 2333. The configuration of screen S-09 is as follows: (a) List of mandatory design change issues: Displays a list of issue_id, subcategory, severity, scope of impact, and recommended design change content. (b) Approval input form: Approve or reject buttons, options for switching to a conversion path (structure preservation conversion, architecture-driven conversion, data conversion, API conversion, IaC conversion, and container conversion), and a text area for the reason for approval. (c) Authorization determination: Checks the user_role of the logged-in user, and disables the approval button if it is not SystemAdmin or TenantAdmin. (d) Approval completion display: Approved quality issues 2411 are given an "Approved" badge. (e) Audit log: For each approval operation, the approver ID, approval time, target issue ID, approval reason, and conversion path destination are recorded in the audit_log table.

[0305] Regarding the determination of permission levels and the input of required fields, the design change approval input reception unit activates the approval button only if the logged-in user's permission is SystemAdmin or TenantAdmin, and accepts the conversion path destination, approval reason, and confirmation checkbox as required input fields.

[0306] The nine screens described above can be accessed from one another via the paths shown in the screen transition overview (Figure 26). A typical operation flow in the second embodiment is as follows: (i) Check the indicators of the source code on screen S-01 (Static Performance Indicator Viewer). (ii) Check the target values ​​on screen S-02 (Performance Target Value Viewing / Editing) (edit as needed). (iii) After the conversion / generation process is executed, wait for the completion of the sandbox measurement on screen S-04 (Measurement Progress). (iv) Check the overall judgment on screen S-05 (4-axis Quality Gate Dashboard). (v) If it fails, transition from the FAIL feedback panel to screen S-03 (Issue Selection). (vi) If there are issues requiring design changes, obtain approval on screen S-09 (Design Change Approval). (vii) Return to screen S-03 and press the retry execution button. (viii) Check the iteration progress on screen S-08 (Retry Status Dashboard). (ix) If necessary, check the details on screens S-06 (Performance Audit Results) and S-07 (IR Chain Trace).

[0307] Each screen meets accessibility requirements (WAI-ARIA compliant, role=tabpanel, aria-selected, keyboard operation supported). It also provides appropriate feedback to the user during loading, error, and API disconnection (apiConnected=false) states. When the API is disconnected, the UI continues to function in its initial state within the Pinia store, and automatically updates with API-obtained values ​​after recovery.

[0308] Access control is as follows: (a) SystemAdmin: Fully accessible, including editing the performance target value of 2422, approving design changes, and manual overrides. (b) TenantAdmin: Fully accessible within the tenant, and can approve design changes. (c) Other general users: Read-only access; editing and approval buttons are disabled.

[0309] [Financial grade quality standards, tenant separation, prohibition of external transmission, operational integration] The second embodiment maintains the following criteria as financial-grade quality standards: (a) CV (Coefficient of Variation) ≤ 5%: Reproducibility of measured performance values ​​measured 10 times consecutively under the same conditions. (b) Relative comparison with a reference machine: Normalization using baseline_machine_spec (e.g., m5.large-baseline-v1). (c) Adoption of median of multiple measurements: The median of three or more measurements is used for performance evaluation. (d) Maintaining isolation with network=none and cap_drop=ALL in Docker Sandbox.

[0310] Tenant isolation is ensured by the `tenant_id` column in all database tables (such as the `quality_issues` table storing quality issue 2411, the `iterations` table storing iteration 2412, and the `performance_scenarios` table), and by the `tenant_id` property of the nodes in graph database 401a (such as ReverseNode, PIRNode, RDIRNode, IIRNode, DesignNode, QualityIssue, Iteration, etc.). Users of tenant A cannot access any data in tenant B. Authentication is implemented using a JWT token method, and the tenant context is established upon login.

[0311] To prevent external transmission, the second embodiment prohibits all data transmission to external LLM services and uses only the local large-scale language model on the AI ​​server 2140. This satisfies the confidential information protection requirements specific to financial institutions.

[0312] As part of the operational and monitoring integration, the second embodiment may be integrated with the existing Prometheus and Grafana monitoring infrastructure, and the following metrics may be displayed on the dashboard: (a) Sandbox measurement failure rate (operational alert if it exceeds 5% per hour); (b) Performance Audit Agent error rate (operational alert if it exceeds 3% per hour); (c) Measurement job queue length (message queue server 2180, operational alert if it exceeds 50); (d) 4-axis quality gate failure rate (quality manager alert if it exceeds 30% per day).

[0313] To address the audit requirements specific to financial institutions, the second embodiment provides the following for history inquiry and audit response: (a) Time-series display of the history of all 2412 iterations (screen S-08). (b) Tracking of the promotion history of the severity automatic promotion unit 2335 by issue. (c) Auditor viewing function for the design change approval record 2416 (viewable with SystemAdmin privileges, with hash signature for tamper detection). (d) Complete tracing of the basis for quality gate judgment (6-stage IR chain tracing).

[0314] [Example of the second embodiment] Example 1: Conversion Project (Conversion-only usage). This case involves reverse engineering of target software assets (COBOL, PHP, Pascal, etc.) and converting them to target languages ​​(Java, TypeScript, Go, etc.). In this case, the IR chain goes through all stages in the order of CS-IR2201 → P-IR2202 → RD-IR2203 → I-IR2204 → CO-IR2205 → DP-IR2206. The static performance index extraction unit 2217 operates when CS-IR2201 is generated and is stored as a performance target value 2422 in the non-functional requirements management node of the second design information layer 2302. The performance audit unit 2319 is executed in a Docker Sandbox on the converted artifact after DP-IR2206 is generated.

[0315] Example 2: Development Project (Generation Only Usage). This case involves generating new software from only the requirements definition document and design document, without existing software. In this case, the IR chain omits the CS-IR2201 stage and proceeds in five stages: P-IR2202 → RD-IR2203 → I-IR2204 → CO-IR2205 → DP-IR2206. Instead of the static performance index extraction unit 2217, non-functional requirements are directly extracted from the requirements definition document and stored in the non-functional requirements management node. The performance audit unit 2319 and the multi-axis quality gate unit 2322 operate in the same manner as in Example 1.

[0316] Figure 39 is a diagram illustrating the conversion path. Example 3: Execution form of 6 conversion paths. The second embodiment corresponds to the following 6 conversion paths. The operation of the IR chain and the multi-axis quality gate unit 2322 is common in each conversion path, but the type of subcategory applied differs for each conversion path. (a) Full modernization 2501 (3 types: Refactoring, Greenfield, and Hybrid): Goes through all 6 stages from CS-IR2201 to DP-IR2206. All 12 subcategories of performance issues are detected. (b) Direct conversion 2502: Code conversion from source language to target language. (c) Data conversion 2503: Data definition conversion of database schema and CSV, etc. The main performance issues detected are db_engine_change and excessive_db_access. (d) API conversion 2504: Interface conversion to REST, GraphQL, or gRPC. external_if_change is the main issue detected. (e) IaC conversion 2505: Infrastructure description code conversion. The main detection target is architecture_change. (f) Container transformation 2506: Generation of container definition file and orchestration manifest.

[0317] Example 4: Typical flow of a forced elimination closed loop. The typical flow of a forced elimination closed loop is as follows: (i) In the parent iteration 2412_I1 (seq=1, parent_iteration_id=null), the multi-axis quality gate unit 2322 performs a judgment and fails on the performance axis. (ii) The forced elimination marking unit 2331 assigns forced elimination flags 2413 to three quality issues 2411 (severity: critical=1, high=2). (iii) Continuation instruction information 2414 is assigned by default for each severity (critical=3, high=2). (iv) On the UI server 2130 screen S-03, the forced elimination section is displayed as disabled with a lock icon. (v) The missing code generation pre-determination unit 2333 classifies whether DRCG is possible based on the subcategory and scope of impact. (vi) Issues that can be processed by DRCG are processed by the missing code generation unit 2317, and issues that cannot be processed by DRCG are branched to the design change approval unit 2336. (vii) The authorized person (SystemAdmin or TenantAdmin) gives approval input on screen S-09. (viii) Child iteration 2412_I2 (seq=2, parent_iteration_id=I1) is started. (ix) The forced resolution verification unit 2334 verifies the issues inherited from the parent, and if there are any unresolved issues, the severity automatic promotion unit 2335 increases the severity by one level and extends the continuation instruction information 2414 by one level. (x) If the 4-axis quality gate of I2 passes, final_verified is started, if it fails, I3 is started (up to a maximum of 5 iterations).

[0318] Example 5: Case where the retry limit is reached. If forced resolution is not achieved after exceeding the maximum number of retries (default 5), the retry iteration management unit 2332 stops the startup of a new iteration 2412 and presents the following options to the operator on the UI (screen S-08): (a) Option A: Switch the conversion path (for example, from full modernization 2501 to direct conversion 2502) and reset the retry counter. (b) Option B: Relax the performance target value 2422 (requires approval by the design change approval unit 2336). (c) Option C: Suspend the project and perform a manual design review.

[0319] Example 6: DRCG pre-determination results for each performance issue subcategory. The missing data completion code generation pre-determination unit 2333 performs the following subcategory classification: (a) DRCG compatible (scope of impact is within function, method, or class): n_plus_one_query (ORM batching), missing_cache (memoization addition), inefficient_loop (algorithm replacement), excessive_io (buffering), memory_leak (release of reference), db_connection_leak (close addition), excessive_db_access (index addition), slow_response (lightweighting). (b) DRCG not compatible (scope of impact is application-wide): framework_change, db_engine_change, external_if_change, architecture_change. Even for quality issue 2411, which has been determined to be DRCG-compliant, the operational scope limitations imposed by G1 to G7 of the responsibility boundary control unit 2318 are applied (for example, prohibiting framework changes in G3 and prohibiting DB engine changes in G4).

[0320] Example 7: Tenant-Isolated Operation. The second embodiment assumes a multi-tenant SaaS environment. A tenant_id column is set in all tables (quality_issues2411, iterations2412, performance_scenarios, and performance_benchmarks, etc.), and the tenant_id property is also assigned to the nodes of graph database 401a. Users of tenant A cannot access any data of tenant B. Authentication is implemented using the JWT token method, and the tenant context is established upon login.

[0321] Example 8: Ensuring Financial Grade Quality Standards. In providing SaaS to financial institutions, the second embodiment maintains the following quality standards: (a) CV (Coefficient of Variation) ≤ 5%: Reproducibility of 10 consecutive measurements under the same conditions is ensured using load patterns defined by perf_profile(idle / low / normal / peak / stress). (b) Relative comparison with a reference machine: Normalization is performed using baseline_machine_spec (e.g., m5.large-baseline-v1) to mitigate environment dependency. (c) Adoption of median of multiple measurements: The median of three or more measurements is used for performance evaluation. (d) Security isolation of Docker Sandbox: network=none and cap_drop=ALL are maintained in all profiles, and a 400 error response is immediately issued in case of violation using perf_profile.security_invariants_hold(). (e) Complete storage of audit logs: Design change approval records 2416, promotion history by the severity automatic promotion unit 2335, and extension history of continuation instruction information 2414 are all stored in the audit_log table.

[0322] Example 9: Combined Operation Case (Coexistence with Existing APM / CI / CD Tools). The second embodiment can be used in conjunction with existing APM (Datadog, New Relic, Dynatrace, etc.) and CI / CD (GitHub Actions, Jenkins, etc.). However, the multi-axis quality gate unit 2322 and forced resolution closed loop of the second embodiment operate independently, and monitoring data from existing tools is read only (acquired via an external API) without data transmission. Only the local LLM (AI server 2140) is used, and data transmission to externally generated AI services is prohibited.

[0323] Example 10: Examples of quality issue detection at each stage of the IR chain. Typical examples of quality issues 2411 being detected at each of the six stages of the IR chain are shown below. (a) CS-IR2201 (first design information layer 2301) stage: N+1 potential loop depth anomalies originating from static performance indicators 2421 detected by syntactic analysis. (b) P-IR2202 (second design information layer 2302) stage: Inconsistency between business objectives and transformation strategies (e.g., mismatch between SLA requirements and technology stack). (c) RD-IR2203 (second design information layer 2302) stage: Conflict between functional and non-functional requirements (e.g., synchronous processing design under low latency requirements). (d) I-IR2204 (second design information layer 2302) stage: Violations of SOLID principles in class and method design, dependency circles. (e) CO-IR2205 (third design information layer 2303) stage: Static analysis violations of generated code, API compatibility errors. (f) DP-IR2206 (Third Design Information Layer 2303) stage: Inconsistency in deployment definition (IaC, container), excessive resource requests. The traceability section 2315 and screen S-07 (IR chain full stage trace display) visualize these six stages on the horizontal axis and individual quality issues 2411 on the vertical axis in a tabular format on an iteration basis.

[0324] Example 11: Operation and Monitoring Integration. As described above, the second embodiment can be integrated with existing Prometheus and Grafana monitoring infrastructure, and metrics such as measurement failure rate, performance audit unit 2319 error rate, measurement job queue length, and 4-axis quality gate FAIL rate are subject to operational alerts.

[0325] Example 12: History Inquiry and Audit Response. As described above, the second embodiment provides a time-series display of the history of all iterations 2412 (screen S-08), tracking of the promotion history of the severity automatic promotion unit 2335 by issue, an auditor viewing function for the design change approval record 2416 (viewable with SystemAdmin privileges, with hash signature for tamper detection), and complete tracing of the basis for quality gate judgment (6-stage IR chain trace).

[0326] [Method and Program Structure] The software design information restoration method according to the second embodiment is understood to be a method consisting of processing steps executed by the single source analysis unit 2211, the division unit 2212, the inference unit 2213, the verification unit 2214, the integration unit 2215, the multiple source summary analysis unit 2216, and the static performance indicator extraction unit 2217. Specifically, the method includes the steps of: performing syntactic analysis on a single source file constituting the target software, generating an abstract syntax tree, and extracting syntactically parseable static information including at least the number of instructions, the number of branches, and the call relationships; dividing the single source file into units of a predetermined maximum number of tokens or maximum number of functions; applying inference using a large-scale language model to the divided source files to generate design intent and processing overview; comparing the design intent and processing overview with the abstract syntax tree to verify the logical correspondence; and a first design information layer 2301, a second design information layer 2302, and a third design information layer 2303. The process includes: storing the design intent and processing overview, for which logical correspondence has been confirmed, as an intermediate representation in the first design information layer 2301 of the design information infrastructure 2300; analyzing dependencies across multiple source files to derive the relationships between modules and the call graph, and integrating them into the first design information layer 2301; and extracting static performance indicators during the syntactic analysis process, including cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses, which include the number of code locations where an inefficient access pattern of repeatedly issuing database queries to retrieve child records for each parent record after retrieving the parent record is observed in static analysis. This makes it possible to protect the process of automatically restoring the design information itself from multiple angles.

[0327] The software design information recovery method is concretized as a method in which an information processing device executes (a) a single source analysis step, (b) a splitting step, (c) an inference step, (d) a verification step, (e) an integration step, (f) a multiple source summary analysis step, and (g) a static performance indicator extraction step.

[0328] Furthermore, the program according to the second embodiment is understood as a program that causes the processor of the information processing device to execute the above-mentioned single-source analysis process, partitioning process, inference process, verification process, integration process, multiple-source summary analysis process, and static performance indicator extraction process. This allows for multifaceted protection of the software product by patenting it as a program that causes a computer to execute a process for automatically restoring design information.

[0329] The program is implemented as a computer program that causes the processor of an information processing device to execute single-source analysis, partitioning, inference, verification, integration, multi-source summary analysis, and static performance indicator extraction processes.

[0330] The software quality issue management method according to the second embodiment is understood to be a method consisting of processing steps executed by the issue recording unit 2311, issue inheritance unit 2312, issue selection unit 2313, issue resolution determination unit 2314, and traceability unit 2315. Specifically, the method includes a first design information layer 2301 that stores the results of analyzing the current structure of the software to be converted and generated, a second design information layer 2302 that stores conversion and generation goals including functional requirements, performance requirements, target execution environment, and scope of application to be realized after conversion or generation, and a conversion and generation strategy including conversion rules, conversion order, scope of conversion, and constraints, and a third design information layer 2303 that stores design information of the software system after conversion or generation, wherein the first design information layer 2301, the second design information layer 2302, and the third design information layer 2303 are configured in chronological order of the conversion and generation process, and the steps of recording quality issues 2411 detected during the conversion or generation process related to at least one of these design information layers in association with the design information layer corresponding to the conversion or generation process in which the quality issues were detected, and The process includes: inheriting quality issues 2411 to a node belonging to the design information layer corresponding to a downstream conversion or generation process in order to make them accessible from downstream conversion or generation processes in the time series of the conversion or generation process; selecting quality issues from the inherited quality issues 2411 to be resolved during conversion or generation based on user input or mechanical determination; determining the resolution status of the selected quality issues 2411 for the code, executable modules, configuration files, or deployment components output by the conversion or generation; and tracking the entire state transition of quality issues 2411, including recording, inheritance, selection, and resolution determination performed after detection, and re-recording performed when it is detected again as a quality issue based on the same or corresponding cause, across multiple intermediate representation stages of the conversion or generation process.

[0331] The software quality issue management method is concretized as a method in which an information processing device executes (a) an issue recording process, (b) an issue inheritance process, (c) an issue selection process, (d) an issue resolution determination process, and (e) a traceability process.

[0332] Furthermore, the software quality issue management program according to the second embodiment is understood as a program that causes the processor of the information processing device to execute the above-mentioned issue recording process, issue inheritance process, issue selection process, issue resolution determination process, and traceability process. This makes it possible to protect software products that realize issue management associated with software conversion or generation from multiple angles.

[0333] The program is implemented as a computer program that causes the processor of an information processing device to execute task recording processing, task inheritance processing, task selection processing, task resolution determination processing, and traceability processing.

[0334] [Differentiation] The embodiments described above are merely illustrative examples for implementing this disclosure. Therefore, this disclosure is not limited to the embodiments described above, and it is possible to implement the embodiments described above by modifying them as appropriate without departing from the spirit of the disclosure.

[0335] The first and second embodiments described above show examples of server configurations, but are not limited thereto. That is, all functions may be integrated into a single server, or they may be distributed as microservices. Furthermore, each function may be implemented by dedicated hardware, software implementation by program, firmware, or a combination thereof.

[0336] The first and second embodiments described above show examples of the number of stages in the IR chain, but are not limited to these. The number of stages in the IR chain may be changed depending on the implementation purpose. For example, CO-IR205 and DP-IR206 may be treated as a single output generation stage.

[0337] In the first and second embodiments described above, the number of dimensions of the GPS vector 800 and the system vector 900 are taken as example values ​​and may be expanded or reduced as necessary.

[0338] In the first and second embodiments described above, examples were shown in which the approval / rejection receiving unit accepts either approval or rejection from the user, but this disclosure is not limited thereto. For example, in addition to approval and rejection, the approval / rejection receiving unit may be configured to accept partial approval, which approves only a portion of the conversion generation result, or conditional approval, which is considered approved only if certain conditions are met.

[0339] In the first and second embodiments described above, examples were shown in which the scoring processing unit 403 sets the weights α and β in hybrid scoring as fixed values, but the disclosure is not limited thereto. For example, the scoring processing unit 403 may be configured to dynamically adjust the weights α and β depending on the type of programming language to be converted, the complexity of the code, or the requirements of the project.

[0340] The first and second embodiments described above illustrate examples in which multiple specialized AI agents use a predetermined number of fixed LLMs, but the disclosure is not limited thereto. For example, the number of specialized AI agents may be configured to dynamically increase or decrease depending on the load of the translation process or the number of languages ​​to be translated, or the type of LLM adopted by each specialized AI agent may be configured to be switched according to the characteristics of the language to be translated.

[0341] In the first and second embodiments described above, an example was shown in which the design information infrastructure 300 consists of three layers: a Reverse layer 301, a Plan layer 302, and a Design layer 303. However, this disclosure is not limited thereto. For example, the design information infrastructure may consist of more or fewer layers than three, and the number of layers may be increased or decreased depending on the scale of the project or the complexity of the system.

[0342] In the first and second embodiments described above, an example was shown in which the automatic feedback loop processing unit sequentially executes five steps from F1 to F5, but the disclosure is not limited thereto. For example, it may be configured to operate in a shortened execution mode in which F2 (improvement suggestion) and F3 (verification) are omitted when the conversion quality exceeds a predetermined threshold, or in a parallel execution mode in which F1 (cause analysis) and F2 (improvement suggestion) are executed in parallel.

[0343] In the first and second embodiments described above, examples were shown in which the GPS vector 800 is composed of four types of subvectors: a structure path subvector, a tenant boundary subvector, an audit path subvector, and a transformation history subvector, but the disclosure is not limited thereto. For example, the GPS vector may be configured to adopt a configuration that adds a security attribute subvector or a performance characteristic subvector.

[0344] The first and second embodiments described above illustrate an example in which the integrated knowledge base aggregates and manages the graph database 401a and the vector database 402a on a single server, but the disclosure is not limited thereto. For example, the graph database and the vector database may be configured to be held in a distributed configuration distributed across multiple geographically distributed nodes, or to employ a hybrid configuration spanning on-premises and cloud environments.

[0345] In the first and second embodiments described above, examples were shown in which the system vector 900 includes feature blocks corresponding to 12 analysis perspectives, but the disclosure is not limited thereto. For example, the number of analysis perspectives may be set to more or fewer than 12, or business domain-specific perspectives (e.g., financial regulatory compliance perspectives or medical safety perspectives) may be added, depending on the characteristics or industry of the system to be transformed.

[0346] The first and second embodiments described above illustrate examples where Provenance information is primarily used to improve the accuracy of subsequent transformation generation processes, but the disclosure is not limited thereto. For example, Provenance information may be used for submission to external regulatory bodies as an audit trail, or for the automatic generation of transformation quality certificates (SLA reports).

[0347] The first and second embodiments described above illustrate an example in which the documents to be converted are obtained from a predetermined document database, but the disclosure is not limited thereto. For example, the document acquisition unit may be configured to acquire documents along with their commit history from a Git repository, or it may be configured to acquire documents that have been updated in real time via an external API.

[0348] In the second embodiment described above, an example was shown in which the software design information restoration function is included as a function of the software design information restoration system 2010, but the disclosure is not limited thereto. For example, the function may be configured as an independent software design information restoration system dedicated solely to the analysis of target software and the restoration of design information, and may be configured to store design information only in the first design information layer, the second design information layer, and the third design information layer, without having a conversion generation processing unit.

[0349] The second embodiment described above shows an example in which the second design information layer stores transformation generation goals and transformation generation strategies, but the disclosure is not limited thereto. For example, the second design information layer may be configured to hold transformation generation goals, which include the target programming language, target execution environment, and performance requirements after the transformation or generation of the software, and transformation generation strategies, which include the transformation rules, transformation order, and constraints to be applied, as separate groups of nodes or separate sublayers.

[0350] In the second embodiment described above, an example was shown in which the design information of the software system after conversion is stored in the third design information layer, but the disclosure is not limited thereto. For example, the third design information layer may be configured to individually hold class definitions, method definitions, field definitions, interface definitions, configuration definitions, and deployment configuration definitions as design information of the software system after conversion or generation of the software.

[0351] In the second embodiment described above, an example was shown in which the inference unit 2213 generates the design intent and processing overview, but the disclosure is not limited thereto. For example, the inference unit 2213 may be configured to generate, in addition to the design intent and processing overview, supplementary explanatory information indicating the main prerequisites, exception handling policies, external dependencies, or performance considerations included in the source file, and the verification unit 2214 may be configured to verify the logical correspondence of the supplementary explanatory information with the abstract syntax tree.

[0352] The second embodiment described above shows an example of analyzing a single source file or multiple source files that constitute the target software, but the disclosure is not limited thereto. For example, the single source analysis unit 2211 and the multiple source summary analysis unit 2216 may be configured to include compiled objects, bytecode, or intermediate code in addition to source code files as targets for analysis, and to restore design information based on the analysis results.

[0353] In the second embodiment described above, an example was shown in which the static performance indicator display unit provides a static performance indicator viewer screen S-01, but the disclosure is not limited thereto. For example, the static performance indicator display unit may be configured to allow switching of the display granularity for each indicator, such as cyclomatic complexity, loop depth distribution, estimated I / O operation count, and estimated database access count, on a function-by-function, file-by-file, module-by-module, or project-by-project basis.

[0354] The second embodiment described above shows an example in which the performance target value 2422 is commonly referenced across multiple iterations, but the disclosure is not limited thereto. For example, the performance index storage unit 2218 may be configured to reference a common performance target value 2422 for each group of iterations belonging to the same conversion generation target, while generating and maintaining a new performance target value 2422 as a separate series when the conversion generation strategy is changed.

[0355] In the second embodiment described above, an example was shown in which the quality issue 2411 is recorded in association with the first design information layer 2301, the second design information layer 2302, or the third design information layer 2303, but the disclosure is not limited thereto. For example, the quality issue 2411 may be detected during a transformation or generation process associated with at least one of the first design information layer 2301, the second design information layer 2302, and the third design information layer 2303, and may be recorded as a composite issue spanning multiple design information layers.

[0356] In the second embodiment described above, an example was shown in which iteration 2412 is treated as a management unit having a parent-child iteration relationship, but the disclosure is not limited thereto. For example, iteration 2412 may be explicitly defined as the execution unit for each software transformation or generation, and may be configured to associate and maintain the start time, end time, executor, applied transformation path, and quality gate determination result for each iteration.

[0357] In the second embodiment described above, an example was shown in which the issue selection unit 2313 selects from the inherited quality issues 2411 to be resolved during conversion or generation, but the disclosure is not limited thereto. For example, the issue selection unit 2313 may be configured to select from the quality issues 2411 inherited by the issue inheritance unit 2312 to be resolved during conversion or generation, and the selection result may be passed in common to the issue resolution determination unit 2314 and the traceability unit 2315.

[0358] In the second embodiment described above, an example was shown in which the traceability unit 2315 tracks the state of quality issue 2411 across six stages of the IR chain, but the disclosure is not limited thereto. For example, the traceability unit 2315 may be configured to track the entire state transition of quality issue 2411 in the intermediate representation chain, including recording, inheritance, selection and resolution decisions performed after detection, and re-recording performed when it is detected again as a quality issue based on the same or corresponding cause.

[0359] In the second embodiment described above, an example was shown in which the missing code generation unit 2317 generates local completion codes, but the disclosure is not limited thereto. For example, the missing code generation unit 2317 may be configured to be activated only when the pre-determination unit 2333 determines that the cause of the quality issue 2411 is a defect that can be resolved by a missing, insufficient, or local completion in the design information layer or the generated code.

[0360] In the second embodiment described above, an example was shown in which the sequence of operations between the main conversion or generation process and the completion process by the missing code generation unit 2317 was clearly indicated, but the disclosure is not limited thereto. For example, the main conversion or generation process may be executed first as a rule-based process based on the conversion dictionary, conversion rules, and design information infrastructure 2300, and the completion by the missing code generation unit 2317 may be applied later and limitedly to resolve issues with the code, executable module, configuration file, or deployment components output as a result of the rule-based process.

[0361] The second embodiment described above shows an example in which quality assurance is implemented as a four-axis quality gate, but the disclosure is not limited thereto. For example, quality assurance may be implemented based on at least three axes: functional quality, structural quality, and security quality, and further extended as a four-axis quality gate by adding performance quality as needed. Furthermore, even if completion is performed by the missing code generation unit 2317, it may be configured to require that the completed deliverable passes through the quality gate.

[0362] In the second embodiment described above, an example was shown in which each quality issue 2411 is uniquely identified by issue_id, but the disclosure is not limited thereto. For example, each quality issue 2411 may be uniquely identified by issue_id and managed in association with the asset ID of the target asset in the asset registry structure 600, and configured to be traceable within and across projects, with individual source code files, design information, products, or related assets associated with it.

[0363] In the second embodiment described above, an example was shown in which the intermediate representation trace display unit displays the state transitions of quality issues 2411 in a tabular format, but the disclosure is not limited thereto. For example, the intermediate representation trace display unit may be configured to display the state transitions of quality issues 2411 in an intermediate representation chain consisting of a current intermediate representation, a conceptual intermediate representation, a requirements design integration intermediate representation, an implementation intermediate representation, a code output intermediate representation, and a deployment intermediate representation in a tabular format in which the divisions of the intermediate representations are arranged horizontally and the individual quality issues 2411 are arranged vertically, and to display each iteration 2412 managed by the retry iteration management unit 2332 as a temporal hierarchy that can be switched and displayed in the tabular format.

[0364] In the second embodiment described above, an example was shown of managing the resolution status of quality issues 2411 as a unit, but the disclosure is not limited thereto. For example, quality issue 2411 may be broken down into multiple sub-issues as needed, and the traceability unit 2315 may be configured to record or display the correspondence between the parent issue and the sub-issues, the resolution status of each sub-issue, and the partial resolution status of the parent issue as a whole.

[0365] In the second embodiment described above, an example was shown in which the system 2010 is configured to function as a software conversion generation system, a software design information restoration system, and a software quality issue management system, but the disclosure is not limited thereto. That is, the system 2010 may be configured to have only one of the functions of a software conversion generation system, a software design information restoration system, and a software quality issue management system.

[0366] In the second embodiment described above, an example was shown in which the operating range of the missing code generation unit 2317 is limited by guards G1 to G7 of the responsibility boundary control unit 2318, but the disclosure is not limited thereto. For example, depending on the operational purpose or system architecture, additional guards such as G8 (code convention violation prohibition guard), G9 (copyright inclusion prohibition guard), and G10 (license non-conformity prohibition guard) may be added, or the upper limit ratio of the difference number of G1 (20% in the first embodiment) may be dynamically adjusted according to operational results.

[0367] In the second embodiment described above, the static performance metrics 2421 included cyclomatic complexity, loop depth distribution, estimated I / O operation count, and estimated database access count, but the disclosure is not limited thereto. Other static metrics, such as Halsted metrics, cognitive complexity, fan-in and fan-out, or dependency graph density, may be added or substituted. Additionally, fields such as availability target, reliability target, and fault recovery time target may be added to the non-functional requirements management node.

[0368] In the second embodiment described above, an example was shown in which the multi-axis quality gate unit 2322 makes judgments on four axes: function, structure, security, and performance. However, this disclosure is not limited thereto. For example, it may be configured as a five-axis or six-axis or more quality gate by adding axes such as accessibility compliance, internationalization compliance, and regulatory compliance in addition to functional accuracy, security robustness, structural soundness, and performance. Furthermore, the threshold values ​​for each axis (0.80, 0.75, 0.85, etc.) may be dynamically updated according to operational performance.

[0369] In the second embodiment described above, nine states were given as examples of the status of quality issue 2411, but this disclosure is not limited thereto. For example, depending on the operational purpose, additional states such as superseded (replaced by a higher-level issue), deferred (carried over to the next project), and invalidated (found to be a false positive in subsequent analysis) may be added.

[0370] In the second embodiment described above, an example was shown where the default retry limit was set to 5 times, but this disclosure is not limited thereto. For example, the retry limit may be set to 3, 7, or 10 times depending on the project size or risk level, and the retry limit may be extended separately for quality issue 2411 with a severity of critical.

[0371] In the second embodiment described above, an example was shown in which the missing code completion code generation pre-determination unit 2333 determines whether DRCG is applicable based on the subcategory and scope of impact, but this disclosure is not limited thereto. For example, it may be configured to make a determination taking into account the test coverage rate related to the target code, the success rate of past similar completions, or the operational policies of the target tenant.

[0372] In the second embodiment described above, an example was shown in which the design change approval unit 2336 targets SystemAdmin or TenantAdmin privileged persons as approvers, but this disclosure is not limited to this. For example, an approval flow such as tiered approval by multiple privileged persons (two-stage approval, three-stage approval), conditional approval, or time-limited approval may be adopted.

[0373] Furthermore, the above-described configuration can be explained as follows.

[0374] The first configuration of the software design information restoration system is a software design information restoration system for restoring software design information, comprising: a single source analysis unit that performs syntactic analysis on a single source file constituting the target software, generates an abstract syntax tree corresponding to the source file, and extracts syntactically parseable static information, including at least the number of instructions, the number of branches, and call relationships, on a function or paragraph basis within the source file; an inference unit that applies inference using a large-scale language model to the single source file and generates a design intent indicating the purpose of the processing that the source file aims to realize and a processing overview summarizing the operation of the source file; a verification unit that compares the design intent and processing overview generated by the inference unit with the abstract syntax tree output by the single source analysis unit to verify whether at least one of the function name, argument structure, return type, and call relationships included in the design intent and processing overview logically corresponds to a node corresponding to the abstract syntax tree; and a storage unit for the results of analyzing the current structure of the target software. A design information infrastructure having a first design information layer, a second design information layer that stores a conversion generation goal including a target programming language, target execution environment, and performance requirements after conversion or generation, and a conversion generation strategy including applicable conversion rules, conversion order, and constraints, and a third design information layer that stores design information of the software system after conversion or generation, comprising: an integration unit that stores the design intent and processing overview, whose logical correspondence has been confirmed by the verification unit, as an intermediate representation of the current state in the first design information layer; a multiple source summary analysis unit that analyzes dependencies across multiple source files constituting the target software, derives relationships between modules and a call graph, and integrates the relationships and the call graph into the first design information layer; and a static performance indicator extraction unit that extracts static performance indicators including at least one of cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses during the syntactic analysis process by the single source analysis unit, wherein the estimated number of database accesses is calculated after obtaining the parent record,This includes the number of code locations (first configuration) where an inefficient access pattern is observed through static analysis, where a database query for retrieving child records is repeatedly issued for each parent record.

[0375] According to the first configuration described above, the inference unit generates the design intent and processing overview through inference using a large-scale language model, and the verification unit verifies the logical correspondence by comparing it with the abstract syntax tree output by the single-source analysis unit. This suppresses hallucination that may occur in the output of the large-scale language model and allows for the restoration of accurate design information. The two-tiered structure, consisting of the analysis results of the single-source analysis unit and the multi-source summary analysis unit which analyzes dependencies across multiple source files and derives the relationships between modules, allows for the step-by-step deriving of design information from the details of individual files to the overall system picture. The static performance indicator extraction unit extracts static performance indicators including at least one of cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses (including the number of code locations where inefficient access patterns are observed), thereby providing an objective basis for subsequent deriving of performance target values.

[0376] In the first configuration, the verification unit may be configured to perform an iterative verification process in which, when it detects an inconsistency between the design intent or processing overview generated by the inference unit and the abstract syntax tree output by the single-source analysis unit, it generates a re-inference instruction for the inference unit to identify the inconsistent part and causes it to re-execute the inference (second configuration).

[0377] According to the second configuration described above, when the verification unit detects an inconsistency, it generates a re-inference instruction to the inference unit to identify the inconsistent part and performs an iterative verification process to re-execute the inference, thereby gradually improving the logical consistency and accuracy of the restored design information.

[0378] In the first configuration, the integration unit may be configured to integrate the contents of existing design documents or business documents associated with the target software into the design information infrastructure (third configuration).

[0379] According to the third configuration described above, the integration unit can build more comprehensive design information, including not only the source code analysis results but also business requirements, by integrating the contents of existing design documents or business documents associated with the target software into the design information infrastructure.

[0380] In the first configuration, the integration unit may be configured to embed the design information stored in the design information infrastructure into a vector space and store it in a vector database and a graph database (fourth configuration).

[0381] According to the fourth configuration described above, the integration unit embeds the design information stored in the design information infrastructure into a vector space and stores it in a vector database and a graph database, enabling searches based on structural relationships and semantic similarities, and allowing for efficient utilization of similar patterns in subsequent software conversions.

[0382] In the first configuration, the integration unit may be configured to fill in 176 design elements specified in a predetermined template with the design intent and processing overview generated by the inference unit (fifth configuration).

[0383] According to the fifth configuration described above, the integration unit fills in the 176 design elements specified in a predetermined template with the design intent and processing overview generated by the inference unit, thereby standardizing and structuring the generated design information and enabling smooth information sharing to subsequent processes.

[0384] In the first configuration, the single-source analysis unit and the multiple-source summary analysis unit may be configured to comprehensively analyze multiple asset types, including source code, database schemas, API definitions, infrastructure description code, and container definitions (sixth configuration).

[0385] According to the sixth configuration described above, the single-source analysis unit and the multi-source summary analysis unit comprehensively analyze multiple asset types, including source code, database schemas, API definitions, infrastructure description code, and container definitions, thereby enabling the centralized reconstruction of the overall system design information by encompassing a wide range of assets that constitute the software.

[0386] In the first configuration, the system may further include a quality evaluation unit that performs a four-axis quality evaluation, including functional quality, structural quality, security quality, and performance quality, on the information stored in the design information infrastructure (seventh configuration).

[0387] According to the seventh configuration described above, the quality evaluation unit can ensure the objective quality of the restored design information from multiple perspectives by performing a four-axis quality evaluation on the information stored in the design information infrastructure, including functional quality, structural quality, security quality, and performance quality.

[0388] In the first configuration, the single-source analysis unit may be configured to perform parallel analysis processing to shorten the analysis time by analyzing multiple source files in parallel (eighth configuration).

[0389] According to the eighth configuration described above, the single-source analysis unit can streamline the analysis process of large-scale software by performing parallel analysis processing, which shortens the analysis time by analyzing multiple source files in parallel.

[0390] In the first configuration, the inference unit may be configured to perform inference using a local large-scale language model that operates within the software design information restoration system without transmitting data to an external service (ninth configuration).

[0391] According to the ninth configuration described above, the inference unit performs inference using a local large-scale language model that operates within the software design information restoration system without transmitting data to external services, thereby preventing the leakage of source code and design information to external parties and meeting high security requirements.

[0392] In the first configuration, the static performance indicators extracted by the static performance indicator extraction unit are further stored in a non-functional requirements management node belonging to the second design information layer of the design information infrastructure, which associates and holds an upper limit on response time, a lower limit on throughput, an upper limit on CPU usage, and an upper limit on memory usage, as the basis for deriving performance target values ​​after software conversion or generation. The performance target values ​​may be configured to be referable as common target values ​​in conversion and generation processes across multiple iterations, and to be used as the basis for comparison with measured performance values ​​obtained by running the code, executable module, or deployment configuration obtained after software conversion or generation in a sandbox environment (10th configuration).

[0393] According to the tenth configuration described above, the performance indicator storage unit stores the extracted static performance indicators in a non-functional requirements management node belonging to the second design information layer, which holds related numerical values ​​such as the upper limit of response time. This provides the basis for deriving performance target values ​​after software conversion or generation, and makes them referable as common target values ​​in conversion and generation processes across multiple iterations. Furthermore, by using these performance target values ​​as the basis for comparison with measured performance values ​​obtained by executing the code and components obtained after software conversion or generation in a sandbox environment, highly accurate performance evaluation combining static indicators and dynamic measured values ​​can be achieved.

[0394] In the first configuration, the system further includes a static performance indicator display unit connected to a user terminal and providing a static performance indicator viewer to the display unit of the user terminal, wherein the static performance indicator viewer displays the cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses extracted by the static performance indicator extraction unit in parallel using a plurality of individual card-type user interface components, and is configured to highlight, with a warning icon, code locations where an inefficient access pattern is observed in static analysis, such as repeatedly issuing database queries to retrieve child records for each parent record after retrieving the parent record (11th configuration).

[0395] According to the 11th configuration described above, the static performance indicator viewer provided by the static performance indicator display unit displays the extracted cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses in parallel in separate card formats. Furthermore, inefficient access patterns such as repeatedly issuing queries for child records after retrieving parent records (potential N+1 query locations, etc.) are highlighted with warning icons, allowing users to intuitively understand areas with performance risks.

[0396] The software design information restoration method relating to the 12th configuration is a control method for a software design information restoration system that restores software design information. The control method performs syntactic analysis on a single source file constituting the target software, generates an abstract syntax tree corresponding to the source file, extracts syntactically parseable static information including at least the number of instructions, the number of branches, and call relationships for each function or paragraph in the source file, applies inference using a large-scale language model to the single source file, generates a design intent indicating the purpose of the processing that the source file aims to realize and a processing summary summarizing the operation of the source file, compares the generated design intent and processing summary with the abstract syntax tree to verify whether at least one of the function name, argument structure, return type, and call relationships included in the design intent and processing summary logically corresponds to a node corresponding to the abstract syntax tree, and stores the results of the analysis of the current structure of the target software in a first design information layer, and a conversion generation element including the target programming language, target execution environment, and performance requirements after the conversion or generation of the software. In a design information infrastructure having a second design information layer that stores a target, a conversion generation strategy including applicable conversion rules, conversion order, and constraints, and a third design information layer that stores design information of the software system after conversion or generation of the software, the first design information layer stores the design intent and the processing overview for which a logical correspondence has been confirmed as an intermediate representation of the current state, analyzes dependencies across multiple source files constituting the target software, derives relationships between modules and a call graph, integrates the relationships and the call graph into the first design information layer, and extracts a static performance indicator (12th configuration) that includes at least one of the following in the process of syntactic analysis: cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses including the number of code locations in which an inefficient access pattern of repeatedly issuing database queries for obtaining child records for each parent record after obtaining the parent record is recognized in static analysis.

[0397] According to the 12th configuration described above, the process of automatically restoring design information itself can be protected from multiple angles.

[0398] The program relating to the 13th configuration includes: a single source analysis process that performs syntactic analysis on a single source file constituting the target software on the processor of the information processing device, generates an abstract syntax tree corresponding to the source file, and extracts syntactically parseable static information, including at least the number of instructions, the number of branches, and call relationships, on a function or paragraph basis within the source file; an inference process that applies inference using a large-scale language model to the single source file to generate a design intent indicating the purpose of the processing that the source file aims to realize and a processing overview summarizing the operation of the source file; a verification process that compares the design intent and processing overview generated by the inference process with the abstract syntax tree to verify whether at least one of the function name, argument structure, return type, and call relationships included in the design intent and processing overview logically corresponds to a node corresponding to the abstract syntax tree; a first design information layer that stores the results of analyzing the current structure of the target software; and the target programming language, target execution environment, and performance after the conversion or generation of the software. The design information infrastructure has a second design information layer that stores a conversion generation goal including requirements, a conversion generation strategy including applicable conversion rules, conversion order, and constraints, and a third design information layer that stores design information of the software system after conversion or generation of the software. The 13th configuration involves executing an integration process in which the first design information layer stores the design intent and processing overview, for which a logical correspondence has been confirmed, as an intermediate representation of the current state; a multiple source summary analysis process that analyzes dependencies across multiple source files constituting the target software, derives relationships between modules and a call graph, and integrates the relationships and the call graph into the first design information layer; and a static performance indicator extraction process that extracts static performance indicators during the syntactic analysis process, including at least one of cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses, which includes the number of code locations where an inefficient access pattern of repeatedly issuing database queries for obtaining child records for each parent record after obtaining the parent record is recognized in static analysis.

[0399] According to the 13th configuration described above, it is possible to provide a program that can suppress hallucination in large-scale language models, enable accurate restoration of design information from source code, and extract static performance metrics to provide a basis for deriving performance target values ​​in subsequent conversion and generation processes. [Explanation of symbols]

[0400] 1: Intermediate representation generation unit, 2: Conversion generation processing unit, 10: Software conversion generation system, 110: Integrated management server, 120: Analysis server, 130: UI server, 140: AI server, 150: Relational database server, 160: Document database server, 170: Integrated knowledge base server, 180: Message queue server, 190: Storage server, 195: Dedicated server for design information infrastructure, 200: IR chain, 201: CS-IR, 202: P-IR, 203: RD-IR, 20 4: I-IR, 205: CO-IR, 206: DP-IR, 211: Dry-Run method, 212: Sampling method, 213: Pattern analysis method, 214: Inference analysis, 220: Knowledge accumulation, 230: Approval gateway, 300: Design information infrastructure, 301: First design information layer (Reverse layer), 302: Second design information layer (Plan layer), 303: Third design information layer (Design layer), 310: Reverse layer details, 320: Plan layer details, 330: Design layer details, 340: Provenance self-replication, 35 0: IR chain linkage, 400: Hybrid scoring processing, 401: Graph database, 402: Vector database, 401a: Graph database, 402a: Vector database, 403: Scoring processing unit, 410: Structural search, 420: Semantic search, 430: Language specification extraction agent, 500: Feedback flow, 501: Quality gate, 502: F1 feedback, 503: F2 feedback, 504: F3 feedback, 505: F4 feedback, 506: F5 feedback, 511: Functional accuracy, 512: Security robustness, 513: Structural soundness, 600: Asset registry structure, 601: Asset ID tree structure, 602: Lineage graph, 610: Business requirements, 611: Design intent, 612: Regulatory compliance, 613: Intellectual property, 614: Operational knowledge, 615: External contracts, 616: KPI, 617: Security, 620: Source hash deduplication, 630: Provenance generation by AI inference, 700: Phased migration structure, 701: Facade, 702: Phase management, 703: Migration flow, 800: GPS vector, 801: Structural path, 802: Tenant boundary, 803: Audit path, 804: Transformation provenance900: System 2010 Vector, 901: Syntax, 902: Semantics, 903: Dependencies, 904: Data Flow, 905: Control Flow, 906: Architecture, 907: Security, 908: Testing, 909: Performance, 910: Documentation, 911: Business Logic, 912: Infrastructure, 1001: Full Modernization, 1002: Direct Transformation, 1003: Data Transformation, 1004: API Transformation, 1005: IaC Transformation, 1006: Container Transformation, 1100: Screen Transition Overview, 1200: Transformation Dictionary System, 1210: Structure-Preserving Transformation Rules, 1220: Architecture-Driven Transformation Rules 2010: Software design information recovery system, 2110: Integrated management server, 2120: Analysis server (syntactic analysis server), 2130: UI server, 2140: AI server, 2150: Relational database (SQL database) server, 2160: Document database (NoSQL database) server, 2170: Integrated knowledge base server (graph / vector database server), 2172: DIT server, 2180: Message queue server (task queue server), 2190: Storage server (Web storage server, Docker) (Including Sandbox), 2195: Dedicated server for design information infrastructure, 2201: Current status intermediate representation (CS-IR), 2202: Conceptual intermediate representation (P-IR), 2203: Requirements design integrated intermediate representation (RD-IR), 2204: Implementation intermediate representation (I-IR), 2205: Code output intermediate representation (CO-IR), 2206: Deployment intermediate representation (DP-IR), 2211: Single source analysis unit, 2212: Splitting unit, 2213: Inference unit, 2214: Verification unit, 2215: Integration unit, 2216: Multiple source summary analysis unit, 2217: Static performance indicators Extraction unit, 2218: Performance indicator storage unit, 2300: Design information infrastructure, 2301: First design information layer (Reverse layer), 2302: Second design information layer (Plan layer), 2303: Third design information layer (Design layer), 2311: Issue recording unit, 2312: Issue inheritance unit, 2313: Issue selection unit, 2314: Issue resolution determination unit, 2315: Traceability unit, 2316: Recommendation engine unit, 2317: Missing data completion code generation unit (DRCG), 2318: Responsibility boundary control unit (ResponsibilityGuard, G1~G7),2319: Performance Audit Agent, 2320: Target Value Comparison Unit, 2321: Severity Determination Unit, 2322: Multi-axis Quality Gate Unit (4-axis Quality Gate Unit), 2331: Forced Resolution Marking Unit, 2332: Retry Iteration Management Unit, 2333: Missing Data Completion Code Generation Pre-determination Unit (Pre-determination Unit), 2334: Forced Resolution Verification Unit, 2335: Severity Automatic Promotion Unit, 23 36: Design Change Approval Section, 2401: Static Performance Index Viewer Screen (Screen S-01), 2402: Performance Target Value Viewing / Editing Screen (Screen S-02), 2403: Issue Selection Screen (Screen S-03), 2404: Performance Measurement Progress Monitor Screen (Screen S-04), 2405: 4-Axis Quality Gate Dashboard Screen (Screen S-05), 2406: Performance Audit Result Viewer Screen (Screen S-06), 2407: Performance Issue IR Chain Full Stage Trace Screen (Screen S-07), 2408: Retry Status Dashboard Screen (Screen S-08), 2409: Design Change Approval Screen (Screen S-09), 2411: Quality Issue (quality_issue), 2412: Iteration, 2413: Must Resolve Flag (must_resolve_flag), 2414: Mandatory Until Iteration Sequence Information (mandatory_until_iteration_seq), 2415: Originating Gate Identifier (originating_gate_fail_id), 2416: Design Change Approval Record (Approval Record), 2421: Static Performance Metrics, 2422: Performance Target Values, 2501: Full Modernization, 2502: Direct Conversion, 2503: Data Conversion, 2504: API Conversion, 2505: IaC Conversion, 2506: Container Conversion,

Claims

1. A software design information recovery system for recovering software design information, A single source analysis unit performs syntactic analysis on a single source file that constitutes the target software, generates an abstract syntax tree corresponding to the source file, and extracts syntactically parseable static information, including at least the number of instructions, the number of branches, and call relationships, on a function or paragraph basis within the source file. An inference unit that applies inference using a large-scale language model to the single source file and generates a design intent that indicates the purpose of the processing that the source file aims to achieve and a processing overview that summarizes the operation of the source file, A verification unit compares the design intent and processing overview generated by the inference unit with the abstract syntax tree output by the single-source analysis unit to verify whether at least one of the function name, argument structure, return type, and call relationship included in the design intent and processing overview logically corresponds to a node in the abstract syntax tree. A design information infrastructure having: a first design information layer that stores the results of analyzing the current structure of the target software; a second design information layer that stores a conversion and generation goal including the target programming language, target execution environment, and performance requirements after the conversion or generation of the software, and a conversion and generation strategy including the conversion rules, conversion order, and constraints to be applied; and a third design information layer that stores the design information of the software system after the conversion or generation of the software; wherein the first design information layer has an integration unit that stores the design intent and the processing overview, whose logical correspondence has been confirmed by the verification unit, as an intermediate representation of the current state; A multi-source summary analysis unit analyzes dependencies across multiple source files constituting the target software, derives relationships between modules and a call graph, and integrates the relationships and the call graph into the first design information layer. The system includes a static performance indicator extraction unit that extracts a static performance indicator, which includes at least one of the following: cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses, during the syntactic analysis process performed by the single-source analysis unit, The estimated number of database accesses includes the number of code locations where, after retrieving a parent record, an inefficient access pattern is observed through static analysis, specifically the number of locations where a database query for retrieving child records is repeatedly issued for each parent record. This is a software design information recovery system.

2. The software design information restoration system according to claim 1, wherein the verification unit, when it detects an inconsistency between the design intent or processing overview generated by the inference unit and the abstract syntax tree output by the single source analysis unit, generates a re-inference instruction for the inference unit to identify the inconsistent part and performs an iterative verification process to cause the inference unit to re-execute the inference.

3. The software design information restoration system according to claim 1, wherein the integration unit integrates the contents of existing design documents or business documents associated with the target software into the design information infrastructure.

4. The software design information restoration system according to claim 1, wherein the integration unit converts the natural language portion of the design information stored in the design information infrastructure into real-valued vectors using a sentence embedding model or a document embedding model, converts the structural information into a structural path representation, and stores them in a vector database and a graph database.

5. The software design information restoration system according to claim 1, wherein the integration unit fills in 176 design elements specified in a predetermined template with the design intent and processing overview generated by the inference unit.

6. The software design information recovery system according to claim 1, wherein the single source analysis unit and the multiple source summary analysis unit comprehensively analyze multiple asset types including source code, database schema, API definition, infrastructure description code, and container definition.

7. The software design information restoration system according to claim 1, further comprising a quality evaluation unit that performs a four-axis quality evaluation, including functional quality, structural quality, security quality, and performance quality, on the information stored in the design information infrastructure.

8. The software design information restoration system according to claim 1, wherein the single-source analysis unit performs parallel analysis processing to shorten the analysis time by analyzing multiple source files in parallel.

9. The software design information restoration system according to claim 1, wherein the inference unit performs inference using a local large-scale language model that operates within the software design information restoration system without transmitting data to an external service.

10. The system further includes a performance indicator storage unit that stores the static performance indicators extracted by the static performance indicator extraction unit in a non-functional requirements management node belonging to the second design information layer of the design information infrastructure, which associates and holds the upper limit of response time, the lower limit of throughput, the upper limit of CPU usage, and the upper limit of memory usage, as the basis for deriving the performance target values ​​after software conversion or generation. The software design information restoration system according to claim 1, wherein the performance target value can be referenced as a common target value in the conversion generation process across multiple iterations, and is used as the basis for comparison with measured performance values ​​obtained by running the code, executable module, or deployment configuration obtained after software conversion or generation in a sandbox environment.

11. The system further includes a static performance indicator display unit that is connected to a user terminal and provides a static performance indicator viewer to the display unit of the user terminal, The static performance indicator viewer displays the cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses extracted by the static performance indicator extraction unit in parallel using a plurality of individual card-type user interface components, and highlights code locations where, after acquiring the parent record, an inefficient access pattern is observed in static analysis, such as repeatedly issuing database queries to acquire child records for each parent record, by adding a warning icon, the software design information restoration system according to claim 1.

12. A control method for a software design information recovery system that recovers software design information, The system performs syntactic analysis on a single source file that constitutes the target software, generates an abstract syntax tree corresponding to the source file, and extracts parseable static information, including at least the number of instructions, the number of branches, and call relationships, for each function or paragraph within the source file. Applying inference using a large-scale language model to the single source file, generate a design intent that indicates the purpose of the processing the source file aims to achieve and a processing overview that summarizes the operation of the source file. The generated design intent and processing overview are compared with the abstract syntax tree to verify whether at least one of the function name, argument structure, return type, and call relationship included in the design intent and processing overview logically corresponds to a node in the abstract syntax tree. In a design information infrastructure having a first design information layer that stores the results of analyzing the current structure of the target software, a second design information layer that stores a conversion and generation goal including the target programming language, target execution environment, and performance requirements after the conversion or generation of the software, and a conversion and generation strategy including the conversion rules, conversion order, and constraints to be applied, and a third design information layer that stores the design information of the software system after the conversion or generation of the software, the first design information layer stores the design intent and the processing overview, for which a logical correspondence has been confirmed, as an intermediate representation of the current state. The dependencies are analyzed across multiple source files constituting the target software, the relationships between modules and the call graph are derived, and the relationships and the call graph are integrated into the first design information layer. During the parsing process, a static performance metric is extracted that includes at least one of the following: cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses, which includes the number of code locations where an inefficient access pattern is observed in static analysis, where a database query for retrieving child records is repeatedly issued for each parent record after the parent record has been retrieved. A control method for a software design information recovery system.

13. In the processor of the information processing device, A single source parsing process that performs syntactic analysis on a single source file constituting the target software, generates an abstract syntax tree corresponding to the source file, and extracts syntactically parseable static information, including at least the number of instructions, the number of branches, and call relationships, on a function or paragraph basis within the source file, An inference process that applies inference using a large-scale language model to the single source file and generates a design intent that indicates the purpose of the processing that the source file aims to achieve and a processing overview that summarizes the operation of the source file, A verification process that compares the design intent and processing overview generated by the inference process with the abstract syntax tree to verify whether at least one of the function name, argument structure, return type, and call relationship included in the design intent and processing overview logically corresponds to a node in the abstract syntax tree. A design information infrastructure comprising: a first design information layer for storing the results of analyzing the current structure of the target software; a second design information layer for storing a conversion and generation goal including the target programming language, target execution environment, and performance requirements after the conversion or generation of the software, and a conversion and generation strategy including the conversion rules, conversion order, and constraints to be applied; and a third design information layer for storing design information of the software system after the conversion or generation of the software; and an integrated process for storing the design intent and processing overview, for which a logical correspondence has been confirmed, as an intermediate representation of the current state in the first design information layer. A multi-source summary analysis process that analyzes dependencies across multiple source files constituting the target software, derives relationships between modules and a call graph, and integrates the relationships and the call graph into the first design information layer, A program that performs a static performance indicator extraction process during the aforementioned parsing process, which extracts static performance indicators including at least one of the following: cyclomatic complexity, loop depth distribution, estimated number of input / output operations, and estimated number of database accesses, which includes the number of code locations where an inefficient access pattern of repeatedly issuing database queries to retrieve child records for each parent record after retrieving the parent record is observed in static analysis.

Images