Software conversion generation system, data structure, program, and control method for the software conversion generation system.

Abstract

This invention provides a software conversion generation system, data structure, program, and control method for the software conversion generation system that can accurately generate conversions of software systems that operate on a target platform. [Solution] The software conversion generation system 10 includes a scoring processing unit that scores by referring to a database which includes a graph database configured to store source code conversion generation rules between multiple programming languages ​​in a graph structure of nodes and edges and enable structural searching, and a vector database configured to store vector embedding representations of the source code conversion generation rules and enable semantic searching, and a conversion generation processing unit that performs conversion generation of a software system while referring to the scores scored by the scoring processing unit.

Description

Technical Field

[0001] The present invention relates to a software conversion generation system, a data structure, a program, and a control method for a software conversion generation system.

Background Art

[0002] Patent Document 1 describes a software code conversion device. This conversion device includes a rule-based knowledge engine that analyzes input code using a custom knowledge base. The knowledge engine performs a process of separating code blocks and converting them into an intermediate or target specification format.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The conversion device described in Patent Document 1 separates code blocks by a rule-based knowledge engine using a custom knowledge base and converts them into an intermediate or target specification format. However, in this conversion process, it is difficult to accurately perform the conversion of software code when the rule corresponding to the software code does not exist in the custom knowledge base.

[0005] The present disclosure has been made to solve the above problems, and an object thereof is to provide a software conversion generation system, a data structure, a program, and a control method for a software conversion generation system capable of accurately performing conversion, generation, or both conversion and generation of a software system operating on a target platform.

Means for Solving the Problems

[0006] To achieve the above objectives, the software conversion and generation system disclosed below is a software conversion and generation system that converts, generates, or both converts and generates a software system that operates on a target platform. The software conversion and generation system comprises: an intermediate representation generation unit that generates an intermediate representation of a software system; a scoring processing unit that refers to a database which includes a graph database that stores source code conversion and generation rules between multiple programming languages ​​in a graph structure of nodes and edges and is configured to enable structural searching based on the structural relationships of the graph structure, and a vector database that stores vector embedding representations of the source code conversion and generation rules and is configured to enable semantic searching based on semantic similarity, and scores based on the results of the structural search and the semantic search; and a conversion and generation processing unit that converts, generates, or both converts and generates a software system that operates on the target platform, while referring to the scores scored by the scoring processing unit.

[0007] Furthermore, the data structure disclosed below is a data structure used by a computer for processing the transformation and generation of software systems. The data structure comprises a graph database configured to enable structural searching based on structural relationships, including transformation and generation rule nodes, language nodes, and transformation and generation possibility relationships connecting them, in the graph structure, which stores source code transformation and generation rules between multiple programming languages ​​in a graph structure of nodes and edges; a vector database configured to enable semantic searching based on semantic similarity, which stores vector embedding representations of the source code transformation and generation rules; a language master database that structures and manages syntax rules, semantic definitions, and inter-language correspondence relationships of multiple programming languages; and a document database that stores source code analysis results and intermediate representation data in an unstructured format. The data structure is configured to enable the determination of transformation and generation patterns by scoring based on the results of structural and semantic searches using the graph database and the vector database.

[0008] Furthermore, the program disclosed below causes the processor of an information processing device to execute: an intermediate representation generation process that generates an intermediate representation of a software system; a scoring process that refers to a database including a graph database that stores source code conversion generation rules between multiple programming languages ​​in a graph structure of nodes and edges, and a vector database that stores vector embedding representations of the source code conversion generation rules, and scores based on the results of a structural search based on the structural relationships of the graph structure and a semantic search based on semantic similarity; and a conversion generation process that converts, generates, or both converts and generates a software system that operates on a target platform, while referring to the scores scored in the scoring process.

[0009] Furthermore, the control method for a software conversion and generation system disclosed below is a control method for a software conversion and generation system that performs conversion, generation, or both conversion and generation of a software system that operates on a target platform. The control method for a software conversion and generation system generates an intermediate representation of the software system, and refers to a database including a graph database that stores source code conversion and generation rules between multiple programming languages ​​in a graph structure of nodes and edges, and a vector database that stores vector embedding representations of the source code conversion and generation rules, to perform a structural search based on the structural relationships of the graph structure and a semantic search based on semantic similarity, scores based on the results of the structural search and semantic search using the graph database and the vector database, and performs conversion, generation, or both conversion and generation of the software system that operates on the target platform while referring to the score obtained by the scoring. [Effects of the Invention]

