Business logic identification method and device, equipment, storage medium and program product

Abstract

The invention provides a business logic identification method and device, equipment, a storage medium and a program product, and relates to the technical field of computers or the field of financial science and technology. The method comprises the steps of obtaining static dependency data of a program unit in a target database; the program units comprise code modules which can be independently called in the target database, and the static dependency data comprise calling relations and calling times among the program units; obtaining dynamic execution data of the program unit in the target database, wherein the dynamic execution data comprises the running frequency of the program unit; performing cross validation according to the static dependency data and the dynamic execution data to obtain a cross validation result; the cross verification comprises screening the program unit based on a preset association condition; and determining a core business logic object based on the cross validation result. The method is used for achieving the effect of improving the business logic identification accuracy.

Description

Technical Field

[0001] This application relates to the fields of computer technology or financial technology, and in particular to a business logic identification method, apparatus, device, storage medium, and program product. Background Technology

[0002] In the context of digital transformation in the financial industry, database migration is necessary. However, during the database migration process, it is crucial to identify the core business logic that is frequently accessed within the database to ensure functional integrity and performance stability after migration. Therefore, accurately identifying the business logic is of paramount importance.

[0003] Currently, existing methods for identifying business logic primarily rely on manual code review. This method depends on testers manually analyzing the code logic of stored procedures, functions, and packages in the database, identifying core business modules through keyword matching or experience. However, because existing methods depend on human experience, the accuracy of business logic identification is relatively poor. Summary of the Invention

[0004] This application provides a business logic identification method, apparatus, device, storage medium, and program product to improve the accuracy of business logic identification.

[0005] Firstly, this application provides a business logic identification method, including:

[0006] Obtain static dependency data of program units in the target database; the program unit includes independently callable code modules in the target database, and the static dependency data includes the calling relationship and the number of calls between program units;

[0007] Obtain dynamic execution data of the program unit in the target database, wherein the dynamic execution data includes the running frequency of the program unit;

[0008] Cross-validation is performed based on the static dependency data and the dynamic execution data to obtain cross-validation results; the cross-validation includes filtering the program units based on preset association conditions.

[0009] Based on the cross-validation results, the core business logic objects are determined.

[0010] In one possible implementation, the step of performing cross-validation based on the static dependency data and the dynamic execution data to obtain the cross-validation result includes:

[0011] Filter out program units in the static dependency data whose in-degree is greater than a preset in-degree threshold; the in-degree indicates the number of times the program unit is called;

[0012] Filter out program units in the dynamic execution data whose running frequency is greater than a preset frequency threshold;

[0013] The intersection of program units with an in-degree greater than the in-degree threshold and program units with a running frequency greater than the frequency threshold is calculated to obtain the cross-validation result.

[0014] In one possible implementation, the step of cross-validating the static dependency data and the dynamic execution data to obtain the cross-validation result includes:

[0015] A network model is established based on the topological characteristics of the static dependency data;

[0016] Based on the network model, the hidden feature vector of the program unit is generated;

[0017] The hidden feature vector is combined with the dynamic execution frequency to obtain the cross-validation results.

[0018] In one possible implementation, after determining the core business logic object based on the cross-validation results, the process includes:

[0019] Based on the out-degree of the core business logic object, program units with an out-degree greater than a preset out-degree threshold are selected; the out-degree indicates the number of times other program units are called.

[0020] Based on the program unit whose out-degree is greater than the preset out-degree threshold, the top-level scheduler is confirmed.

[0021] In one possible implementation, obtaining the static dependency data of program units in the target database includes:

[0022] Based on the program units in the target database, determine the program units in the user mode;

[0023] Obtain the static dependency data of the program unit in the user mode.

[0024] In one possible implementation, obtaining the dynamic execution data of program units in the target database includes:

[0025] Based on the performance view of the target database, determine the latest execution frequency data;

[0026] The latest execution frequency data is merged with the historical execution frequency data to update the running frequency of the program unit;

[0027] Based on the running frequency of the program unit, the dynamic execution data of the program unit is obtained.

[0028] In one possible implementation, after determining the core business logic object based on the cross-validation results, the process includes:

[0029] Perform multi-level clustering on the core business logic objects to obtain clustering results;

[0030] Based on the clustering results, a recommendation report is output.

[0031] In one possible implementation, before performing multi-level clustering on the core business logic object to obtain the clustering result, the following steps are included:

[0032] Semantic tags are obtained by performing semantic analysis on the program unit names, comments, or associated documents using natural language processing;

[0033] By using a preset threshold and recursively traversing the circular dependency path using the semantic tags, the call path result is determined; the circular dependency path indicates the path of the dependency and call loop formed between two or more program units.

[0034] Based on the call path results, high-frequency call paths are retained.

[0035] Secondly, this application provides a business logic identification device, comprising:

[0036] The first acquisition module is used to acquire static dependency data of program units in the target database; the program unit includes independently callable code modules in the target database, and the static dependency data includes the calling relationship between program units and the number of times they are called;

[0037] The second acquisition module is used to acquire the dynamic execution data of the program unit in the target database, wherein the dynamic execution data includes the running frequency of the program unit;

[0038] The verification module is used to perform cross-validation based on the static dependency data and the dynamic execution data to obtain cross-validation results; the cross-validation includes filtering the program units based on preset association conditions;

[0039] The determination module is used to determine the core business logic object based on the cross-validation results.

[0040] Thirdly, this application provides an electronic device, including: a memory and a processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform various possible embodiments as described in the first aspect above.

[0041] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement various possible embodiments of the first aspect above.

