A method for PLM system inter-custom code automation migration

Abstract

This application relates to the field of software engineering technology and discloses a method for automated migration of customized code between PLM systems. The method includes: constructing a program profile containing a static semantic dependency graph and a dynamic execution trajectory graph; mining behavioral patterns in the dynamic execution trajectory graph and introducing intent entropy for quantitative evaluation to dynamically allocate migration strategies of overall behavior reconstruction or conservative step-by-step mapping; performing code transformation based on the allocated strategy; verifying the transformed code and triggering a feedback mechanism by identifying non-habitual migrations to achieve self-learning optimization of migration rules. Furthermore, this invention supports incremental migration, determining the impact domain of code changes through graph difference operations and migrating only the affected parts to adapt to version iterations. By deeply analyzing the business intent of the code and combining self-learning and incremental migration mechanisms, this invention significantly improves the automation level, accuracy, and version iteration efficiency of code migration.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, specifically to a method for automated migration of custom code between PLM systems. Background Technology

[0002] This invention relates to the field of Product Lifecycle Management (PLM) software technology, and more specifically, to a method for automated migration of customized code between PLM systems. Currently, against the backdrop of promoting the localization of key industrial software, many enterprises are replacing their existing PLM systems with domestically developed systems. In this process of localization, how to efficiently and accurately migrate the large number of customized functions accumulated over a long period in the source system is a crucial factor determining the success or failure and efficiency of the project.

[0003] In current technical practices, migrating between PLM systems, especially those involving deeply customized code, presents a significant challenge. Customized code in the source PLM system, accumulated over many years, is deeply coupled with the original system's underlying architecture and APIs, forming a complex and massive codebase. Due to significant differences in architecture, data model, and API interfaces between the target domestic PLM system and the source system, simple code migration is not feasible.

[0004] Therefore, the currently widely adopted technical solutions heavily rely on manual labor. This process typically requires the implementation team to first invest a significant amount of time in a comprehensive review and reverse engineering of the existing customized code to understand its underlying business logic. Subsequently, developers need to manually redevelop and implement these functions entirely on a new domestic PLM platform based on the analysis results. This purely manual migration model often takes years, not only consuming enormous human and financial resources, but also potentially disrupting and posing risks to the company's normal business operations due to the lengthy implementation cycle and complex debugging process.

[0005] Therefore, this invention proposes a method for automated migration of customized code between PLM systems to address the shortcomings of existing technologies. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a method for automated migration of custom code between PLM (Product Lifecycle Management) systems. This method solves the problem that existing custom code migration between PLM systems primarily relies on manual analysis and rewriting; this process is not only time-consuming, labor-intensive, and costly, but also highly prone to errors. Existing solutions often struggle to accurately understand the underlying business intent behind the source code, resulting in migrated code that, while logically correct, performs poorly in terms of performance, maintainability, or compatibility with the target system's API. Especially when custom code logic is complex and version iterations are frequent, the full-scale, repetitive manual migration work becomes a bottleneck restricting the efficiency of enterprise digital transformation.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a method for automated migration of customized code between PLM systems, comprising the following steps:

[0008] S100. Construct a program profile, which includes a static semantic dependency graph and a dynamic execution trajectory graph generated based on the source PLM system's customized code.

[0009] S200. Perform behavior analysis and strategy decision-making, wherein the behavior analysis and strategy decision-making includes mining at least one behavior pattern from the dynamic execution trajectory map, performing intention entropy quantification evaluation on the behavior pattern to obtain the intention entropy value of the behavior pattern, and assigning a migration strategy to the behavior pattern based on the comparison result of the intention entropy value and the preset entropy threshold.

[0010] S300. Based on the migration strategy allocated by the behavior pattern, and according to the graph transformation rules, the code structure corresponding to the behavior pattern in the source PLM system customized code is converted into the code of the target PLM system.

[0011] S400: Perform verification and self-learning optimization, which includes dynamically analyzing the code of the converted target PLM system to generate a target dynamic execution trajectory diagram, identifying non-habitual migrations, and triggering a feedback mechanism based on the identification results to optimize the diagram conversion rules.

[0012] Furthermore, when receiving a new version of the source PLM system customization code, it also includes:

[0013] S500: Perform incremental migration management, which includes generating a new version of the static semantic dependency graph, determining the impact domain affected by the code change through graph difference operation, and only within the impact domain: re-evaluating the intent entropy quantization of the affected behavior patterns to allocate migration strategies; performing code conversion according to the newly allocated migration strategies; and verifying and self-learning optimization of the converted code.

[0014] Preferably, the step of constructing the program profile in S100 specifically includes:

[0015] Static analysis is performed on the source PLM system custom code to generate the static semantic dependency graph, wherein the nodes of the static semantic dependency graph represent program entities and the edges represent the semantic relationships between the program entities;

[0016] By dynamically instrumenting the bytecode of the source PLM system's customized code and executing preset test cases, runtime call events are captured, generating the dynamic execution trajectory graph, where nodes in the dynamic execution trajectory graph represent method call instances, and edges represent the call order.

[0017] Preferably, in step S200, the step of performing intent entropy quantification assessment on the behavioral pattern specifically includes:

[0018] Identify and count all non-repeating subsequent method call events that appear immediately following the behavior pattern in the dynamic execution trajectory graph, forming a set of subsequent events;

[0019] Calculate the conditional probability of each subsequent method call event occurring in the set of subsequent events;

[0020] Based on the conditional probability, the intent entropy value of the behavioral pattern is calculated using the information entropy formula.

