Multi-terminal collaborative model development method and device and collaborative development system

Abstract

The invention provides a multi-terminal collaborative model development method and device and a collaborative development system, and the method comprises the steps: receiving a model development task, and decomposing the model development task into a plurality of development sub-tasks; establishing communication connection with each developer terminal, and issuing the development sub-task to each developer terminal; a first monitoring step: creating a corresponding model development transaction and creating a read view corresponding to the model development transaction under the condition that the editing action of the developer terminal is monitored; a second monitoring step: under the condition that the storage action of the developer terminal is monitored, obtaining an editing result of the model development transaction, and storing the editing result according to the read view; repeating the first monitoring step and the second monitoring step until all the development subtasks have corresponding editing results; and assembling the editing result to obtain a target model. The method solves the problems that in the prior art, multi-person collaborative modeling arrangement is complex in composition, and conflicts are prone to occurring.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and more specifically, to a multi-terminal collaborative model development method, apparatus, computer-readable storage medium, and collaborative development system. Background Technology

[0002] Data center operations often involve creating and maintaining orchestrations. Some large orchestrations are complex in structure, and if only one person is involved in editing and development, the efficiency is low. Existing technologies have proposed real-time editing of online shared documents to improve development speed. However, because the editing process in existing technologies is directly shared with all users, while model development cannot be directly shared with other users' modifications, it is necessary to orchestrate the collaborative model building process through permissions. However, due to the complex hierarchy of complex models, the corresponding orchestration structure is prone to storage conflicts due to improper orchestration. Summary of the Invention

[0003] The main objective of this application is to provide a multi-terminal collaborative model development method, apparatus, computer-readable storage medium, and collaborative development system to at least solve the problem that the existing technology of multi-person collaborative modeling and arrangement is complex and prone to conflicts.

[0004] To achieve the above objectives, according to one aspect of this application, a multi-terminal collaborative model development method is provided, comprising: receiving a model development task, and decomposing the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task; establishing a communication connection with each developer terminal, and distributing the development sub-tasks to each developer terminal; a first listening step, wherein upon listening to an editing action of a developer terminal, a corresponding model development transaction is created and a read view corresponding to the model development transaction is created, the read view including at least the transaction ID of the model development transaction; a second listening step, wherein upon listening to a save action of a developer terminal, the editing result of the model development transaction is obtained, and the editing result is stored according to the read view; the first listening step and the second listening step are repeated at least once in sequence until all development sub-tasks have corresponding editing results and there are no unsaved model development transactions in the system; and the editing results corresponding to each development sub-task are assembled to obtain a target model.

[0005] Optionally, after the development subtask is distributed to each of the developer terminals, the method further includes: sequentially traversing each of the model development transactions according to the read view to determine the editing status of each of the model development transactions; determining the editing result whose editing status is saved and corresponds to the maximum value of the transaction ID of the read view as the current model status; generating a first instruction according to the current model status and sending it to all the developer terminals of the development subtask to which the current model status belongs, wherein the first instruction is used to instruct the developer terminals to visualize the current model status.

[0006] Optionally, creating a read view corresponding to the model development transaction includes: determining the transaction ID of the currently created model development transaction to obtain a first transaction ID; obtaining the transaction IDs of each first target transaction to obtain multiple second transaction IDs, wherein the first target transaction is the model development transaction that belongs to the same development subtask as the currently created model development transaction and is in the editing stage; determining the minimum value of the second transaction ID to obtain a third transaction ID; determining the maximum value of the second transaction ID to obtain a fourth transaction ID; and concatenating the first transaction ID, each of the second transaction IDs, the third transaction ID, and the fourth transaction ID sequentially to obtain the read view.

[0007] Optionally, after creating the corresponding model development transaction and the corresponding read view, the method further includes: when a component addition operation is detected on the developer terminal, determining whether each developer terminal has an existing component identical to the added component; if an existing component identical to the added component exists, determining the component ID of the existing component as the component ID of the added component; if no existing component identical to the added component exists, generating the component ID of the added component using a snowflake algorithm.

[0008] Optionally, the snowflake algorithm is used to generate the component ID of the newly added component, including: obtaining the generation timestamp of the newly added component to obtain a first serial number; determining the model ID corresponding to the newly added component and the terminal ID of the developer terminal that created the newly added component to obtain a second serial number; determining the creation order of the newly added component to obtain a third serial number; and concatenating the first serial number, the second serial number and the third serial number in sequence to obtain the component ID of the newly added component.

[0009] Optionally, storing the editing result according to the read view includes: determining the original version of the editing result based on the development subtask to which the editing result belongs and the corresponding read view; determining whether the target editing result is consistent with the original version, wherein the target editing result is an editing result already stored in the system and belonging to the same development subtask as the original version; if the target editing result is consistent with the original version, overwriting the target editing result with the original version; if the target editing result is inconsistent with the original version, comparing the editing result and the target editing result according to the component ID, and storing the editing result according to the comparison result.

[0010] Optionally, storing the editing result based on the comparison result includes: determining the added components of the editing result relative to the original version as a first target component, determining the added components of the target editing result relative to the original version as a second target component; determining the deleted components of the editing result relative to the original version as a third target component, determining the deleted components of the target editing result relative to the original version as a fourth target component; determining the revised components of the editing result relative to the original version as a fifth target component, determining the revised components of the target editing result relative to the original version as a sixth target component; and, if the first, second, and third conditions are simultaneously satisfied, using the editing result to modify the original version. The target editing results are overwritten, with the first condition being that the first target component and the second target component do not overlap, the second condition being that the third target component and the fourth target component do not overlap, and the third condition being that the fifth target component and the sixth target component do not overlap. If any of the first, second, and third conditions is not met, target identifiers are added to the overlapping components between the first and second target components, the overlapping components between the third and fourth target components, and the overlapping components between the fifth and sixth target components. The editing results with target identifiers and the target editing results are then sent to the administrator terminal.