[0042] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements various possible implementations of the first aspect described above.

[0043] This application provides a business logic identification method, apparatus, device, storage medium, and program product. By acquiring static dependency data and dynamic execution data of program units in a target database, it provides data basis for subsequently identifying core business logic objects. The program unit includes independently callable code modules in the target database. The static dependency data includes the call relationships and call counts between program units, and the dynamic execution data includes the running frequency of the program unit. Cross-validation is performed based on the static dependency data and the dynamic execution data to obtain cross-validation results. Through flexible configuration of preset association conditions, it adapts to the identification needs of different business scenarios. The cross-validation includes filtering the program unit based on preset association conditions. Based on the cross-validation results, core business logic objects can be identified, improving the accuracy of business logic identification. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0045] Figure 1 A flowchart illustrating a business logic identification method provided in this application;

[0046] Figure 2 A flowchart illustrating another business logic identification method provided in this application;

[0047] Figure 3 A schematic diagram of the structure of a business logic identification device provided in this application;

[0048] Figure 4 This is a schematic diagram of the hardware structure of an electronic device provided in this application.

[0049] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0050] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0051] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0052] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0053] First, some of the terms used in this invention will be explained:

[0054] Structured Query Language (SQL) is a programming language used to access, query, update, and manage relational database systems.

[0055] Metadata refers to data that describes data. It can be descriptive information about the data, including information such as the data's structure, attributes, and relationships.

[0056] In the context of digital transformation in the financial industry, database migration is necessary. However, during the database migration process, it is crucial to identify the core business logic that is frequently accessed within the database to ensure functional integrity and performance stability after migration. Therefore, accurately identifying the business logic is of paramount importance.

[0057] Currently, the main methods for identifying business logic are as follows:

[0058] 1. Manual code review. This method relies primarily on testers manually analyzing the code logic of stored procedures, functions, and packages in the database, using keyword matching or experience to identify core business modules. However, this method, due to its dependence on human experience, can lead to omissions or misjudgments in business logic identification.

[0059] 2. Single static analysis identification method. This method mainly obtains the compile-time dependencies between program units by querying the data dictionary view and constructs a call graph. However, this method only reflects the call logic at design time and cannot reflect the actual execution frequency at runtime. This leads to high-frequency utility class objects being misidentified as core business modules, resulting in poor accuracy in business logic identification.

[0060] Therefore, existing business logic identification methods rely on human experience or single static analysis, resulting in poor accuracy in business logic identification.

[0061] In view of the above-mentioned problems of existing business logic identification methods, this application proposes a method that does not rely on human experience or single static analysis. This method can improve the accuracy of business logic identification.

[0062] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0063] The execution entity of this business logic identification method can be, for example, a logic identification system. Optionally, the logic identification system can be any existing electronic device with processing capabilities, such as a terminal or a server. In some embodiments, the logic identification system can also be deployed in a server cluster or cloud environment. This application does not limit the deployment environment of the logic identification system.

[0064] Figure 1 This is a flowchart illustrating a business logic identification method provided in this application. Figure 1 As shown, the method includes:

[0065] S101, Obtain static dependency data of program units in the target database. The program unit includes independently callable code modules in the target database. The static dependency data includes the calling relationship between program units and the number of calls.

[0066] For example, the target database could be a relational database that stores business data.

[0067] For example, a program unit can be the smallest executable unit in the target database that encapsulates business logic.

[0068] For example, a calling relationship can be an association between a caller and a callee among program units.

[0069] As one possible implementation, the logic recognition system can determine the program unit in user mode based on the program unit in the target database. Then, it can obtain the static dependency data of the program unit in user mode.

[0070] Optionally, the logic recognition system can read the original dependency records of program units from the metadata of the target database. From these original dependencies, program units in user mode are identified, program units in system mode and non-program unit objects are filtered out, and program units in user mode are retained.

[0071] For example, a system pattern can be a pre-defined system-level object in the target database. For instance, a system pattern could be a utility function, a management object, or a dependency on a common synonym.

[0072] For example, non-program unit objects can be tables, views, indexes, etc.

[0073] Optionally, the logic recognition system can count the filtered dependency records to obtain the static call count of each program unit, and associate the filtered call relationships with the statistically obtained call counts to form complete static dependency data of call relationships and call counts.

[0074] Optionally, the logic recognition system can also obtain basic information about stored procedures from the target database, match call statements in program unit code using regular expressions, extract the relationship between the caller and the callee, and count the static call count by the callee after parsing the call relationship.

[0075] Optionally, the logic recognition system can also connect to the target database through a programming language, execute SQL queries to query dependency records, complete call relationship filtering, call count statistics and data integration in the code, and store the integrated static dependency data as a structured file or write it to a data warehouse.

[0076] Optionally, the logic recognition system can also call the database's built-in Application Programming Interface (API) to read dependency records.

[0077] Using the above method, the program unit in user mode can be identified based on the target database. Obtaining the static dependency data of this program unit in user mode solves the identification distortion problem caused by system-level object obfuscation, reduces data redundancy, and thus improves the efficiency of business logic identification.

[0078] S102, obtain the dynamic execution data of the program unit in the target database, the dynamic execution data including the running frequency of the program unit.

[0079] For example, the execution frequency can be the number of times the program unit is actually called and executed within a specified time dimension.

[0080] Optionally, the logic recognition system can filter out records from the original execution records that can independently call program units, excluding program units in system mode and non-business type execution records. Simultaneously, it can associate the program unit identifiers to obtain the mapping relationship between execution records and program units. Non-business type execution records may be, for example, the execution operations of database background processes, and the program unit identifiers may be, for example, object names or unique identifiers.

