Methods, apparatus, computer equipment, and storage media for determining dependencies

Abstract

This application relates to a method, apparatus, computer device, storage medium, and computer program product for determining dependencies. The method includes: acquiring multiple target datasets invoked by various call logics to be analyzed, and dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset and the dataset invocation status when the dataset is invoked by the call logics to be analyzed; matching the dataset name and dataset invocation status of each dataset in each target dataset to determine the target call logic matched by each call logic to be analyzed; and creating call logic dependencies between each call logic to be analyzed and the target call logic, the call logic dependencies describing that the call logic to be analyzed and the target call logic successfully invoke the same dataset. This method ensures the efficiency of the generated dependencies and avoids impacting runtime performance load.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, and storage medium for determining dependencies. Background Technology

[0002] With the advancement of technology and the increasing demands of games on Central Processing Unit (CPU) performance, the performance improvement provided by a single-core, high-frequency CPU is becoming increasingly limited. Therefore, the multi-core operation of Entity Component System (ECS) is becoming the norm. The increased volume of data calls leads to a greater complexity in the logic of data calls within the system, making the dependencies between these calls more intricate.

[0003] Currently, dependency information can be derived by modifying the key interfaces of existing ECS ​​instances and adding a new data container for dependency statistics. This container is then populated at runtime for dynamic analysis, ultimately exporting dependency information. However, while runtime dynamic analysis can output dependencies, the dependency analysis code may be highly coupled to the existing runtime logic, impacting performance. Furthermore, the efficiency of iterative data collection during optimization is relatively low. Therefore, ensuring the efficiency of the generated dependency relationships while avoiding negative impacts on runtime performance is a pressing issue that needs to be addressed. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, and storage medium for determining dependencies that can ensure the efficiency of the generated dependencies and avoid impacting the performance load of the operation, in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a method for determining dependencies. The method includes:

[0006] Obtain the target datasets called by multiple call logics to be analyzed, as well as the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset called by the call logic to be analyzed.

[0007] Match the dataset name and dataset call status of each dataset in each target dataset to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and the dataset call status of both the target call logic and the matched call logic to be analyzed is a successful call.

[0008] Create call logic dependencies between each call logic to be analyzed and the target call logic. The call logic dependencies are used to describe whether the call logic to be analyzed and the target call logic successfully call the same dataset.

[0009] Secondly, this application also provides an apparatus for determining dependencies. The apparatus includes:

[0010] The data acquisition module is used to acquire the target datasets called by multiple analysis logics, as well as the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset called by the analysis logic.

[0011] The logic matching module is used to match the dataset name and dataset call status of each dataset in each target dataset to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and the dataset call status of both the target call logic and the matched call logic to be analyzed is a successful call.

[0012] The dependency creation module is used to create call logic dependencies between each call logic to be analyzed and the target call logic. The call logic dependency describes that the call logic to be analyzed and the target call logic successfully call the same dataset.

[0013] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0014] Obtain the target datasets called by multiple call logics to be analyzed, as well as the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset called by the call logic to be analyzed.

[0015] Match the dataset name and dataset call status of each dataset in each target dataset to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and the dataset call status of both the target call logic and the matched call logic to be analyzed is a successful call.

[0016] Create call logic dependencies between each call logic to be analyzed and the target call logic. The call logic dependencies are used to describe whether the call logic to be analyzed and the target call logic successfully call the same dataset.

[0017] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0018] Obtain the target datasets called by multiple call logics to be analyzed, as well as the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset called by the call logic to be analyzed.

[0019] Match the dataset name and dataset call status of each dataset in each target dataset to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and the dataset call status of both the target call logic and the matched call logic to be analyzed is a successful call.

[0020] Create call logic dependencies between each call logic to be analyzed and the target call logic. The call logic dependencies are used to describe whether the call logic to be analyzed and the target call logic successfully call the same dataset.

[0021] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0022] Obtain the target datasets called by multiple call logics to be analyzed, as well as the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset called by the call logic to be analyzed.

[0023] Match the dataset name and dataset call status of each dataset in each target dataset to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and the dataset call status of both the target call logic and the matched call logic to be analyzed is a successful call.

[0024] Create call logic dependencies between each call logic to be analyzed and the target call logic. The call logic dependencies are used to describe whether the call logic to be analyzed and the target call logic successfully call the same dataset.

[0025] The aforementioned method, apparatus, computer device, storage medium, and computer program product for determining dependencies acquire multiple target datasets invoked by the call logic to be analyzed, and dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name and the dataset invocation status of the dataset invoked by the call logic to be analyzed. Then, the dataset name and invocation status of each dataset in each target dataset are matched to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic matches the dataset name of the matched call logic to be analyzed, and both the dataset invocation status of the target call logic and the dataset invocation status of the matched call logic to be analyzed are successful invocations. Finally, a call logic dependency relationship is created between each call logic to be analyzed and the target call logic. The call logic dependency relationship describes that the call logic to be analyzed and the target call logic successfully invoke the same dataset. When obtaining the target dataset for the call logic to be analyzed, the dataset information corresponding to the target dataset is also collected. By matching the dataset name and the dataset call status in each dataset information, the target call logic that successfully calls the same dataset as the call logic to be analyzed is obtained, thus creating a dependency relationship between the call logics. At this time, it is not necessary to analyze the call flow through dependency analysis code, but to directly obtain the relevant information of the called target dataset, avoiding the problem of high coupling between dependency analysis code and running logic, thereby reducing the possibility of affecting the actual running performance. Furthermore, obtaining the relevant information of the called target dataset does not require cyclical collection of information for each dataset, thus avoiding the problem of low efficiency of cyclical data collection during actual iterative optimization. Therefore, the efficiency of the generated dependency relationship can be guaranteed, and the impact on the running performance load can be avoided. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of an embodiment of the dependencies collected by the table registration preview in one example;

[0027] Figure 2 This is an application environment diagram of a dependency determination method in one embodiment;

[0028] Figure 3 This is a flowchart illustrating the process of determining dependencies and generating a dependency view in one embodiment.

[0029] Figure 4 This is a flowchart illustrating a method for determining dependencies in one embodiment;

[0030] Figure 5 This is a flowchart illustrating the process of determining the target invocation logic in one embodiment;

[0031] Figure 6 This is a schematic diagram of dataset information in one embodiment;

[0032] Figure 7 This is a schematic diagram illustrating the process of obtaining the target dataset and dataset information in one embodiment.

[0033] Figure 8 This is a schematic diagram of logical operation information in one embodiment;

[0034] Figure 9 This is a flowchart illustrating the process of filtering to obtain the target function opcode in one embodiment;

[0035] Figure 10 This is a schematic diagram of the process for obtaining the target dataset through filtering in one embodiment;

[0036] Figure 11 This is a flowchart illustrating the process of determining the target invocation logic in one embodiment;

[0037] Figure 12 This is a flowchart illustrating a method for determining dependencies in another embodiment;

[0038] Figure 13 This is a schematic diagram of the code field in an XML file that executes a dependency determination method in one embodiment;

[0039] Figure 14 A flowchart illustrating the process of generating a dependency view based on the dependency relationships between calling logics in one embodiment;

[0040] Figure 15 This is a flowchart illustrating the process of generating a dependency view after creating a call logic dependency relationship in one embodiment.

[0041] Figure 16 This is a schematic diagram of a dependency view in one embodiment;

[0042] Figure 17 This is a schematic diagram of a dependency view in another embodiment;

[0043] Figure 18 This is a complete flowchart illustrating a method for determining dependencies in one embodiment;

[0044] Figure 19 This is a structural block diagram of a dependency determination device in one embodiment;

[0045] Figure 20 This is a structural block diagram of a dependency determination device in another embodiment;

[0046] Figure 21 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0048] With the advancement of technology and the increasing demands of games on CPU performance, the performance improvement provided by high-frequency single-core CPUs is becoming increasingly limited. Therefore, multi-core operation in ECS (Elastic Compute Service) is becoming the norm. The increased volume of data calls leads to a greater number of data call logics within the system, making the dependencies between these logics more complex. Currently, this can be addressed through manual code review or by recording the relevant information of each component in a table based on the actual runtime call order of various systems for previewing. Specifically... Figure 1 The table shown is a preview of the dependencies collected. However, manual code review or table registration is inefficient for determining dependencies.

[0049] Therefore, one approach is to modify the existing critical interfaces of the ECS instance, adding a new data container for dependency statistics. This container is then populated at runtime for dynamic analysis, ultimately exporting dependency information. However, while runtime dynamic analysis can output dependencies, the dependency analysis code may be highly coupled to the existing runtime logic, impacting performance. Furthermore, analyzing dependencies based on this code typically requires additional data structures, significantly increasing the logical and performance load. In actual iterative optimization, multiple loops are needed: logic execution, dependency collection, dependency output, dependency logic optimization, and then logic execution again, resulting in low efficiency in iterative data collection. Therefore, ensuring the efficiency of the generated dependencies while avoiding impact on runtime performance is a critical issue that needs to be addressed.

[0050] Therefore, this application provides a method for determining dependencies that ensures the efficiency of the generated dependencies and avoids impacting runtime performance. The dependency determination method provided in this application can be applied to applications such as... Figure 2 The application environment shown depicts a scenario where terminal 202 communicates with server 204 via a network. A data storage system can store the data that server 204 needs to process. The data storage system can be integrated onto server 204, or it can be located in the cloud or on another server.

[0051] Specifically, taking the application of server 204 in this embodiment as an example, server 204 can obtain, at runtime, the target datasets called by multiple call logics to be analyzed, and the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset called by the call logic to be analyzed. Then, server 204 matches the dataset name and dataset call status of each dataset in each target dataset to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and the dataset call status of both the target call logic and the matched call logic to be analyzed are successful calls. Based on this, server 204 creates a call logic dependency relationship between each call logic to be analyzed and the target call logic. The call logic dependency relationship describes that the call logic to be analyzed and the target call logic successfully call the same dataset.

[0052] The terminal 202 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle systems. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The server 204 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0053] It is understood that the embodiments of this application are specifically applied to a system with multiple cores operating in an Entity-Component-System (ECS) architecture. Here, Entity refers to an entity, and Entity represents a discrete entity in the program that has its own dataset. Generally, Entity acts as a sequence number (identity, ID) that associates various components together; therefore, Entity does not contain any code or act as a container for its associated components. Component refers to a component, and Component essentially contains the specific data of Entity, which is read and written in System. Therefore, the dataset described in the embodiments of this application specifically refers to the specific data included in Component, that is, the specific data of Entity. System refers to a system that provides the logic for transforming the data in a component from the current state to the next state. The System also uses Job to actually call the specific data in Component. Job is the calling logic described in the embodiments of this application. Job is a piece of concurrent logic actually called in System, and at least one Job will be called in a System.