[0021] Preferably, in step S200, the step of assigning a migration strategy to the behavioral pattern specifically includes:

[0022] When the intent entropy value is less than or equal to the entropy threshold, an overall behavior reconstruction migration strategy is assigned to the behavior pattern.

[0023] When the intent entropy value is greater than the entropy threshold, a conservative step-by-step mapping migration strategy is assigned to the behavior pattern.

[0024] Preferably, the overall behavior reconstruction migration strategy is used to replace multiple API calls corresponding to the behavior pattern as a whole business unit with a single or a small number of high-level API calls with equivalent functions in the target PLM system; the conservative step-by-step mapping migration strategy is used to treat each API call that makes up the behavior pattern as an independent functional unit and perform mapping conversion one by one.

[0025] Preferably, in step S300, when converting the code structure corresponding to the behavior pattern in the source PLM system's customized code into the code of the target PLM system, the step further includes:

[0026] When a code structure corresponding to a behavior pattern is identified in the static semantic dependency graph, if there is a polymorphic method call in the code structure, the dynamic execution trajectory graph is queried to determine the runtime object type of the polymorphic method call, thereby eliminating call ambiguity before code conversion is performed.

[0027] Preferably, the step of identifying non-habitual migrations in S400 specifically includes:

[0028] The complexity of the target dynamic execution trajectory graph and the complexity of the functionally equivalent native trajectory in the target system's native behavior pattern library are calculated using a predefined graph complexity metric function.

[0029] When the complexity of the target dynamic execution trajectory map is higher than the complexity of the original trajectory, the corresponding migration result is determined to be the non-habitual migration.

[0030] Preferably, the graph complexity metric function calculates complexity based on a weighted combination of at least one of the following indicators: the total number of nodes in the graph, the number of times a specific type of resource is accessed in the graph, the maximum depth of the call stack in the graph, or the number of times a specific design pattern appears in the graph.

[0031] Preferably, in step S400, the step of triggering the feedback mechanism to optimize the graph transformation rules specifically includes:

[0032] Backtracking leads to the source behavior pattern of the non-habitual migration and the graph transformation rules applied to the source behavior pattern;

[0033] Based on the native trajectories in the native behavior pattern library of the target system, an optimized target code template is generated through reverse engineering.

[0034] Using the source behavior pattern and optimized target code template, new graph transformation rules are constructed and updated to the graph transformation rule library.

[0035] Preferably, in step S500, when re-evaluating the intent entropy quantification of behavioral patterns within the influence domain to allocate migration strategies, the method further includes:

[0036] The behavioral patterns within the influence domain are re-evaluated using intent entropy quantification to obtain new intent entropy values.

[0037] And based on the new intent entropy value, the migration strategy assigned to the behavior pattern is dynamically adjusted.

[0038] This invention provides a method for automated migration of custom code between PLM systems. It has the following beneficial effects:

[0039] 1. This method constructs a program profile containing both a static semantic dependency graph and a dynamic execution trajectory graph, enabling a comprehensive understanding of the code's structure and actual runtime behavior. Furthermore, by introducing intent entropy to quantify and evaluate the mined behavioral patterns, it can distinguish between highly cohesive operations with clear business intent and low-level operations with strong generality. Based on this, the system can dynamically apply overall behavior reconstruction or conservative step-by-step mapping strategies, thereby achieving a leap from simple API syntax mapping to deep business semantic mapping. This ensures that the migrated code is not only functionally equivalent but also structurally and efficiently closer to the target system's design paradigm.

[0040] 2. This method introduces verification and self-learning optimization steps after code conversion. By analyzing the target dynamic execution trajectory graph of the migrated code and comparing its complexity with the target system's native behavior pattern library, it can automatically identify non-habitual migrations that are functionally correct but redundant in implementation. Once identified, the feedback mechanism is triggered, and the system can backtrack to locate the graph conversion rules that caused the problem and generate optimized code templates based on the native trajectory, thereby building and updating the graph conversion rule library. This closed-loop mechanism enables the migration capability to evolve and continuously improve during use.

[0041] 3. For updates to the source system's custom code, this method provides an incremental migration management mechanism. By performing graph difference operations on the static semantic dependency graphs of the old and new versions, the minimum scope affected by the code changes, i.e., the influence domain, can be precisely defined. Subsequent analysis, transformation, and verification processes are only performed within this influence domain, avoiding repetitive work on unchanged code parts. This targeted migration approach greatly shortens the code migration cycle caused by software upgrades or patch updates, significantly reducing system maintenance costs and time. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the system architecture of the present invention;

[0043] Figure 2 This is a schematic diagram of the method flow of the present invention;

[0044] Figure 3 This is a schematic diagram of the strategy-driven code conversion of the present invention;

[0045] Figure 4 This is a schematic diagram of the rule base self-learning feedback closed loop of the present invention.

[0046] Among them, 100 is the program profile construction module; 200 is the behavior pattern analysis module; 300 is the code conversion and generation module; 400 is the verification and self-learning module; and 500 is the incremental migration management module. Detailed Implementation

[0047] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] See attached document Figure 1This invention provides a system for automated migration of customized code between PLM systems. The system is deployed on a computer device, which includes hardware such as a processor, memory, and network interface. The system may include: a program profile construction module 100, a behavior pattern analysis module 200, a code conversion and generation module 300, a verification and self-learning module 400, and an incremental migration management module 500.