[0081] Optionally, the logic recognition system can count the filtered execution records according to a preset time dimension to calculate the running frequency of the program unit. For example, the logic recognition system can optionally count the number of times the program unit is executed per day, or the number of times it is executed per second. The logic recognition system can associate the basic information of the program unit with the statistically obtained running frequency to form dynamic execution data of program units and running frequencies. The basic information of the program unit can be, for example, its name and type.

[0082] As one possible implementation, the logic recognition system can determine the latest execution frequency data based on the performance view of the target database. Then, it merges this latest execution frequency data with historical execution frequency data to update the running frequency of the program unit. Finally, based on the running frequency of the program unit, it obtains the dynamic execution data of that program unit.

[0083] For example, the latest execution frequency data could be the execution frequency data of program units within a predetermined time window, collected in real time from the target database performance view.

[0084] For example, historical execution frequency data can be data on the execution frequency of program units within a predetermined time dimension in the past.

[0085] Optionally, the logic recognition system can collect performance views of the target database at fixed time intervals to obtain the latest execution frequency data. For example, the logic recognition system can collect the execution frequency of a certain program unit every 5 minutes.

[0086] Optionally, the logic recognition system can pre-create a historical frequency data storage table in the target database, defining the table structure. The table structure may include, for example, data such as program unit name, type, statistical time, and historical frequency.

[0087] Optionally, the logic recognition system can connect to the performance view of the target database, filter execution records of independently callable program units through SQL queries, count the number of executions within a specified latest time window, calculate the latest execution frequency data, and associate it with the unique identifier of the program unit. It then reads the corresponding program unit's historical frequency data in the same time dimension from the aforementioned historical frequency data storage table. For example, if the latest time window is set to 1 hour, the corresponding historical time window is also 1 hour.

[0088] Optionally, the logic recognition system can merge the latest execution frequency data and historical execution frequency data using a fusion method such as a weighted average to update the running frequency of the program unit. Optionally, the weights used for calculating the weighted average of the latest and historical execution frequency data (i.e., the weights corresponding to the latest and historical execution frequency data) can be pre-stored in the logic recognition system. It should be understood that this application does not limit the relative magnitudes of the weights corresponding to the latest and historical execution frequency data.

[0089] Optionally, in response to updating the execution frequency of the program unit, the logic recognition system can connect to the target database via a programming language and execute SQL to obtain the dynamic execution data of the program unit. The logic recognition system can also obtain the dynamic execution data of the program unit by parsing the stored information in the target database.

[0090] Using the above method, the latest execution frequency data can be determined based on the performance view of the target database, reducing manual intervention. By fusing this latest execution frequency data with historical execution frequency data, the running frequency of the program unit is updated, improving data real-time performance. Based on the running frequency of the program unit, dynamic execution data is obtained, reflecting the actual operating status of the program unit and improving the accuracy of business logic identification.

[0091] S103, perform cross-validation based on the static dependency data and the dynamic execution data to obtain the cross-validation result; the cross-validation includes filtering the program unit based on preset association conditions.

[0092] Optionally, the logic recognition system can perform format standardization processing on static dependency data and dynamic execution data, align the static dependency data and dynamic execution data based on the program unit name, remove invalid data that cannot be matched, and obtain an association table of static dependency data and dynamic execution data.

[0093] Optionally, the logic recognition system can also load pre-defined cross-validation rules and store them in the configuration library.

[0094] Optionally, the logic recognition system can filter the above association table by setting preset static dependency data filtering thresholds and dynamic execution data filtering thresholds to obtain program units that meet the above filtering thresholds.

[0095] Optionally, the logic recognition system can also classify the program units that meet the aforementioned screening thresholds, and a preset screening threshold ladder table, to obtain cross-validation results. For example, program units can be divided into core program units, ordinary program units, idle program units, and temporary core units, etc.

[0096] Optionally, the logic recognition system can store the cross-validation results in a custom table in the target database. For example, the cross-validation results stored in the custom table can include filtering criteria and the level classification of the program unit. The logic recognition system can also output the cross-validation results in the form of visual reports or log files, depending on business requirements.

[0097] In some embodiments, the logic recognition system can filter out program units in the static dependency data whose in-degree is greater than a preset in-degree threshold, where the in-degree indicates the number of times the program unit is called. Then, it can filter out program units in the dynamic execution data whose execution frequency is greater than a preset frequency threshold. Finally, it performs intersection calculations between the program units whose in-degree is greater than the in-degree threshold and the program units whose execution frequency is greater than the frequency threshold to obtain cross-validation results.

[0098] For example, in-degree can refer to a quantitative indicator in static dependency data that represents the number of times a program unit is called by other program units. For instance, if the in-degree of a program unit is 8, it means that the program unit has been called 8 times by other program units.

[0099] For example, the preset in-degree threshold can be a pre-configured in-degree critical point, which can be used to filter static high-in-degree program units.

[0100] For example, the preset frequency threshold can be a pre-configured operating frequency critical point, which can be used to filter dynamic high-frequency program units.

[0101] For example, the intersection operation can be a set intersection operation performed on program units with an in-degree greater than an in-degree threshold and program units with an operating frequency greater than a frequency threshold. The result of the operation can be program units that simultaneously satisfy the above two filtering conditions.

[0102] Optionally, the logic recognition system can set a preset in-degree threshold and a preset frequency threshold in the system configuration module according to the database operation and maintenance requirements and business scenario characteristics, and store the above threshold parameters in the system configuration table.

