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

Abstract

The present invention provides a software conversion and generation system, a program, and a control method for the software conversion and generation system that can accurately perform conversion, generation, or both conversion and generation of software systems that operate on a target platform. [Solution] The software conversion generation system 10 comprises an intermediate representation generation unit 1 that analyzes a document and generates a first intermediate representation while referring to a database, extracts information related to the conversion generation of a software system by executing a trial conversion generation process that simulates the conversion generation process of a software system using the first intermediate representation, generates a second intermediate representation using the extracted conversion generation information, and adds the extracted conversion generation information to a database, and a conversion generation processing unit 2 that performs conversion generation of a software system using the first intermediate representation and the second intermediate representation.

Description

Technical Field

[0001] The present invention relates to a software conversion generation system, 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, difficulties, optimal patterns, and the existence of special syntax may be found after the process starts. In this case, it is difficult to accurately execute the conversion of software code.

[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 program, and a control method for a software conversion generation system that can accurately perform 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 performs conversion, generation, or both conversion and generation of a software system that operates on a target platform. The software conversion and generation system comprises: an intermediate representation generation unit that acquires a document, analyzes the document, generates a first intermediate representation while referring to a database containing information on the characteristics of multiple programming languages, extracts information related to the conversion and generation of a software system by executing a trial conversion and generation process that simulates the conversion and generation process of a software system using the first intermediate representation, generates a second intermediate representation using the extracted conversion and generation information, and adds the extracted conversion and generation information to the database; and a conversion and generation processing unit that performs conversion, generation, or both conversion and generation of a software system that operates on the target platform using the first intermediate representation and the second intermediate representation.

[0007] Furthermore, the program disclosed below causes the processor of the information processing device to execute an intermediate representation generation process that acquires a document, analyzes the document, generates a first intermediate representation while referring to a database containing information on the characteristics of multiple programming languages, extracts information related to conversion and generation by executing a trial conversion and generation process that simulates the conversion and generation process of a software system using the first intermediate representation, generates a second intermediate representation using the extracted information related to conversion and generation, and adds the extracted information related to conversion and generation to the database; and a conversion and generation process that uses the first intermediate representation and the second intermediate representation to perform conversion, generation, or both conversion and generation of a software system that operates on a target platform.

[0008] 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. This control method obtains a document, analyzes the document, generates a first intermediate representation while referring to a database containing information on the characteristics of multiple programming languages, and extracts information related to the conversion and generation of a software system by executing a trial conversion and generation process that simulates the conversion and generation process of a software system using the first intermediate representation. It then generates a second intermediate representation using the extracted conversion and generation information, adds the extracted conversion and generation information to the database, and performs conversion, generation, or both conversion and generation of a software system that operates on the target platform using the first and second intermediate representations. [Effects of the Invention]

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

[0010] [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 this 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 an issue 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.

Mode for Carrying Out the Invention

[0011] Hereinafter, an embodiment of the present invention will be described based on the drawings. Note that the present invention is not limited to the following embodiments, and design changes can be appropriately made within the scope that satisfies the configuration of the present invention. In the following description, the same reference numerals are commonly used between different drawings for the same part or parts having the same function, and the repeated description thereof will be omitted. Also, the respective configurations described in the embodiments and modification examples may be combined or changed as appropriate. In addition, for the sake of clarity of explanation, in the drawings referred to below, the configurations are shown in a simplified or schematic manner, or some of the constituent members are omitted.

[0012] [1. Overall Configuration of Software Conversion Generation System 10] FIGS. 1A and 1B are schematic views showing the configuration of a software conversion generation system 10 in the present embodiment. In this specification, "software conversion generation" means converting a software system so as to operate on a target platform, generating a new software system for the target platform, or performing both of these. Hereinafter, when simply referred to as "conversion generation", it means a concept including conversion, generation, or both conversion and generation. That is, the software conversion generation system 10 is a system that generates and converts a software system so as to operate on a target platform. Note that in the present disclosure, in addition to those shown below, any known hardware configuration (such as a control circuit, a storage circuit, and a network) can be adopted for the "system". The control circuit includes a processor that executes each control process based on a program.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0034] Furthermore, as a physical implementation of 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0052] Examples of execution methods for the trial transformation process include a Dry-Run method 211 for 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0111] Each of the above thresholds may be set according to the implementation. As an example, 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 target object 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.

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

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