[0010] With the above configuration, it is possible to accurately perform the conversion, generation, or both of the conversion and generation of software systems that operate on the target platform. [Brief explanation of the drawing]

[0011] [Figure 1A] Figure 1A is a schematic diagram showing the configuration of the software conversion generation system 10 in this embodiment. [Figure 1B] Figure 1B is a schematic diagram showing the configuration of the software conversion generation system 10 in this embodiment. [Figure 2] Figure 2 is a flowchart showing the processing of the IR chain 200 in this 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]FIG. 5 is a diagram for explaining a feedback flow 500. [Figure 6] FIG. 6 is a diagram for explaining an asset registry structure 600. [Figure 7] FIG. 7 is a diagram showing a gradual transition structure 700 according to the Strangler Fig pattern. [Figure 8] FIG. 8 is a block diagram showing the configuration of a GPS vector 800. [Figure 9] FIG. 9 is a block diagram showing the configuration of a system vector 900 of the present system. [Figure 10] FIG. 10 is a conceptual diagram for explaining six process paths. [Figure 11A] FIG. 11A shows an overview of screen transitions 1100 in a UI server 130. [Figure 11B] FIG. 11B is a diagram showing the screen configuration of an analysis result dashboard. [Figure 11C] FIG. 11C is a diagram showing the configuration of a quality issue list screen. [Figure 11D] FIG. 11D is a diagram showing the configuration of a traceability display screen. [Figure 11E] FIG. 11E is a diagram showing the configuration of a task selection type conversion parameter screen. [Figure 11F] FIG. 11F is a diagram showing the screen transitions of an administrator console. [Figure 11G] FIG. 11G is a diagram showing the screen configuration of a dynamic viewer. [Figure 11H] FIG. 11H is a diagram showing the screen transitions of a modernization workflow. [Figure 12] FIG. 12 is a diagram showing a conversion dictionary system 1200. [Figure 13] FIG. 13 is a diagram showing the detailed flow of six process paths. [Figure 14] FIG. 14 is a diagram showing the relationship of six core asset elements. [Figure 15] FIG. 15 is a diagram for explaining tenant separation. [Modes for carrying out the invention]

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

[0013] [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 this 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.

[0014] As shown in Figure 1A, the software conversion generation system 10 of this 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".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0030] [2. Databases and Knowledge Management Structure] The logical knowledge base in this 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.

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

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

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

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

[0035] Furthermore, as a physical implementation of this 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 a predetermined dimension, and combining these feature vectors with the GPS vector 800.

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

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

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

[0039] 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 this embodiment, is mainly materialized 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.

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

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

[0042] In this 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, analyze source code or related documents, and generate concrete syntax trees, abstract syntax trees, symbol information, or dependency information.

[0043] [4. Step-by-step intermediate representation chain] Figure 2 is a flowchart showing the processing of the IR chain 200 in this embodiment. As shown in Figure 2, the IR chain 200 in this 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 this 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.

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

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

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

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

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

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

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

[0051] 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 this embodiment, CS-IR201, P-IR202, RD-IR203, I-IR204, CO-IR205, and DP-IR206 correspond to design information layer linkage IRs.

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

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

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

[0055] 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 this embodiment, it includes RD-IR203, which is the requirements design integrated intermediate representation, and I-IR204, which is the implementation intermediate representation.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0085] In this embodiment, the design information infrastructure 300 may be implemented by multiple 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0112] Each of the above thresholds may be set according to the implementation. As an example, a threshold T1 for functional accuracy, a threshold T2 for security robustness, a threshold T3 for structural soundness, a threshold T4 for overall quality, a threshold T5 for analysis completeness, and a threshold T6 for the target quality 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.

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