[0103] Optionally, the logic recognition system can connect to the static dependency data storage source of the target database, extract the in-degree data of program units, and simultaneously call a preset in-degree threshold parameter to filter out program units with an in-degree greater than the preset in-degree threshold, generating a static high-in-degree program unit set. Alternatively, it can connect to the dynamic execution data storage source of the target database, extract the execution frequency data of program units, and simultaneously call a preset frequency threshold parameter to filter out program units with an execution frequency greater than the preset frequency threshold, generating a dynamic high-frequency program unit set.

[0104] Optionally, the logic recognition system can use the static high-in-degree program unit set and the dynamic high-frequency program unit set as operation objects, perform set intersection calculation, and filter out program units that exist in both sets simultaneously to obtain the cross-validation result. The cross-validation result may include, for example, the program unit name, type, in-degree value, and running frequency value. The logic recognition system can also perform data verification on the cross-validation result to ensure that the name and type of the aforementioned program units completely match in the two sets.

[0105] By using the above method, program units with an in-degree greater than a preset in-degree threshold in the static dependency data and program units with a running frequency greater than a preset frequency threshold in the dynamic execution data are selected. The intersection of the program units with an in-degree greater than the in-degree threshold and the program units with a running frequency greater than the frequency threshold is calculated to obtain the cross-validation results. By filtering in stages, false positives are reduced, thereby improving the accuracy of business logic identification.

[0106] As one possible implementation, the logic recognition system can build a network model based on the topological features of the static dependency data. Then, based on this network model, a hidden feature vector for the program unit is generated. Finally, this hidden feature vector is combined with the dynamic execution frequency to obtain the cross-validation result.

[0107] For example, the topological features of static dependency data can be the core features that characterize the relationship structure between program units. These topological features might include program units, the calling relationships between program units, the number of calls, and the dependency path length.

[0108] For example, the network model can be a directed weighted graph model constructed based on the topological features of static dependency data. For instance, in this network model, nodes can correspond to program units, directed edges can correspond to the calling relationships between program units, and edge weights can correspond to the number of calls.

[0109] For example, the latent feature vector can be a topological feature representation of a program unit in a dependent network.

[0110] Optionally, the logic recognition system can connect to the static dependency data source of the target database, filter independently callable program units, and extract topological features such as the caller-callee relationship between program units, the in-degree of the callee, the number of node connections, and the dependency path length. Based on these topological features, a neural network is used to model the network, resulting in the network model.

[0111] Optionally, the logic recognition system can input the network model into a feature extraction model to obtain the implicit feature vector of the program unit. For example, the feature extraction model can be any pre-trained deep learning model or machine learning model with feature extraction capabilities.

[0112] Optionally, the logic recognition model can calculate a weighted average of the latent feature vector and the dynamic execution frequency based on preset weight coefficients to obtain a comprehensive score for each program unit. By setting a total score threshold, program units with a comprehensive score greater than the preset threshold are selected, thus obtaining the cross-validation result.

[0113] Using the above method, a network model can be obtained based on the topological features of the static dependency data. Based on this network model, a hidden feature vector for the program unit is generated, enhancing topology analysis. Combining this hidden feature vector with the dynamic execution frequency yields cross-validation results, preventing the omission of indirect core positions reflected by the hidden feature vector due to direct dependencies, thereby improving the accuracy of business logic identification.

[0114] S104. Based on the cross-validation results, determine the core business logic objects.

[0115] Optionally, the logic recognition system can extract the comprehensive score from the cross-validation results and determine the core business logic object based on the preset comprehensive score and business logic object mapping table.

[0116] Optionally, the technical indicators and business value indicators of the cross-validation results can be weighted and integrated to generate a comprehensive value score. By setting a value score threshold, high-value core business logic objects can be selected and graded according to the score.

[0117] For example, a logic recognition system can extract technical indicators such as the comprehensive score and running frequency of program units from cross-validation results. These technical indicators are then normalized with defined business value indicators. The weights of the technical and business value indicators are configured according to requirements. A fusion score is obtained by calculating the product of the normalized score of the technical indicator and its weight, and the product of the normalized score of the business value indicator and its weight. A fusion score threshold is set to filter out core objects, and they are then categorized according to their fusion scores.

[0118] For example, if the normalized score of the technical indicator for a program unit is 0.8, the weight of the technical indicator is 0.3, the normalized score of the business value indicator is 0.6, and the weight of the business value indicator is 0.7, then by calculating 0.8*0.3+0.6*0.7=0.66, the fusion score can be obtained as 0.66. Setting the fusion score thresholds for core business logic objects to be greater than or equal to 0.9, second-level business logic objects to be greater than 0.7 and less than 0.9, and third-level business logic objects to be less than or equal to 0.7, the program unit is determined to be a third-level business logic object. If the fusion score of a program unit is 0.95, then the program unit is determined to be a core business logic object.

[0119] In this embodiment, by acquiring the static dependency data of program units in the target database, and the dynamic execution data of those program units in the target database, a data basis is provided for subsequently determining the core business logic object. The program unit includes independently callable code modules in the target database. The static dependency data includes the call relationships and call counts between program units, and the dynamic execution data includes the running frequency of the program unit. Cross-validation is performed based on the static dependency data and the dynamic execution data to obtain cross-validation results. Through flexible configuration of preset association conditions, the identification needs of different business scenarios can be adapted. The cross-validation includes filtering the program unit based on preset association conditions. Based on the cross-validation results, the core business logic object can be determined, improving the accuracy of business logic identification.