[0114] Also, the judgment processing unit may be realized as the control logic of the overall management server 110 or the control logic of the approval gateway 230. When the approval / rejection reception 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.

[0115] 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 reception unit may receive partial approval that approves only a part, or conditional approval that is regarded as approval when a predetermined condition is satisfied. [[ID=二十]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0131] Migration flow 703 may include a rollback mechanism. If the migration result of 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0187] Furthermore, the conversion generation process results and quality gate judgment results are updated as proof history, which may continuously improve the accuracy of conversion pattern selection in subsequent projects.

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

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

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

[0191] 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 needed.

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

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

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

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

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

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

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

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

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

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

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

[0203] The software conversion and generation system according to the first configuration is a software conversion and generation system that converts, generates, or both converts and generates a software system that operates on a target platform, and comprises: an intermediate representation generation unit that acquires a document, analyzes the document, generates a first intermediate representation while referring to a database containing information on the characteristics of multiple programming languages, extracts information related to the conversion and generation of a software system by executing a trial conversion and generation process that simulates the conversion and generation process of a software system using the first intermediate representation, generates a second intermediate representation using the extracted conversion and generation information, and adds the extracted conversion and generation information to the database; and a conversion and generation processing unit that converts, generates, or both converts and generates a software system that operates on the target platform using the first intermediate representation and the second intermediate representation (first configuration).

[0204] According to the first configuration described above, trial conversion processing using the first intermediate representation allows for the extraction and analysis of information such as conversion processing difficulties, optimal patterns, and the existence of special syntax in advance. This improves the quality of the second intermediate representation and enhances the accuracy of the actual conversion generation. Furthermore, by accumulating the extracted information in the database, the system's conversion capabilities autonomously improve with each conversion run. As a result, difficulties and other issues can be extracted in advance before the start of the actual conversion, enabling accurate conversion, generation, or both conversion and generation of software systems operating on the target platform.

[0205] In the first configuration, the software conversion generation system may further include an approval / rejection receiving unit that receives approval or rejection from the user for the first intermediate expression and the second intermediate expression after the intermediate expression generation unit has generated them, and 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 (second configuration).

[0206] According to the second configuration described above, the approval function of the approval / rejection reception unit and the decision processing unit allows the user's decision-making to be involved in the transition of the intermediate expression to the next process. As a result, transparency and security of decision-making in the conversion generation process can be ensured.

[0207] In the first configuration, the first intermediate representation may include a conceptual intermediate representation that expresses a concept including business objectives and constraints in a graph structure, and the second intermediate representation may include a requirements design integrated intermediate representation that expresses functional requirements, non-functional requirements, and architectural design integrally in a single graph structure, and an implementation intermediate representation that includes class, method, and field-level definitions for the target platform (third configuration).

[0208] According to the third configuration described above, by generating intermediate representations in multiple stages, from the conceptualization of business objectives (intermediate conceptual representation) to requirements design (integrated requirements design intermediate representation) and detailed implementation (intermediate implementation representation), the design information to be converted can be structurally managed and appropriately inherited throughout the conversion process.

[0209] In the third configuration, the requirements design integrated intermediate representation may be configured to represent the functional requirements, non-functional requirements, and architecture design as a single graph structure, maintain intrinsic traceability from the functional requirements to the architecture design as edges on the graph, and have a change propagation mechanism in which the architecture design is modified in response to changes in the functional requirements (fourth configuration).

[0210] According to the fourth configuration described above, in the requirements design integrated intermediate representation, functional requirements, non-functional requirements, and architectural design are represented as a single graph structure, maintaining intrinsic traceability. This realizes a change propagation mechanism in which changes in functional requirements are immediately propagated to the architectural design, thereby preventing inconsistencies between requirements and design.

[0211] In the first configuration, parsing the document may be configured to generate intermediate products, including generating concrete and abstract syntax trees based on a parser, generating a symbol table conversion, creating a data flow graph, and extracting metadata, and generating the first intermediate representation may be configured to generate the first intermediate representation using the intermediate products (fifth configuration).

[0212] According to the fifth configuration described above, by performing detailed document analysis through the generation of syntax trees and data flow graphs using a parser, the structure of the current software can be accurately grasped, which can serve as the basis for generating a highly accurate first intermediate representation.