[0049] In a specific implementation scenario, the PLM code adaptive migration system of the present invention can be deployed in a cluster environment consisting of one or more servers; the backend service of the system interacts with a relational or graph database to persistently store static semantic dependency graphs, dynamic execution trajectory graphs, and graph transformation rule bases; the system can also be integrated with version control systems (such as Git) to automatically obtain the source code of new versions; each module of the system can be implemented as an independent microservice and communicate through application programming interfaces (APIs) to improve the scalability and maintainability of the system.

[0050] The program profiling module 100 is used to perform static and dynamic analysis on the input source PLM system customized code to generate the data foundation required for subsequent steps. This module 100 receives the source PLM system's source code as input and outputs a static semantic dependency graph and a dynamic execution trajectory graph. Specifically, the program profiling module 100 includes:

[0051] A static semantic dependency graph building unit is configured to perform deep static analysis of the source code. This unit first parses the source code file using a program analysis library to generate an abstract syntax tree (AST). Then, based on this AST, it performs symbol resolution, precisely linking variables in the code to their declarations. Next, it performs type propagation and inference through control flow and data flow analysis to determine the static type of each expression. Finally, this unit constructs a static semantic dependency graph. ;in, It is a collection of nodes representing program entities such as classes, methods, and fields. It is a set of edges representing semantic relationships such as invocation, inheritance, and data flow.

[0052] The dynamic execution trajectory generation unit is configured to capture the behavior of source code during actual runtime. This unit employs bytecode instrumentation to monitor target classes and methods in the source system without modifying the source code. When executing test cases covering core business logic, the unit records each method call event, including the call sequence, runtime types and values ​​of parameters, and return value information. All captured event sequences are organized into one or more dynamic execution trajectory diagrams. ;in, It is a collection of nodes representing each instance of a specific method call. It is a set of directed edges that represent the order in which calls are made, and which have a temporal relationship.

[0053] The behavior pattern analysis module 200 is used to process the dynamic execution trajectory map generated by the program profiling module 100, mine the underlying behavior patterns, and quantitatively evaluate them to formulate differentiated migration strategies. Specifically, the behavior pattern analysis module 200 includes:

[0054] Behavioral pattern mining unit, which is configured to perform dynamic execution trajectory mapping In this study, a sequence pattern mining algorithm is used to identify frequently occurring API call subsequences, and each such subsequence is defined as a behavioral pattern. .

[0055] Intent entropy evaluation unit, which is configured to evaluate each identified behavioral pattern The stability of business intent is quantified; this intent entropy evaluation unit introduces intent entropy. To measure; first, statistics in China closely follows the model The collection of all different subsequent method call events. And calculate each subsequent event. Conditional probability of occurrence Intent entropy Calculated using the following formula:

[0056] ;

[0057] in: Representative behavioral patterns Intentional entropy; It represents an identified behavioral pattern, namely a specific sequence of API calls; Represents the following pattern The total number of all non-repeating subsequent method call events; Representing the A unique set of subsequent method call events; Representative in pattern After it happened, subsequent events The conditional probability of occurrence.

[0058] The migration strategy layering unit is configured to bind behavioral patterns to migration strategies based on the calculation results of the intent entropy evaluation unit; this migration strategy layering unit calculates the intent entropy value. With a preset entropy threshold Compare; if Then assign an overall behavior reconstruction strategy to this pattern; if If so, a conservative step-by-step mapping strategy is assigned to this mode.

[0059] The code conversion and generation module 300 is used to execute specific code conversion and generation tasks according to the strategy defined by the behavior pattern analysis module 200. Specifically, the code conversion and generation module 300 includes:

[0060] The graph transformation rule library is a data storage unit used to store code transformation rules; each rule contains the graph structure definition of the source schema, the generation template of the target code, and the application conditions associated with a specific migration strategy.

[0061] The hybrid analysis and transformation engine is the core of this module's execution; this engine traverses the static semantic dependency graph. When a behavioral pattern is identified When matching the code structure, the engine queries its bound migration strategy; based on this strategy, the engine selects applicable rules from the graph transformation rule base; during rule application, the engine queries the dynamic execution trajectory graph. To resolve ambiguities in static analyses such as polymorphism and ensure the accuracy of rule application;

[0062] The target code generation unit is configured to integrate and format the transformation results output by the hybrid analysis and transformation engine, and finally generate source code files that conform to the technical specifications of the target PLM system.

[0063] The verification and self-learning module 400 is used to verify the quality of the generated code and establish a feedback mechanism to achieve self-optimization and evolution of the rule base. Specifically, the verification and self-learning module 400 includes:

[0064] The migrated dynamic profiling unit functions similarly to the dynamic execution trajectory generation unit, but its operation target is the target system code generated by the code conversion and generation module 300. This migrated dynamic profiling unit runs test cases in the target system environment, captures the execution trajectory of the new code, and generates the target dynamic execution trajectory diagram. .

[0065] The behavioral equivalence verification unit is configured to verify the behavior using graph isomorphism or subgraph isomorphism algorithms. With the original Perform a structural comparison on the critical business path; if the two remain consistent in the call sequence at the critical nodes, it confirms that the migration maintains the equivalence of the business logic.

[0066] Architecture compliance analysis and self-learning unit, which is configured to Compare with a pre-built library of native behavioral patterns that contains best practices for the target system; if found... If the implementation method (such as call chain length and resource access count) is inferior to the native mode, it is determined to be a non-standard migration. This determination will trigger a feedback mechanism that analyzes the source mode and transformation rules that led to this result, and automatically generates a new, more optimized rule, which is then submitted to the graph transformation rule base to improve the quality of subsequent migrations in the system.