[0120] In some embodiments, the logic identification system can determine the core business logic object based on the cross-validation result, and then filter out program units whose out-degree is greater than a preset out-degree threshold based on the out-degree of the core business logic object, wherein the out-degree indicates the number of times other program units are called. Then, based on the program units whose out-degree is greater than the preset out-degree threshold, the top-level scheduler is confirmed.

[0121] For example, the preset out-degree threshold can be a pre-configured out-degree numerical threshold used to filter program units with high scheduling capabilities.

[0122] Optionally, the logic recognition system can filter out program units carrying core business based on comprehensive scores and business-related features from cross-validation results, thus obtaining a set of core business logic objects. From the static dependency data of the target database, the out-degree data of the core business logic objects is extracted, a mapping relationship between core objects and out-degree is established, and a preset out-degree threshold is invoked to filter out core business logic objects with out-degrees greater than the preset threshold, resulting in a candidate set of core objects with high scheduling capabilities. Combining this with the call chain of the core business process, program units that constitute core business operations are confirmed from the candidate set of core objects, thus obtaining the top-level scheduler.

[0123] Using the method described above, after identifying the core business logic object based on the cross-validation results, program units with an out-degree greater than a preset out-degree threshold can be selected based on the out-degree of this core business logic object. This out-degree indicates the number of times other program units of the same object are called. Based on these program units with an out-degree greater than the preset out-degree threshold, the top-level scheduler is confirmed, ensuring the integrity of the core scheduling logic and thus improving the accuracy of business logic identification.

[0124] In some embodiments, the logic recognition system can determine the core business logic object based on the cross-validation results, then perform multi-level clustering on the core business logic object to obtain the clustering results. Then, based on the clustering results, a recommendation report is output.

[0125] For example, multi-level clustering can be used to stratify core business logic objects according to their call frequency and dependency network location.

[0126] For example, the dependency network location can be the structural location of a core business logic object in a static dependency network model.

[0127] Optionally, the logic recognition system can obtain the call frequency of the core business logic object from dynamic execution data, calculate the centrality of the core business logic object based on the aforementioned network model, and determine the network position dependent on the core business logic object. The logic recognition system can construct prompt words based on the call frequency and network position dependent, and input these prompt words into a deep learning model to obtain the clustering result of the core business logic object. These prompt words are used to determine the clustering result of the core business logic object based on the call frequency and network position dependent. The clustering result includes a core layer, intermediate layer, or edge layer, etc. It should be understood that the implementation method of training the deep learning model to obtain the clustering result of the core business logic object can refer to any existing training model implementation method for obtaining the clustering result of the core business logic object, and will not be elaborated here.

[0128] Optionally, the logic recognition system can generate a structured recommendation report based on the clustering results and the characteristics of each cluster group. For example, the recommendation report could suggest performance tuning for the core layer and caching mechanisms for the edge layer.

[0129] Using the method described above, after identifying the core business logic objects based on the cross-validation results, multi-level clustering is performed on these objects to obtain clustering results. Hierarchical clustering enhances the ability to distinguish business attributes. Based on these clustering results, a recommendation report is output, reducing manual intervention and improving decision-making efficiency.

[0130] As one possible implementation, the logic recognition system can perform multi-level clustering on the core business logic object. Before obtaining the clustering results, it can perform semantic analysis on the program unit name, comments, or associated documents using natural language processing to obtain semantic tags. Then, by using a preset threshold and these semantic tags, it can recursively traverse circular dependency paths to determine the call path results. These circular dependency paths indicate the dependencies and call loops formed between two or more program units. Based on these call path results, high-frequency call paths are then retained.

[0131] For example, semantic tags can be standardized feature tags that characterize the business functions, module affiliation, and priority of a program unit.

[0132] For example, a circular dependency path could be a closed loop of dependencies where program unit A calls program unit B, program unit B calls program unit C, and program unit C calls program unit A in reverse.

[0133] For example, the preset threshold can be used to filter valid circular dependency paths. For instance, the preset threshold may include a path length threshold and a call frequency threshold.

[0134] Optionally, the logic recognition system can collect the names of program units, code comments, and associated business requirement documents. Through natural language processing, it employs word segmentation algorithms to split the text, keyword extraction algorithms to filter core features, and semantic mapping algorithms to match standardized tags. By obtaining the caller-caller relationships between program units, it iteratively traverses dependency links according to a preset path length threshold, identifying circular dependency paths where the starting and ending objects are the same. The system compares the path call frequency with a preset threshold, retaining high-frequency paths with frequencies exceeding the preset threshold.

[0135] Using the above method, multi-level clustering is performed on the core business logic object. Before obtaining the clustering results, semantic analysis is conducted on the program unit name, comments, or associated documents using natural language processing to obtain semantic tags. By setting a preset threshold and recursively traversing circular dependency paths using these semantic tags, the call path results can be determined, improving the adaptability and accuracy of business logic identification. The circular dependency path indicates the path of dependencies and call loops formed between two or more program units. Based on the call path results, high-frequency call paths are retained, reducing computational complexity.

[0136] Figure 2 A flowchart illustrating another business logic identification method provided in this application. (For example...) Figure 2 As shown, the method includes:

[0137] Step 1: Static Dependency Analysis

[0138] Obtain dependency data for all program units (stored procedures, functions, packages) in user mode: Collect the dependencies between objects, including dependents and dependents, by querying the data dictionary view of the database.

[0139] Construct a dependency graph: Using program units as nodes and dependencies as directed edges (from the caller to the callee), construct a directed graph.

[0140] Computation node metrics:

[0141] In-degree: Counts the number of times each node is a dependency (i.e., the number of times it is called). For example, in-degree can be the number of times it is depended on.

[0142] Out-degree: Counts the number of times each node acts as a dependency (i.e., the number of times it calls other objects). For example, out-degree can be the number of times it depends on other objects.

[0143] Filter non-user objects: exclude core system objects, management objects, and objects that depend on system patterns such as common synonyms.

[0144] Environmental isolation filtration includes:

[0145] (1) Specify that the query results should only output the two core fields: the name of the dependent object under the current user and the name of the object being depended on.

[0146] (2) Specify the data source for the query as a data dictionary view in the database that stores the dependencies of all objects of the current user.

[0147] (3) By filtering the owner field of the dependent object, exclude system-level dependency records that belong to core system objects, management objects, and depend on common synonyms.

[0148] (4) Based on the previous filtering conditions, further filter out records whose dependent objects are stored procedures, functions, or packages to achieve combined condition filtering.

[0149] In-degree calculation includes:

[0150] (1) Specify the name of the dependent object returned by the query, and count the number of times each dependent object is depended on, and alias the count result as in-degree.

[0151] (2) Specify the data source for the query as a data dictionary view in the database that stores the dependencies of all objects of the current user.

[0152] (3): Group the data in the data dictionary view according to the name of the dependent object, and let the counting operation be performed based on each unique dependent object.

[0153] (4) Filter out group records where the statistical value of the number of times they are depended on after grouping is greater than the in-degree threshold, and retain only the dependent objects whose number of times they are depended on exceeds the threshold and their count results. The in-degree threshold is configurable.

[0154] Out-degree calculation includes:

[0155] (1) Specify the name of the dependent object under the current user to be returned by the query, and count the number of external dependencies of each dependent object, and alias the count result as the out-degree.

[0156] (2) Specify the data source for the query as a data dictionary view in the database that stores the dependencies of all objects of the current user.

[0157] (3) Group the data in the data dictionary view according to the name of the dependent object, and let the counting operation be performed based on each unique dependent object.

[0158] (4) Filter out group records where the statistical value of the number of external dependencies after grouping is greater than the out-degree threshold, and only retain the dependent objects whose number of external dependencies exceeds the out-degree threshold and their count results. The out-degree threshold is configurable.

[0159] Circular dependency detection includes:

[0160] Use the WITH clause to traverse the call chain and explore the dependency tree of a specific core object.

[0161] Among them, enhanced circular dependency detection (supporting cross-level recursion):

[0162] (1) Define a recursive public table expression and specify the four columns it contains: caller object name, callee object name, dependency path, and dependency path depth.

[0163] (2) As a recursive anchor query, select the dependent object name and the dependent object name from the data dictionary view, concatenate them into the initial dependency path from the caller to the callee, and set the initial link depth value.

[0164] (3) Specify that the data source for the anchor query is the data dictionary view that stores the current user object's dependency relationship.

[0165] (4) Filter the results of anchor point queries and retain only non-system-level dependency records where the owner of the dependent object is not a core system object or a management object, and which depend on common synonyms.

[0166] (5) As a separator for recursive queries, it merges the anchor query results with the subsequent recursive query results and is the core keyword of recursion.

[0167] (6) As a recursive query part, select a new dependent object name and a dependent object name, and concatenate the new dependent object after the existing dependent path to form a complete link, and add 1 to the link depth on the original basis.

[0168] (7) Specify the source of the dependent data in the recursive query as the data dictionary view and set its table name.

[0169] (8) Connect the data dictionary view table of the recursive query with the recursive common table expression, and the association condition is that the new dependent object name is equal to the caller object name of the previous link, so as to realize the recursive traversal of the dependency link.

[0170] (9) Set a depth limit for recursive queries, and continue recursion only when the link depth is less than the depth threshold to prevent query performance explosion or excessively large result sets caused by infinite loops.

[0171] (10) End the definition of the recursive public table expression.

[0172] (11) Query all columns from the result set generated by recursion and filter out records where the caller object name is the same as the callee object name, so as to locate the loop point in the dependency chain.

[0173] Step 2: Perform dynamic statistical analysis

[0174] Get dynamic execution data: Get the execution statistics of SQL statements within a specified time window from the database's dynamic performance view, including the number of executions and execution time.

[0175] Mapping SQL to program units: By matching the module and action attributes of the SQL statement, as well as the core columns storing the SQL statement text content, with the program unit name, SQL execution statistics are associated with the corresponding program unit. For SQL statements that cannot be directly associated, matching is performed by analyzing the stored procedure / function names called in the core columns storing the SQL statement text content.

[0176] SQL and program unit mapping rules include:

[0177] (1) Direct matching: Match package name by module.

[0178] (2) Text parsing: When the module is empty, the core column storing the text content of the SQL statement is parsed and the stored procedure name of the syntax call is extracted.

[0179] (3) Function signature matching: Identify the SQL statement that calls the function and obtains its return value.

[0180] Calculate the execution frequency of program units: For each program unit, sum up the execution counts of all associated SQL statements to obtain the total execution count.

[0181] Step 3: Identification of Core Business Logic

[0182] Candidate set generation: Based on static dependencies, program units with an in-degree greater than a preset threshold (e.g., in-degree ≥ 5) are selected as candidate core business logic objects.

[0183] Business importance verification: Combine the candidate set with dynamic execution statistics to filter out program units with execution frequency exceeding a preset threshold (e.g., execution times > 1000 times / day) and high in-degree.