[0213] In the first configuration, the intermediate representation generation unit is configured by integrating a large-scale language model and graph-based search extension generation, and the intermediate representation generation unit may include a plurality of expert AI agents, and the plurality of expert AI agents may jointly execute a trial transformation generation process in which they tentatively execute the transformation generation process while referring to the database together, and may also be configured to add new transformation generation patterns and knowledge information obtained in the trial transformation generation process to the database (sixth configuration).

[0214] According to the sixth configuration described above, by coordinating a specialized AI agent that integrates a large-scale language model with graph-based search extension generation, it becomes possible to leverage the AI's reasoning power to perform highly accurate trial transformation processing and knowledge extraction, thereby achieving autonomous improvement of more advanced transformation capabilities.

[0215] In the sixth configuration, the process of adding to the database by the multiple specialized AI agents may be configured to include a process of adding new transformation generation patterns to the database without erasing existing ones, by searching for existing transformation generation patterns in the trial transformation generation process and adding new transformation generation patterns, optimization parameters, and quality improvement information to the database based on the results of inferring the applicability of the transformation generation patterns by the large-scale language model (seventh configuration).

[0216] According to the seventh configuration described above, the AI ​​agent can accumulate and add new patterns, etc., based on its reasoning, without erasing existing patterns. This allows for the safe and continuous utilization of past knowledge in subsequent processes within the same project and in future separate projects.

[0217] In the first configuration, the database may be configured as an integrated knowledge base including a graph database that stores source code conversion 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 generation rules and is configured to enable semantic searching based on semantic similarity (eighth configuration).

[0218] According to the eighth configuration described above, by configuring the database as an integrated knowledge base that includes a graph database capable of structural searching and a vector database capable of semantic searching, transformation knowledge can be managed comprehensively and integrally from the perspectives of both structural relationships and semantic similarities.

[0219] In the eighth configuration, the intermediate representation generation unit may be configured to perform a hybrid search that combines the results of a structural search based on a graph query using the graph database and the results of a semantic similarity search based on cosine similarity using the vector database as an integrated score with predetermined weighting, and to determine a transformation generation pattern in the generation of the first intermediate representation and the trial transformation generation process based on the integrated score (ninth configuration).

[0220] According to the ninth configuration described above, hybrid search, which combines structural search results and semantic similarity search results as an integrated score, can discover the optimal semantically similar transformation pattern even when no perfectly matching transformation rule exists, thereby achieving high-quality transformation and generation.

[0221] In the eighth configuration, the software conversion generation system further comprises a language specification extraction agent that works in conjunction with the intermediate representation generation unit, and the language specification extraction agent may be configured to obtain and analyze the grammar specification of a new programming language from the document, generate a parser corresponding to the new programming language, and register the syntax rules, semantic definitions, and correspondences with existing languages ​​of the new programming language in the integrated knowledge base (tenth configuration).

[0222] According to the above-described configuration 10, the language specification extraction agent automatically obtains the official grammar specifications of new programming languages ​​and generates parsers and registers them in the database, thus enabling the system to easily and automatically expand its supported programming languages ​​without relying on manual configuration.

[0223] In the first configuration, the analysis of the document by the intermediate representation generation unit may be configured to include: detection and isolation analysis of code fragments of another programming language, different from the programming language in the document, that are embedded in a part of the document; and integration processing that integrates related objects, including copybooks, include files, data definitions, and screen definitions referenced by the document (11th configuration).

[0224] According to the 11th configuration described above, by performing embedded language detection, separation and analysis, and integration processing of related files, precise analysis becomes possible even for source code containing multiple languages ​​or systems that depend on external definitions, thereby improving the accuracy and comprehensiveness of conversion.

[0225] In the first configuration, the transformation generation processing unit is capable of integrally executing six process paths, including full modernization, direct transformation, API transformation, data transformation, infrastructure definition transformation, and container transformation, and the first intermediate representation and the second intermediate representation generated by the intermediate representation generation unit, as well as the database, may be configured to be used in common by the six process paths (12th configuration).

[0226] According to the above 12th configuration, six process paths, including full modernization and API conversion, can be handled integrally using a common intermediate representation and knowledge base, enabling flexible responses to diverse forms of conversion needs with consistent quality.

[0227] In the first configuration, the database may be configured to have a two-tiered knowledge management structure consisting of a language master database that structures and manages the syntax rules, semantic definitions, and inter-language correspondences of multiple programming languages, and a conversion dictionary that manages conversion patterns between the programming languages ​​(13th configuration).