[0114] [12. Approval / Rejection Receiving Unit and Judgment Processing Unit] In this embodiment, the approval / rejection receiving unit may be implemented by the approval gateway 230 and the UI server 130. After the intermediate representation generation unit 1 generates the first intermediate representation and the second intermediate representation, the approval / rejection receiving unit receives the approval / rejection from the user for the intermediate representation.

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

[0116] When rejection is received, 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 approval / rejection receiving unit may receive partial approval that approves only a part, or conditional approval that is regarded as approval when a predetermined condition is satisfied.

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

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

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

[0120] Data transformation 1003 may be a path for transforming a database schema, data definition, or data file.

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

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

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

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

[0125] In this 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.

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

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

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

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

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

[0131] 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 may be defined, and the migration from the legacy system to the new system may proceed in stages.

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

[0133] [15. Four-Asset Model, Core Assets, and Asset Registry] This 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 language master databases, conversion dictionaries, rule sets, etc. Output assets include converted code, design deliverables, deployment definitions, reports, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0153] [18. Verification Implementation Methods] As verification of this 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.

[0154] In this verification process, API testing, extension testing, browser testing, and quality checks may be performed.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0182] 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 applied to modules above a predetermined threshold, and the Greenfield type may be applied to modules below the predetermined threshold. This embodiment may be applied, for example, to the modernization of a large-scale financial system.

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

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

[0185] 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]

[0186] In this 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.

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

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

[0189] [24. Variant] 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.

[0190] The above embodiment shows an example of a server configuration, but is not limited to this. 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 of these.

[0191] The above embodiment shows an example of the number of stages in the IR chain, but it is not limited to this. 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.

[0192] In the above embodiment, 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.

[0193] In the above embodiment, an example was shown in which the approval / rejection receiving unit accepts either approval or rejection from the user, but the disclosure is not limited thereto. For example, the approval / rejection receiving unit may be configured to accept not only approval and rejection, but also 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.

[0194] In the above embodiment, an example was 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.

[0195] The above embodiment shows an example 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 conversion process or the number of languages ​​to be converted, 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 converted.

[0196] In the above embodiment, an example was shown in which the design information infrastructure 300 is composed of three layers: a Reverse layer 301, a Plan layer 302, and a Design layer 303. However, this disclosure is not limited to this example. 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.

[0197] In the above embodiment, 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.

[0198] In the above embodiment, an example was 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. However, the disclosure is not limited thereto. For example, the GPS vector may be configured to adopt a configuration that includes additional security attribute subvectors or performance characteristic subvectors.

[0199] The above embodiment shows an example in which the integrated knowledge base manages the graph database 401 and the vector database 402 by consolidating them 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.

[0200] In the above embodiment, an example was 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.

[0201] In the embodiments described above, examples were shown in which 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).

[0202] The above embodiment shows 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 the 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.

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

[0204] The first configuration of the software conversion and generation system is a software conversion and generation system that performs conversion, generation, or both conversion and generation of a software system that operates on a target platform, and comprises: an intermediate representation generation unit that generates an intermediate representation of the software system; a graph database that stores source code conversion and generation rules between multiple programming languages ​​in a graph structure of nodes and edges and is configured to enable structural searching based on the structural relationships of the graph structure; a vector database that stores vector embedding representations of the source code conversion and generation rules and is configured to enable semantic searching based on semantic similarity; a scoring processing unit that refers to the database and scores based on the results of the structural search and the semantic search; and a conversion and generation processing unit that performs conversion, generation, or both conversion and generation of the software system that operates on the target platform while referring to the scores scored by the scoring processing unit (first configuration).

[0205] According to the first configuration described above, by performing scoring based on the results of structural searches based on structural relationships using a graph database and semantic searches based on semantic similarity using a vector database, it is possible to discover semantically similar transformation patterns even when no perfectly matching transformation rules exist in the database. As a result, it is possible to accurately perform transformation, generation, or both transformation and generation of software systems running on the target platform.

[0206] In the first configuration, the software conversion generation system may further include an acceptance / rejection receiving unit that accepts or rejects the intermediate expression from a user after the intermediate expression has been generated by the intermediate expression generation unit, and a determination processing unit that permits processing by the conversion generation processing unit when the acceptance / rejection receiving unit accepts acceptance from the user, and prevents processing by the conversion generation processing unit when the acceptance / rejection receiving unit accepts rejection from the user (second configuration).