[0067] The incremental migration management module 500 is used to handle version iterations of the source system's custom code, enabling efficient and accurate incremental migration of code changes. Specifically, the incremental migration management module 500 includes:

[0068] The differential analysis unit is configured to, upon receiving a new version of the source code, invoke the static semantic dependency graph construction unit to generate a new version of the static graph. Subsequently, the differential analysis unit analyzed the static graphs of the old and new versions. and Perform graph differencing to generate a difference dependency graph that only contains the parts of the code that have changed. .

[0069] The influence domain analysis unit is configured to be based on the difference dependency graph. Tracing back through the complete program dependencies, identifying the scope of all code entities directly or indirectly affected by code changes, and thereby selecting the minimum set of test cases that need to be re-executed.

[0070] The local migration execution unit is configured as a scheduling behavior pattern analysis module 200, a code conversion and generation module 300, and a verification and self-learning module 400, but it only executes within the scope determined by the influence domain analysis unit. In particular, the local migration execution unit triggers a re-evaluation of the intent entropy of the affected behavior pattern and dynamically adjusts its migration strategy according to the changes in the evaluation results, ultimately completing the local migration, verification, and merging of the changed code.

[0071] See attached document Figure 1 With appendix Figure 2 The following is a detailed description of step S100 in this embodiment of the invention. This step involves processing the input source PLM system custom code to construct a comprehensive program profile containing its static structural information and dynamic behavioral information, providing complete data support for subsequent analysis and migration decisions.

[0072] In step S100, the specific implementation of program profile construction includes the generation of a static semantic dependency graph and the generation of a dynamic execution trajectory graph.

[0073] The generation of static semantic dependency graphs aims to accurately represent the internal logic and dependencies of the source code; its specific implementation steps are as follows:

[0074] S111 performs lexical and syntactic analysis on the Java source code files of the source PLM system to generate an initial abstract syntax tree (AST); this tree structure is a hierarchical representation of code syntax units.

[0075] S112, performs symbol resolution based on the AST; this process traverses the syntax tree, constructs a symbol table for each identifier (such as variable name, method name) that appears in the code, and precisely links each use to its unique declaration; through this step, the system can clearly distinguish variables with the same name in different scopes and establish basic reference relationships between code entities.

[0076] S113, Execution Type Propagation and Inference; This step is achieved by combining control flow analysis and data flow analysis. Control flow analysis is used to determine the possible execution paths of the program, while data flow analysis traces the passing of variable values ​​along these paths. For example, for a variable declared as an interface type, the system infers its actual runtime type at a specific code location by tracing back the data flow to find the location where it was instantiated (such as the new expression). This step is crucial for accurately handling polymorphism in object-oriented programming later on.

[0077] S114. Based on the above analysis results, construct a static semantic dependency graph. This static semantic dependency graph is a directed graph rich in semantic information; where, It is a collection of nodes in the graph, where each node represents a program entity, which may include classes, interfaces, methods, fields, variable declarations, etc. The graph is a set of edges, each representing a specific semantic relationship, which may include call relationships, inheritance relationships, implementation relationships, data flow to relationships, and instantiation relationships. This static semantic dependency graph fully depicts the static structure of the code, type information, and the interdependencies between entities.

[0078] The generation of dynamic execution trajectory graphs aims to capture the behavioral patterns of code in a real runtime environment, thus overcoming the limitations of static analysis in obtaining runtime information; its specific implementation steps are as follows:

[0079] S121 employs Java-Agent technology to dynamically instrument the bytecode of the source PLM system's custom code during Java Virtual Machine (JVM) class loading. This step utilizes bytecode manipulation libraries (such as ASM) to dynamically weave monitoring probe code into the entry and exit points of target methods (mainly methods that interact with the PLM system's core API) without modifying any source code files.

[0080] S122, in the source PLM system environment configured with this Java-Agent, execute a set of automated test cases covering core business scenarios or perform standard manual business operations.

[0081] S123, when the code execution reaches the instrumented location, the monitoring probe is activated and is responsible for capturing and recording detailed runtime context information; the captured information includes, but is not limited to: the complete signature of the called method, the timestamps of the start and end of the method execution, the current thread ID, the runtime types of all method parameters (obtained through Object.getClass()) and their serialized values, and the method's return value;

[0082] S124 aggregates and processes the call event streams with temporal relationships captured by all monitoring probes, constructing one or more dynamic execution trajectory diagrams. This dynamic execution trajectory diagram is a directed graph representing the actual execution flow; where, S123 is a collection of nodes in the graph. Each node represents a specific method call instance, and each node stores all the runtime context information captured in S123. Given the set of edges in the graph, if an instance is called... The completion time is immediately adjacent to the calling instance. If at the start time of both events, and both are in the same thread, then there exists a path from... point to The directed edges represent the actual order of the calls.

[0083] See attached document Figure 1 With appendix Figure 2 The following is a detailed description of step S200 in this embodiment of the invention. This step involves in-depth analysis of the dynamic execution trajectory graph generated in step S100. The purpose is to identify business-meaning behavioral patterns from complex runtime data and to quantitatively evaluate the stability of their underlying intent, thereby formulating targeted and differentiated migration strategies for subsequent code conversion.

[0084] In step S200, the specific implementation of behavior analysis and strategy decision-making includes the mining of behavior patterns and the quantitative evaluation of intent entropy.