[0011] According to another aspect of this application, a multi-terminal collaborative model development apparatus is provided, the apparatus comprising: a first processing unit, configured to receive a model development task and decompose the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task; a communication unit, configured to establish a communication connection with each developer terminal and distribute the development sub-tasks to each developer terminal; a first listening unit, configured to, in a first listening step, upon listening to an editing action of a developer terminal, create a corresponding model development transaction and create a read view corresponding to the model development transaction, the read view including at least the transaction ID of the model development transaction; a second listening unit, configured to, in a second listening step, upon listening to a save action of a developer terminal, obtain the editing result of the model development transaction and store the editing result according to the read view; a repeating unit, configured to repeat the first listening step and the second listening step at least once in sequence until all the development sub-tasks have corresponding editing results and there are no unsaved model development transactions in the system; and a second processing unit, configured to assemble the editing results corresponding to each development sub-task to obtain a target model.

[0012] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform any of the methods described.

[0013] According to another aspect of this application, a collaborative development system is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including methods for performing any one of the methods described.

[0014] Applying the technical solution of this application, in the above-mentioned multi-terminal collaborative model development method, firstly, a model development task is received, and the model development task is decomposed into multiple development sub-tasks according to the model structure and model actions carried by the model development task; then, a communication connection is established with each developer terminal, and the development sub-tasks are distributed to each developer terminal; then, in the first listening step, when an editing action is detected on a developer terminal, a corresponding model development transaction is created and a read view corresponding to the model development transaction is created, the read view including at least the transaction ID of the model development transaction; then, in the second listening step, when a save action is detected on a developer terminal, the editing result of the model development transaction is obtained, and the editing result is stored according to the read view; then, the first listening step and the second listening step are repeated at least once in sequence until all development sub-tasks have corresponding editing results and there are no unsaved model development transactions in the system; finally, the editing results corresponding to each development sub-task are assembled to obtain the target model. This application achieves version control by reading user operations during the collaborative modeling process in real time and then uniquely identifying each user's operation through a read view. This ensures that the operations of different users are isolated, and different users can read the latest saved model version in real time. At the same time, storing the editing results of different users based on the read view can avoid storage conflicts between operations from the same source, thus solving the problem that the existing technology of multi-person collaborative modeling and arrangement is complex and prone to conflicts. Attached Figure Description

[0015] Figure 1 A hardware structure block diagram of a mobile terminal for a multi-terminal collaborative model development method provided in an embodiment of this application is shown.

[0016] Figure 2 A flowchart illustrating a multi-terminal collaborative model development method according to an embodiment of this application is shown.

[0017] Figure 3 A structural block diagram of a multi-terminal collaborative model development apparatus provided according to an embodiment of this application is shown.

[0018] The above figures include the following reference numerals:

[0019] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0020] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] As described in the background section, in existing technologies, editing is directly shared among all users, while model development cannot be directly shared with other users' modifications. It requires orchestration of the collaborative model building process through permissions. However, due to the complex hierarchy of complex models, the corresponding orchestration structure is prone to storage conflicts due to improper orchestration. To solve the problem of complex orchestration structure and easy conflict in existing technologies for multi-user collaborative modeling, the embodiments of this application provide a multi-terminal collaborative model development method, apparatus, computer-readable storage medium, and collaborative development system.

[0024] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0025] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a multi-terminal collaborative model development method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0026] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the multi-terminal collaborative model development method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0027] This embodiment provides a multi-terminal collaborative model development method that runs on a mobile terminal, computer terminal, or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0028] Figure 2 This is a flowchart of a multi-terminal collaborative model development method according to an embodiment of this application. For example... Figure 2 As shown, the method includes the following steps:

[0029] Step S201: Receive the model development task and decompose the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task.

[0030] Specifically, when a project begins, the model manager receives model development tasks from the Agricultural Bank of China's data center. These tasks typically include the model's basic framework and expected behavior. Based on the model's complexity and specific requirements, the model manager uses the system's provided functions to break down the tasks into multiple development sub-tasks, such as structural modeling, behavioral modeling, and parameter setting. Each sub-task is assigned specific goals and standards; for example, structural modeling might involve building the model's basic architecture, while behavioral modeling focuses on writing scripts and processes.

[0031] Step S202: Establish communication connections with each developer terminal and distribute development subtasks to each developer terminal;

[0032] Specifically, the WebSocket protocol is used to establish real-time bidirectional communication, enabling the server and client to continuously update their status without requiring frequent requests. Specifically, upon system startup, a persistent communication connection is established with each developer's terminal using WebSocket technology. This ensures that developers can receive messages from the system instantly, such as the online status of team members and real-time editing notifications. After developers log into the system, the model administrator, based on predefined permissions and responsibilities, distributes development subtasks to the corresponding developer terminals through this bidirectional communication channel. The distributed tasks include a detailed subtask description, a required completion time, and related model documents and supporting materials.

[0033] Step S203, First Listening Step: Upon detecting an editing action on the developer's terminal, create a corresponding model development transaction and a corresponding read view for the model development transaction. The read view includes at least the transaction ID of the model development transaction.

[0034] Specifically, when the system detects editing actions on a developer's terminal, it creates a model development transaction for this series of operations and determines the corresponding read view to ensure global uniqueness. Along with the creation of the model development transaction, the system also generates a read view containing the transaction ID and other key information, such as a list of active transactions (m_ids) and transaction boundary values ​​(min_trx_id, max_trx_id). The system updates the read view in real time to ensure it reflects a snapshot of the current model state, thereby controlling the model version that the developer can read during editing.

[0035] Step S204, the second listening step, upon detecting the save action on the developer's terminal, obtain the editing result of the model development transaction, and store the editing result according to the read view;

[0036] Specifically, the system monitors save actions on the developer's terminal. Once a save event is detected, it collects all edits associated with that transaction ID. Based on the information recorded in the read view, the system decides how to store these edits. If there is no conflict with the version in the read view, the edits are saved directly to the database, and a new version associated with the transaction ID is created. If a conflict exists, the system prompts the developer to resolve the conflict. Only after the conflict is properly resolved can the edits be finally committed and saved.