[0228] According to the 13th configuration described above, by separating and managing the database in a two-tiered structure of language specification information and conversion knowledge information, mutual interference with changes in language specifications and the addition of new conversion patterns can be prevented, thereby realizing scalable knowledge management.

[0229] In the sixth configuration, the plurality of specialized AI agents may include a specialized AI agent that evaluates the quality of the transformation generation results on three axes: functional accuracy, security robustness, and structural soundness, and the specialized AI agent that evaluates the quality on the three axes may be configured to feed back the evaluation results on the three axes to the database and form a learning loop that continuously improves the quality of subsequent transformation generation (14th configuration).

[0230] According to the above 14th configuration, quality can be evaluated along three axes: functional accuracy, security robustness, and structural soundness. By feeding the results back into the database, a robust learning loop can be formed that continuously improves the quality of subsequent transformation generation from multiple perspectives.

[0231] In the first configuration, the software conversion generation system may further include an automatic feedback loop processing unit that executes an automatic feedback loop, which includes: a quality gate determination unit that performs a quality gate determination on the result of conversion generation by the conversion generation processing unit based on predetermined quality standards; a cause analysis process that analyzes the cause of failure and identifies the root cause and the affected conversion generation pattern if the quality gate determination unit determines that the result is unsatisfactory; an improvement proposal process that generates improvement proposals for conversion generation rules, conversion dictionaries, or language specifications stored in the database based on the root cause; a verification process that experimentally executes the improvement proposal in an isolated verification environment and compares the quality scores before and after the improvement; an approval application process that applies the improvement proposal to the database after predetermined approval based on the results of the verification process; and a reprocess that re-executes conversion generation by the conversion generation processing unit using the database to which the improvement proposal has been applied (15th configuration).

[0232] According to the above 15th configuration, a series of automated feedback loops are provided that, in the event of a quality gate failure, perform everything from root cause analysis to engine improvement suggestions, sandbox verification, approval control, and reprocessing. This enables an autonomous and continuous quality improvement process without human intervention.

[0233] In the 15th configuration, the quality gate determination unit may be configured to calculate an analysis completeness score indicating whether the document was analyzed accurately and completely by the intermediate representation generation unit, and an object quality score indicating the quality of the source code of the document being analyzed, and to activate the automatic feedback loop if the analysis completeness score falls below a predetermined threshold, and to provide the object quality score to the conversion generation processing unit as a basis for determining the subsequent conversion generation strategy if the object quality score falls below a predetermined threshold (16th configuration).

[0234] According to the above 16th configuration, by separately calculating the "analysis completeness score" and the "object quality score," it is possible to accurately determine whether the cause of quality degradation is a problem on the analysis side or a problem with the source code itself, and to automatically execute appropriate countermeasures for each.

[0235] In the 15th configuration, the approval application process may be configured to determine the risk level based on the content of each improvement action included in the improvement proposal, apply without approval if the risk level is at the first level, require approval from an administrator within the tenant if the risk level is at the second level, and require approval from a system administrator if the risk level is at the third level, thereby performing a stepwise determination of approvers (17th configuration).

[0236] According to the above configuration (No. 17), by implementing a step-by-step approval control process from automatic application to system administrator approval depending on the risk level of the improvement proposal, it is possible to achieve both speed in applying improvements and security against significant changes to the system.

[0237] In the 16th configuration, the transformation generation processing unit applies a transformation generation that includes improvement processing for quality issues of the source code of the document detected by the analysis when the object quality score is less than the predetermined threshold, and the improvement processing for quality issues may be configured to include at least one of the following: removal of dead code, method splitting to reduce cyclomatic complexity, replacement of security vulnerability patterns with secure patterns, encapsulation of global variables, and addition of error handling (18th configuration).

[0238] According to the above 18th configuration, when the quality score of the target object is low, applying quality improvement type transformations such as dead code removal and method splitting can improve the internal quality of the software itself, rather than simply changing the language.

[0239] In the third configuration, the software conversion generation system further comprises a design information infrastructure referenced by the intermediate representation generation unit, the design information infrastructure having a first design information layer that stores the results of analyzing the current structure of the software to be converted and generated; a second design information layer that stores business objectives, constraints, conversion generation objectives, and conversion generation strategies used for generating the conceptual intermediate representation, the requirements design integrated intermediate representation, and the implementation intermediate representation; and a third design information layer that stores functional requirements, non-functional requirements, architecture designs, and class, method, and field-level definitions for the target platform, wherein each of the design information layers is chained together in a time-series configuration along the conversion generation process, and the system further comprises an update processing unit that updates the design information infrastructure by sequentially recording the results of conversion generation performed by the conversion generation processing unit in association with each of the design information layers (19th configuration).