[0184] Key business entry point identification: Identify program units with an out-degree greater than a preset threshold (e.g., out-degree ≥ 10) and an in-degree less than a preset threshold (e.g., in-degree ≤ 2) as the top-level business logic entry point (e.g., end-of-day scheduling program).

[0185] Manual annotation assistance: Match candidate object names with preset business keywords to further confirm their business attributes.

[0186] Core business logic identification algorithm:

[0187] (1) Define a function to encapsulate the identification logic of the core database objects.

[0188] (2) Call the above function to filter out database objects with an in-degree greater than or equal to 5 and construct a static high in-degree candidate set.

[0189] (3) Call the above function to filter out database objects that are executed more than 1,000 times per day and build a dynamic high-frequency candidate set.

[0190] (4) Take the intersection of the static high in-degree candidate set and the dynamic high frequency candidate set, and use the result as the true core object of the database.

[0191] (5) Iterate through each object in the initially selected core object set to prepare for subsequent business keyword matching and priority adjustment.

[0192] (6) Call the keyword function to determine whether the name of the core object being traversed contains the specified business keyword.

[0193] (7) If the name of the current core object matches the specified business keyword, increment the optimization priority value of the object by 1 and improve its optimization level.

[0194] Step 4: Identification of High-Frequency Call Objects

[0195] Based on dynamic execution statistics, program units whose execution frequency exceeds a preset threshold (e.g., execution times > 5000 times / day) are selected as high-frequency call objects.

[0196] By combining static dependencies, analyze the position of frequently called objects in the dependency graph (such as whether they are public utility classes or core business services).

[0197] Step 5: Visualization and Optimization Suggestion Generation

[0198] Dependency visualization: Combines dependency graphs with execution frequency data to graphically display node size (representing execution frequency) and color (representing in-degree / out-degree), highlighting core business logic and frequently called objects.

[0199] Generate an optimization suggestion report.

[0200] Optionally, for frequently accessed objects, performance optimization is recommended (such as SQL tuning and caching mechanisms).

[0201] Optionally, for high-in-degree objects, it is recommended to perform stability hardening (such as enhanced exception handling) and improve documentation.

[0202] Optionally, for circular dependency paths, it is recommended to refactor to reduce coupling.

[0203] Figure 3 This is a schematic diagram of the structure of a business logic identification device provided in this application. Figure 3 As shown, the business logic identification device 300 may include: a first acquisition module 301, a second acquisition module 302, a verification module 303, and a determination module 304. Among them,

[0204] The first acquisition module 301 is used to acquire static dependency data of program units in the target database; the program unit includes independently callable code modules in the target database, and the static dependency data includes the calling relationship between program units and the number of calls;

[0205] The second acquisition module 302 is used to acquire the dynamic execution data of the program unit in the target database, the dynamic execution data including the running frequency of the program unit;

[0206] Verification module 303 is used to perform cross-validation based on the static dependency data and the dynamic execution data to obtain cross-validation results; the cross-validation includes filtering the program unit based on preset association conditions;

[0207] Module 304 is used to determine the core business logic object based on the cross-validation results.

[0208] Optionally, the first acquisition module 301 is further configured to determine the program unit in user mode based on the program unit in the target database;

[0209] Retrieve the static dependency data of the program unit in the user mode.

[0210] Optionally, the second acquisition module 302 is further configured to determine the latest execution frequency data based on the performance view of the target database;

[0211] The latest execution frequency data is merged with the historical execution frequency data to update the running frequency of the program unit;

[0212] Based on the running frequency of the program unit, obtain the dynamic execution data of the program unit.

[0213] Optionally, the verification module 303 is also used to filter out program units in the static dependency data whose in-degree is greater than a preset in-degree threshold; the in-degree indicates the number of times the program unit is called;

[0214] Filter out program units in the dynamic execution data whose running frequency is greater than a preset frequency threshold;

[0215] The intersection of the program unit whose in-degree is greater than the in-degree threshold and the program unit whose running frequency is greater than the frequency threshold is calculated to obtain the cross-validation result.

[0216] Optionally, the verification module 303 is also used to establish a network model based on the topological characteristics of the static dependency data;

[0217] Based on this network model, the hidden feature vector of this program unit is generated;

[0218] The hidden feature vector is combined with the dynamic execution frequency to obtain the cross-validation results.

[0219] Optionally, the determining module 304 is further configured to, after determining the core business logic object based on the cross-validation result, filter out program units whose out-degree is greater than a preset out-degree threshold based on the out-degree of the core business logic object; the out-degree indicates the number of times other program units are called;

[0220] Based on the program unit whose out-degree is greater than the preset out-degree threshold, the top-level scheduler is confirmed.

[0221] Optionally, the determining module 304 is further configured to perform multi-level clustering on the core business logic object after determining it based on the cross-validation result, and obtain the clustering result;

[0222] Based on the clustering results, a recommendation report is generated.

[0223] Optionally, the determining module 304 is also used to perform semantic analysis on the program unit name, comments or associated documents through natural language processing before performing multi-level clustering on the core business logic object and obtaining the clustering results;

[0224] By using a preset threshold and recursively traversing the circular dependency path using the semantic tag, the result of the call path is determined; the circular dependency path indicates the dependency formed between two or more program units and the path of the call loop.

[0225] Based on the results of this call path, high-frequency call paths are retained.