[0085] S211, Dynamic execution trajectory diagram generated in step S100 Above, perform sequence pattern mining; this step will Each independent execution thread's call path is considered a sequence database; by applying sequence pattern mining algorithms, such as the PrefixSpan algorithm, the system can identify frequently occurring, consecutive API call subsequences; each such high-frequency subsequence is defined as a behavioral pattern. It represents a set of conventional operations used by the source system when performing specific business functions.

[0086] S221, after identifying the behavioral pattern Next, the system quantitatively assesses the certainty of its business intent; this process introduces the concept of intent entropy to calculate a specific behavioral pattern. The system first traverses the dynamic execution trajectory graph to determine the intent entropy. All instances of this behavioral pattern The event sequence is determined by counting all immediately following method call events; all these unique subsequent method call events constitute the set of successor events for this pattern. .

[0087] S222, for each unique successor event Calculate its behavioral patterns Conditional probability of occurrence after occurrence This conditional probability is calculated using statistical frequency: [The following is a partial translation of the original text, which is incomplete and requires further context.] In behavioral patterns The total number of occurrences thereafter, divided by the behavioral pattern. exist The total number of times it appears in the text.

[0088] S223, Based on the above probability distribution, the behavior pattern is calculated using the formula for information entropy. Intentional entropy This value reflects behavioral patterns. The average uncertainty of subsequent actions; the calculation formula is quoted from the formula for information entropy in the intention entropy assessment unit, as follows:

[0089] ;

[0090] in: Representative behavioral patterns Intentional entropy; It represents an identified behavioral pattern, namely a specific sequence of API calls; Represents the following behavior pattern The total number of all non-repeating subsequent method call events; Representing the A unique set of subsequent method call events; Representative in behavioral patterns After it happened, subsequent events The conditional probability of occurrence.

[0091] A low intent entropy value close to 0 indicates this behavioral pattern. The subsequent behavior is highly consistent and predictable, which usually means that the pattern corresponds to a specific and stable high-level business intent; conversely, a high intent entropy value indicates that the subsequent behavior of the pattern is divergent and diverse, which usually means that the pattern is a widely reused and multi-purpose underlying basic operation; this quantitative evaluation result is the direct basis for the subsequent dynamic layering of migration strategies.

[0092] See attached document Figure 1 With appendix Figure 2 After completing the quantitative assessment of the intent entropy of the behavioral patterns, step S200 continues to perform dynamic stratification of the migration strategy. This process uses the quantitative assessment results of the previous steps to automatically associate a specific code conversion strategy with each identified behavioral pattern in order to achieve differentiated code migration.

[0093] S231, the system divides the preceding steps into each behavior pattern. Calculated intention entropy value With a pre-configured entropy threshold Comparison; Entropy threshold The specific value can be determined through one or more of the following methods:

[0094] Experience setting: An experience value is pre-set by an experienced software architect based on the API design philosophy of the target PLM system;

[0095] Statistical analysis: Intent entropy is calculated on a large number of source system code samples with known migration strategies to form a statistical distribution of entropy values. A specific quantile of this distribution (e.g., the 25th percentile) is selected as a threshold to statistically distinguish between high and low entropy patterns.

[0096] Adaptive learning: During system operation, based on the self-learning feedback results in step S400, the entropy threshold is adjusted. Dynamic adjustments can be made. For example, if a large number of patterns judged as low-entropy ultimately lead to non-habitual migrations, the system can be appropriately adjusted to lower the entropy level. The value of .

[0097] The entropy threshold It serves as a decision boundary to distinguish behavioral patterns with different levels of behavioral stability.

[0098] S232, if a behavioral pattern Intentional entropy Less than or equal to the entropy threshold The system will then apply this behavior pattern This is related to the overall behavior refactoring migration strategy; this strategy specifies that, in the subsequent code conversion phase, the behavior pattern will correspond to this behavior pattern. The source code snippet is treated as a whole business unit; the code conversion and generation module 300 will apply specific refactoring rules to replace the source code snippets with one or a few high-level API calls that are functionally equivalent in the target PLM system, replacing those originating from this behavior pattern. The complete API call sequence.

[0099] S233, if a behavioral pattern Intentional entropy Greater than the entropy threshold The system will then apply this behavior pattern This relates to a conservative step-by-step mapping migration strategy; this strategy specifies that, in subsequent code conversion phases, this behavioral pattern will be established. Each API call is treated as an independent functional unit; the code conversion and generation module 300 will independently apply the basic mapping rules to each API call in the sequence, and convert them into the basic API calls corresponding to the functions in the target PLM system, thereby maintaining the original call structure of the source program at that code location.

[0100] See attached document Figure 1 With appendix Figure 2 The following is a detailed description of step S300 in the embodiments of the present invention. This step involves performing a specific code conversion task. Its core is to convert the customized code of the source PLM system into the equivalent code of the target PLM system based on the differentiated migration strategy formulated for different behavior patterns in step S200 and combined with the comprehensive information of static and dynamic analysis.

[0101] In one specific embodiment, each rule in the graph transformation rule base can be stored in a structured manner, such as using JSON, XML, or a database table; each rule contains at least the following fields: rule ID, source pattern graph structure definition (used for matching). The structured representation includes the code structure, associated migration strategies (overall behavior refactoring or conservative step-by-step mapping), target code generation templates (templated code containing parameters to be filled), and rule priorities; this structured representation facilitates efficient querying, matching, and application by hybrid analysis and transformation engines.

[0102] See attached document Figure 3In step S300, the specific implementation of hybrid analysis-driven code transformation includes hybrid analysis and rule matching, as well as policy-driven code generation.