[0037] Step S205: Repeat the first listening step and the second listening step at least once in sequence until all development subtasks have corresponding editing results and there are no unsaved model development transactions in the system.

[0038] Specifically, the system will continuously monitor and execute the first and second monitoring steps described above until all development subtasks have been submitted and saved, with no pending development matters. That is, the editing results of each subtask are correctly processed and stored, forming a complete model version.

[0039] Step S206: Assemble the editing results corresponding to each development subtask to obtain the target model.

[0040] Specifically, after all subtasks are completed and all model development transactions are properly handled, the system will begin the assembly process. Assembly includes merging the results of each subtask according to the preset order and dependencies of the model structure, and handling conflicts. For conflicts that can be resolved automatically, such as adding and deleting components (which do not involve common parts in their respective operations), the system will directly merge these editing results. For conflicts requiring manual intervention, the system will display the conflict points in a graphical interface, allowing administrators to choose which changes to retain, ultimately forming a unified model version.

[0041] In this embodiment, firstly, a model development task is received, and the task is decomposed into multiple sub-tasks based on the model structure and actions it carries. Then, a communication connection is established with each developer terminal, and the sub-tasks are distributed to each terminal. Next, in the first listening step, upon detecting an editing action on a developer terminal, a corresponding model development transaction is created, along with a read view. The read view includes at least the transaction ID of the model development transaction. Then, in the second listening step, upon detecting a save action on a developer terminal, the editing result of the model development transaction is obtained, and the result is stored according to the read view. Then, the first and second listening steps are repeated at least once until all sub-tasks have corresponding editing results and there are no unsaved model development transactions in the system. Finally, the editing results of each sub-task are assembled to obtain the target model. This application achieves version control by reading user operations during the collaborative modeling process in real time and then uniquely identifying each user's operation through a read view. This ensures that the operations of different users are isolated, and different users can read the latest saved model version in real time. At the same time, storing the editing results of different users based on the read view can avoid storage conflicts between operations from the same source, thus solving the problem that the existing technology of multi-person collaborative modeling and arrangement is complex and prone to conflicts.

[0042] To enable real-time synchronization of development progress, in one optional implementation, after distributing development subtasks to each developer's terminal, the method further includes:

[0043] Step S301: Based on the read view, traverse each model development transaction sequentially to determine the editing status of each model development transaction;

[0044] Specifically, during multi-user collaborative modeling, the system creates a read view for each user's editing activity. This read view records the transaction ID, the list of active transactions (m_ids), the minimum active transaction ID (min_trx_id), and the global maximum transaction ID (max_trx_id). When the model administrator needs to check the current state of the model, the system iterates through all model development transactions according to each read view to determine whether the transaction has been saved, i.e., whether the transaction has been committed and completed, thus obtaining the aforementioned editing status.

[0045] Step S302: Determine the edit result with the edit status set to "saved" and the maximum value of the corresponding transaction ID in the read view as the current model status;

[0046] Specifically, after traversing and inspecting the status of model development transactions, the system will filter out those transactions with an edit status of "saved". Then, based on the transaction IDs in the read view, the system will find the maximum value of the transaction IDs among these saved transactions. This maximum value represents the latest model version that has not been overwritten by new transactions. The edit results associated with this maximum transaction ID are determined as the current model state, i.e., the latest and stable version of the model.

[0047] Step S303: Generate a first instruction based on the current model state and send it to all developer terminals of the development subtask to which the current model state belongs. The first instruction is used to instruct the developer terminals to visualize the current model state.

[0048] Specifically, after determining the current model state, the system generates a first instruction. This instruction contains a description of the current model state and the target to which the instruction is sent. Using the WebSocket protocol, the system pushes this first instruction to the terminals of all relevant developers in real time, including those who are working on subtasks related to the current model state. Upon receiving the first instruction, the developer's terminal immediately updates its displayed model state, visually displaying the latest model version. In other words, the model seen by the user in the interface is updated in real time.

[0049] The above embodiments enhance the real-time nature and transparency of team collaboration, allowing each developer to immediately see the latest model status, reducing misunderstandings and conflicts caused by information lag. Real-time visual updates improve development efficiency, ensuring all team members are on the same page, promoting smooth collaboration and efficient team communication. Simultaneously, WebSocket's real-time communication capabilities reduce the network burden of traditional HTTP requests, improving information response speed and making real-time model status updates more efficient and faster.

[0050] To prevent storage conflicts related to model development progress, in an optional implementation, step S203 includes:

[0051] Step S2031: Determine the transaction ID of the currently created model development transaction to obtain the first transaction ID;

[0052] Specifically, when a user begins editing a diagram or making other model modifications, the system creates a new model development transaction for that editing operation. The system uses the snowflake algorithm to assign a globally unique transaction ID to this newly created model development transaction; this ID is called the first transaction ID.

[0053] Step S2032: Obtain the transaction ID of each first target transaction to obtain multiple second transaction IDs. The first target transaction is the model development transaction that is the same as the development subtask to which the currently created model development transaction belongs and is in the editing stage.

[0054] Specifically, it's based on the Read View construction principle under the Multi-Version Concurrency Control (MVCC) mechanism. The Read View needs to contain all active (uncommitted) transaction IDs to determine which versions are visible in subsequent read operations. It identifies all development subtasks related to the currently created model development transaction; "related" here refers to subtasks belonging to the workflow. For each model development transaction that is being edited but not yet committed, the system obtains its transaction ID and aggregates these IDs to obtain multiple second transaction IDs.

[0055] Step S2033: Determine the minimum value of the second transaction ID to obtain the third transaction ID; determine the maximum value of the second transaction ID to obtain the fourth transaction ID.

[0056] Specifically, the third transaction ID, which is the minimum value in the second transaction ID set, reflects the earliest uncommitted edit activity in the current read view. The fourth transaction ID, which is the maximum value in the second transaction ID set, reflects the latest uncommitted edit activity in the current read view.