[0207] According to the second configuration described above, the approval gateway function provided by the approval / rejection reception unit and the decision processing unit allows the user's decision to be involved in the transition of the intermediate representation to the next process, thereby ensuring transparency and security of decision-making in the conversion generation process.

[0208] In the first configuration, the scoring processing unit may be configured to assign a first weight to the results of semantic similarity searches based on cosine similarity in the vector database, assign a second weight to the results of structural searches based on graph queries in the graph database, combine the semantic search results assigned the first weight and the structural search results assigned the second weight as an integrated score, and perform ranking based on the integrated score (third configuration).

[0209] According to the third configuration described above, a first weight is assigned to the semantic search results of the vector database, and a second weight to the structural search results of the graph database. By combining these as an integrated score, ranking can be performed that takes into account both structural relevance and semantic similarity.

[0210] In the first configuration, the database may be configured to include a language master database that manages syntax rules, semantic definitions, and inter-language correspondences of multiple programming languages, the graph database, the vector database, and a document database that stores source code analysis results and intermediate representation data in an unstructured format (fourth configuration).

[0211] According to the fourth configuration described above, by including a language master database, graph database, vector database, and document database, it is possible to manage everything from structural knowledge of programming language specifications to unstructured data, and it can function as an integrated foundation that supports structural and semantic searches.

[0212] In the first configuration, the transformation generation rules stored in the graph database may be configured to have a structure in which an edge indicating an inverse transformation generation relationship is provided between a forward transformation generation rule node from the first programming language to the second programming language and a reverse transformation generation rule node from the second programming language to the first programming language (fifth configuration).

[0213] According to the fifth configuration described above, in the graph database, by adding edges that indicate the inverse transformation generation relationship between forward and reverse transformation generation rule nodes, the correspondence between bidirectional transformation generation rules can be associated and managed.

[0214] In the first configuration, the software conversion generation system further comprises a language specification extraction agent that works in conjunction with the scoring processing unit, wherein the language specification extraction agent is configured to acquire the grammar specification of a new programming language, analyze the grammar specification, generate a parser corresponding to the new programming language, and register the syntax rules, semantic definitions, and correspondence relationships with existing languages ​​of the new programming language in the database (sixth configuration).

[0215] According to the sixth configuration described above, the language specification extraction agent acquires and analyzes the grammar specifications of new programming languages, generates parsers, and registers them in the database, thus easily expanding the system's supported programming languages ​​without relying on manual configuration.

[0216] In the first configuration, the scoring processing unit may have a search agent that integrates a large-scale language model and graph-based search extension generation, and the search agent may be configured to perform the structural search and the semantic search while referring to the database, and to add new transformation generation patterns obtained as a result of the transformation generation process performed by the transformation generation processing unit to the database (seventh configuration).

[0217] According to the seventh configuration described above, a search agent integrating a large-scale language model and graph-based search extension generation performs searches while referring to the database, and adds new transformation generation patterns obtained as a result of the transformation generation process to the database. This enables search and knowledge accumulation that leverages the reasoning power of AI, thereby improving transformation accuracy.

[0218] In the seventh configuration, the intermediate representation generated by the intermediate representation generation unit is configured as a stepwise intermediate representation chain, and the scoring processing unit may be configured to perform the structural search and the semantic search at each stage of the stepwise intermediate representation chain to obtain a transformation generation pattern, and to perform a knowledge update process to add the results of the transformation generation performed by the transformation generation processing unit to the database (eighth configuration).

[0219] According to the eighth configuration described above, structural and semantic searches are performed at each stage of the stepwise intermediate representation chain to obtain transformation generation patterns, and knowledge update processing is performed to add the results of transformation generation to the database. This allows for the selection of patterns and updating of knowledge according to each stage of the transformation process.

[0220] In the eighth configuration, the system may further be configured to include a plurality of specialized AI agents, including the search agent, document analysis agent, report generation agent, test agent, language specification extraction agent, security audit agent, and architecture audit agent, which cooperate by referring to the database (ninth configuration).