[0103] S311, the hybrid analysis and transformation engine within the code transformation and generation module 300 is started and begins traversing the static semantic dependency graph generated in step S100. This traversal process is a systematic scan of the source code structure.

[0104] S312, during traversal During the process, when the engine identifies a behavior pattern that matches a certain behavior pattern discovered in step S200... When given the corresponding code structure, the engine will query the behavior pattern. The associated migration strategy is either overall behavior reconstruction or conservative stepwise mapping.

[0105] S313, when performing rule matching, the engine performs hybrid analysis to ensure accuracy, especially when dealing with object-oriented polymorphic method calls; for If a method call point exists where the static type of the calling object is an interface or its parent class, there is call ambiguity; in this case, the engine will query the dynamic execution trajectory graph. The actual runtime call instance corresponding to the static call point was located; through analysis... By recording the most frequently occurring runtime object type at that location, the engine can determine the primary implementation of the polymorphic call, thereby eliminating ambiguity.

[0106] S314, the engine combines the migration strategy obtained in step S312 and the precise runtime information determined in step S313 to select a unique and most applicable transformation rule from the graph transformation rule base; this transformation rule precisely defines how to transform the code structure of the source program into the code structure of the target program.

[0107] S321, when the migration strategy corresponding to the selected rule is holistic behavior refactoring, the code generation process is manifested as high-level abstraction replacement; for example, a behavior pattern determined to be low-entropy is represented in the source code as three consecutive statements: "Connection conn=DB.getConnection();", "conn.prepare("SQL");", "conn.execute();". The engine will apply a holistic refactoring rule, treating these three statements as a whole and replacing them with a functionally equivalent high-level API call in the target system, such as "TundraDB.executeUpdate("SQL");". The target code generation unit then generates more concise code that conforms to the target system's design paradigm.

[0108] S322, when the migration strategy corresponding to the selected rule is conservative stepwise mapping, the code generation process is characterized by the preservation of the original logical structure. For example, a behavior pattern determined to be high-entropy is represented in the source code as two statements: "Itemitem=Finder.findItem(id);" and "item.updateStatus("new_status");". The engine will apply independent basic mapping rules to these two statements respectively; "Finder.findItem(id);" may be transformed into "TundraFinder.fetch(id);", while "item.updateStatus("new_status");" is transformed into "tundraItem.setStatus("new_status");". The target code generation unit generates two corresponding statements accordingly, maintaining the stepwise operation logic of the source program.

[0109] S323, the hybrid analysis and transformation engine completes the... After traversing and transforming all the code structures, the target code generation unit integrates all the generated code fragments, processes class definitions, package declarations, and import statements, and finally synthesizes them into a complete, syntactically correct source code file that can be compiled and executed in the target PLM system.

[0110] See attached document Figure 1 With appendix Figure 2 The following is a detailed description of step S400 in this embodiment of the invention. This step involves quality assurance and closed-loop optimization of the migrated code generated in step S300; its purpose is not only to verify the correctness of the migrated code in terms of business functions, but also to evaluate its implementation quality under the target system architecture and establish a feedback mechanism that can self-optimize.

[0111] See attached document Figure 4 In step S400, the specific implementation of verification and self-learning optimization includes dynamic profiling and behavioral equivalence verification of the migrated code, as well as architectural compliance analysis based on the native pattern library.

[0112] In step S411, the post-migration dynamic profiling unit within the verification and self-learning module 400 is activated to perform dynamic analysis on the target PLM system code generated in step S300. This post-migration dynamic profiling unit employs the same bytecode instrumentation technique as in step S121 to monitor the newly generated code within the target PLM system's runtime environment. By executing the same test case set as in step S122, the post-migration dynamic profiling unit captures the actual runtime call sequence and context information of the new code, and constructs a target dynamic execution trajectory diagram accordingly. .

[0113] S412, the behavioral equivalence verification unit is responsible for verifying the consistency of business logic before and after the migration; this behavioral equivalence verification unit will use the target dynamic execution trajectory diagram generated in step S411. The source dynamic execution trajectory diagram generated in step S100 A formal comparison is performed; this comparison process uses graph isomorphism or subgraph isomorphism algorithms on the key execution paths corresponding to the core business logic; if the two trajectory graphs show isomorphism in terms of call sequence and branch structure of key API nodes, the migrated code is determined to be equivalent to the source code at the business logic level.

[0114] S421, To perform architectural compliance analysis, the system pre-builds and maintains a "target system native behavior pattern library". The process of building the native behavior pattern library of the target system is as follows: apply the dynamic analysis method in step S100 to the official source code, best practice example code and other high-quality code libraries of the target PLM system to capture its dynamic execution trajectory when performing standard business operations, and store these trajectories as native behavior patterns in the library.

[0115] S422, to quantify the quality of code implementation, the system defines a configurable graph complexity metric function. This graph complexity metric is used to compute a given execution trajectory graph. The complexity; Specifically, this can be achieved through a weighted combination of one or more of the following indicators:

[0116] The total number of nodes in the trajectory graph, which is the total number of API calls;

[0117] The number of times a specific type of resource (such as a database connection or file handle) is accessed in the trajectory graph;

[0118] The maximum depth of the call stack in the trajectory graph;

[0119] The number of times a specific design pattern (such as frequent object creation) appears in the trajectory diagram.

[0120] In a preferred embodiment, the graph complexity metric function This can be expressed as a weighted sum of these indicators:

[0121] ;