[0057] Step S2034: Concatenate the first transaction ID, each of the second transaction IDs, the third transaction ID, and the fourth transaction ID in sequence to obtain the read view.

[0058] Specifically, a read view is a data structure used to store a snapshot of a transaction at the start of its execution, including the transaction ID and other metadata used to determine the visible version. It helps transactions see a consistent database state during execution. The system concatenates the first transaction ID, the second set of transaction IDs, the third transaction ID, and the fourth transaction ID in a specific order to form the read view data structure.

[0059] Through the above embodiments, the construction of read views enables the system to control user access to the model based on the start time and state of transactions, ensuring that the model version seen by the user is consistent during the same editing stage. This not only enhances the transaction isolation of model development but also improves the efficiency and accuracy of multi-user collaborative modeling, reducing unnecessary conflicts and problems caused by improper version control. Through these steps, the process of creating read views becomes systematic and standardized, providing a solid foundation for subsequent version control and conflict resolution, and contributing to improved professionalism and user experience throughout the modeling process.

[0060] To further prevent storage conflicts in model development progress, in an optional implementation, after creating the corresponding model development transaction and the corresponding read view, the above method further includes:

[0061] Step S401: If a component addition operation is detected in the developer terminal, determine whether there is an existing component in each developer terminal that is the same as the added component.

[0062] Specifically, when the system detects that any developer terminal has performed a component addition operation, it immediately initiates a check process. The goal of this process is to check whether the same component already exists and has been created by other developers. The system uses real-time communication technologies (such as WebSocket) to retrieve information about the current editing versions of all developer terminals from the cache, including a list of created components and their IDs. Then, the system compares the new component with the list of existing components, determining whether a duplicate component exists by comparing the component's attributes (such as name, type, parameters, etc.).

[0063] Step S402: If there is an existing component that is identical to the newly added component, the component ID of the existing component is determined as the component ID of the newly added component.

[0064] Specifically, if the system finds during the check that a newly added component has exactly the same attributes as an existing component, the system will not generate a new ID for the new component. Instead, the component ID of the existing component will be assigned to the new component to ensure the uniqueness of components in the model.

[0065] Step S403: If there is no existing component identical to the newly added component, the snowflake algorithm is used to generate the component ID of the newly added component.

[0066] Specifically, the Snowflake algorithm is a distributed ID generation algorithm that can efficiently generate globally unique IDs and is suitable for component ID generation in high-concurrency environments. If no existing component matching the newly added component is found during system checks, the system will automatically invoke the Snowflake algorithm to generate a brand new, globally unique component ID.

[0067] Through the above embodiments, the automated checking and ID allocation process reduces the need for developers and administrators to manually resolve component conflicts, making the development process more automated and efficient. By ensuring the uniqueness of components and avoiding the creation of duplicate components, the consistency and readability of the model are enhanced, which is beneficial for collaboration and communication among team members. The introduction of the snowflake algorithm enables the system to effectively generate component IDs in high-concurrency environments, meeting the needs of large team collaborative development, reducing system load, and improving the overall performance of model development.

[0068] To ensure the interpretability of the component ID, in an optional implementation, step S403 above includes:

[0069] Step S4031: Obtain the generation timestamp of the newly added component to get the first serial number;

[0070] Specifically, when a component addition operation is triggered during model development, the system first captures this event. The system obtains the current time's timestamp in real time (accurate to milliseconds). This timestamp occupies 41 bits in the Snowflake algorithm and becomes the first sequence number for generating the component ID. The choice of timestamp ensures that each generated component ID reflects the order and time of component creation, distinguishing the order even in high-concurrency environments.

[0071] Step S4032: Determine the model ID corresponding to the newly added component and the terminal ID of the developer terminal that created the newly added component to obtain the second serial number;

[0072] Specifically, in the Snowflake algorithm, the portions originally used to identify the data center ID and machine ID are redefined in this technical solution as the model ID (occupying 10 bits) and the developer terminal ID (occupying 10 bits). When a component addition operation is triggered, the system extracts the model ID from the context of the current transaction to identify which model the component belongs to. Simultaneously, the system identifies the developer terminal ID that performed the addition operation to track which terminal created the component. This is particularly important in multi-user environments, ensuring clear component ownership.

[0073] In addition, development team IDs and subtask IDs can be introduced.

[0074] Step S4033: Determine the creation order of the new components and obtain the third serial number;

[0075] Specifically, the remaining 12 bits in the snowflake algorithm are used to generate a sequence number. This part is referred to as the third sequence number in this technique, and it is used to identify the sequence position of components generated by the same model and terminal at the same timestamp. When a component is added, the system assigns an incrementing sequence number to the operation to ensure that the generated component ID is unique even within a microsecond-level time window.

[0076] Step S4034: Concatenate the first serial number, the second serial number, and the third serial number in sequence to obtain the component ID of the newly added component.

[0077] Specifically, after determining the different components of the component ID in the first three steps, the system concatenates these components in a predetermined order (timestamp, model ID + terminal ID, serial number) to form a 64-bit integer, which serves as the component's ID. This concatenation operation is performed efficiently within the system, ensuring that the new component immediately obtains a unique and meaningful ID, facilitating subsequent modeling and version control operations.

[0078] Through the above embodiments, the generation of component IDs follows the basic principles of the Snowflake algorithm, ensuring both the global uniqueness of the IDs and enhancing their information content and ordering. By combining timestamps, model IDs, terminal IDs, and serial numbers, component IDs become reliable data identifiers in model construction, supporting efficient collaborative work in multi-user, multi-terminal environments.

[0079] To resolve conflicts between edited results uploaded from different terminals, in one optional implementation, step S204 includes:

[0080] Step S2041: Determine the original version of the edit result based on the development subtask to which the edit result belongs and the corresponding read view;

[0081] Specifically, when a developer completes a development subtask and saves its edits, the system determines the original version of the edit based on the read view information. The original version refers to the version state of the model or component seen by the developer at the start of the current transaction; it serves as the baseline for comparison and merging of the edits.