[0221] According to the ninth configuration described above, multiple specialized AI agents responsible for search, document analysis, report generation, testing, language specification extraction, security audits, and architecture audits can collaborate by referencing the database, thereby supporting transformation and generation processes from multiple perspectives.

[0222] In the first configuration, the transformation generation processing unit may execute six process paths, including full modernization, direct transformation, API transformation, data transformation, infrastructure definition transformation, and container transformation, and the database may be configured to be used as a common knowledge base for the six process paths (10th configuration).

[0223] According to the above-described configuration 10, a common knowledge base can be used to address six process paths, including full modernization, API conversion, and container conversion, enabling a consistent and flexible response to diverse forms of conversion needs.

[0224] In the first configuration, the vector embedding representation is generated from the abstract syntax tree of the source code, and the semantic search in the scoring processing unit may be configured to find semantically equivalent transformation generation patterns between different programming languages ​​and determine a transformation generation path by matching them with transformation generation rules included in the graph database (11th configuration).

[0225] According to the 11th configuration described above, semantic search using vector embedding representations generated from an abstract syntax tree can discover semantically equivalent transformation generation patterns between different programming languages. By comparing these patterns with transformation generation rules in a graph database, the optimal transformation generation path can be determined with greater accuracy.

[0226] The data structure relating to the 12th configuration is a data structure used by a computer for processing the transformation and generation of software systems. The data structure comprises a graph database configured to store source code transformation and generation rules between multiple programming languages ​​in a graph structure of nodes and edges, and to enable structural searching based on structural relationships including transformation and generation rule nodes, language nodes, and edges of transformation and generation possibility relationships connecting them in the graph structure; a vector database configured to store vector embedding representations of the source code transformation and generation rules, and to enable semantic searching based on semantic similarity; a language master database that structures and manages syntax rules, semantic definitions, and inter-language correspondence relationships of multiple programming languages; and a document database that stores source code analysis results and intermediate representation data in an unstructured format. The data structure is configured to determine transformation and generation patterns by scoring based on the results of structural and semantic searches using the graph database and the vector database (12th configuration).

[0227] According to the 12th configuration described above, by providing a data structure that includes a graph database, a vector database, a language master database, and a document database, it becomes possible to determine the optimal pattern through integrated scoring of structural and semantic searches. Furthermore, by protecting the integrated knowledge base as a data structure invention, it becomes possible to enforce rights against any entity that uses the data structure.

[0228] The program relating to the 13th configuration is a program that causes the processor of an information processing device to execute an intermediate representation generation process that generates an intermediate representation of a software system; a scoring process that refers to a database including a graph database that stores source code conversion generation rules between multiple programming languages ​​in a graph structure of nodes and edges, and a vector database that stores vector embedding representations of the source code conversion generation rules, and scores based on the results of a structural search based on the structural relationships of the graph structure and a semantic search based on semantic similarity; and a conversion generation process that converts, generates, or both converts and generates a software system that operates on a target platform, while referring to the scores scored in the scoring process (13th configuration).

[0229] According to the 13th configuration described above, even when no perfectly matching rule exists, it is possible to provide a program that can find semantically similar transformation patterns and perform transformation, generation, or both transformation and generation of software systems running on the target platform with high accuracy.

[0230] The control method for a software conversion and generation system relating to the 14th configuration is a control method for a software conversion and generation system that performs conversion, generation, or both conversion and generation of a software system that operates on a target platform, and involves generating an intermediate representation of the software system, referring to a database that includes a graph database storing source code conversion and generation rules between multiple programming languages ​​in a graph structure of nodes and edges, and a vector database storing vector embedding representations of the source code conversion and generation rules, performing a structural search based on the structural relationships of the graph structure and a semantic search based on semantic similarity, scoring based on the results of the structural search and semantic search using the graph database and the vector database, and performing conversion, generation, or both conversion and generation of the software system that operates on the target platform while referring to the score obtained by the scoring (14th configuration).

[0231] According to the 14th configuration described above, it is possible to provide a control method for a software transformation and generation system that can find semantically similar transformation patterns even when no perfectly matching rule exists, and can accurately perform transformation, generation, or both transformation and generation of a software system operating on a target platform.