[0122] in: Represents a given execution trajectory graph; This represents the total number of metrics considered. Representing the The calculation function of various metrics, such as Calculate the total number of nodes in the graph; Representing the The weighting coefficient of the metric; this weighting coefficient It is configurable, allowing users to assign different levels of importance to different complexity metrics based on the performance requirements and architectural characteristics of the target system.

[0123] S423, Architecture compliance analysis and self-learning unit perform architecture compliance analysis; for a trajectory map generated after migration. The architecture's compliance analysis and self-learning unit first integrates with the native behavior pattern library. The original trajectory is equivalent to the search function in the middle. Subsequently, the architecture compliance analysis and self-learning unit respectively calculate the complexity of both. and ;like The value is significantly higher than If the migration result is not found, it is marked as a non-standard migration. This mark indicates that although the migrated code is functionally correct, its implementation is inferior to the native implementation of the target system.

[0124] See attached document Figure 1 With appendix Figure 2 In step S423, after marking a migration result as a non-habitual migration, step S400 continues to execute the self-learning feedback loop of the rule base; this process is the core mechanism for the self-evolution and continuous optimization of the present invention, which automatically improves its internal knowledge base by analyzing suboptimal migration results.

[0125] S431, the architecture compliance analysis and self-learning unit automatically triggers a feedback mechanism after identifying non-habitual migrations. This automatic feedback mechanism first traces the root cause of the migration result. The system uses the mapping relationship maintained during the code conversion process to dynamically execute the trajectory diagram of the target that caused the excessive complexity. By backtracking, the source of this code snippet can be precisely located within the static semantic dependency graph. The specific code structure in the source code, i.e., the source behavior pattern. And the graph transformation rules applied to the source behavior pattern in step S300 that have poor performance.

[0126] S432, based on the analysis results, the system automatically generates an optimized target code template; this process utilizes the original behavior pattern trajectory retrieved in step S423, which is functionally equivalent and less complex. The system has The node sequence and structure are reverse engineered and abstracted into a parameterized, reusable target code template. This target code template represents the best practice for implementing this functionality within the target PLM system.

[0127] S433, the system utilizes the source behavior pattern located in step S431. and the new target code template generated in step S432 To construct a new and more optimized graph transformation rule. The new rule It was submitted to the graph transformation rule base; to ensure its priority application in subsequent migrations, the system configured this new rule. The system can either assign a higher priority to the inefficient rule or directly replace the existing rule with the new one; in another embodiment, the system can also generate a new rule. As an optimization suggestion, it is presented to the developers for review, and after confirmation, it is officially added to the rule base. Through this step, the system completes a complete self-learning and optimization loop, enabling it to adopt a better approach to code migration when encountering the same source behavior pattern in the future.

[0128] See attached document Figure 1 With appendix Figure 2 The following provides a detailed description of step S500 in this embodiment of the invention. This step involves processing the version iteration and evolution of the source PLM system's customized code. Its purpose is to provide an efficient and accurate incremental migration mechanism to avoid a complete re-analysis and migration of the entire codebase when partial changes occur in the source code.

[0129] In step S500, the specific implementation of incremental migration management includes change impact domain localization based on differential dependency graph, and dynamic re-evaluation of intent entropy and policy adaptation in local migration.

[0130] S511, when the system receives a new version of the source PLM system customized code, the incremental migration management module 500 is activated; its internal differential analysis unit first calls the static semantic dependency graph construction unit to execute the complete process of steps S111 to S114 on the new source code, generating a new version of the static semantic dependency graph. .

[0131] S512, the differential analysis unit then generates the new graph. The old image was retained from the previous version. Perform graph difference operations; this graph difference operation accurately identifies the added, deleted, or modified program entities and their dependencies by comparing the node sets and edge sets of two graphs, generating a difference dependency graph containing only the change information. .

[0132] S513, the influence domain analysis unit is based on this difference dependency graph. In the complete program dependency graph Propagation analysis is conducted within this context; the influence domain analysis unit starts from... Starting from the point of change in the code, a bidirectional tracing is performed along the dependencies such as calls and data flows to identify the set of all program entities directly or indirectly affected by the code change; this set is defined as the influence domain of this incremental migration.

[0133] S521, after determining the domain of influence, the local migration execution unit initiates a limited-scope local migration process; this local migration process identifies all behavioral patterns that intersect with the domain of influence. For each affected behavioral pattern The system triggers a re-execution of the intent entropy calculation in step S200.

[0134] S522, the system analyzes the affected behavioral patterns by running a minimal set of test cases related to the influence domain, selected by the influence domain analysis unit. Collect new dynamic execution data and recalculate its intent entropy according to the formula in step S223 to obtain a new entropy value. .

[0135] S523, the local migration execution unit will use the newly calculated intent entropy value A comparative analysis is performed with the original migration strategy for this pattern, and the execution strategy is dynamically and adaptively adjusted; if the entropy value of a behavioral pattern changes significantly due to code changes, for example, from Become The system will automatically adjust its associated migration strategy from overall behavior reconstruction to conservative step-by-step mapping. Conversely, if the entropy value increases from... Become The strategy then changes from conservative step-by-step mapping to overall behavior reconstruction.

[0136] In S524, the local migration execution unit schedules the code conversion and generation module 300 and the verification and self-learning module 400, but only within the influence domain determined in S513, and according to the latest migration strategy dynamically adjusted in S523, to perform local code conversion, generation, verification, and potential self-learning optimization. Finally, the newly generated target code is merged with the original target code library, completing an efficient and adaptive incremental migration cycle.