[0054] Therefore, the dependency relationships described in the embodiments of this application are used to describe read and write calls to the same dataset by different calling logics. For example, Job1 and Job2 are actual calling logics from the same or different systems. If Job1 reads from dataset 1 and Job2 writes to dataset 1, or if Job1 reads from dataset 1 and Job2 reads from dataset 1, or if Job1 writes to dataset 1 and Job2 writes to dataset 1, a data race will occur. This will prevent Job1 and Job2 from executing concurrently using multithreading. In this case, it can be determined that there is a dependency relationship between Job1 and Job2.

[0055] Furthermore, the dependency determination method provided in this application embodiment can be applied to scenarios such as game optimization, program optimization, game archiving, or program archiving. That is, after determining the dependency relationship between calling logic through the dependency determination method provided in this application embodiment, a dependency relationship view can be generated and displayed, as follows: Figure 3 As shown, the parsing configuration is loaded first. Specifically, the parsing configuration is used to parse the assembly, such as configuring preset opcode types, preset type information, and preset data call interface types. The aforementioned preset type information can further include preset operand types and preset method name types. Then, the assembly (i.e., the ECS assembly) is loaded, and the acquired assembly is parsed based on the parsing configuration to collect key information. This key information includes key call logic information (Job Info) for each system, and key dataset information (Component-Data Info). Specifically, the dataset information refers to the dataset information corresponding to the dataset described in this embodiment, as well as the logical operation information corresponding to the call logic.

[0056] Based on this, the key information collected is used to obtain the dataset invocation status of each dataset and the data invocation status of the actual data in each dataset. This allows us to determine the invocation logic that successfully invokes the same dataset, and to create invocation logic dependencies between different invocation logics that successfully invoke the same dataset. A dependency view is then generated based on these dependencies, including the invocation logic nodes corresponding to each invocation logic. Therefore, in practical applications, by generating the invocation logic nodes corresponding to each invocation logic in the dependency view, and the invocation logic dependency edges between these nodes, we can analyze whether issues such as multi-threaded concurrent execution caused by dependencies have been optimized. Alternatively, multiple historically generated dependency views can be saved for archiving or optimization comparison scenarios. No specific application scenarios are exhaustively limited here.

[0057] In one embodiment, such as Figure 4 As shown, a method for determining dependencies is provided, which can be applied to... Figure 2 Taking server 204 as an example, it can be understood that this method can also be applied to terminal 202, and also to a system including terminal 202 and server 204, and is implemented through the interaction between terminal 202 and server 204. In this embodiment, the method includes the following steps:

[0058] Step 402: Obtain the target datasets called by the multiple call logics to be analyzed, and the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset called by the call logic to be analyzed.

[0059] The call logic to be analyzed refers to the call logic that has a call logic dependency relationship with it. As described in the previous embodiments, during business service, the server needs to use a Job to actually call specific data in the component through the system. The Job is the call logic described in the embodiments of this application. The call logic is specifically a piece of concurrent logic in the system that actually calls the data. Usually, when executing certain functions, it is necessary to call multiple data based on multiple call logics. Therefore, a system will call at least one call logic. Thus, the target dataset is the dataset called by the call logic to be analyzed, and the target dataset can be a set composed of one or more datasets called by the call logic to be analyzed. As described in the previous embodiments, the component actually contains the specific data of the entity and is read and written in the system. Therefore, the dataset is specifically the set of specific data included in the component. The aforementioned calls specifically include: reading calls or writing calls to the data.

[0060] For example, there are multiple call logics to be analyzed, namely call logic A1, call logic A2, call logic A3, and call logic A4. During operation, call logic A1 calls component B1, call logic A2 calls component B1, call logic A3 calls component B2, and call logic A4 calls both components B3 and B4. The specific data set included in component B1 is dataset C1, the specific data set included in component B2 is dataset C2, the specific data set included in component B3 is dataset C3, and the specific data set included in component B4 is dataset C4. Therefore, it can be determined that call logic A1 specifically calls dataset C1, call logic A2 specifically calls dataset C1, call logic A3 specifically calls dataset C2, and call logic A4 specifically calls both datasets C3 and C4.

[0061] Secondly, each dataset has corresponding dataset information when it is invoked. This means that the dataset information differs depending on the invocation logic used to invoke the dataset. Therefore, the dataset information describes the invocation information when the corresponding dataset is invoked by the logic to be analyzed. The dataset information includes at least: the dataset name (Component Name) and the dataset invocation status (isWritable) of the invocation logic to be analyzed. The dataset name is specifically the component name (Name) field, and the dataset invocation status describes whether a read call (Read) or a write call (Write) was successfully performed when the dataset was invoked by the logic to be analyzed.

[0062] It is understandable that the dataset information may also include: actual call data information in the dataset. The actual call data information includes at least: the actual call data in the dataset that is called by the call logic to be analyzed, and the data call status (dataReadWritables) of the actual call data called by the call logic to be analyzed. The data call status is used to describe whether the call logic to be analyzed successfully reads or writes the actual call data in the dataset.

[0063] Specifically, when running any business service, the server can obtain the target datasets invoked by each logic call to be analyzed. The server then further collects the dataset information corresponding to each dataset within each target dataset. That is, when running any business service, the server acquires the assembly, performs reflection parsing on the assembly to obtain the target datasets invoked by each logic call to be analyzed, then obtains the label information reflected from each target dataset to collect the dataset invocation status of each dataset, and parses each dataset to obtain the dataset name. The aforementioned reflection parsing is specifically the reflection processing in the IL Runtime.

[0064] Step 404: Match the dataset name and dataset call status of each dataset in each target dataset to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and the dataset call status of both the target call logic and the matched call logic to be analyzed is a successful call.

[0065] The matching process involves the dataset name and the dataset invocation status of each dataset. Therefore, the dataset name of the target invocation logic matches the dataset name of the matched invocation logic to be analyzed, and both the target and matched invocation logics have successfully invoked the same dataset.

[0066] Specifically, the server matches the dataset information corresponding to each dataset in the target dataset called by each of the call logics to be analyzed, that is, it matches the dataset name and dataset call status of each dataset in each target dataset. The server first matches the dataset name of each dataset in the target dataset of the call logic to be analyzed. If there are datasets with the same dataset name in the target datasets of two call logics to be analyzed, the server then determines the dataset call status of the two call logics to the dataset with the same dataset name. When the dataset call status is used to describe a successful call, it can be determined that the two call logics to be analyzed are each other's target call logics.

[0067] For ease of understanding, suppose there are two call logics to be analyzed, A1 and A2. During operation, call logic A1 calls component B1, and call logic A2 calls component B1. The specific data set included in component B1 is dataset C1. As shown in the previous example, call logic A1 specifically calls dataset C1, and call logic A2 specifically calls dataset C1. At this point, it can be determined that both call logic A1 and call logic A2 call dataset C1. At this point, the server should further determine the dataset call status when the call logic A1 calls the dataset C1, and the dataset call status when the call logic A2 calls the dataset C1. If none of the aforementioned dataset call statuses are failure calls (False), then the dataset call statuses are both successful calls. A successful call means either a successful read call or a successful write call. Only then can the server determine that the target call logic matched by the call logic A1 is the call logic A2, and vice versa.

[0068] Step 406: Create call logic dependencies between each call logic to be analyzed and the target call logic. The call logic dependencies are used to describe that the call logic to be analyzed and the target call logic successfully call the same dataset.

[0069] The call logic dependency relationship describes whether the call logic to be analyzed and the target call logic successfully invoke the same dataset. Specifically, since the dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and both the dataset invocation status of the target call logic and the dataset invocation status of the matched call logic to be analyzed are successful invocations, meaning that the matched call logic to be analyzed and the target call logic successfully invoked the same dataset, a corresponding call logic dependency relationship can be created between each call logic to be analyzed and the matched target call logic. This call logic dependency relationship describes whether the call logic to be analyzed and the target call logic successfully invoked the same dataset.

[0070] For ease of understanding, based on the foregoing example, if the server determines that the target call logic matched by the call logic A1 to be analyzed is the call logic A2 to be analyzed, then the server can further create a call logic dependency relationship between the call logic A1 and the call logic A2 to be analyzed. This call logic dependency relationship describes that the call logic A1 and the call logic A2 to be analyzed successfully call the same dataset. It is understood that the examples in this embodiment are for understanding this solution and should not be construed as specific limitations on this solution.

[0071] In the aforementioned method for determining dependencies, when obtaining the target dataset of the call logic to be analyzed, the dataset information corresponding to the target dataset is also collected. This is achieved by matching the dataset name with the call status in each dataset's information to identify the target call logic that successfully calls the same dataset as the call logic to be analyzed, thus creating a dependency relationship between the call logics. In this case, it is not necessary to analyze the call flow through dependency analysis code; instead, the relevant information of the called target dataset is directly obtained. This avoids the problem of high coupling between dependency analysis code and runtime logic, thereby reducing the possibility of impacting actual runtime performance. Furthermore, obtaining the relevant information of the called target dataset does not require iterative collection of information from each dataset, thus avoiding the low efficiency of iterative data collection during actual iterative optimization. Therefore, the efficiency of the generated dependency relationship is guaranteed, and the impact on runtime performance load is avoided.

[0072] The following will detail the implementation method for matching: In one embodiment, such as Figure 5 As shown, the dataset name and dataset call status of each dataset in each target dataset are matched to determine the target call logic that matches each call logic to be analyzed, including:

[0073] Step 502: Based on the call times corresponding to each dataset of each logic call to be analyzed, perform a reverse traversal to determine the logic operations to be judged that have a preceding operation relationship with each logic operation to be analyzed. The reverse traversal is used to describe: traversing other logic operations to be analyzed whose call time is earlier than the logic operation to be analyzed. The preceding operation relationship is used to describe: the call time of the logic operation to be judged is earlier than the logic operation to be analyzed.

[0074] When each logic called upon a dataset in the target dataset, the corresponding call time is recorded. Therefore, the call time for each dataset describes the timestamp of the dataset being called by the logic. Different logics calling the same dataset may have the same or different call times. For example, the call time for logic A1 calling dataset C1 is timestamp D1, for logic A2 calling dataset C1 is timestamp D2, for logic A3 calling dataset C2 is timestamp D3, for logic A4 calling dataset C3 is timestamp D4, and for logic A4 calling dataset C4 is timestamp D5.