[0082] Step S2042: Determine whether the target edit result is consistent with the original version. The target edit result is the edit result that has been stored in the system and belongs to the same development subtask as the edit result.

[0083] Specifically, the system searches the database for a target editing result that is associated with the current editing result and originated from the same original version. By comparing the transaction ID with the information in the read view, the system determines whether the target editing result has been modified based on the same original version.

[0084] Step S2043: If the target editing result is consistent with the original version, the edited result is used to overwrite the target editing result;

[0085] Specifically, if the target edit result is identical to the original version, it means that no other edits were saved to this version during the current editing period, and the current edit result can safely overwrite the original record. The system updates the corresponding subtask and component versions in the database, replaces the old content with the new edit result, and increments the version number.

[0086] Step S2044: If the target editing result is inconsistent with the original version, compare the editing result and the target editing result according to the component ID, and store the editing result according to the comparison result.

[0087] Specifically, if a discrepancy is detected between the target edit result and the original version, the system will compare each component in the current edit result with that in the target edit result. Based on the component ID, the system checks if any component exists in both the edit result and the target edit result but with different content. For conflicting components, the system determines a merging strategy based on specific rules, which may include automatic merging (e.g., adding and deleting conflict-free components), manual merging (for complex conflicts), or refusing to save (if the merging rules do not apply).

[0088] Through the above embodiments, the conflict detection and merging mechanism ensures that state changes of models and components are properly handled under multi-user concurrent operations, reducing the probability of data conflicts. This also reflects the durability and consistency of transactions; even in a concurrent environment, the system can guarantee that the saved editing results are up-to-date and consistent, enhancing the team's confidence and efficiency in collaborative development.

[0089] To resolve conflicts between edited results uploaded from different terminals, in one optional implementation, step S2044 includes:

[0090] Step S20441: Determine the added component of the editing result relative to the original version as the first target component, and determine the added component of the target editing result relative to the original version as the second target component;

[0091] Specifically, the system identifies newly added components in the current edit result that do not match the original version as the first target components. Simultaneously, it identifies newly added components that do not match the original version from the target edit results already stored in the system, calling them the second target components. Through JSON comparison or similar data comparison techniques, the system can accurately identify the differences in the newly added components.

[0092] Step S20442: Determine the deleted component of the edited result relative to the original version as the third target component, and determine the deleted component of the target edited result relative to the original version as the fourth target component;

[0093] Specifically, the system identifies components missing from the original version in the current edit result and marks them as third target components. Simultaneously, it finds components that are also missing from the original version in the stored target edit results; these are called fourth target components. By comparing these, the system can understand which components were simultaneously deleted by multiple developers, which may indicate components that need to be retained or conflicts that need to be resolved.

[0094] Step S20443: Determine the revision component of the edit result relative to the original version as the fifth target component, and determine the revision component of the target edit result relative to the original version as the sixth target component;

[0095] Specifically, the system identifies the modified components in the current edit result; these are considered the fifth target components. Similarly, components modified relative to the original version are identified from the target edit result and marked as the sixth target components. This step is based on a comparison using component IDs to determine which components have been modified.

[0096] Step S20444: If the first condition, the second condition, and the third condition are met simultaneously, the editing result is used to overwrite the target editing result. The first condition is that the first target component and the second target component do not overlap. The second condition is that the third target component and the fourth target component do not overlap. The third condition is that the fifth target component and the sixth target component do not overlap.

[0097] Specifically, after determining that there are no duplicates between the first target component and the second target component, the third target component and the fourth target component, and the fifth target component and the sixth target component, the system determines that the conditions for direct overwrite are met. The system updates the target editing result to the current editing result, and may also update the version number to reflect the new status.

[0098] Step S20445: If any one of the first, second, and third conditions is not met, add target identifiers to the duplicate components between the first target component and the second target component, the duplicate components between the third and fourth target components, and the duplicate components between the fifth and sixth target components.

[0099] Specifically, when the system detects duplicate components in add, delete, or revise operations, it adds target identifiers (such as displaying them with different colors) to these components. Target identifiers help developers and administrators quickly identify which components are in conflict and require manual merging or resolution.

[0100] Step S20446: Send the edited result with the target identifier and the target edited result to the administrator terminal.

[0101] Specifically, the system packages the edited results with the target identifier and the target edited results together and sends them to the administrator terminal. The administrator terminal should have conflict resolution tools, be able to display the conflicting areas, and provide merge suggestions or manual adjustment functions.

[0102] Through the above embodiments, the combination of real-time notifications and conflict management tools improves the administrator's response speed and handling capabilities to conflicts. Administrators can resolve conflicts more efficiently, ensuring model consistency and usability, and promoting team collaboration and project progress. Through this conflict detection and handling mechanism, the system can effectively manage version control and editing conflicts in multi-user collaborative modeling scenarios, not only improving the efficiency of collaborative modeling but also ensuring the accuracy and integrity of the model. The system can automatically identify and handle simple, conflict-free editing result overwrites, while providing sophisticated conflict marking and management tools to ensure proper conflict resolution even in complex situations, avoiding data loss and version chaos, and enhancing the smoothness of team collaboration and the reliability of the project.

[0103] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0104] This application also provides a multi-terminal collaborative model development apparatus. It should be noted that this multi-terminal collaborative model development apparatus can be used to execute the multi-terminal collaborative model development method provided in this application. This apparatus is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0105] The following describes the multi-terminal collaborative model development device provided in the embodiments of this application.

[0106] Figure 3 A structural block diagram of a multi-terminal collaborative model development device according to an embodiment of this application. (See diagram below.) Figure 3 As shown, the device includes:

[0107] The first processing unit 10 is used to receive the model development task and decompose the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task.

[0108] Communication unit 20 is used to establish communication connections with each developer terminal and to distribute development subtasks to each developer terminal;

[0109] The first listening unit 30 is used for the first listening step. When the editing action of the developer terminal is detected, the corresponding model development transaction is created and the corresponding read view of the model development transaction is created. The read view includes at least the transaction ID of the model development transaction.