[0137] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for automated migration of custom code between PLM systems, characterized in that, Includes the following steps: S100. Construct a program profile, which includes a static semantic dependency graph and a dynamic execution trajectory graph generated based on the source PLM system's customized code. S200. Perform behavior analysis and strategy decision-making, wherein the behavior analysis and strategy decision-making includes mining at least one behavior pattern from the dynamic execution trajectory map, performing intention entropy quantification evaluation on the behavior pattern to obtain the intention entropy value of the behavior pattern, and assigning a migration strategy to the behavior pattern based on the comparison result of the intention entropy value and the preset entropy threshold. S300. Based on the migration strategy allocated by the behavior pattern, and according to the graph transformation rules, the code structure corresponding to the behavior pattern in the source PLM system customized code is converted into the code of the target PLM system. S400: Perform verification and self-learning optimization, which includes dynamically analyzing the code of the converted target PLM system to generate a target dynamic execution trajectory diagram, identifying non-habitual migrations, and triggering a feedback mechanism based on the identification results to optimize the diagram conversion rules. Furthermore, when receiving a new version of the source PLM system customization code, it also includes: S500: Perform incremental migration management, which includes generating a new version of the static semantic dependency graph, determining the impact domain affected by the code change through graph difference operation, and only within the impact domain: re-evaluating the intent entropy quantization of the affected behavior patterns to allocate migration strategies; performing code conversion according to the newly allocated migration strategies; and verifying and self-learning optimization of the converted code.

2. The method for automated migration of customized code between PLM systems according to claim 1, characterized in that, The step of constructing the program profile in S100 specifically includes: Static analysis is performed on the source PLM system custom code to generate the static semantic dependency graph, wherein the nodes of the static semantic dependency graph represent program entities and the edges represent the semantic relationships between the program entities; By dynamically instrumenting the bytecode of the source PLM system's customized code and executing preset test cases, runtime call events are captured, generating the dynamic execution trajectory graph, where nodes in the dynamic execution trajectory graph represent method call instances, and edges represent the call order.

3. The method for automated migration of customized code between PLM systems according to claim 1, characterized in that, In step S200, the step of performing intent entropy quantification and evaluation on the behavioral pattern specifically includes: Identify and count all non-repeating subsequent method call events that appear immediately following the behavior pattern in the dynamic execution trajectory graph, forming a set of subsequent events; Calculate the conditional probability of each subsequent method call event occurring in the set of subsequent events; Based on the conditional probability, the intent entropy value of the behavioral pattern is calculated using the information entropy formula.

4. The method for automated migration of customized code between PLM systems according to claim 1, characterized in that, In step S200, the step of assigning a migration strategy to the behavior pattern specifically includes: When the intent entropy value is less than or equal to the entropy threshold, an overall behavior reconstruction migration strategy is assigned to the behavior pattern. When the intent entropy value is greater than the entropy threshold, a conservative step-by-step mapping migration strategy is assigned to the behavior pattern.

5. The method for automated migration of customized code between PLM systems according to claim 4, characterized in that, The overall behavior reconstruction migration strategy is used to replace multiple API calls corresponding to the behavior pattern as a whole business unit with a single or a small number of high-level API calls with equivalent functions in the target PLM system; the conservative step-by-step mapping migration strategy is used to treat each API call that makes up the behavior pattern as an independent functional unit and perform mapping conversion one by one.

6. The method for automated migration of customized code between PLM systems according to claim 1, characterized in that, In step S300, when converting the code structure corresponding to the behavior pattern in the source PLM system's customized code into the code of the target PLM system, the following steps are also included: When a code structure corresponding to a behavior pattern is identified in the static semantic dependency graph, if there is a polymorphic method call in the code structure, the dynamic execution trajectory graph is queried to determine the runtime object type of the polymorphic method call, thereby eliminating call ambiguity before code conversion is performed.

7. The method for automated migration of customized code between PLM systems according to claim 1, characterized in that, The step of identifying non-habitual migrations in S400 specifically includes: The complexity of the target dynamic execution trajectory graph and the complexity of the functionally equivalent native trajectory in the target system's native behavior pattern library are calculated using a predefined graph complexity metric function. When the complexity of the target dynamic execution trajectory map is higher than the complexity of the original trajectory, the corresponding migration result is determined to be the non-habitual migration.

8. The method for automated migration of customized code between PLM systems according to claim 7, characterized in that, The graph complexity metric function calculates complexity based on a weighted combination of at least one of the following metrics: the total number of nodes in the graph, the number of accesses to a specific type of resource in the graph, the maximum depth of the call stack in the graph, or the number of occurrences of a specific design pattern in the graph.

9. The method for automated migration of customized code between PLM systems according to claim 1, characterized in that, In step S400, the step of triggering the feedback mechanism to optimize the graph transformation rules specifically includes: Backtracking leads to the source behavior pattern of the non-habitual migration and the graph transformation rules applied to the source behavior pattern; Based on the native trajectories in the native behavior pattern library of the target system, an optimized target code template is generated through reverse engineering. Using the source behavior pattern and optimized target code template, new graph transformation rules are constructed and updated to the graph transformation rule library.

10. The method for automated migration of customized code between PLM systems according to claim 1, characterized in that, In step S500, when re-evaluating the intent entropy quantification of behavioral patterns within the influence domain to allocate migration strategies, the following further steps are included: The behavioral patterns within the influence domain are re-evaluated using intent entropy quantification to obtain new intent entropy values. And based on the new intent entropy value, the migration strategy assigned to the behavior pattern is dynamically adjusted.

Images