[0232] In the sixth configuration, the software conversion generation system further comprises a quality gate determination unit that performs a quality gate determination on the conversion generation result by the conversion generation processing unit based on predetermined quality standards, and if the quality gate determination unit determines that it is unsatisfactory, the language specification extraction agent analyzes the cause of failure to identify the root cause, and based on the root cause, performs improvements to the conversion generation rules stored in the graph database, the conversion dictionary stored in the database, or the language specification, and the scoring processing unit may be configured to improve the accuracy of subsequent conversion generation pattern selection using the improved conversion generation rules, conversion dictionary, or language specification (15th configuration).

[0233] According to the above-described configuration 15, when the quality gate determination unit determines that a product is unacceptable, a feedback mechanism is provided that analyzes the cause of the unacceptability, improves the database's conversion generation rules, conversion dictionary, or language specifications, and enhances the accuracy of subsequent pattern selection. This enables an autonomous and continuous learning and quality improvement process without human intervention.

[0234] In the first configuration, the scoring processing unit may be configured to calculate a parsing completeness score by weighting a predetermined weight for each of several parsing evaluation elements, including parsing success rate, syntax tree generation rate, symbol resolution rate, dependency detection rate, and embedded language detection rate, for the parsing results of the document analysis by the intermediate representation generation unit, and to initiate the database improvement process if the parsing completeness score falls below a predetermined threshold (16th configuration).

[0235] According to the above-described configuration 16, an analysis completeness score is calculated by weighting multiple analysis evaluation elements such as the parsing success rate, and if the score is low, a database improvement process is initiated. This allows for appropriate identification of whether the cause of quality degradation is a problem on the analysis side and enables the implementation of corrective actions.

[0236] This disclosure also includes the following inventions: [Additional note 1] A software conversion and generation system that performs conversion, generation, or both conversion and generation of software systems, Databases including graph databases and vector databases, A software transformation generation system comprising: a scoring processing unit that selects a transformation generation pattern based on scoring that integrates the results of a structural search using the graph database and a semantic search using the vector database. [Additional note 2] The scoring processing unit assigns a first weight to the results of the structural search and a second weight to the results of the semantic search to calculate an integrated score. An intermediate representation generation unit that acquires and analyzes documents and generates intermediate representations while referring to the aforementioned database, A conversion generation processing unit that performs a conversion generation process using the aforementioned intermediate representation, A software conversion and generation system as described in Appendix 1, further comprising the features described in Appendix 1. [Explanation of Symbols]

[0237] 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 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, 302: Second design information layer (Plan layer), 303: Third design information layer, 310: Reverse layer details, 320: Plan layer details, 330: Design layer details, 340: Self-replicating, 350: IR chain linkage, 400: Hybrid Scoring processing, 401: Graph database, 402: 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 513: Robustness, 600: Structural soundness, 601: Asset registry structure, 602: Asset ID tree structure, 610: Business requirements, 611: Design intent, 612: Regulatory compliance, 613: Intellectual property, 614: Operational knowledge, 615: External contracts, 616: KPIs, 617: Security, 620: Source hash deduplication, 630: Provenance generation, 700: Phased migration structure, 701: Facade, 702: Phase management, 703: MigrationFlow, 800: GPS vector, 801: Structural path, 802: Tenant boundary, 803: Audit path, 804: Transformation history, 900: Main system 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

Claims