[0075] Secondly, reverse traversal is used to describe: traversing other logic operations to be analyzed whose invocation time precedes that of the logic operation to be analyzed. Based on this, the preceding operation relationship is used to describe: the invocation time of the logic operation to be judged precedes that of the logic operation to be analyzed. Furthermore, it can be seen that the logic operation to be judged and the logic operation to be analyzed have a following operation relationship, and the following operation relationship is used to describe: the invocation time of the logic operation to be analyzed is later than that of the logic operation to be judged.

[0076] Specifically, the server first determines the call time corresponding to each call of the logic to be analyzed to each dataset in the target dataset. Then, based on the call time corresponding to each dataset, it iterates through other logic operations to be analyzed whose call time precedes that of the logic operation to be analyzed, to determine the logic operations to be judged whose call time precedes that of the logic operation to be analyzed. Furthermore, the server can further determine the logic operations to be judged based on the logic operations to be judged that have a preceding operation relationship with each logic operation to be analyzed.

[0077] For example, in the aforementioned example, timestamps D1 to D5 are arranged in order of priority, meaning timestamp D1 precedes timestamp D2, timestamp D2 precedes timestamp D3, and so on. Therefore, for the call logic A1 to be analyzed, since the call time corresponding to dataset C1 is timestamp D1, which is the earliest call time, a reverse traversal of call logic A1 cannot obtain the corresponding logic operation with a preceding operation relationship. However, it can identify call logics A2, A3, and A4 that have a following operation relationship with call logic A1.

[0078] Similarly, for the call logic A2 to be analyzed, since the call time corresponding to the dataset C1 called by the call logic A2 is timestamp D2, the call logic A2 to be analyzed can traverse the call logics to be analyzed whose call time is earlier than timestamp D2. And the call logics to be analyzed whose call time is earlier than timestamp D2 are the call logics to be analyzed A1. Therefore, it can be determined that the logic operation to be judged that has a pre-operation relationship with the call logic A2 to be analyzed is the call logic A1 to be analyzed, and the call logic A2 that has a post-operation relationship with the call logic A1 to be analyzed is the call logic A2 to be analyzed.

[0079] Similarly, for the call logic A3 to be analyzed, the logic operations to be determined that have a preceding operation relationship with the call logic A3 to be analyzed are the call logic A1 to be analyzed and the call logic A2 to be analyzed, and the call logic A3 to be analyzed can be determined to have a following operation relationship with the call logic A2 to be analyzed.

[0080] Furthermore, for the call logic A4 to be analyzed, the logic operations to be determined that have a preceding operation relationship with the call logic A4 are the call logic A1, the call logic A2, and the call logic A3. There are also call logic operations to be analyzed whose following operation relationship with the call logic A4 cannot be determined.

[0081] Step 504: Match the dataset name and dataset call status of each dataset in the target dataset of each logic operation to be analyzed with the dataset name and dataset call status of each dataset in the target dataset of each logic operation to be judged, and determine the target call logic from each logic operation to be judged.

[0082] Specifically, the server first matches the dataset name of each dataset in the target dataset of each logic operation to be analyzed with the dataset name of each dataset in the target dataset of each logic operation to be judged. This determines that there are datasets with the same dataset name in the target datasets of the logic operations to be analyzed and the target datasets of the logic operations to be judged. The server then further determines the dataset call status when the dataset with the same dataset name is called by the logic operation to be analyzed, and the dataset call status when the dataset with the same dataset name is called by the logic operation to be judged. If both of the aforementioned dataset call statuses describe a successful call, the logic operation to be judged can be determined as the target call logic of the logic operation to be analyzed.

[0083] Therefore, after determining the target calling logic matched by each logic operation to be analyzed, the dataset information corresponding to the dataset jointly called by the logic operation to be analyzed and the target calling logic can also include a set of dependency relationships (Dependable Datas) that have calling logic dependencies with the calling logic. The dependency relationship set includes at least: a set of pre-dependencies and a set of post-dependencies. The set of pre-dependencies includes pre-dependent calling logic (dependableJobName) that jointly calls the dataset and has pre-dependent relationships. The set of post-dependencies includes post-dependent calling logic (blockableJobName) that jointly calls the dataset and has post-dependent relationships. Pre-dependencies are used to describe that the pre-dependent calling logic successfully calls the same dataset before another logic operation, while post-dependencies are used to describe that the logic operation successfully calls the same dataset before another dependent calling logic.

[0084] Based on this, since the logic operation to be analyzed and the target calling logic both invoke the same dataset, the dataset information matched for the logic operation to be analyzed is different from the dataset information matched for the target logic operation. Specifically, the dependency set of the dataset information matched for the logic operation to be analyzed includes a set of preceding dependencies, which includes preceding dependent calling logic that has a preceding dependency relationship with the logic operation to be analyzed, and the target calling logic included in the preceding dependent calling logic. Conversely, the dependency set of the dataset information matched for the target logic operation includes a set of following dependencies, which includes following dependent calling logic that has a following dependency relationship with the target logic operation, and the logic operation to be analyzed included in the following following dependent calling logic.

[0085] For example, based on the foregoing example, a reverse traversal of the call logic A1 to be analyzed cannot yield the corresponding logic operation to be determined with a preceding operation relationship. However, it can determine the call logics A2, A3, and A4 to be analyzed that have a following operation relationship with the call logic A1 to be analyzed. For the call logic A2 to be analyzed, the logic operation to be determined with a preceding operation relationship with the call logic A2 to be analyzed is the call logic A1 to be analyzed, and the call logic A2 to be analyzed is the call logic A2 to be analyzed. However, since both the call logics A1 and A2 to be analyzed call the dataset C1, and the dataset call status when the call logic A1 to the dataset C1, and the dataset call status when the call logic A2 to the dataset C1, are not both failure calls (False), i.e., both dataset call statuses are successful calls, only then can the server determine that the target call logic matched by the call logic A2 to be analyzed is the call logic A1 to be analyzed.

[0086] Therefore, the dataset information of dataset C1 matched by the call logic A2 to be analyzed includes a set of preceding dependencies, and the set of preceding dependencies includes at least the call logic A1 to be analyzed. Similarly, it can be seen that the dataset information of dataset C1 matched by the call logic A1 to be analyzed includes a set of subsequent dependencies, and the set of subsequent dependencies includes at least the call logic A2 to be analyzed.

[0087] To facilitate understanding of detailed dataset information, such as Figure 6As shown, the dataset information of the dataset called by the logic to be analyzed may include: dataset information 601, dataset information 602, dataset information 603, and dataset information 604. Each dataset information 601 to dataset information 604 includes the dataset name, the dataset call status of the dataset called by the logic to be analyzed, the data call status of the actual called data in the dataset called by the logic to be analyzed, and a dependency set. The dependency set specifically includes a set of pre-dependencies and a set of post-dependencies. The set of pre-dependencies specifically includes the name of the calling logic obtained by the pre-dependent calling logic that has a pre-dependency relationship with the calling logic to be analyzed, and the set of post-dependencies specifically includes the name of the calling logic obtained by the post-dependent calling logic that has a post-dependency relationship with the calling logic to be analyzed.

[0088] It is understood that the examples in this embodiment are for the purpose of understanding this solution, but should not be construed as specific limitations on this solution.

[0089] In this embodiment, by performing a reverse traversal based on the call time, the subsequent and preceding dependencies between the call logics to be analyzed can be obtained. This allows for the determination of the target call logic from each logic operation to be judged during the matching process. The determined target call logic not only ensures that it calls the same dataset, but also further describes the sequential call relationship between the two call logics on the same dataset, thereby improving the accuracy and completeness of the obtained call logic dependency relationship.

[0090] The following will detail the methods for collecting dataset information: In one embodiment, such as... Figure 7 As shown, the system obtains the target datasets invoked by multiple logic calls to be analyzed, as well as the dataset information corresponding to each dataset in each target dataset, including:

[0091] Step 702: Obtain the assembly and perform reflection parsing on the assembly to obtain multiple function opcodes.

[0092] Specifically, the assembly refers to the ECS assembly, which includes information about the relevant classes during the runtime of the business service. This information includes at least the methods, fields, constructors, and parent classes invoked during the runtime of the business service. The reflection resolution process specifically refers to reflection processing within the IL Runtime.

[0093] Specifically, the server obtains the assembly when the business service is running, and then performs reflection parsing on the methods, fields, constructors, and parent classes that the business service specifically calls in the assembly to obtain multiple function operation codes (Instruction Operation Code, Instruction OpCode) for the business service runtime. Each function operation code has a corresponding operation code type.

[0094] Step 704: Based on the opcode type corresponding to each function opcode, filter out the target function opcode from multiple function opcodes, and parse the target function opcode to obtain the corresponding logical operation information. The target function opcode matches the logic to be analyzed and called. The logical operation information includes at least the logical type description information of the logic to be analyzed and called that is matched by the target function opcode.

[0095] The target function opcode is a function opcode whose corresponding opcode type is a preset opcode type, which includes at least the `Call` type. The target function opcode's type information conforms to preset type information, which includes at least operand type and method name type. Therefore, the preset type information includes at least preset operand type and preset method name type. The preset operand types include at least `Entities.JobChunkExtensions` and `Entities.InternalCompilerInterface`, and the preset method name types include at least `ScheduleParallel`, `ScheduleSingle`, `ScheduleSingle`, `Schedule`, and `RunJobChunk`. The preset opcode type, preset operand type, and preset method name type can be flexibly configured based on actual situations and application requirements; this example should not be interpreted as a specific limitation.

[0096] Secondly, each function opcode corresponds to a specific call logic; therefore, the determined target function opcode specifically matches the call logic to be analyzed in this embodiment. Based on this, the target function opcode has corresponding logical operation information (Job Info), which includes at least: the logical type description information (JobTypeDefinition) of the call logic to be analyzed matched by the target function opcode. It can be understood that the logical operation information may also include: the call logic name (JobName) of the call logic to be analyzed, and the system name (SystemName) of the system to which the call logic to be analyzed belongs. The aforementioned call logic name specifically refers to the name field of the call logic to be analyzed, and the system name specifically refers to the name field of the system to which the call logic to be analyzed belongs.

[0097] Specifically, based on the opcode type corresponding to each function opcode, the server first selects the function opcodes that match the preset opcode type from multiple function opcodes as the target function opcodes. The target function opcodes match the call logic to be analyzed. Then, the server further parses the target function opcodes to obtain the logical operation information corresponding to the target function opcodes. That is, by parsing the parameters of the target function opcodes, the server obtains the call logic name and the logical type description information of the call logic to be analyzed. The server then fills the call logic name and the logical type description information of the call logic to be analyzed into the data structure corresponding to the logical operation information to obtain the logical operation information described in this embodiment.