[0226] The business logic identification device provided in this application embodiment can execute the methods provided in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0227] Figure 4 This is a schematic diagram of the hardware structure of an electronic device provided in this application. Figure 4 As shown, the electronic device 400 includes a memory 401, a processor 402, and a communication interface 403. The memory 401, processor 402, and communication interface 403 are communicatively connected to each other. For example, the memory 401, processor 402, and communication interface 403 can be connected via a network. Alternatively, the electronic device 400 may also include a bus 404. The memory 401, processor 402, and communication interface 403 are communicatively connected to each other via the bus 404. Figure 4 The electronic device 400 is a device that uses a memory 401, a processor 402, and a communication interface 403 to communicate with each other via a bus 404.

[0228] The memory 401 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 401 may store programs, and when the programs stored in the memory 401 are executed by the processor 402, the processor 402 and the communication interface 403 are used to execute the methods provided in any of the foregoing embodiments. The memory may also store data required for at least one method in this embodiment.

[0229] The processor 402 may be a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), graphics processing unit (GPU), or one or more integrated circuits.

[0230] Processor 402 can also be an integrated circuit chip with signal processing capabilities. In implementation, the methods disclosed in the embodiments of this application can be completed by the integrated logic circuits in the hardware of processor 402 or by instructions in software form. The processor 402 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments below of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments below of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 401, and processor 402 reads the information in memory 401 and, in conjunction with its hardware, completes the methods disclosed in the embodiments of this application.

[0231] Communication interface 403 uses transceiver modules, such as, but not limited to, transceivers, to enable communication between electronic device 400 and other devices or communication networks. For example, data sets can be acquired through communication interface 403.

[0232] When the aforementioned electronic device 400 includes a bus 404, the bus 404 may include a path for transmitting information between various components of the electronic device 400 (e.g., memory 401, processor 402, communication interface 403).

[0233] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Specifically, the computer-readable storage medium stores program instructions, which are used in the methods described in the above embodiments.

[0234] This application also provides a program product including executable instructions stored in a readable storage medium. At least one processor of an electronic device can read the executable instructions from the readable storage medium, and the at least one processor executes the executable instructions to cause the electronic device to perform the methods provided in the various embodiments described above.

[0235] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0236] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0237] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0238] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0239] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0240] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0241] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0242] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0243] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A business logic identification method, characterized in that, include: Obtain static dependency data of program units in the target database; the program unit includes independently callable code modules in the target database, and the static dependency data includes the calling relationship and the number of calls between program units; Obtain dynamic execution data of the program unit in the target database, wherein the dynamic execution data includes the running frequency of the program unit; Cross-validation is performed based on the static dependency data and the dynamic execution data to obtain cross-validation results; the cross-validation includes filtering the program units based on preset association conditions. Based on the cross-validation results, the core business logic objects are determined.

2. The method according to claim 1, characterized in that, The step of performing cross-validation based on the static dependency data and the dynamic execution data to obtain cross-validation results includes: Filter out program units in the static dependency data whose in-degree is greater than a preset in-degree threshold; the in-degree indicates the number of times the program unit is called; Filter out program units in the dynamic execution data whose running frequency is greater than a preset frequency threshold; The intersection of program units with an in-degree greater than the in-degree threshold and program units with a running frequency greater than the frequency threshold is calculated to obtain the cross-validation result.

3. The method according to claim 1, characterized in that, The step of performing cross-validation based on the static dependency data and the dynamic execution data to obtain cross-validation results includes: A network model is established based on the topological characteristics of the static dependency data; Based on the network model, the hidden feature vector of the program unit is generated; The hidden feature vector is combined with the dynamic execution frequency to obtain the cross-validation results.

4. The method according to claim 1, characterized in that, After determining the core business logic object based on the cross-validation results, the process includes: Based on the out-degree of the core business logic object, program units with an out-degree greater than a preset out-degree threshold are selected; the out-degree indicates the number of times other program units are called. Based on the program unit whose out-degree is greater than the preset out-degree threshold, the top-level scheduler is confirmed.

5. The method according to claim 1, characterized in that, The step of obtaining static dependency data of program units in the target database includes: Based on the program units in the target database, determine the program units in the user mode; Obtain the static dependency data of the program unit in the user mode.

6. The method according to claim 1, characterized in that, The step of obtaining dynamic execution data of program units in the target database includes: Based on the performance view of the target database, determine the latest execution frequency data; The latest execution frequency data is merged with the historical execution frequency data to update the running frequency of the program unit; Based on the running frequency of the program unit, the dynamic execution data of the program unit is obtained.

7. The method according to any one of claims 1-6, characterized in that, After determining the core business logic object based on the cross-validation results, the process includes: Perform multi-level clustering on the core business logic objects to obtain clustering results; Based on the clustering results, a recommendation report is output.

8. The method according to claim 7, characterized in that, Before performing multi-level clustering on the core business logic objects to obtain the clustering results, the following steps are included: Semantic tags are obtained by performing semantic analysis on the program unit names, comments, or associated documents using natural language processing; By using a preset threshold and recursively traversing the circular dependency path using the semantic tags, the call path result is determined; the circular dependency path indicates the path of the dependency and call loop formed between two or more program units. Based on the call path results, high-frequency call paths are retained.

9. A business logic identification device, comprising: The first acquisition module is used to acquire static dependency data of program units in the target database; the program unit includes independently callable code modules in the target database, and the static dependency data includes the calling relationship between program units and the number of times they are called; The second acquisition module is used to acquire the dynamic execution data of the program unit in the target database, wherein the dynamic execution data includes the running frequency of the program unit; The verification module is used to perform cross-validation based on the static dependency data and the dynamic execution data to obtain cross-validation results; the cross-validation includes filtering the program units based on preset association conditions; The determination module is used to determine the core business logic object based on the cross-validation results.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images