1. A software conversion and generation system that converts, generates, or both converts and generates software systems that operate on a target platform, An intermediate representation generation unit that generates an intermediate representation of a software system, A scoring processing unit that refers to a database and scores based on the results of the structural search and the semantic search, the graph database having a graph structure having nodes that store at least one of the source language identifier, target language identifier, conversion priority, conversion performance score, and bidirectional flag of source code conversion generation rules between multiple programming languages, and edges that store relationships indicating the possibility of source code conversion between the multiple programming languages, and the graph structure being configured to enable structural search based on structural relationships, and a vector database that stores vector embedding representations of the source code conversion generation rules and is configured to enable semantic search based on semantic similarity, A conversion and generation processing unit that performs conversion, generation, or both conversion and generation of a software system operating on the target platform, Equipped with, The scoring processing unit is, In the graph database, the structural search is performed to search for candidates for source code transformation generation rules with a high degree of structural relevance by inputting a graph query, or by using one of the following methods: pattern matching, or graph traversal. In the vector database, the semantic search is performed to find candidate source code transformation generation rules with high semantic similarity. A scoring process is performed to calculate an integrated score, which is a weighted sum of the structural relevance of the candidate source code transformation generation rules obtained by the structural search and the semantic relevance of the candidate source code transformation generation rules obtained by the semantic search. A software conversion and generation system comprising: a conversion and generation processing unit that determines from among the candidate source code conversion and generation rules the source code conversion and generation rule with the highest integrated score as the source code conversion and generation rule to be used for conversion and generation; and a software conversion and generation system that operates on the target platform in accordance with the source code conversion and generation rule.

2. After the intermediate expression is generated by the intermediate expression generation unit, the acceptance / rejection receiving unit accepts acceptance or rejection of the intermediate expression from the user, The software conversion generation system according to claim 1, further comprising: a determination processing unit that permits processing by the conversion generation processing unit when the approval / rejection receiving unit receives approval from the user, and prevents processing by the conversion generation processing unit when the approval / rejection receiving unit receives rejection from the user.

3. The software conversion generation system according to claim 1, wherein the scoring processing unit assigns a first weight to the results of a semantic similarity search based on cosine similarity in the vector database, assigns a second weight to the results of a structural search based on a graph query in the graph database, combines the semantic search results assigned the first weight and the structural search results assigned the second weight as the integrated score, and ranks the candidates for the source code conversion generation rule based on the integrated score.

4. The software conversion generation system according to claim 1, wherein the database includes a language master database for managing syntax rules, semantic definitions, and inter-language correspondences of multiple programming languages, the graph database, the vector database, and a document database for storing source code analysis results and intermediate representation data in an unstructured format.

5. The software conversion generation system according to claim 1, wherein the source code conversion generation rules stored in the graph database have a structure in which edges indicating an inverse conversion generation relationship are provided between a forward conversion generation rule node from a first programming language to a second programming language and a reverse conversion generation rule node from the second programming language to the first programming language.

6. The system further includes a language specification extraction agent that works in conjunction with the aforementioned scoring processing unit, The software conversion generation system according to claim 1, wherein the language specification extraction agent obtains the grammar specification of a new programming language, analyzes the grammar specification, generates a parser corresponding to the new programming language, and registers the syntax rules, semantic definitions, and correspondence relationships with existing languages ​​of the new programming language in the database.

7. The scoring processing unit has a search agent that integrates a large-scale language model and graph-based search extension generation. The software conversion generation system according to claim 1, wherein the search agent performs the structural search and the semantic search while referring to the database, and adds the new conversion generation pattern obtained as a result of the conversion generation process performed by the conversion generation processing unit to the database.

8. The intermediate representation generated by the intermediate representation generation unit is configured as a stepwise intermediate representation chain. The software conversion generation system according to claim 7, wherein the scoring processing unit performs the structural search and the semantic search at each stage of the stepwise intermediate representation chain to obtain a conversion generation pattern, and performs a knowledge update process to add the results of the conversion generation performed by the conversion generation processing unit to the database.

9. The software conversion generation system according to claim 8, further comprising a plurality of specialized AI agents, including the search agent, document analysis agent, report generation agent, test agent, language specification extraction agent, security audit agent, and architecture audit agent, which cooperate in referring to the database.

10. The aforementioned conversion generation processing unit executes six process paths, including full modernization, direct conversion, API conversion, data conversion, infrastructure definition conversion, and container conversion. The software conversion generation system according to claim 1, wherein the database is configured to be used as a common knowledge base for the six process paths.

11. The software transformation generation system according to claim 1, wherein the vector embedding representation is generated from an abstract syntax tree of the source code, and the semantic search in the scoring processing unit discovers a transformation generation pattern that is semantically equivalent between different programming languages ​​and determines a transformation generation path by comparing it with the source code transformation generation rules included in the graph database.