[0110] The second listening unit 40 is used in the second listening step. When the save action of the developer terminal is detected, the editing result of the model development transaction is obtained and the editing result is stored according to the read view.

[0111] The repeating unit 50 is used to repeat the first listening step and the second listening step at least once in sequence until all development subtasks have corresponding editing results and there are no unsaved model development transactions in the system.

[0112] The second processing unit 60 is used to assemble the editing results corresponding to each development sub-task to obtain the target model.

[0113] In this embodiment, the first processing unit receives the model development task and decomposes it into multiple development sub-tasks based on the model structure and model actions carried by the task; the communication unit establishes communication connections with each developer terminal and distributes the development sub-tasks to each developer terminal; the first listening unit, in its first listening step, creates a corresponding model development transaction and a corresponding read view when it detects an editing action on a developer terminal, the read view including at least the transaction ID of the model development transaction; the second listening unit, in its second listening step, obtains the editing result of the model development transaction when it detects a save action on a developer terminal, and stores the editing result according to the read view; the repeating unit repeats the first and second listening steps at least once until all development sub-tasks have corresponding editing results and there are no unsaved model development transactions in the system; the second processing unit assembles the editing results corresponding to each development sub-task to obtain the target model. This application achieves version control by reading user operations during the collaborative modeling process in real time and then uniquely identifying each user's operation through a read view. This ensures that the operations of different users are isolated, and different users can read the latest saved model version in real time. At the same time, storing the editing results of different users based on the read view can avoid storage conflicts between operations from the same source, thus solving the problem that the existing technology of multi-person collaborative modeling and arrangement is complex and prone to conflicts.

[0114] To enable real-time synchronization of development progress, in one optional implementation, the above-mentioned apparatus further includes:

[0115] The first determining unit is used to determine the editing status of each model development transaction by sequentially traversing each model development transaction according to the read view after the development subtask is distributed to each developer terminal.

[0116] The second determining unit is used to determine the editing result, which is in the edited state and corresponds to the maximum value of the transaction ID of the read view, as the current model state;

[0117] The first sending unit is used to generate a first instruction based on the current model state and send it to all developer terminals of the development subtask to which the current model state belongs. The first instruction is used to instruct the developer terminals to visualize the current model state.

[0118] To prevent storage conflicts related to model development progress, in one optional implementation, the first monitoring unit includes:

[0119] The first determination module is used to determine the transaction ID of the currently created model development transaction, and obtain the first transaction ID;

[0120] The first acquisition module is used to acquire the transaction ID of each first target transaction and obtain multiple second transaction IDs. The first target transaction is the model development transaction that is the same as the development subtask to which the currently created model development transaction belongs and is in the editing stage.

[0121] The second determining module is used to determine the minimum value of the second transaction ID to obtain the third transaction ID, and to determine the maximum value of the second transaction ID to obtain the fourth transaction ID;

[0122] The first processing module is used to concatenate the first transaction ID, each of the second transaction IDs, the third transaction ID, and the fourth transaction ID in sequence to obtain a read view.

[0123] To further prevent storage conflicts related to model development progress, in an optional implementation, the above-mentioned apparatus further includes:

[0124] The third listening unit is used to determine whether there is a component that is the same as the newly added component in each developer terminal after the corresponding model development transaction is created and the corresponding read view is created.

[0125] The first determining unit is used to determine the component ID of the existing component as the component ID of the new component when there is an existing component that is the same as the new component.

[0126] The generation unit is used to generate the component ID of the new component using the snowflake algorithm when there is no existing component identical to the new component.

[0127] To ensure the interpretability of the component ID, in one optional implementation, the above-mentioned generation unit includes:

[0128] The second acquisition module is used to obtain the generation timestamp of the newly added component and get the first serial number;

[0129] The third determination module is used to determine the model ID corresponding to the newly added component and the terminal ID of the developer terminal that created the newly added component, and obtain the second serial number;

[0130] The fourth module is used to determine the creation order of new components and obtain the third sequence number;

[0131] The second processing module is used to concatenate the first serial number, the second serial number, and the third serial number in sequence to obtain the component ID of the newly added component.

[0132] To resolve conflicts between edited results uploaded from different terminals, in one optional implementation, the second monitoring unit includes:

[0133] The fifth determination module is used to determine the original version of the edit result based on the development subtask to which the edit result belongs and the corresponding read view;

[0134] The sixth determination module is used to determine whether the target editing result is consistent with the original version. The target editing result is the editing result that has been stored in the system and belongs to the same development subtask as the original version.

[0135] The first storage module is used to overwrite the target editing result when the target editing result is consistent with the original version;

[0136] The second storage module is used to compare the edited result with the target edited result based on the component ID when the target edited result is inconsistent with the original version, and to store the edited result based on the comparison result.

[0137] To resolve conflicts between edited results uploaded from different terminals, in one optional implementation, the second storage module includes:

[0138] The first determining submodule is used to determine the added component of the editing result relative to the original version as the first target component, and to determine the added component of the target editing result relative to the original version as the second target component;

[0139] The second determination submodule is used to determine the deleted components of the edited result relative to the original version as the third target component, and to determine the deleted components of the target edited result relative to the original version as the fourth target component;

[0140] The third determination submodule is used to determine the revision component of the editing result relative to the original version as the fifth target component, and to determine the revision component of the target editing result relative to the original version as the sixth target component;

[0141] The first storage submodule is used to overwrite the target editing result with the editing result when the first condition, the second condition and the third condition are met at the same time. The first condition is that the first target component and the second target component do not overlap. The second condition is that the third target component and the fourth target component do not overlap. The third condition is that the fifth target component and the sixth target component do not overlap.

[0142] The second storage submodule is used to add target identifiers to duplicate components between the first target component and the second target component, duplicate components between the third target component and the fourth target component, and duplicate components between the fifth target component and the sixth target component, if any one of the first condition, the second condition, and the third condition is not met.