[0240] According to the above 19th configuration, by sequentially recording the execution results in a design information infrastructure in which the first to third design information layers are linked in chronological order, it is possible to structurally grasp the overall picture of the conversion target throughout all stages of the conversion process, thereby ensuring the inheritance of design intent and complete traceability.

[0241] The program relating to the 20th configuration is a program that causes the processor of the information processing device to execute an intermediate representation generation process which involves acquiring a document, analyzing the document, generating a first intermediate representation while referring to a database containing information on the characteristics of multiple programming languages, extracting information related to conversion and generation by executing a trial conversion and generation process which simulates the conversion and generation process of a software system using the first intermediate representation, generating a second intermediate representation using the extracted information related to conversion and generation, and adding the extracted information related to conversion and generation to the database, and a conversion and generation process which uses the first intermediate representation and the second intermediate representation to perform conversion, generation, or both conversion and generation of a software system that operates on the target platform (the 20th configuration).

[0242] According to the 20th configuration described above, it is possible to provide a program that can accurately perform conversion, generation, or both conversion and generation of software systems operating on a target platform by pre-extracting difficulties and other issues before the actual conversion begins, thereby autonomously improving the system's conversion capabilities.

[0243] The control method for a software conversion and generation system according to the 21st 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 comprises: acquiring a document, analyzing the document, generating a first intermediate representation while referring to a database containing information on the characteristics of multiple programming languages, and using the first intermediate representation to perform a trial conversion and generation process that simulates the conversion and generation process of a software system, thereby extracting information related to the conversion and generation of a software system, generating a second intermediate representation using the extracted information related to the conversion and generation, adding the extracted information related to the conversion and generation to the database, and using the first intermediate representation and the second intermediate representation to perform conversion, generation, or both conversion and generation of a software system that operates on the target platform (21st configuration).

[0244] According to the 21st configuration described above, it is possible to provide a control method for a software conversion and generation system that can autonomously improve the system's conversion capabilities by pre-extracting difficulties and other issues before the actual conversion begins, and can accurately perform conversion, generation, or both conversion and generation of software systems that operate on the target platform.

[0245] This disclosure also includes the following inventions: [Additional note 1] In any one of the above configurations 1 to 21, The aforementioned database may constitute an integrated knowledge base including a graph database and a vector database. The intermediate representation generation unit may be configured to extract information related to the conversion generation, including conversion generation pattern information, conversion difficulty information, and quality information, from the results of the trial execution. The aforementioned conversion generation processing unit includes functional accuracy, security robustness, and structural integrity. The conversion generation results are evaluated based on quality gates using multiple quality evaluation axes, and the quality gates are The system may be configured to trigger a feedback loop if it determines that the system has failed. [Explanation of Symbols]

[0246] 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 acquires a document, analyzes the document, and in a database that stores syntax rules, semantic definitions, inter-language correspondences, conversion generation patterns between multiple programming languages, and conversion generation information extracted by a trial conversion generation process, performs a search based on the results of the analysis of the document, generates a first intermediate representation including a conceptual intermediate representation that expresses a concept including business objectives and constraints in a graph structure using the search results, extracts information regarding the conversion generation of a software system by performing a trial conversion generation process that simulates the conversion generation process of a software system using the first intermediate representation, generates a second intermediate representation using the extracted conversion generation information, which includes a requirements design integrated intermediate representation that integrally expresses functional requirements, non-functional requirements, and architecture design in a single graph structure, and an implementation intermediate representation that includes class, method, and field-level definitions for the target platform, and adds the extracted conversion generation information to the database. A software conversion and generation system comprising: a conversion and generation processing unit that performs conversion, generation, or both conversion and generation of a software system operating on the target platform using the first intermediate representation and the second intermediate representation.

2. After the first intermediate expression and the second intermediate expression are generated by the intermediate expression generation unit, the acceptance / rejection receiving unit accepts acceptance or rejection from the user regarding the first intermediate expression and the second intermediate expression, 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 requirements design integrated intermediate representation represents the functional requirements, the non-functional requirements, and the architecture design as a single graph structure, maintains intrinsic traceability from the functional requirements to the architecture design as edges on the graph, and has a change propagation mechanism in which the architecture design is modified in accordance with changes to the functional requirements, as described in claim 1, for the software conversion generation system.