[0098] For ease of understanding, such as Figure 8 As shown, the specific logical operation information for each logic to be analyzed and called under the system includes: logical operation information 801, logical operation information 802, logical operation information 803, and logical operation information 804. Logical operation information 801 to 804 each include the name of the corresponding logic to be analyzed, the description of the logic type, and the system name of the system to which it belongs. It can be understood that... Figure 8 The examples provided are for understanding this solution, but should not be construed as specific limitations of this solution.

[0099] Step 706: Perform reflection parsing on the logic type description information of the logic to be analyzed that matches each target function opcode, so as to filter out the target dataset called by the logic to be analyzed that matches each target function opcode.

[0100] Specifically, the server then performs reflection parsing on the logical operation information obtained from the previous step to further filter and obtain the target dataset called by the logic to be analyzed, which is matched by the opcode of each target function.

[0101] Step 708: Obtain the label information reflected from each target dataset to collect the dataset call status of each dataset in each target dataset, and parse each dataset in the target dataset to obtain the dataset name of each dataset.

[0102] Specifically, the server obtains the attribute information reflected from each target dataset, collects the current read / write attributes based on the attribute information, and records the read / write attributes to the dataset access status of each dataset in each target dataset. Thus, the dataset access status can accurately describe whether a dataset was successfully read or successfully written. Furthermore, the server further parses each dataset in the target dataset to obtain the dataset name for each dataset.

[0103] In this embodiment, the target opcode is obtained and filtered through reflection parsing, and then the target function opcode is further parsed to obtain the corresponding logical operation information. The logical operation information can accurately describe the detailed information of each call logic to be analyzed. Furthermore, by performing reflection parsing on the logical type description information in the logical operation information, the target dataset and the dataset information corresponding to the target dataset can be determined. Reflection parsing for data and information acquisition can ensure the accuracy of information processing, thereby providing a complete and reliable data basis for the subsequent determination of logical relationships, and further improving the accuracy of the determined call logic dependency relationship.

[0104] The following details the specific implementation method for filtering out the target function opcode from multiple function opcodes: In one embodiment, such as Figure 9 As shown, based on the opcode type corresponding to each function opcode, the target function opcode is obtained by filtering from multiple function opcodes, including:

[0105] Step 902: The function operation code whose corresponding operation code type is a preset operation code type is determined as a candidate function operation code.

[0106] The preset opcode types include at least the Call type. These preset opcode types can be flexibly configured based on actual circumstances and application requirements; the example here should not be interpreted as a specific limitation. Specifically, the server first determines the opcode type corresponding to each function opcode, and then filters candidate function opcodes whose opcode type matches the preset opcode type from among the function opcodes. That is, the server matches the opcode type corresponding to each function opcode with the Call type, and determines the function opcodes whose opcode type is specifically Call as candidate function opcodes.

[0107] Step 904: Parse the type information of each candidate function opcode. The type information includes at least the operand type and the method name type.

[0108] The type information includes at least the operand type and the method name type. Specifically, the server further parses the operand type and method name type of each candidate function opcode determined in the previous step to facilitate subsequent filtering of operand type and method name type.

[0109] Step 906: Select the candidate function operation codes whose type information matches the preset type information as the target function operation codes.

[0110] Since the type information includes at least operand type and method name type, the preset type information includes at least the preset operand type and preset method name type. The preset operand types include at least: Entities.JobChunkExtensions and Entities.InternalCompilerInterface, and the preset method name types include at least: ScheduleParallel, ScheduleSingle, ScheduleSingle, Schedule, and RunJobChunk. The preset operand type and preset method name type can be flexibly configured based on actual situations and application requirements; the example here should not be interpreted as a specific limitation.

[0111] Specifically, the server filters each candidate function opcode based on preset type information and the type information of each candidate function opcode. That is, it filters the operand type and method name type from each candidate function opcode to obtain the target function opcode that both conform to the preset operand type and preset method name type.

[0112] For example, the type information of candidate function opcode E1 includes operand type F1 and method name type G1; the type information of candidate function opcode E2 includes operand type F2 and method name type G2; and the type information of candidate function opcode E3 includes operand type F3 and method name type G3. The preset operand types in the preset type information specifically include operand type F1 and operand type F2, and the preset method name types specifically include method name type G2 and method name type G3. Therefore, it can be seen that operand type F1 of candidate function opcode E1 and operand type F2 of candidate function opcode E2 conform to the preset operand types, while method name type G2 of candidate function opcode E2 and method name type G3 of candidate function opcode E3 conform to the preset method name types. Since both operand type and method name type must conform to the preset type information, it can be determined that candidate function opcode E2 is specifically the target function opcode.

[0113] It is understood that the examples in this embodiment are for the purpose of understanding this solution, but should not be construed as specific limitations on this solution.

[0114] In this embodiment, by matching the opcode type corresponding to each function opcode with the preset opcode type, candidate function opcodes that are of the preset opcode type are first screened out. Then, the operand type and method name type of the candidate function opcodes are further considered, thereby ensuring that the target function opcodes obtained by screening not only meet the requirements of the preset opcode type, but also meet the requirements of parsing the preset operand type and preset method name type, thereby ensuring the reliability and accuracy of the determined target function opcodes.

[0115] The following details the specific implementation method for obtaining the target dataset through reflection parsing: In one embodiment, as follows... Figure 10 As shown, the logical type description information of the call logic matched by each target function opcode is processed by reflection parsing to filter out the target dataset called by the call logic matched by each target function opcode, including:

[0116] Step 1002: Perform reflection parsing on the description information of each logical type to obtain the set of fields of the logic to be analyzed and called that matches the operation code of each target function. The set of fields includes multiple logical operation fields. Each logical operation field has a corresponding data call interface type and is used to call the dataset.

[0117] Each invocation logic's logical type description information includes at least: a method set and a field set. The field set includes multiple logical operation fields, each with a corresponding data invocation interface type, and each logical operation field is specifically used to invoke the dataset. The method set includes multiple data invocation methods, and each data invocation method has a corresponding data invocation method type.

[0118] Specifically, the server performs reflection parsing on the description information of each logical type, that is, it obtains the set of fields of the target function opcode that matches the logic to be analyzed from the description information of the logical type of each logic to be analyzed through reflection parsing.

[0119] Step 1004: From each set of fields, select the target logic operation field that matches the target function operation code to be analyzed and called, and the data call interface type corresponding to the target logic operation field conforms to the preset data call interface type.

[0120] Specifically, the data call interface type corresponding to the target logical operation field conforms to the preset data call interface type, and the preset data call interface type is at least: Entities.IComponentData or IBufferElementData. It is understood that the preset data call interface type can be flexibly configured based on actual circumstances and application requirements; the example here should not be interpreted as a specific limitation.

[0121] Specifically, since each field set includes multiple logical operation fields, and each logical operation field has a corresponding data call interface type, the server filters and selects the data call interface type corresponding to each logical operation field in each field set based on a preset data call interface type. In other words, the server specifically determines the logical operation fields whose corresponding data call interface type is a preset data call interface type as the target logical operation fields. The target logical operation field can be: a set of logical operation fields consisting of one or more logical operation fields.

[0122] For example, after performing reflection parsing on the logical type description information of the call logic matched by the target function opcode, a set of fields for the call logic to be analyzed is obtained. This set of fields specifically includes logical operation fields H1, H2, and H3, and logical operation field H1 corresponds to data call interface type I1, logical operation field H2 corresponds to data call interface type I2, and logical operation field H3 corresponds to data call interface type I3. If the preset data call interface types are data call interface type I1 and data call interface type I3, then the target logical operation fields can be determined to specifically include logical operation fields H1 and H3. It is understood that the examples in this embodiment are for understanding this solution and should not be construed as specific limitations on this solution.

[0123] Step 1006: Parse the target logical operation fields to determine each target dataset.

[0124] Specifically, the server parses each target logical operation field to determine each target dataset. Since each logical operation field is specifically used to call a dataset, after the server determines the target logical operation field that conforms to the preset data call interface type, it can parse the target logical operation field to determine which dataset the target logical operation field is specifically used to call, and thus determine that the dataset called by the target logical operation field is the corresponding target dataset.

[0125] In this embodiment, the set of fields used by each logic to be analyzed when calling the dataset during operation is determined by reflection parsing. Then, by matching and filtering the data call interface type of each logic operation field in the set of fields, it is ensured that the determined target logic operation fields conform to the configured preset data call interface type. Thus, the target dataset obtained by parsing the target logic operation fields that meet the configuration requirements can more accurately describe the dataset specifically called by the logic to be analyzed during operation, thereby ensuring the authenticity and reliability of the determined target dataset.

[0126] It is understandable that the foregoing embodiments provide a method for two different calling logics to call the same dataset. However, in practical applications, there may be instances where two different calling logics call different data within the same dataset, meaning that the two different calling logics do not actually call the same data. Therefore, to ensure the reliability of the creation of calling logic dependencies, the foregoing steps are further optimized and improved from a more granular data dimension:

[0127] In one embodiment, such as Figure 11 As shown, the dataset information also includes: actual call data information in the dataset, which includes at least: actual call data in the dataset that is called by the call logic to be analyzed, and the data call status of the actual call data being called by the call logic to be analyzed.

[0128] The actual call data information includes at least: the actual call data in the dataset that is called by the call logic to be analyzed, and the data call status of the actual call data when called by the call logic to be analyzed. The actual call data is the data used by the call logic to be analyzed to call the dataset. For example, dataset C1 specifically includes data J1, J2, J3, and J4, and the call logic to be analyzed A1 calls data J1, J2, and J3 in dataset C1. Therefore, it can be determined that the actual call data in dataset C1 for the call logic to be analyzed A1 is: data J1, data J2, and data J3.

[0129] Secondly, the data call status is similar to the dataset call status. The data call status is used to describe a more specific data-related status. That is, the data call status describes whether the actual data in the dataset was successfully read or written when it was called by the call logic to be analyzed.

[0130] Based on this, the dataset name and dataset call status of each dataset in each target dataset are matched to determine the target call logic that matches each call logic to be analyzed, including:

[0131] Step 1102: Match the dataset name and dataset call status of each dataset in each target dataset to determine the candidate call logic that matches each call logic to be analyzed.

[0132] Specifically, the server first matches the dataset name of each dataset in the target dataset of the call logic to be analyzed. If there are datasets with the same dataset name in the target datasets of two call logics to be analyzed, the server then determines the dataset call status of the two call logics to the datasets with the same dataset name. When the dataset call status is used to describe a successful call, it can be determined that the two call logics to be analyzed are each other's candidate call logics.