[0143] The sending submodule is used to send the edited results with the target identifier and the target edited results to the administrator terminal.

[0144] The aforementioned multi-terminal collaborative model development device includes a processor and a memory. The first processing unit, communication unit, first listening unit, second listening unit, repeating unit, and second processing unit are all stored as program units in the memory. The processor executes these program units stored in the memory to achieve the corresponding functions. All of the above modules reside in the same processor; alternatively, the modules may be located in different processors in any combination.

[0145] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and the efficiency of model development can be improved by adjusting kernel parameters.

[0146] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0147] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to execute the multi-terminal collaborative model development method.

[0148] Specifically, the development methods for multi-terminal collaborative models include:

[0149] Step S201: Receive the model development task and decompose the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task.

[0150] Step S202: Establish communication connections with each developer terminal and distribute development subtasks to each developer terminal;

[0151] Step S203, First Listening Step: Upon detecting an editing action on the developer's terminal, create a corresponding model development transaction and a corresponding read view for the model development transaction. The read view includes at least the transaction ID of the model development transaction.

[0152] Step S204, the second listening step, upon detecting the save action on the developer's terminal, obtain the editing result of the model development transaction, and store the editing result according to the read view;

[0153] Step S205: Repeat the first listening step and the second listening step at least once in sequence until all development subtasks have corresponding editing results and there are no unsaved model development transactions in the system.

[0154] Step S206: Assemble the editing results corresponding to each development subtask to obtain the target model.

[0155] This invention provides a processor for running a program, wherein the program executes the multi-terminal collaborative model development method.

[0156] Specifically, the development methods for multi-terminal collaborative models include:

[0157] Step S201: Receive the model development task and decompose the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task.

[0158] Step S202: Establish communication connections with each developer terminal and distribute development subtasks to each developer terminal;

[0159] Step S203, First Listening Step: Upon detecting an editing action on the developer's terminal, create a corresponding model development transaction and a corresponding read view for the model development transaction. The read view includes at least the transaction ID of the model development transaction.

[0160] Step S204, the second listening step, upon detecting the save action on the developer's terminal, obtain the editing result of the model development transaction, and store the editing result according to the read view;

[0161] Step S205: Repeat the first listening step and the second listening step at least once in sequence until all development subtasks have corresponding editing results and there are no unsaved model development transactions in the system.

[0162] Step S206: Assemble the editing results corresponding to each development subtask to obtain the target model.

[0163] This invention provides a collaborative development system, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps:

[0164] Step S201: Receive the model development task and decompose the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task.

[0165] Step S202: Establish communication connections with each developer terminal and distribute development subtasks to each developer terminal;

[0166] Step S203, First Listening Step: Upon detecting an editing action on the developer's terminal, create a corresponding model development transaction and a corresponding read view for the model development transaction. The read view includes at least the transaction ID of the model development transaction.

[0167] Step S204, the second listening step, upon detecting the save action on the developer's terminal, obtain the editing result of the model development transaction, and store the editing result according to the read view;

[0168] Step S205: Repeat the first listening step and the second listening step at least once in sequence until all development subtasks have corresponding editing results and there are no unsaved model development transactions in the system.

[0169] Step S206: Assemble the editing results corresponding to each development subtask to obtain the target model.

[0170] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps:

[0171] Step S201: Receive the model development task and decompose the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task.

[0172] Step S202: Establish communication connections with each developer terminal and distribute development subtasks to each developer terminal;

[0173] Step S203, First Listening Step: Upon detecting an editing action on the developer's terminal, create a corresponding model development transaction and a corresponding read view for the model development transaction. The read view includes at least the transaction ID of the model development transaction.

[0174] Step S204, the second listening step, upon detecting the save action on the developer's terminal, obtain the editing result of the model development transaction, and store the editing result according to the read view;

[0175] Step S205: Repeat the first listening step and the second listening step at least once in sequence until all development subtasks have corresponding editing results and there are no unsaved model development transactions in the system.

[0176] Step S206: Assemble the editing results corresponding to each development subtask to obtain the target model.

[0177] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0178] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0179] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0180] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0181] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0182] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0183] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0184] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0185] The technical features of 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.

[0186] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0187] As can be seen from the above description, the embodiments of this application achieve the following technical effects:

[0188] 1) The multi-terminal collaborative model development method of this application firstly receives a model development task and decomposes it into multiple development sub-tasks according to the model structure and model actions carried by the model development task; then, it establishes a communication connection with each developer terminal and distributes the development sub-tasks to each developer terminal; then, in the first listening step, when an editing action is detected on a developer terminal, a corresponding model development transaction is created and a read view corresponding to the model development transaction is created, the read view including at least the transaction ID of the model development transaction; then, in the second listening step, when a save action is detected on a developer terminal, the editing result of the model development transaction is obtained and the editing result is stored according to the read view; then, the first listening step and the second listening step are repeated at least once until all development sub-tasks have corresponding editing results and there are no unsaved model development transactions in the system; finally, the editing results corresponding to each development sub-task are assembled to obtain the target model. This application achieves version control by reading user operations during the collaborative modeling process in real time and then uniquely identifying each user's operation through a read view. This ensures that the operations of different users are isolated, and different users can read the latest saved model version in real time. At the same time, storing the editing results of different users based on the read view can avoid storage conflicts between operations from the same source, thus solving the problem that the existing technology of multi-person collaborative modeling and arrangement is complex and prone to conflicts.