12. In the processor of the information processing device, An intermediate representation generation process that generates an intermediate representation of a software system, A graph database including a graph structure having nodes that store at least one of the source language identifier, target language identifier, conversion priority, conversion performance score, and bidirectional flag among source code conversion generation rules between multiple programming languages, and edges that store relationships indicating the possibility of source code conversion between the multiple programming languages, and configured to enable structural searches based on structural relationships; and a vector database that stores vector embedding representations of the source code conversion generation rules and configured to enable semantic searches based on semantic similarity, wherein the scoring process refers to the database and scores based on the results of the structural search and the semantic search. While referring to the scores scored in the aforementioned scoring process, the system is made to perform a conversion and generation process that converts, generates, or both converts and generates a software system that operates on the target platform. The aforementioned scoring process is, In the graph database, the structural search is performed to search for candidates for source code transformation generation rules with a high degree of structural relevance by inputting a graph query, or by using one of the following methods: pattern matching, or graph traversal. In the vector database, the semantic search is performed to find candidate source code transformation generation rules with high semantic similarity. A scoring process is performed to calculate an integrated score, which is a weighted sum of the structural relevance of the candidate source code transformation generation rules obtained by the structural search and the semantic relevance of the candidate source code transformation generation rules obtained by the semantic search. The conversion generation process is a program that determines, from among the candidate source code conversion generation rules, the source code conversion generation rule with the highest integrated score to be used for conversion generation, and performs conversion, generation, or both conversion and generation of a software system that operates on the target platform according to the source code conversion generation rule.

13. A control method for a software conversion and generation system that performs conversion, generation, or both conversion and generation of a software system operating on a target platform, Generate an intermediate representation of the software system, A graph database including a graph structure having nodes that store at least one of the source language identifier, target language identifier, conversion priority, conversion performance score, and bidirectional flag among source code conversion generation rules between multiple programming languages, and edges that store relationships indicating the possibility of source code conversion between the multiple programming languages, and configured to enable structural searches based on structural relationships, and a vector database that stores vector embedding representations of the source code conversion generation rules and is configured to enable semantic searches based on semantic similarity, is referenced to perform scoring based on the results of the structural search and the semantic search. While referring to the score obtained by the scoring, a conversion and generation process is executed that converts, generates, or both converts and generates the software system that operates on the target platform. Performing the aforementioned scoring means In the graph database, the structural search is performed to search for candidates for source code transformation generation rules with a high degree of structural relevance by inputting a graph query, or by using one of the following methods: pattern matching, or graph traversal. In the vector database, the semantic search is performed to find candidate source code transformation generation rules with high semantic similarity. This includes performing scoring to calculate an integrated score which is a weighted sum of the structural relevance of the candidate source code transformation generation rules obtained by the structural search and the semantic relevance of the candidate source code transformation generation rules obtained by the semantic search, A control method for a software conversion generation system, which involves executing the conversion generation process, selecting a source code conversion generation rule with a high integrated score from among the candidate source code conversion generation rules as the source code conversion generation rule to be used for conversion generation, and performing conversion, generation, or both conversion and generation of a software system that operates on the target platform according to the source code conversion generation rule.

14. The system further comprises a quality gate determination unit that performs a quality gate determination based on predetermined quality standards on the results of the conversion generation by the conversion generation processing unit, If the quality gate determination unit determines that the product is unacceptable, the language specification extraction agent will: Analyze the reasons for failure and identify the root cause. Based on the aforementioned root cause, improvements are made to the conversion generation rules stored in the graph database, the conversion dictionaries stored in the database, or the language specifications. The software conversion generation system according to claim 6, wherein the scoring processing unit improves the accuracy of subsequent conversion generation pattern selection using improved conversion generation rules, conversion dictionaries, or language specifications.

15. The software conversion generation system according to claim 1, wherein the scoring processing unit calculates a parsing completeness score by assigning predetermined weights to a plurality of parsing evaluation elements, including parsing success rate, syntax tree generation rate, symbol resolution rate, dependency detection rate, and embedded language detection rate, for the parsing completeness score of the document analysis result by the intermediate representation generation unit, and activates the database improvement process when the parsing completeness score falls below a predetermined threshold.

Images