[0133] Furthermore, if, as in the aforementioned embodiments, the call times corresponding to each dataset are considered by each logic to be analyzed, then the server first determines the call time corresponding to each logic to be analyzed calling each dataset in the target dataset. Then, based on the call times corresponding to each dataset, it iterates through other logic operations whose call times precede the logic operation to be analyzed, to determine the logic operations to be judged whose call times precede the logic operation to be analyzed. Finally, the server considers candidate call logics that have a preceding operation relationship with each logic operation to be analyzed. The specific implementation is similar to that in the aforementioned embodiments and will not be repeated here.

[0134] Step 1104: Match the actual call data information of each dataset in the target dataset of each call logic to be analyzed with the actual call data information of each dataset in the target dataset of the candidate call logic. Determine the target call logic matched by each call logic to be analyzed from the candidate call logic. The call logic to be analyzed and the matched target call logic call the same actual call data, and the data call status is successful call.

[0135] Specifically, the analysis of the calling logic and the matching target calling logic referencing the same actual called data, and the data call status is "successful." Referring to the same actual called data can mean either that the calling logic to be analyzed and the target calling logic call the same actual called data from the same dataset, or that there is overlap in the actual called data from the same dataset. For example, dataset C1 includes data J1, J2, J3, and J4. The calling logic to be analyzed, A1, calls data J1, J2, and J3 from dataset C1, and the target calling logic also calls data J1, J2, and J3 from dataset C1. Therefore, it can be determined that the calling logic to be analyzed, A1, and the target calling logic call the same actual called data. Alternatively, the target calling logic calls data J2 and J3 from dataset C1. Although the target calling logic does not call data J1, the called data J2 and J3 overlap with those of the calling logic to be analyzed, A1, and the target calling logic still call the same actual called data.

[0136] It is understood that the examples in this embodiment are for the purpose of understanding this solution, but should not be construed as specific limitations on this solution.

[0137] Specifically, after the server filters and obtains candidate call logics, since it can be determined that the candidate call logics and the call logic to be analyzed have successfully invoked the same dataset, it is necessary to further determine whether the candidate call logics and the call logic to be analyzed have successfully invoked the same data in the same dataset. That is, the server matches the actual call data information of the call logic to be analyzed with the actual call data information of the candidate call logics to determine the target call logic matched by each call logic to be analyzed.

[0138] The server first extracts the dataset information of the datasets where the call logic to be analyzed and the candidate call logic have been successfully called together. Then, it obtains the actual call data of the actual call data information in the dataset information of the call logic to be analyzed and the actual call data of the actual call data information in the dataset information of the candidate call logic. Then, it matches whether the actual call data of the call logic to be analyzed is consistent with the actual call data of the candidate call logic. If the actual call data is consistent, or if there is some overlap in the actual call data, it is then determined whether the consistent or partially overlapping actual call data has been successfully called. If so, it can be determined that the candidate call logic is the target call logic matched by the call logic to be analyzed.

[0139] In this embodiment, the dataset name and dataset call status in each dataset information are first matched to obtain candidate call logics that have successfully called the same dataset as the call logic to be analyzed. The actual call data information between the call logic to be analyzed and the candidate call logic is determined by matching, thereby ensuring that the determined target call logic and the call logic to be analyzed call the same data in the same dataset. Filtering from a more granular data dimension can ensure that the obtained target call logic is more accurate and real, further improving the reliability and accuracy of the subsequent creation of call logic dependencies.

[0140] The following will describe in detail how to collect actual call data and the data call status: In one embodiment, such as Figure 12 As shown, methods for determining dependencies also include:

[0141] Step 1202: Perform reflection parsing on the logical type description information of each to obtain the set of methods for the call logic to be analyzed that match the opcode of each target function. The set of methods includes multiple data call methods, and each data call method has a corresponding data call method type.

[0142] The method set includes multiple data call methods, each with a corresponding data call method type. Specifically, the server performs reflection parsing on the description information of each logical type, that is, it obtains the set of methods matching the target function opcode of the logic to be analyzed from the logical type description information of each logic to be analyzed through reflection parsing.

[0143] Step 1204: From each set of methods, select the candidate data call method that matches the call logic to be analyzed for each target function opcode. The data call method type of the data call method is the candidate logic operation method of the preset data call method type.

[0144] In this example, the data call method type for the candidate logical operation method is a preset data call method type, and the preset data call method type is Execute. It is understood that the preset data call method type can be flexibly configured based on actual circumstances and application requirements; this example should not be interpreted as a specific limitation.

[0145] Specifically, the method set includes multiple data call methods, and each data call method has a corresponding data call method type. Therefore, the server filters and selects the data call method type corresponding to each data call method in each method set based on a preset data call method type. In other words, the server specifically determines the data call methods whose corresponding data call method type is a preset data call method type as candidate data call methods. Furthermore, candidate data call methods can be: a set of data call methods consisting of one or more data call methods.

[0146] Step 1206: Analyze the method execution instructions of each candidate logical operation method, determine the actual call data and data call status of each candidate logical operation method, and determine the dataset to which the actual call data of the candidate logical operation method belongs.

[0147] The method execution instruction can be either a Store instruction or a Load instruction. The Store instruction describes writing data, while the Load instruction describes reading data. Specifically, the server analyzes the method execution instructions of each candidate logical operation method to determine the actual data being called. Furthermore, it determines the data call status by judging the specific instruction type of the method execution instruction. That is, if the method execution instruction is a Store instruction and executes successfully, it indicates a successful write operation to the actual data being called. Similarly, if the method execution instruction is a Load instruction and executes successfully, it indicates a successful read operation to the actual data being called.

[0148] Furthermore, the server determines the dataset to which the actual data invoked by the candidate logical operation method belongs by using the operand types of the method execution instructions. That is, it matches the operand types of the method execution instructions with the operand types of each dataset, identifying the dataset whose operand types match as the dataset to which the method execution instructions belong. The identified actual invoked data and its invocation status can be recorded in the dataset information of the dataset to which the actual invoked data belongs. It is understandable that the server can also record information such as the actual usage rate of the invoked data during runtime; this is not limited here.

[0149] In this embodiment, the set of methods used by each logic call to invoke data during operation is determined by reflection parsing. Then, the data invocation method type of each logic operation method in the method set is matched and filtered to ensure that the determined candidate logic operation methods conform to the configured preset data invocation method type. Thus, the method execution instructions of the candidate logic operation methods that meet the configuration requirements are analyzed to obtain the actual invocation data information and the dataset to which the actual invocation data belongs. The obtained actual invocation data information can be recorded in the dataset information of the dataset to which the actual invocation data belongs to ensure the reliability and integrity of the dataset information.

[0150] In practical applications, it is possible Figure 13 The code fields in the XML file shown implement the method for determining dependencies in the aforementioned embodiments. Furthermore, in various application scenarios, after obtaining the call logic dependencies between call logics, runtime optimization, runtime archiving, or comparison before and after runtime optimization can be performed based on these dependencies. Considering that a view approach can more accurately display the call logic dependencies between call logics, this embodiment also provides a method for generating a dependency view based on the call logic dependencies between call logics, specifically as follows... Figure 14 As shown.

[0151] First, the assembly is imported. The method described in the preceding embodiments is used to generate call logic dependencies between the various call logics. Then, a dependency view is generated based on these dependencies. This dependency view includes at least the call logic nodes corresponding to each call logic, and call logic dependency edges between call logic nodes with dependency relationships. The dependency view may also include the corresponding system nodes of the system to which each call logic belongs. Next, the generated dependency view is displayed on a device with a display module, allowing administrators to preview nodes and analyze the call logic nodes and their dependency edges to obtain the desired results. After the analysis is complete, the generated dependency view can be stored. When a comparative analysis is needed again, the stored historical dependency view can be imported to obtain comparison results or optimization results. It is understood that the above example is only for understanding this solution and should not be construed as a specific limitation.

[0152] The following describes in detail how to generate and apply a dependency view after creating the dependency relationships between call logics: In one embodiment, as... Figure 15As shown, after creating the calling logic dependencies between each calling logic to be analyzed and the target calling logic, the method for determining the dependencies also includes:

[0153] Step 1502: Generate a dependency view based on the call logic dependency relationship between each call logic to be analyzed and the target call logic. The dependency view includes the call logic nodes corresponding to each call logic.

[0154] The dependency view includes the call logic nodes corresponding to each call logic, as well as call logic dependency edges between call logic nodes that have call logic dependencies. Furthermore, the dependency view may also include the corresponding system nodes of the system to which each call logic belongs. For example, based on the call logic dependency between the call logic to be analyzed and the target call logic, then in the dependency view, there are call logic dependency edges between the call logic node corresponding to the call logic to be analyzed and the call logic node corresponding to the target call logic. For ease of understanding, as shown below... Figure 16 As shown, the dependency view can include system node 1601, system node 1602, system node 1603, and system node 1604 corresponding to the system. System node 1601 includes call logic nodes 1605 and 1606 corresponding to the call logic of that system. Similarly, system node 1602 includes call logic nodes 1607, 1609, and 1609 corresponding to the call logic of that system. System node 1603 includes call logic node 1610 corresponding to the call logic of that system. System node 1604 includes call logic nodes 1611 and 1612 corresponding to the call logic of that system.

[0155] The datasets and data within the datasets under different calling logic nodes are all datasets and data invoked by the calling logic corresponding to the called logic node, and are obtained through methods such as... Figure 16 As shown in the dependency view, there is a call logic dependency edge between logical node 1606 and logical node 1608. Therefore, there is a call logic dependency relationship between the call logic corresponding to logical node 1606 and the call logic corresponding to logical node 1608.

[0156] Similarly, it can be seen that there is a call logic dependency edge between logical node 1608 and logical node 1609, indicating that there is a call logic dependency relationship between the call logic corresponding to logical node 1608 and the call logic corresponding to logical node 1609. There is also a call logic dependency edge between logical node 1608 and logical node 1610, indicating that there is a call logic dependency relationship between the call logic corresponding to logical node 1608 and the call logic corresponding to logical node 1610. Furthermore, there is a call logic dependency edge between logical node 1610 and logical node 1612, indicating that there is a call logic dependency relationship between the call logic corresponding to logical node 1610 and the call logic corresponding to logical node 1612. It is understood that the examples in this embodiment are for understanding the present solution and should not be construed as specific limitations on the present solution.

[0157] Specifically, the server generates a dependency view based on the call logic dependencies between each call logic to be analyzed and the target call logic. That is, the server first creates a logic node corresponding to each call logic, and then connects the logic nodes corresponding to the call logics with call logic dependencies through the call logic dependencies between the call logics to be analyzed and the target call logic, thereby generating the dependency view. Furthermore, the server can also create system nodes corresponding to the system, and divide the system according to the system to which each call logic belongs. For a more accurate and clear view display, the server can also create dataset nodes corresponding to the datasets called by each call logic, as well as data nodes corresponding to the actual data called within the datasets.