[0189] 2) The multi-terminal collaborative model development device of this application includes: a first processing unit receiving a model development task and decomposing it into multiple development sub-tasks based on the model structure and model actions carried by the task; a communication unit establishing communication connections with each developer terminal and distributing the development sub-tasks to each developer terminal; a first listening unit in a first listening step, upon detecting an editing action on a developer terminal, creating a corresponding model development transaction and a corresponding read view, the read view including at least the transaction ID of the model development transaction; a second listening unit in a second listening step, upon detecting a save action on a developer terminal, acquiring the editing result of the model development transaction and storing the editing result according to the read view; a repeating unit repeating the first and second listening steps at least once until all development sub-tasks have corresponding editing results and there are no unsaved model development transactions in the system; and a second processing unit assembling the editing results corresponding to each development sub-task to obtain the target model. This application achieves version control by reading user operations during the collaborative modeling process in real time and then uniquely identifying each user's operation through a read view. This ensures that the operations of different users are isolated, and different users can read the latest saved model version in real time. At the same time, storing the editing results of different users based on the read view can avoid storage conflicts between operations from the same source, thus solving the problem that the existing technology of multi-person collaborative modeling and arrangement is complex and prone to conflicts.

[0190] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for developing a multi-terminal collaborative model, characterized in that, include: Receive a model development task, and decompose the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task; Establish communication connections with each developer terminal and distribute the development subtasks to each developer terminal; The first listening step involves, upon detecting an editing action on the developer's terminal, creating a corresponding model development transaction and a read view corresponding to the model development transaction, wherein the read view includes at least the transaction ID of the model development transaction. The second monitoring step involves, upon detecting a save action on the developer's terminal, obtaining the editing result of the model development transaction and storing the editing result according to the read view; Repeat the first listening step and the second listening step at least once, until all the development subtasks have corresponding editing results and there are no unsaved model development transactions in the system; The editing results corresponding to each of the development sub-tasks are assembled to obtain the target model.

2. The method according to claim 1, characterized in that, After distributing the development subtasks to each developer's terminal, the method further includes: According to the read view, each of the model development transactions is traversed sequentially to determine the editing status of each of the model development transactions; The edit result whose edit status is saved and corresponds to the maximum value of the transaction ID of the read view is determined as the current model status; A first instruction is generated based on the current model state and sent to all developer terminals of the development subtask to which the current model state belongs. The first instruction is used to instruct the developer terminals to visualize the current model state.

3. The method according to claim 1, characterized in that, Creating the read view corresponding to the model development transaction includes: Determine the transaction ID of the currently created model development transaction to obtain the first transaction ID; Obtain the transaction ID of each first target transaction to obtain multiple second transaction IDs. The first target transaction is the model development transaction that is the same as the development subtask to which the currently created model development transaction belongs and is in the editing stage. Determine the minimum value of the second transaction ID to obtain the third transaction ID, and determine the maximum value of the second transaction ID to obtain the fourth transaction ID; The first transaction ID, each of the second transaction IDs, the third transaction ID, and the fourth transaction ID are concatenated sequentially to obtain the read view.

4. The method according to claim 1, characterized in that, After creating the corresponding model development transaction and the corresponding read view for the model development transaction, the method further includes: If a component addition operation is detected on the developer terminal, determine whether each developer terminal has an existing component that is the same as the added component; If an existing component exists that is identical to the newly added component, the component ID of the existing component is determined as the component ID of the newly added component; If no existing component is identical to the newly added component, the snowflake algorithm is used to generate the component ID of the newly added component.

5. The method according to claim 4, characterized in that, The snowflake algorithm is used to generate the component ID of the newly added component, including: Obtain the generation timestamp of the newly added component to get the first serial number; Determine the model ID corresponding to the newly added component and the terminal ID of the developer terminal that created the newly added component to obtain the second serial number; Determine the creation order of the newly added components to obtain the third sequence number; The first serial number, the second serial number, and the third serial number are concatenated sequentially to obtain the component ID of the newly added component.

6. The method according to claim 1, characterized in that, Storing the editing results according to the read view includes: The original version of the edit result is determined based on the development subtask to which the edit result belongs and the corresponding read view; Determine whether the target edit result is consistent with the original version. The target edit result is the edit result that is stored in the system and belongs to the same development subtask as the original edit result. If the target edit result is consistent with the original version, the target edit result is overwritten using the edit result. If the target edit result is inconsistent with the original version, the edit result and the target edit result are compared according to the component ID, and the edit result is stored according to the comparison result.

7. The method according to claim 6, characterized in that, The editing results are stored based on the comparison results, including: The added component of the edit result relative to the original version is determined as the first target component, and the added component of the target edit result relative to the original version is determined as the second target component; The edited result relative to the original version of the deleted component is determined as the third target component, and the target edited result relative to the original version of the deleted component is determined as the fourth target component; The edit result relative to the original version's revision component is determined as the fifth target component, and the target edit result relative to the original version's revision component is determined as the sixth target component; If the first, second, and third conditions are met simultaneously, the editing result is used to overwrite the target editing result. The first condition is that the first target component and the second target component do not overlap. The second condition is that the third target component and the fourth target component do not overlap. The third condition is that the fifth target component and the sixth target component do not overlap. If any one of the first condition, the second condition, and the third condition is not met, add target identifiers to the duplicate components between the first target component and the second target component, the duplicate components between the third target component and the fourth target component, and the duplicate components between the fifth target component and the sixth target component; The edited result with the target identifier and the target edited result are sent to the administrator terminal.

8. A multi-terminal collaborative model development device, characterized in that, The device includes: The first processing unit is used to receive the model development task and decompose the model development task into multiple development sub-tasks according to the model structure and model actions carried by the model development task. A communication unit is used to establish a communication connection with each developer terminal and to distribute the development subtasks to each developer terminal. The first listening unit is used in the first listening step. When the editing action of the developer terminal is detected, the unit creates a corresponding model development transaction and a read view corresponding to the model development transaction. The read view includes at least the transaction ID of the model development transaction. The second listening unit is used in the second listening step. When the save action of the developer terminal is detected, the unit obtains the editing result of the model development transaction and stores the editing result according to the read view. The repeating unit is used to repeat the first listening step and the second listening step at least once in sequence until all the development subtasks have corresponding editing results and there are no unsaved model development transactions in the system; The second processing unit is used to assemble the editing results corresponding to each of the development sub-tasks to obtain the target model.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 7.

10. A collaborative development system, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising methods for performing any one of claims 1 to 7.

Images