4. Parsing the aforementioned document involves generating intermediate products, including the generation of concrete and abstract syntax trees based on a parser, the conversion and generation of symbol tables, the creation of a data flow graph, and the extraction of metadata. The software conversion generation system according to claim 1, wherein generating the first intermediate representation includes generating the first intermediate representation using the intermediate product.

5. The aforementioned intermediate representation generation unit is configured by integrating a large-scale language model and graph-based search extension generation. The aforementioned intermediate representation generation unit includes a plurality of specialized AI agents, The software conversion generation system according to claim 1, wherein the plurality of specialized AI agents jointly execute the trial conversion generation process while referring to the database together, and add new conversion generation patterns and knowledge information acquired in the trial conversion generation process to the database.

6. The additional processing of the database by the aforementioned multiple specialized AI agents is as follows: In the aforementioned trial transformation generation process, the existing transformation generation patterns are searched, The software conversion generation system according to claim 5, which includes a process of adding new conversion generation patterns without erasing existing conversion generation patterns by adding new conversion generation patterns, optimization parameters, and quality improvement information to the database based on the results of inferring the applicability of the conversion generation patterns using the large-scale language model.

7. The aforementioned database is A graph database configured to store source code conversion generation rules between multiple programming languages ​​in a graph structure of nodes and edges, and to enable structural searching based on the structural relationships of the graph structure, The software conversion generation system according to claim 1, comprising an integrated knowledge base including a vector database configured to store vector embedding representations of the source code conversion generation rules and to enable semantic searching based on semantic similarity.

8. The intermediate representation generation unit, A hybrid search is performed that combines the results of a structural search based on graph queries using the graph database and the results of a semantic similarity search based on cosine similarity using the vector database, with predetermined weightings, to form an integrated score. The software conversion generation system according to claim 7, wherein a conversion generation pattern is determined in the generation of the first intermediate representation and the trial conversion generation process based on the integrated score.

9. The system further includes a language specification extraction agent that works in conjunction with the aforementioned intermediate representation generation unit. The software conversion generation system according to claim 7, wherein the language specification extraction agent obtains and analyzes the grammar specification of a new programming language from the document, 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 integrated knowledge base.

10. The analysis of the document by the intermediate representation generation unit is performed as follows: Detection and isolation analysis of code fragments of another programming language, different from the programming language in the aforementioned document, that are embedded in a part of the aforementioned document, The software conversion generation system according to claim 1, further comprising: an integration process for integrating related objects, including copybooks, include files, data definitions, and screen definitions referenced by the aforementioned document.

11. The aforementioned transformation generation processing unit is capable of integrally executing six process paths, including full modernization, direct transformation, API transformation, data transformation, infrastructure definition transformation, and container transformation. The software conversion generation system according to claim 1, wherein the first intermediate representation and the second intermediate representation generated by the intermediate representation generation unit, as well as the database, are configured to be used in common by the six process paths.

12. The software conversion generation system according to claim 1, wherein the database has a two-tiered knowledge management structure comprising a language master database that structures and manages the syntax rules, semantic definitions, and inter-language correspondences of multiple programming languages, and a conversion dictionary that manages conversion patterns between the programming languages.

13. The aforementioned multiple specialized AI agents, It includes a specialized AI agent that evaluates the quality of the conversion generation results on three axes: functional accuracy, security robustness, and structural integrity. The software conversion generation system according to claim 5, wherein a specialized AI agent that evaluates quality along the three axes feeds back the evaluation results along the three axes to the database, forming a learning loop that continuously improves the quality of subsequent conversion generation.

14. A quality gate determination unit performs a quality gate determination based on predetermined quality standards on the result of the conversion generation by the conversion generation processing unit, If the quality gate determination unit determines that the product is unacceptable, a cause analysis process is performed to analyze the cause of the unacceptability and identify the root cause and the affected transformation generation pattern. An improvement suggestion process that generates improvement suggestions for conversion generation rules, conversion dictionaries, or language specifications stored in the database based on the aforementioned root cause, A verification process is performed to execute the aforementioned improvement proposal in an isolated verification environment and compare the quality scores before and after the improvement. An approval application process is performed to apply the improvement proposal to the database after obtaining the necessary approvals based on the results of the verification process. The software conversion generation system according to claim 1, further comprising an automatic feedback loop processing unit that executes an automatic feedback loop, which includes reprocessing to re-execute conversion generation by the conversion generation processing unit using the database to which the improvement proposal has been applied.