[0158] Furthermore, as can be seen from the foregoing embodiments, the calling logic dependency relationship specifically includes the preceding dependency relationship and the following dependency relationship. Therefore, the order of each node in the dependency relationship view can also be sorted by connecting the preceding dependency relationship and the following dependency relationship.

[0159] Step 1504: Display the dependency view and analyze the dependency view to obtain the target result, which includes at least: archived results or optimized comparison results.

[0160] The target results include at least: archiving results or optimization comparison results. Archiving results are the results obtained from analysis when the business requirement is to archive, while optimization comparison results are the results obtained from analysis when the business requirement is to optimize. Optimization comparison results need to be obtained through analysis and comparison of at least two dependency views.

[0161] Specifically, the server can display a dependency view through a device with a display arm, allowing administrators to analyze the displayed dependency view to obtain the target results. Therefore, the dependency view can display information including each system node and logical node, as well as the dataset nodes and data nodes called by the calling logic corresponding to each logical node, and the ordering connections of pre-dependencies and post-dependencies.

[0162] Taking an optimization comparison scenario as an example, the server can first retrieve the historical dependency view stored from the previous run, and then generate the current dependency view after optimization. By comparing the displayed historical dependency view with the current dependency view, it's possible to analyze whether dependency issues have been optimized, thus obtaining optimization comparison results. Furthermore, in practical applications, the server can continue to save the current dependency view as the historical dependency view for the next run, for use in archiving or optimization comparison scenarios.

[0163] For ease of understanding, when displaying the dependency view, such as Figure 17 As shown, after an operation is performed on calling node 1701, the dependency view can also display calling nodes that have pre-dependencies and post-dependencies with calling node 1701. That is, the calling logic corresponding to calling node 1702 has a pre-dependency with the calling logic corresponding to calling node 1701, and the calling logic corresponding to calling node 1703 has a post-dependency with the calling logic corresponding to calling node 1701. At the same time, the dataset node and data node called by calling node 1701 can also be displayed.

[0164] In this embodiment, generating a dependency view can also display the connection relationships between nodes in more detail. This allows for efficient analysis of the overall and local dependencies at runtime by analyzing the connection edges between nodes and the dataset nodes and data nodes that each node depends on, thereby obtaining the target results more accurately and efficiently.

[0165] Based on the detailed description of the foregoing embodiments, the complete process of the dependency determination method in the embodiments of this application will be described below. In one embodiment, such as... Figure 18 As shown, a method for determining dependencies is provided, which can be applied to... Figure 2 The method is illustrated using server 204 as an example. It is understood that this method can also be applied to terminal 202, and to a system including terminal 202 and server 204, and is implemented through the interaction between terminal 202 and server 204. In this embodiment, the method includes the following steps:

[0166] Step 1801: Obtain the assembly and perform reflection parsing on the assembly to obtain multiple function opcodes.

[0167] Specifically, the assembly refers to the ECS assembly, which includes information about the relevant classes during the runtime of the business service. This information includes at least the methods, fields, constructors, and parent classes invoked during the runtime of the business service. The reflection resolution process specifically refers to reflection processing within the IL Runtime.

[0168] Specifically, the server obtains the assembly when the business service is running, and then performs reflection parsing on the methods, fields, constructors, and parent classes that the business service specifically calls in the assembly to obtain multiple function opcodes for the business service runtime. Each function opcode has a corresponding opcode type.

[0169] Step 1802: Determine the function operation code whose corresponding operation code type is a preset operation code type as a candidate function operation code.

[0170] The preset opcode types include at least the Call type. These preset opcode types can be flexibly configured based on actual circumstances and application requirements; the example here should not be interpreted as a specific limitation. Specifically, the server first determines the opcode type corresponding to each function opcode, and then filters candidate function opcodes whose opcode type matches the preset opcode type from among the function opcodes. That is, the server matches the opcode type corresponding to each function opcode with the Call type, and determines the function opcodes whose opcode type is specifically Call as candidate function opcodes.

[0171] Step 1803: Parse the type information of each candidate function opcode. The type information includes at least the operand type and the method name type.

[0172] The type information includes at least the operand type and the method name type. Specifically, the server further parses the operand type and method name type of each candidate function opcode determined in the previous step to facilitate subsequent filtering of operand type and method name type.

[0173] Step 1804: Select the candidate function operation codes whose type information matches the preset type information as the target function operation codes.

[0174] Since the type information includes at least operand type and method name type, the preset type information includes at least the preset operand type and preset method name type. The preset operand types include at least: Entities.JobChunkExtensions and Entities.InternalCompilerInterface, and the preset method name types include at least: ScheduleParallel, ScheduleSingle, ScheduleSingle, Schedule, and RunJobChunk. The preset operand type and preset method name type can be flexibly configured based on actual situations and application requirements; the example here should not be interpreted as a specific limitation.

[0175] Specifically, the server filters each candidate function opcode based on preset type information and the type information of each candidate function opcode. That is, it filters the operand type and method name type from each candidate function opcode to obtain the target function opcode that both conform to the preset operand type and preset method name type.

[0176] Step 1805: Perform reflection parsing on the description information of each logical type to obtain the set of fields of the call logic to be analyzed that match the opcode of each target function.

[0177] Each invocation logic's logical type description information includes at least: a method set and a field set. The field set includes multiple logical operation fields, each with a corresponding data invocation interface type, and each logical operation field is specifically used to invoke the dataset. The method set includes multiple data invocation methods, and each data invocation method has a corresponding data invocation method type.

[0178] Specifically, the server performs reflection parsing on the description information of each logical type, that is, it obtains the set of fields of the target function opcode that matches the logic to be analyzed from the description information of the logical type of each logic to be analyzed through reflection parsing.

[0179] Step 1806: From each set of fields, select the target logic operation field that matches the logic to be analyzed and called by each target function operation code.

[0180] Specifically, the data call interface type corresponding to the target logical operation field conforms to the preset data call interface type, and the preset data call interface type is at least: Entities.IComponentData or IBufferElementData. It is understood that the preset data call interface type can be flexibly configured based on actual circumstances and application requirements; the example here should not be interpreted as a specific limitation.

[0181] Specifically, since each field set includes multiple logical operation fields, and each logical operation field has a corresponding data call interface type, the server filters and selects the data call interface type corresponding to each logical operation field in each field set based on a preset data call interface type. In other words, the server specifically determines the logical operation fields whose corresponding data call interface type is a preset data call interface type as the target logical operation fields. The target logical operation field can be: a set of logical operation fields consisting of one or more logical operation fields.

[0182] Step 1807: Parse each target logic operation field to determine the target dataset called by the logic to be analyzed, which is matched by each target function opcode.

[0183] Specifically, each target logical operation field is parsed to determine the target dataset invoked by the logic being analyzed, matching the opcode of each target function. Since each logical operation field is specifically used to invoke a dataset, after the server determines the target logical operation field that conforms to the preset data invocation interface type, it can parse the target logical operation field to determine which dataset the target logical operation field is specifically used to invoke, and thus determine that the dataset invoked by the target logical operation field is the corresponding target dataset.

[0184] Step 1808: Perform reflection parsing on the logical type description information of each to obtain the set of methods that match the call logic to be analyzed for each target function opcode.

[0185] The method set includes multiple data call methods, each with a corresponding data call method type. Specifically, the server performs reflection parsing on the description information of each logical type, that is, it obtains the set of methods matching the target function opcode of the logic to be analyzed from the logical type description information of each logic to be analyzed through reflection parsing.

[0186] Step 1809: Select candidate data call methods from the set of methods that match the call logic to be analyzed for each target function opcode.

[0187] In this example, the data call method type for the candidate logical operation method is a preset data call method type, and the preset data call method type is Execute. It is understood that the preset data call method type can be flexibly configured based on actual circumstances and application requirements; this example should not be interpreted as a specific limitation.

[0188] Specifically, the method set includes multiple data call methods, and each data call method has a corresponding data call method type. Therefore, the server filters and selects the data call method type corresponding to each data call method in each method set based on a preset data call method type. In other words, the server specifically determines the data call methods whose corresponding data call method type is a preset data call method type as candidate data call methods. Furthermore, candidate data call methods can be: a set of data call methods consisting of one or more data call methods.

[0189] Step 1810: Analyze the method execution instructions of each candidate logical operation method, determine the actual call data and data call status of each candidate logical operation method, and determine the dataset to which the actual call data of the candidate logical operation method belongs.

[0190] The method execution instruction can be either a Store instruction or a Load instruction. The Store instruction describes writing data, while the Load instruction describes reading data. Specifically, the server analyzes the method execution instructions of each candidate logical operation method to determine the actual data being called. Furthermore, it determines the data call status by judging the specific instruction type of the method execution instruction. That is, if the method execution instruction is a Store instruction and executes successfully, it indicates a successful write operation to the actual data being called. Similarly, if the method execution instruction is a Load instruction and executes successfully, it indicates a successful read operation to the actual data being called.

[0191] Furthermore, the server determines the dataset to which the actual data invoked by the candidate logical operation method belongs by using the operand types of the method execution instructions. That is, it matches the operand types of the method execution instructions with the operand types of each dataset, identifying the dataset whose operand types match as the dataset to which the method execution instructions belong. The identified actual invoked data and its invocation status can be recorded in the dataset information of the dataset to which the actual invoked data belongs. It is understandable that the server can also record information such as the actual usage rate of the invoked data during runtime; this is not limited here.

[0192] Step 1811: Match the actual call data information of each dataset in the target dataset of each call logic to be analyzed with the actual call data information of each dataset in the target dataset of the candidate call logic, and determine the target call logic matched by each call logic to be analyzed from the candidate call logic.

[0193] Specifically, the call logic to be analyzed and the matching target call logic call the same actual call data, and the data call status is successful. Calling the same actual call data can mean either that the call logic to be analyzed and the target call logic call the same actual call data in the same dataset, or that the call logic to be analyzed and the target call logic call the same actual call data in the same dataset overlaps.

[0194] Specifically, after the server filters and obtains candidate call logics, since it can be determined that the candidate call logics and the call logic to be analyzed have successfully invoked the same dataset, it is necessary to further determine whether the candidate call logics and the call logic to be analyzed have successfully invoked the same data in the same dataset. That is, the server matches the actual call data information of the call logic to be analyzed with the actual call data information of the candidate call logics to determine the target call logic matched by each call logic to be analyzed.

[0195] The server first extracts the dataset information of the datasets where the call logic to be analyzed and the candidate call logic have been successfully called together. Then, it obtains the actual call data of the actual call data information in the dataset information of the call logic to be analyzed and the actual call data of the actual call data information in the dataset information of the candidate call logic. Then, it matches whether the actual call data of the call logic to be analyzed is consistent with the actual call data of the candidate call logic. If the actual call data is consistent, or if there is some overlap in the actual call data, it is then determined whether the consistent or partially overlapping actual call data has been successfully called. If so, it can be determined that the candidate call logic is the target call logic matched by the call logic to be analyzed.

[0196] Step 1812: Create the calling logic dependency relationship between each calling logic to be analyzed and the target calling logic.

[0197] The call logic dependency relationship describes whether the call logic to be analyzed and the target call logic successfully invoke the same dataset. Specifically, since the dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and both the dataset invocation status of the target call logic and the dataset invocation status of the matched call logic to be analyzed are successful invocations, meaning that the matched call logic to be analyzed and the target call logic successfully invoked the same dataset, a corresponding call logic dependency relationship can be created between each call logic to be analyzed and the matched target call logic. This call logic dependency relationship describes whether the call logic to be analyzed and the target call logic successfully invoked the same dataset.

[0198] Step 1813: Generate a dependency view based on the dependency relationship between each call logic to be analyzed and the target call logic.

[0199] The dependency view includes the call logic nodes corresponding to each call logic, as well as call logic dependency edges between call logic nodes that have call logic dependencies. Furthermore, the dependency view may also include the system nodes corresponding to the systems to which each call logic belongs. For example, based on the call logic dependency between the call logic to be analyzed and the target call logic, in the dependency view, there are call logic dependency edges between the call logic node corresponding to the call logic to be analyzed and the call logic node corresponding to the target call logic.

[0200] Specifically, the server generates a dependency view based on the call logic dependencies between each call logic to be analyzed and the target call logic. That is, the server first creates a logic node corresponding to each call logic, and then connects the logic nodes corresponding to the call logics with call logic dependencies through the call logic dependencies between the call logics to be analyzed and the target call logic, thereby generating the dependency view. Furthermore, the server can also create system nodes corresponding to the system, and divide the system according to the system to which each call logic belongs. For a more accurate and clear view display, the server can also create dataset nodes corresponding to the datasets called by each call logic, as well as data nodes corresponding to the actual data called within the datasets.

[0201] Furthermore, as can be seen from the foregoing embodiments, the calling logic dependency relationship specifically includes the preceding dependency relationship and the following dependency relationship. Therefore, the order of each node in the dependency relationship view can also be sorted by connecting the preceding dependency relationship and the following dependency relationship.

[0202] Step 1814: Display the dependency view and analyze the dependency view to obtain the target result.

[0203] The target results include at least: archiving results or optimization comparison results. Archiving results are the results obtained from analysis when the business requirement is to archive, while optimization comparison results are the results obtained from analysis when the business requirement is to optimize. Optimization comparison results need to be obtained through analysis and comparison of at least two dependency views.

[0204] Specifically, the server can display a dependency view through a device with a display arm, allowing administrators to analyze the displayed dependency view to obtain the target results. Therefore, the dependency view can display information including each system node and logical node, as well as the dataset nodes and data nodes called by the calling logic corresponding to each logical node, and the ordering connections of pre-dependencies and post-dependencies.

[0205] It should be understood that the specific implementation methods of steps 1801 to 1814 are similar to those of the aforementioned embodiments, and will not be repeated here.

[0206] It should be understood that although the steps in the flowcharts of the embodiments described above 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 flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0207] Based on the same inventive concept, this application also provides a dependency determination apparatus for implementing the dependency determination method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations of one or more dependency determination apparatus embodiments provided below can be found in the limitations of the dependency determination method described above, and will not be repeated here.

[0208] In one embodiment, such as Figure 19 As shown, a dependency determination device is provided, comprising: a data acquisition module 1902, a call logic matching module 1904, and a dependency creation module 1906, wherein:

[0209] The data acquisition module 1902 is used to acquire the target datasets called by multiple analysis logics respectively, as well as the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset called by the analysis logic.

[0210] Call logic matching module 1904 is used to match the dataset name and dataset call status of each dataset in each target dataset to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and the dataset call status of the target call logic and the dataset call status of the matched call logic to be analyzed are both successful call.

[0211] The dependency creation module 1906 is used to create call logic dependencies between each call logic to be analyzed and the target call logic. The call logic dependency is used to describe that the call logic to be analyzed and the target call logic successfully call the same dataset.

[0212] In one embodiment, the logic matching module 1904 is specifically used to perform a reverse traversal based on the call times corresponding to each dataset of each logic to be analyzed, to determine the logic operations to be judged that have a preceding operation relationship with each logic operation to be analyzed. The reverse traversal describes: traversing other logic operations to be analyzed whose call times precede the logic operations to be analyzed, and the preceding operation relationship describes: the call time of the logic operation to be judged precedes the logic operation to be analyzed. The module matches the dataset name and dataset call status of each dataset in the target dataset of each logic operation to be analyzed with the dataset name and dataset call status of each dataset in the target dataset of each logic operation to be judged, and determines the target call logic from each logic operation to be judged.

[0213] In one embodiment, the dataset information matched by the logic operation to be analyzed also includes a set of prerequisite dependencies. The set of prerequisite dependencies includes prerequisite dependency call logic that has a prerequisite dependency relationship with the logic operation to be analyzed. The prerequisite dependency call logic includes the target call logic. The prerequisite dependency relationship is used to describe that the prerequisite dependency call logic successfully calls the same dataset before the logic operation to be analyzed.

[0214] The dataset information matched by the target logical operation also includes a set of post-dependencies. The set of post-dependencies includes post-dependent call logic that has a post-dependent relationship with the target logical operation. The post-dependent call logic includes the call logic to be analyzed. The post-dependencies are used to describe that the target logical operation successfully calls the same dataset before the post-dependent call logic.

[0215] In one embodiment, the data acquisition module 1902 is specifically used to acquire a program assembly and perform reflection parsing on the program assembly to obtain multiple function opcodes; based on the opcode type corresponding to each function opcode, select target function opcodes from the multiple function opcodes, and parse the target function opcodes to obtain the corresponding logical operation information. The target function opcodes match the call logic to be analyzed, and the logical operation information includes at least: the logical type description information of the call logic to be analyzed matched by the target function opcode; perform reflection parsing on the logical type description information of the call logic to be analyzed matched by each target function opcode to select the target datasets called by the call logic to be analyzed matched by each target function opcode; acquire the label information reflected from each target dataset to collect the dataset call status of each dataset in each target dataset, and parse each dataset in the target dataset to obtain the dataset name of each dataset.

[0216] In one embodiment, the data acquisition module 1902 is specifically used to determine the function opcodes whose corresponding opcode type is a preset opcode type as candidate function opcodes; parse the type information of each candidate function opcode, the type information including at least: operand type and method name type; and determine the candidate function opcodes whose type information matches the preset type information as target function opcodes.

[0217] In one embodiment, the data acquisition module 1902 is specifically used to perform reflection parsing processing on the description information of each logical type to obtain the field set of the call logic to be analyzed matched by each target function opcode. The field set includes multiple logical operation fields, each logical operation field has a corresponding data call interface type, and the logical operation field is used to call the dataset. From each field set, the target logical operation field of the call logic to be analyzed matched by each target function opcode is selected, and the data call interface type corresponding to the target logical operation field conforms to the preset data call interface type. Each target logical operation field is parsed to determine each target dataset.

[0218] In one embodiment, the dataset information further includes: actual call data information in the dataset, which includes at least: actual call data in the dataset called by the call logic to be analyzed, and the data call status of the actual call data called by the call logic to be analyzed; the call logic matching module 1904 is specifically used to match the dataset name and dataset call status of each dataset in each target dataset to determine the candidate call logic matched by each call logic to be analyzed; to match the actual call data information of each dataset in the target dataset of each call logic to be analyzed with the actual call data information of each dataset in the target dataset of the candidate call logic, to determine the target call logic matched by each call logic to be analyzed from the candidate call logic, the call logic to be analyzed and the matched target call logic call the same actual call data, and the data call status is a successful call.

[0219] In one embodiment, the logic matching module 1904 is further configured to perform reflection parsing on the logic type description information of each object to obtain a set of methods for the analysis of the call logic matched by each target function opcode. The set of methods includes multiple data call methods, each with a corresponding data call method type. From each set of methods, candidate data call methods for the analysis of the call logic matched by each target function opcode are selected. The data call method type of the data call method is a candidate logic operation method of a preset data call method type. The method execution instructions of each candidate logic operation method are analyzed to determine the actual call data and data call status called by each candidate logic operation method, and to determine the dataset to which the actual call data called by the candidate logic operation method belongs.

[0220] In one embodiment, such as Figure 20 As shown, the dependency determination device also includes a dependency view generation module 2002 and a dependency result analysis module 2004;

[0221] The dependency view generation module 2002 is used to generate a dependency view based on the call logic dependency relationship between each call logic to be analyzed and the target call logic after the dependency creation module creates the call logic dependency relationship between each call logic to be analyzed and the target call logic. The dependency view includes the call logic node corresponding to each call logic.

[0222] The Dependency Result Analysis Module 2004 is used to display the dependency view and analyze the dependency view to obtain the target result, which includes at least: archived results or optimization comparison results.

[0223] Each module in the aforementioned dependency determination device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0224] In one embodiment, a computer device is provided, which may be a server or a terminal. This embodiment uses a server as an example for description, and its internal structure diagram can be as follows. Figure 21 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores datasets and related data such as dataset information. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for determining dependencies.

[0225] Those skilled in the art will understand that Figure 21 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0226] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0227] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0228] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0229] 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, and the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0230] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0231] The technical features in the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0232] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for determining dependencies, characterized in that, include: Obtain the target datasets called by multiple analysis logics respectively, and the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset called by the analysis logic. The dataset name and dataset call status of each dataset in each target dataset are matched to determine the target call logic matched by each call logic to be analyzed. The dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and the dataset call status of both the target call logic and the matched call logic to be analyzed is a successful call. Create calling logic dependencies between each of the calling logics to be analyzed and the target calling logic, wherein the calling logic dependencies describe that the calling logic to be analyzed and the target calling logic successfully call the same dataset; The process involves matching the dataset name and call status of each dataset in the target datasets to determine the target call logic matched by each call logic to be analyzed. This includes: performing a reverse traversal based on the call times corresponding to each dataset in each call logic to be analyzed to determine the logic operation to be judged that has a preceding operation relationship with each logic operation to be analyzed. The reverse traversal describes traversing other logic operations to be analyzed whose call times precede the logic operation to be analyzed. The preceding operation relationship describes that the call time of the logic operation to be judged precedes the logic operation to be analyzed. The process also involves matching the dataset name and call status of each dataset in the target datasets of each logic operation to the dataset name and call status of each dataset in the target datasets of each logic operation to determine the target call logic from each logic operation to be judged. The logic operation to be analyzed is the call logic to be analyzed.