15. The aforementioned quality gate determination unit is For the analysis of the document by the intermediate representation generation unit, an analysis completeness score is calculated, indicating whether the document was analyzed accurately and completely, and an object quality score is calculated, indicating the quality of the source code of the document being analyzed. The software conversion generation system according to claim 14, wherein the automatic feedback loop is activated when the analysis completeness score falls below a predetermined threshold, and the object quality score is provided to the conversion generation processing unit as a basis for determining the subsequent conversion generation strategy when the object quality score falls below a predetermined threshold.

16. The aforementioned approval application process is, Based on the content of each improvement action included in the aforementioned improvement proposal, the risk level is determined. This shall be applied without approval if the aforementioned risk level is at the first level. If the aforementioned risk level is at the second level, approval from the administrator within the tenant is required. Approval from the system administrator is required if the aforementioned risk level is at the third level. A software conversion generation system according to claim 14, which performs a step-by-step determination of approvers.

17. The conversion generation processing unit, when the object quality score is less than the predetermined threshold, applies a conversion generation that includes improvement processing for the quality issues of the source code of the document detected by the analysis. The software transformation generation system according to claim 15, wherein the improvement process for the aforementioned quality issues includes at least one of the following: removal of dead code, method splitting to reduce cyclomatic complexity, replacement of security vulnerability patterns with secure patterns, encapsulation of global variables, and addition of error handling.

18. The intermediate representation generation unit further includes a design information infrastructure that it references, The aforementioned design information infrastructure is A first design information layer that stores the results of analyzing the current structure of the software to be converted and generated, A second design information layer that stores business objectives, constraints, transformation generation objectives, and transformation generation strategies used in generating the aforementioned conceptual intermediate representation, the requirements design integrated intermediate representation, and the implementation intermediate representation, It has a third design information layer that stores functional requirements, non-functional requirements, architectural designs, and class, method, and field-level definitions for the target platform, The software conversion generation system according to claim 1, further comprising an update processing unit that updates the design information infrastructure by sequentially recording the results of conversion generation performed by the conversion generation processing unit in association with each of the design information layers, wherein each of the design information layers is configured in a chain along the time series of the conversion generation process.

19. In the processor of the information processing device, Intermediate representation generation process: Obtain a document, analyze the document, and in a database that stores syntax rules, semantic definitions, inter-language correspondences, conversion generation patterns between multiple programming languages, and conversion generation information extracted by a trial conversion generation process, perform a search based on the results of the analysis of the document, generate a first intermediate representation including a conceptual intermediate representation that expresses a concept including business objectives and constraints in a graph structure using the search results, extract information related to conversion generation by performing a trial conversion generation process that simulates the conversion generation process of a software system using the first intermediate representation, generate a second intermediate representation using the extracted conversion generation information, which includes a requirements design integrated intermediate representation that integrally expresses functional requirements, non-functional requirements, and architecture design in a single graph structure, and an implementation intermediate representation that includes class, method, and field-level definitions for the target platform, and add the extracted conversion generation information to the database. A program that uses the first intermediate representation and the second intermediate representation to perform a conversion and generation process that converts, generates, or both converts and generates a software system that operates on a target platform.

20. 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, The system acquires a document, analyzes the document, and, in a database that stores syntax rules, semantic definitions, inter-language correspondences, conversion generation patterns between multiple programming languages, and conversion generation information extracted through a trial conversion generation process, performs a search based on the results of the analysis of the document, and uses the search results to generate a first intermediate representation that includes an intermediate representation of the concept, which represents the concept including business objectives and constraints in a graph structure. By performing a trial conversion generation process that simulates the conversion generation process of the software system using the first intermediate representation, information regarding the conversion generation of the software system is extracted. A second intermediate representation is generated using the extracted information on the transformation generation, which includes a requirements design integrated intermediate representation that integrally represents functional requirements, non-functional requirements, and architectural design in a single graph structure, and an implementation intermediate representation that includes class, method, and field-level definitions for the target platform, and the extracted information on the transformation generation is added to the database. A control method for a software conversion and generation system, which uses the first intermediate representation and the second intermediate representation to perform conversion, generation, or both conversion and generation of a software system that operates on the target platform.

Images