2. The method according to claim 1, characterized in that, The dataset information matched by the logic operation to be analyzed also includes a set of prerequisite dependencies. The set of prerequisite dependencies includes prerequisite dependency call logic that has a prerequisite dependency relationship with the logic operation to be analyzed. The prerequisite dependency call logic includes the target call logic. The prerequisite dependency relationship is used to describe that the prerequisite dependency call logic successfully calls the same dataset before the logic operation to be analyzed. The dataset information matched by the target logical operation also includes a set of subsequent dependencies. The set of subsequent dependencies includes subsequent dependency call logics that have a subsequent dependency relationship with the target logical operation. The subsequent dependency call logic includes the call logic to be analyzed. The subsequent dependency relationship is used to describe that the target logical operation successfully calls the same dataset before the subsequent dependency call logic; the target logical operation is the target call logic.

3. The method according to claim 1, characterized in that, The step of obtaining the target datasets invoked by multiple analysis logics, and the dataset information corresponding to each of the target datasets, includes: Obtain the assembly and perform reflection parsing on the assembly to obtain multiple function opcodes; Based on the opcode type corresponding to each of the aforementioned function opcodes, a target function opcode is selected from the plurality of function opcodes, and the target function opcode is parsed to obtain the corresponding logical operation information. The target function opcode is matched with the logic to be analyzed and called. The logical operation information includes at least: the logical type description information of the logic to be analyzed and called that is matched by the target function opcode. The logical type description information of the call logic matched by each target function opcode is subjected to reflection parsing to filter out the target dataset called by the call logic matched by each target function opcode. Obtain the label information reflected from each of the target datasets, collect the dataset call status of each dataset in each of the target datasets, and parse each dataset in the target datasets to obtain the dataset name of each dataset.

4. The method according to claim 3, characterized in that, The step of filtering the target function operation code from the plurality of function operation codes based on the operation code type corresponding to each of the aforementioned function operation codes includes: Functional opcodes whose corresponding opcode type is a preset opcode type are identified as candidate functional opcodes; Parse the type information of each candidate function opcode, wherein the type information includes at least: operand type and method name type; The candidate function operation codes whose type information matches the preset type information are determined as the target function operation codes.

5. The method according to claim 3, characterized in that, The step of performing reflection parsing on the logic type description information of the call logic matched by each of the target function opcodes to obtain the target dataset called by the call logic matched by each of the target function opcodes includes: The description information of each logical type is subjected to reflection parsing to obtain the set of fields of the logic to be analyzed and called that matches the operation code of each target function. The set of fields includes multiple logical operation fields. Each logical operation field has a corresponding data call interface type and is used to call the dataset. From each of the field sets, select the target logic operation field that matches the target function operation code to be analyzed and called logic, wherein the data call interface type corresponding to the target logic operation field conforms to the preset data call interface type; Parse each of the target logical operation fields to determine each of the target datasets.

6. The method according to any one of claims 1 to 5, characterized in that, The dataset information also includes: actual call data information in the dataset, which includes at least: actual call data in the dataset that is called by the call logic to be analyzed, and the data call status of the actual call data being called by the call logic to be analyzed; The step of matching the dataset name and dataset call status of each of the target datasets to determine the target call logic matched by each of the call logics to be analyzed includes: The dataset name and dataset call status of each of the target datasets are matched to determine the candidate call logic that matches each of the call logics to be analyzed. The actual call data information of each dataset in the target dataset of each of the call logics to be analyzed is matched with the actual call data information of each dataset in the target dataset of the candidate call logics. The target call logic matched by each call logic to be analyzed is determined from the candidate call logics. The call logic to be analyzed and the matched target call logic call the same actual call data, and the data call status is a successful call.

7. The method according to claim 6, characterized in that, The method further includes: The description information of each logic type is subjected to reflection parsing to obtain the set of methods for the call logic to be analyzed that matches each target function opcode. The set of methods includes multiple data call methods, and each data call method has a corresponding data call method type. From each of the method sets, select the candidate data call method that matches the call logic to be analyzed for each of the target function operation codes, wherein the data call method type of the data call method is the candidate logic operation method of the preset data call method type; Analyze the method execution instructions of each candidate logical operation method to determine the actual call data and data call status of each candidate logical operation method, and determine the dataset to which the actual call data of the candidate logical operation method belongs.

8. The method according to claim 1, characterized in that, After creating the calling logic dependencies between each of the calling logics to be analyzed and the target calling logic, the method further includes: A dependency view is generated based on the call logic dependencies between each of the call logics to be analyzed and the target call logic. The dependency view includes call logic nodes corresponding to each call logic. Display the dependency view and analyze the dependency view to obtain the target result, which includes at least: archived results or optimized comparison results.

9. A device for determining dependencies, characterized in that, The device includes: The data acquisition module is used to acquire the target datasets called by multiple analysis logics respectively, and the dataset information corresponding to each dataset in each target dataset. The dataset information includes at least: the dataset name of the dataset, and the dataset call status of the dataset being called by the analysis logic. The logic matching module is used to match the dataset name and dataset call status of each dataset in each of the target datasets to determine the target call logic matched by each of the call logics to be analyzed. This includes: performing a reverse traversal based on the call times corresponding to each dataset for each call logic to be analyzed, to determine the logic operations to be judged that have a preceding operation relationship with each logic operation to be analyzed. The reverse traversal describes traversing other logic operations to be analyzed whose call times precede the logic operation to be analyzed, and the preceding operation relationship describes that the call time of the logic operation to be judged precedes the logic operation to be analyzed. The module also matches the dataset name and dataset call status of each dataset in the target datasets of each logic operation to be analyzed with the dataset name and dataset call status of each dataset in the target datasets of each logic operation to be judged, to determine the target call logic from each logic operation to be judged. The logic operation to be analyzed is the call logic to be analyzed, the dataset name of the target call logic is consistent with the dataset name of the matched call logic to be analyzed, and both the dataset call status of the target call logic and the dataset call status of the matched call logic to be analyzed are successful calls. The dependency creation module is used to create call logic dependencies between each of the call logics to be analyzed and the target call logic. The call logic dependencies describe that the call logic to be analyzed and the target call logic successfully call the same dataset.

10. The apparatus according to claim 9, characterized in that, The dataset information matched by the logic operation to be analyzed also includes a set of prerequisite dependencies. The set of prerequisite dependencies includes prerequisite dependency call logic that has a prerequisite dependency relationship with the logic operation to be analyzed. The prerequisite dependency call logic includes the target call logic. The prerequisite dependency relationship is used to describe that the prerequisite dependency call logic successfully calls the same dataset before the logic operation to be analyzed. The dataset information matched by the target logical operation also includes a set of subsequent dependencies. The set of subsequent dependencies includes subsequent dependency call logics that have a subsequent dependency relationship with the target logical operation. The subsequent dependency call logic includes the call logic to be analyzed. The subsequent dependency relationship is used to describe that the target logical operation successfully calls the same dataset before the subsequent dependency call logic; the target logical operation is the target call logic.

11. The apparatus according to claim 9, characterized in that, The data acquisition module is specifically used to acquire a program assembly and perform reflection parsing on the program assembly to obtain multiple function opcodes; based on the opcode type corresponding to each of the multiple function opcodes, a target function opcode is selected from the multiple function opcodes, and the target function opcode is parsed to obtain the corresponding logical operation information. The target function opcode matches the logic to be analyzed, and the logical operation information includes at least: the logical type description information of the logic to be analyzed matched by the target function opcode; reflection parsing is performed on the logical type description information of the logic to be analyzed matched by each of the target function opcodes to obtain the target datasets called by the logic to be analyzed matched by each of the target function opcodes; the tag information reflected from each of the target datasets is acquired to collect the dataset call status of each dataset in each of the target datasets, and each dataset in the target dataset is parsed to obtain the dataset name of each dataset.

12. The apparatus according to claim 11, characterized in that, The data acquisition module is specifically used to determine the function operation codes whose corresponding operation code type is a preset operation code type as candidate function operation codes; parse the type information of each candidate function operation code, the type information including at least: operand type and device name type; and determine the candidate function operation codes whose type information matches the preset type information as the target function operation code.

13. The apparatus according to claim 11, characterized in that, The data acquisition module is specifically used to perform reflection parsing on the description information of each logic type to obtain a set of fields that match the logic to be analyzed and called by each target function operation code. The set of fields includes multiple logic operation fields, each logic operation field has a corresponding data call interface type, and the logic operation field is used to call the dataset. From each set of fields, the target logic operation field that matches the logic to be analyzed and called by each target function operation code is selected, and the data call interface type corresponding to the target logic operation field conforms to a preset data call interface type. Parse each of the target logical operation fields to determine each of the target datasets.

14. The apparatus according to any one of claims 9 to 13, characterized in that, The dataset information also includes: actual call data information in the dataset, which includes at least: actual call data in the dataset that is called by the call logic to be analyzed, and the data call status of the actual call data being called by the call logic to be analyzed; The call logic matching module is specifically used to match the dataset name and dataset call status of each dataset in each target dataset to determine the candidate call logic matched by each call logic to be analyzed; to match the actual call data information of each dataset in the target dataset of each call logic to be analyzed with the actual call data information of each dataset in the target dataset of the candidate call logic, to determine the target call logic matched by each call logic to be analyzed from the candidate call logic, wherein the call logic to be analyzed and the matched target call logic call the same actual call data, and the data call status is a successful call.

15. The apparatus according to claim 14, characterized in that, The call logic matching module further includes a function to perform reflection parsing on the description information of each logic type to obtain a set of devices that match the call logic to be analyzed for each target function opcode. The set of devices includes multiple data calling devices, each of which has a corresponding data calling device type. From each set of devices, a candidate data calling device that matches the call logic to be analyzed for each target function opcode is selected. The data calling device type of the data calling device is a candidate logic operation device of a preset data calling device type. Analyze the device execution instructions of each candidate logic operation device, determine the actual call data and data call status called by each candidate logic operation device, and determine the dataset to which the actual call data called by the candidate logic operation device belongs.

16. The apparatus according to claim 9, characterized in that, The device for determining dependencies also includes a dependency view generation module and a dependency result analysis module; The dependency view generation module is used to generate a dependency view based on the call logic dependency relationship between each of the call logics to be analyzed and the target call logic after the call logic dependency relationship between each of the call logics to be analyzed and the target call logic is created. The dependency view includes call logic nodes corresponding to each call logic. The dependency result analysis module is used to display the dependency view and analyze the dependency view to obtain the target result, which includes at least: archived result or optimization comparison result.

17. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

18. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images