A conflict detection method based on software collaborative development and related products

Abstract

The application relates to the technical field of software development, in particular to a conflict detection method based on software collaborative development and related products, wherein an original software model and / or an original software document is uniformly formalized modeling according to a preset structure to obtain a corresponding original unified structure; an operation sequence on the original unified structure is determined according to modification operations of a user on the original software model and / or the original software document; whether each operation action contained in the operation sequence conflicts on the original unified structure is judged; a conflict sequence is determined based on the conflict judgment result of the operation sequence, and the conflict sequence is used to represent a conflict problem existing in the modification operations of the user on the original software model and / or the original software document. The formalized model of the unified structure is constructed, multi-dimensional elements of the software model and the software document are accurately mathematically defined, and the identification precision of model layer conflicts can be effectively improved.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a conflict detection method and related products based on collaborative software development. Background Technology

[0002] As software systems become increasingly complex, the Unified Modeling Language (UML), as a core modeling tool in software engineering, plays an irreplaceable role in requirements analysis, system design, and team collaboration. However, in multi-user collaborative development scenarios, frequent modifications to UML models often lead to merge conflicts between different versions. For example, in a multi-user distributed development environment, different developers may delete model elements or adjust dependencies in the same version of the design model. If these conflicts are not detected and handled in a timely manner, model inconsistencies will occur, thereby affecting software quality and development efficiency.

[0003] Existing control tools, such as the Distributed Version Control System (Git), are used to track file changes, facilitating collaborative development and managing different versions of a project. With Git, developers can record every modification to a file, revert to historical versions, and its branch management feature allows team members to develop different features in parallel before merging them into the main version, greatly improving development efficiency and project management flexibility. On the one hand, it provides conflict detection mechanisms at the code level; on the other hand, in the realm of real-time collaborative documents, it ensures data consistency through Operational Transformation (OT) and Conflict-Free Replicated Data Types (CRDTs).

[0004] However, existing control tools for conflict management in collaborative model design and development are limited to differences at the syntactic and behavioral levels. They lack targeted support for the structural features of the model (such as hierarchical relationships and dynamic dependencies between model elements, inclusion relationships, dependencies, and constraints between elements), and cannot effectively identify and handle semantic conflicts caused by changes in the structural features of the model. This leads to missed or false detections of conflicts, resulting in low accuracy in identifying model-level conflicts and making it difficult to provide developers with clear conflict tracing and decision support. Summary of the Invention

[0005] This application aims to provide a conflict detection method and related products based on collaborative software development, to provide systematic conflict management support for collaborative software development, and to promote the efficient practice of Model-Driven Engineering (MDE).

[0006] Specifically, this is achieved through the following technical solutions:

[0007] In a first aspect, this application provides a conflict detection method based on collaborative software development, comprising: performing a unified formal modeling of the original software model and / or the original software document according to a preset structure to obtain an original unified structure corresponding to the original software model and / or the original software document; determining an operation sequence on the original unified structure based on the modification operations performed by the user on the original software model and / or the original software document, the operation sequence including at least one operation action; traversing the operation sequence and determining whether each operation action conflicts on the original unified structure; determining a conflict sequence based on the conflict determination result of the operation sequence, the conflict sequence being used to characterize the conflict problems existing in the modification operations performed by the user on the original software model and / or the original software document.

[0008] Secondly, this application provides a conflict detection system based on software collaborative development, comprising:

[0009] The unified structure modeling module is used to perform unified formal modeling of the original software model and / or the original software document according to a preset structure, so as to obtain the original unified structure corresponding to the original software model and / or the original software document.

[0010] An operation sequence determination module is used to determine an operation sequence on the original unified structure based on the user's modification operations on the original software model and / or the original software document, wherein the operation sequence includes at least one operation action.

[0011] An operation conflict detection module is used to traverse the operation sequence and determine whether each operation action conflicts with the original unified structure.

[0012] The conflict sequence determination module determines a conflict sequence based on the conflict judgment result of the operation sequence. The conflict sequence is used to characterize the conflict problems existing in the modification operations performed by the user on the original software model and / or the original software document.

[0013] Thirdly, this application provides an electronic device comprising: at least one processor; a memory communicatively connected to the at least one processor; and a computer program stored in the memory and running on the at least one processor; wherein, when the at least one processor executes the computer program, it is used to implement the conflict detection method based on software collaborative development described in the first aspect above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium, wherein a computer program present in the computer-readable storage medium, when executed by a computer device, is used to implement the conflict detection method based on software collaborative development described in the first aspect.

[0015] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a computer device, is used to implement the conflict detection method based on software collaborative development described in the first aspect.

[0016] As shown above, this application addresses the version conflict problem of software models and software documents caused by parallel modifications in multi-user collaborative software development. By constructing a formal model with the aforementioned unified structure, it provides precise mathematical definitions for the multi-dimensional elements of software models and software documents, offering a solid theoretical foundation for conflict detection. Based on this formal model with a unified structure, operations between models can be further formally defined, and various deep semantic conflicts that are difficult to identify in traditional version control tools, such as conflicts involving the deletion of model elements, the deletion of dependencies, and the addition of dependencies, along with their logical conditions, can be precisely defined. This elevates conflict detection from traditional textual syntax comparison to a formal structural and semantic analysis level, providing systematic conflict management support for collaborative software development and effectively promoting the efficient practice of model-driven engineering. It solves the technical problem that existing control tools cannot effectively identify and handle semantic conflicts caused by changes in the structural features of software models or software documents, resulting in missed or false detections. This improves the accuracy of model-level conflict identification and facilitates providing developers with clear conflict tracing and decision support.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a conflict detection method based on software collaborative development, provided for an embodiment of this application;

[0020] Figure 2 Class diagram of the e-commerce management system provided in the embodiments of this application;

[0021] Figure 3 An example diagram illustrating the unified structure of software documentation generated using a developed prototyping tool, provided for embodiments of this application.

[0022] Figure 4 The modified class diagram of the e-commerce management system provided in the embodiments of this application;

[0023] Figure 5 A class diagram of the e-commerce management system before and after modification, provided for an embodiment of this application;

[0024] Figure 6 This is a class diagram for deleting conflicting model elements provided in an embodiment of this application;

[0025] Figure 7 This application provides a class diagram for deleting dependency conflicts in an embodiment.

[0026] Figure 8 The UML class diagram of the e-commerce management system provided by developers A and B before modification in the embodiments of this application;

[0027] Figure 9 The UML class diagrams of the e-commerce management system modified by developers A and B respectively, provided in the embodiments of this application;

[0028] Figure 10 A schematic diagram illustrating the conflict detection results for developers A and B respectively modifying the UML class diagram of the e-commerce management system, as provided in this embodiment of the application.

[0029] Figure 11 A schematic diagram of the structure of a conflict detection system based on software collaborative development provided in this application embodiment;

[0030] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0032] Example 1

[0033] Please see Figure 1 , Figure 1 This is a flowchart illustrating a conflict detection method based on software collaborative development, provided as an embodiment of this application. Figure 1 As shown, this conflict detection method based on software collaborative development includes the following:

[0034] 101. Perform unified formal modeling on the original software model and / or the original software document according to a preset structure to obtain the original unified structure corresponding to the original software model and / or the original software document.

[0035] Software models are typically constructed using the Unified Modeling Language (UML), data flow diagrams, or ER diagrams (Entity-Relationship Diagrams). UML, as the most important visual modeling language in this field, aims to provide a standardized, graphical modeling method for software systems. Through a series of precisely defined graphical symbols, such as class diagrams, sequence diagrams, and state diagrams, it abstracts complex software systems into views that can be understood and communicated by developers from different backgrounds, describing the system's static structure, dynamic behavior, and interaction relationships. It can also abstract complex systems into structured, machine-understandable semi-formal models. It is this semi-formal characteristic that lays the foundation for the subsequent precise conflict detection and formal analysis in the embodiments of this application.

[0036] This application embodiment performs unified formal modeling of the original software model according to a preset structure, and analyzes and represents the UML model from a structural level. This unified structure is defined as a multivariate array, which includes a set of model elements, a set of containment relationships between model elements, a set of dependency classifications, a set of constraints on model elements, a set of constraints on dependencies, and a set of model element classifications.

[0037] For example, the original software model is formally modeled according to a preset structure to obtain the original unified structure corresponding to the original software model.

[0038] in,

[0039] ME0 is the set of model elements;

[0040] This represents a set of containment relationships between model elements. For example This means that x0 is contained in y0;

[0041] Represents the set of dependencies of type j. For example, for all but This is called a dependency relationship, where x0 is the dependent subject of the dependency relationship, y0 is the dependent object of the dependency relationship, that is, x0 depends on y0, and j represents the type of the dependency relationship;

[0042] This represents the set of constraints on model elements. Any model element in the unified structure has only one constraint. If a model element b has one constraint a, i.e., ... Then it is represented as

[0043] This represents the set of constraints for a dependency relationship. Similarly, any dependency relationship in a unified structure has only one constraint. If the dependency relationship (x0, y0) has a constraint h, that is... Then it is represented as

[0044] Represents the set of elements of the i-th type of model. Right now, Used to classify model elements; for example, model elements in the software development process can be divided into requirement, design, implementation, testing, and code types; the corresponding model element type sets include requirement set, design set, implementation set, test set, and code set, which can be represented as follows: as well as

[0045] It should be noted that a constraint can also be a model element; that is, a model element can also be a constraint.

[0046] The following example illustrates this:

[0047] Please refer to Figure 2 , Figure 2 The class diagram of the e-commerce management system provided in the embodiments of this application is as follows: Figure 2The diagram shown illustrates a class diagram of an e-commerce management system, which is represented according to the unified structure described above:

[0048]

[0049] in,

[0050] ME={Cashier,Order,products,totalAmounts,calculateTotal(),Employee,work(),Manager,managerStock(),Product,price,Inventory,[Cashierend:1,checkout,Orderend:1...*],[Manager_end:1...*,manage,Inventory_end:1...*]};

[0051]

[0052]

[0053] It should be noted that, as mentioned above, ME is the combination of all model elements in the model, including classes, attributes, methods, and relationships between classes; it also represents the containment relationship between model elements, for example, (products, Order) means that the Order class contains the attribute products; This indicates the association between classes. When the association does not have an explicit reference, it is represented as a bidirectional association. For example, the Order class and the Cashier class have a bidirectional association, represented as (Cashier, Order) or (Order, Cashier). Represents the inheritance relationship between classes (Cashier, Employee). Represents the constraints of model elements; Constraints that represent dependency relationships, for example, [Cashierend:1,checkout,Orderend:1...*] represents the constraint on the association relationship between the Cashier class and the Order class, where checkout represents the association name; Indicates the class name; Represents the attributes of a class; Represents the operations of a class; Indicates the associated name.

[0054] The following describes the specific implementation method for formally modeling the original software document according to a preset structure to obtain the original unified structure corresponding to the original software document:

[0055] One of the core objectives of this application is to extend the scope of application of the unified structure from structured UML models to traditional software documents, such as requirements specifications or design documents. These documents are traditionally considered large blocks of natural language text, which poses a significant challenge to version control and automated consistency maintenance. This application enables any software document to be transformed into a software model. Its internal logical elements, such as chapters and clauses, as well as the references, inclusions, and dependencies between elements, constitute a formalizable internal structure. Therefore, the software model and the software document are not clearly distinct but can be effectively unified; that is, any software document can be transformed into a software model, for example, using package diagrams in UML to model the document. The internal structure of the document can be explicitly expressed, so the document is no longer flat text but, like the UML model, becomes a structured object that can be automatically analyzed and verified. This application also unifies the detection and management of model conflicts between software documents and software models.

[0056] This application embodiment can efficiently convert the content of a regular document into a hierarchical unified structure (US) by traversing a single document. Specifically, a stack is used to maintain the document's structural depth and current path in real time. For each element in the document, a new node is first created. Then, by comparing the level of the new node with the level of the top element of the stack, a loop pop operation is used to accurately locate its parent node in the tree structure. Subsequently, the new node is added as a child node to the parent node, or, if no parent node is available, it is used as the new root node. Finally, the new node is pushed onto the stack to build the subsequent structure. After traversal, a unified structure model (US) that fully reflects the hierarchical structure of the original document is returned. This algorithm can be implemented by a computer program, as shown below:

[0057] 1

[0058] 2

[0059] 3 for each h in D do

[0060] 4 let newNode←new Node()

[0061] 5 while not head.isEmpty()and head.peek().level>←newNode.level

[0062] 6. head.pop()

[0063] 7 end while

[0064] 8. If not head.isEmpty() then

[0065] 9 let parent←head.peek()

[0066] 10. parent.addChild(newNode)

[0067] 11 else

[0068] 12. US.addRootNode(newNode)

[0069] 13 end if

[0070] 14. M.addNode(newNode)

[0071] 15. head.push(newNode)

[0072] 16 end for

[0073] 17 Return to US

[0074] The algorithm takes a standard original software document D0 as input and outputs the original unified structure US0 corresponding to the original software document D0, as described above. In this way, it achieves formal modeling not only of the original software model but also of the original software document according to a preset structure, obtaining the original unified structure corresponding to the original software model and / or the original software document. Figure 3 As shown, Figure 3This application provides an example diagram of a unified structure corresponding to software documentation generated using a prototype tool developed in this embodiment. This prototype tool was specifically developed by the applicant to solve the technical problem addressed in this application embodiment. It is implemented using web technology and achieves the purpose of validity verification through formal conflict detection based on a unified structure. The core objective of this prototype tool is to combine abstract theoretical models with actual collaborative development scenarios. It can load and convert UML class diagrams and software documentation into the aforementioned unified structure model, record user modification operations, and, based on the conflict detection method for software collaborative development proposed in this application embodiment, automatically analyze and report potential conflicts during the merging process. Its core visual operation interface is built using the JavaScript graphics library GoJS. GoJS is a powerful library specifically designed for building interactive diagrams and graphs, making it ideal for the dynamic rendering and manipulation of UML models. Furthermore, JavaScript, as a cross-platform interpreted scripting language, allows this tool to run without installation, solely within a browser environment, greatly facilitating theoretical verification and result demonstration.

[0075] 102. Based on the user's modification operations on the original software model and / or the original software documentation, determine the operation sequence on the original unified structure, the operation sequence including at least one operation action.

[0076] In this embodiment of the application, the specific implementation method may be as follows: based on the user's modification operations on the original software model and / or the original software document, obtain the modified first software model and / or the first software document; perform unified formal modeling on the first software model and / or the first software document according to the preset structure to obtain a first unified structure corresponding to the first software model and / or the first software document; determine the user's modification operations on the original software model and / or the original software document based on the original unified structure and the first unified structure; combine all the user's modification operations on the original software model and / or the original software document according to the operation order to obtain the operation sequence on the original unified structure.

[0077] As described above, the user modifies the original software model and / or the original software document to obtain the modified first software model and / or the first software document; referring to the aforementioned method, the first software model and / or the first software document are uniformly formalized and modeled according to the preset structure to obtain the first unified structure US1 corresponding to the first software model and / or the first software document.

[0078] Among them, let

[0079] It should be noted that the user may perform multiple modification operations on the original software model and / or the original software documentation. For example, after the first modification operation, a first unified structure US1 will be obtained. Then, for the second modification operation, the first unified structure US1 obtained after the first modification operation should be regarded as the original unified structure US0 at the time of the second modification operation. Therefore, the original unified structure US0 here is a relative concept, relative to the later modification operation, and so on.

[0080] Therefore, for a specific modification operation, based on the original unified structure and the first unified structure, the user's modification action on the original software model and / or the original software document is determined. A specific implementation may be as follows: subtract the first unified structure from the original unified structure to obtain a second unified structure; determine whether the model element set of the second unified structure is empty; if not, determine that the user has performed a first operation of deleting model elements on the original software model and / or the original software document; determine whether the dependency classification set of the second unified structure is empty; if not, determine that the user has performed a second operation of deleting dependencies on the original software model and / or the original software document; or...

[0081] Subtracting the original unified structure from the first unified structure yields a third unified structure; it is determined whether the model element set of the third unified structure is empty; if not, it is determined that the user has performed a third operation of adding model elements to the original software model and / or the original software document; it is determined whether the dependency classification set of the third unified structure is empty; if not, it is determined that the user has performed a fourth operation of adding dependencies to the original software model and / or the original software document.

[0082] Specifically, the first unified structure mentioned above refers to the new unified structure obtained after modifying the original unified structure. The definition of the new unified structure is explained below:

[0083] If the original unified structure US0 minus the first unified structure US1 yields the second unified structure US2, i.e., (US0US1) = US2. Wherein, Determine whether the model element set ME2 of the second unified structure US2 is empty. If ME2 ≠ 0, it is determined that the user has performed a first operation of deleting model elements on the original software model and / or the original software document. US1 is then called a unified structure that has partially deleted model elements from US0. It is understood that if ME2 = 0, it is determined that the user has not performed an operation of deleting partial model elements on the original software model and / or the original software document.

[0084] Similarly, if the first unified structure US1 minus the original unified structure US0 yields the third unified structure US3, i.e., (US1US0) = US3. Wherein, Determine whether the model element set ME3 of the third unified structure US3 is empty. If ME3 ≠ 0, it is determined that the user has performed a third operation to add model elements to the original software model and / or the original software document. US1 is then called a unified structure that adds some model elements to US0. It is understood that if ME3 = 0, it is determined that the user has not performed an operation to add model elements to the original software model and / or the original software document.

[0085] For example, such as Figure 4 As shown, Figure 4 The modified class diagram of the e-commerce management system provided in the embodiments of this application; that is, Figure 4 For users regarding the above Figure 2 The modified class diagram of the e-commerce management system, as described above, has the following unified structural representation:

[0086]

[0087] in,

[0088] ME new ={Cashier,Order,products,totalAmounts,calculateTotal(),Employee,work(),Product,price,Inventory,[Cashierend:1,checkout,Orderend:1...*]};

[0089] new ={(products,Order),(totalAmounts,Order),(calculateTotal(),Order),(work(),Employee),(price,Product),(products,Inventory)};

[0090]

[0091]

[0092] pass Figure 2 reduce Figure 4 The difference between the two unified structural models is obtained, i.e., (CD CD) new ),like Figure 5 As shown, Figure 5The class diagram of the e-commerce management system before and after modification provided in the embodiments of this application is as follows: Figure 5 The corresponding unified structure (i.e., (CDCD)) new )) represents the following:

[0093]

[0094] in,

[0095] ME difference ={Manager,managerStock(),Employee,Inventory,products,work(),[Manager_end:1...*,manage,Inventory_end:1...*]};

[0096] difference ={(work(),Employee),(managerStock(),Manager),(products,Inventory)};

[0097]

[0098] It should be noted that this application defines a difference between two unified structures. When a deleted model element has a dependency on a retained model element, the deletion operation saves this dependency to the new unified structure obtained after modification, for subsequent conflict detection or merging modifications. This operation aims to calculate a new difference model representing the changed content. This difference model not only includes the core elements removed from the unified structure of the original model, but more importantly, it specifically preserves the dependencies and related constraints between these removed elements and other elements. This design is crucial for subsequent conflict detection analysis because it ensures that the complete context of the change is preserved.

[0099] Based on the unified structure defined above, this application embodiment decomposes any complex model modification process into four basic atomic operations, and provides a precise mathematical description for each operation, as shown below:

[0100] (1) Delete model elements

[0101] For example, the operation of deleting a model element e from the original unified structure US0 is denoted as... Then, US0 performs the operation of deleting model element e to obtain a new unified structure, which is represented by the first unified structure US1 mentioned above:

[0102] here

[0103] in,

[0104]

[0105] (2) Delete dependencies

[0106] For example, the operation of deleting a dependency {(x0,y0)} from the original unified structure US0 is denoted as... We obtain a new unified structure, which can still be represented using the first unified structure US1 mentioned above:

[0107] here

[0108] in,

[0109]

[0110]

[0111]

[0112] (3) Add model elements

[0113] For example, the operation of inserting a model element e into the original uniform structure US0 is denoted as... Then, US0 performs the operation of adding model element e to obtain a new unified structure, which is represented by the first unified structure US1 mentioned above:

[0114] here

[0115] in,

[0116]

[0117]

[0118]

[0119] (4) Increase dependencies

[0120] For example, the operation of inserting a dependency {(x0,y0)} into the original unified structure US0 is denoted as... Then, US0 performs the operation of adding the dependency {(x0,y0)} to obtain a new unified structure, which is represented by the first unified structure US1 mentioned above:

[0121]

[0122] here

[0123] in,

[0124]

[0125]

[0126]

[0127]

[0128]

[0129] By formally defining the addition and deletion operations in a unified structure, a mathematical basis for accurately identifying conflicts is provided for version management and collaborative development of software models and software documentation.

[0130] In real-world scenarios involving multi-user collaborative development, modifications to the software model typically manifest as a series of sequential operations. This application will further explore the potential problems arising from the combined execution of these operations. The core objective is to establish a formal framework for identifying and defining modification conflicts between software model versions.

[0131] If there exists an operation sequence S = A1...A n , i{1,...n}:A i Belongs to the above and One of the operations, namely, the four most basic atomic operations mentioned above constitute the operation sequence described in this application embodiment. By identifying the modification operations performed by the user on the original software model and / or the original software document (the specific implementation method is as described above, identifying the determined modification operation type and the operation timestamp, the operation sequence on the original unified structure can be determined), the operation sequence on the original unified structure is determined, and the operation sequence includes at least one operation action. Then S is called an operation sequence on US0, and [S] represents all the operation actions contained in the sequence S, that is, [S] = {A1,...,A...} n If there exist two operation sequences S = A1...A2... n And S` = B1...B m Then the combination of S and S' is represented as SS' = A1...A n B1...B m If performing an operation sequence S on US0 results in a new unified structure US1, then it is represented as follows:

[0132] 103. Traverse the operation sequence and determine whether each operation action conflicts with the original unified structure.

[0133] The above embodiments provide a detailed explanation of how to identify user modifications to the original software model and / or the original software documentation, and how to determine the operation sequence on the original unified structure based on the identified modifications. After determining the operation sequence on the original unified structure, it is necessary to determine whether each operation conflicts with the original unified structure based on the operation sequence. A specific implementation method may be:

[0134] Step 1: Identify the type of the current operation, specifically including the above. and The specific implementation method of this step can be referred to step 102 above, and will not be repeated here.

[0135] Step 2: Determine whether the current operation conflicts with the original unified structure based on the type of the current operation, as shown below:

[0136] (1) If the current operation is the first operation of deleting model elements

[0137] Determine whether the deleted model element belongs to the set of model elements of the original unified structure; if so, determine that the current operation is legal in the original unified structure; otherwise, determine that the current operation conflicts with the original unified structure.

[0138] Specifically, suppose there exists an operation sequence S = A1...A n And there exist n+1 unified structures US0, US1, ..., US n , making If A i+1 It is the first operation to delete model elements. Then determine whether the deleted model element belongs to the set of model elements of the original unified structure. If e ME i Then determine the current first operation action. It is legal on the original unified structure.

[0139] Otherwise, i.e., e ME i Then it is called the current first operation. This is in conflict with the original unified structure. For example... Figure 6 As shown, Figure 6 The class diagram for deleting model elements provided in this application embodiment involves an original class diagram that undergoes two different operation sequences S1 and S2, both of which simultaneously delete the Manager class. Therefore, a conflict in deleting model elements will occur during merging.

[0140] (2) If the current operation is the second operation that deletes the dependency.

[0141] Determine whether the deleted dependency belongs to the dependency classification set of the original unified structure; if so, determine that the current operation is legal in the original unified structure; otherwise, determine that the current operation conflicts in the original unified structure.

[0142] Specifically, as mentioned above, if A i+1 This is the second action to delete the dependency. Then determine whether the deleted dependency belongs to the dependency classification set of the original unified structure. If... Then determine the current second operation action. It is legal on the original unified structure.

[0143] Otherwise, that is This is called the current second operation. The original unified structure involves removing dependency conflicts. For example... Figure 7 As shown, Figure 7 This is a class diagram for deleting dependency conflicts provided in an embodiment of this application. Figure 7 As shown, an original class diagram goes through two different operation sequences S3 and S4. However, operation sequence S3 removes the Employee class and its generalization relationship with the Cashier and Manager classes, while operation sequence S4 also removes the generalization relationship between the Manager class and the Employee class. Therefore, a dependency deletion conflict will occur during subsequent merging.

[0144] (3) If the current operation is the third operation of adding model elements

[0145] It can be directly determined that the current operation is legal within the original unified structure.

[0146] Specifically, since the operation of inserting a model element does not conflict with any other operation, adding the operation of inserting a model element at any point in a valid sequence will still make the sequence valid. That is, adding the operation of inserting a model element at any position in a valid sequence will not affect its validity. For example, considering the original unified structure US0 and the first unified structure US1, suppose there exists a valid operation sequence S on US0. Therefore, the operation sequence S is also valid on US1, and the operation sequence S is valid on US1. It is also legal.

[0147] It should be noted that, among them and These respectively represent: US0 is a substructure of US1, and a combination of US0 and US1.

[0148] In UML behavioral diagrams, there is a type of element node that represents a reference to a part of the diagram, allowing it to be referenced multiple times by diagrams of the same type. This reference relationship is defined through substructures with a unified structure. As mentioned above, if Then US0 is called a substructure of US1, denoted as:

[0149]

[0150] in,

[0151]

[0152] Then US0 and US1 are said to be composable, denoted as: Any two unified structures can be combined into a new unified structure.

[0153] Therefore, if A i+1 It is the third operation to add model elements. This directly confirms that the current operation is legal within the original unified structure.

[0154] (4) If the current operation is the fourth operation that adds a dependency.

[0155] Determine whether both the dependent subject and the dependent object in the added dependency relationship belong to the model element set of the original unified structure; if so, determine that the current operation is legal in the original unified structure; otherwise, determine that the current operation conflicts in the original unified structure.

[0156] Specifically, as mentioned above, if A i+1 It is the fourth operation to add dependencies. Then determine whether both the dependent subject and the dependent object in the added dependency relationship belong to the set of model elements of the original unified structure. If x0ME i y0ME i Then determine the current fourth operation action. It is valid on the original unified structure. Otherwise, i.e., x0ME i y0ME i Then the current fourth operation is called Add dependency conflicts to the original unified structure.

[0157] Step 3: Return to Step 1 above and repeat until the operation sequence has been traversed. This determines which operations in the operation sequence conflict with the original unified structure.

[0158] This application embodiment systematically identifies logical and temporal conflicts by sequentially traversing an operation sequence. Each operation is compared with an initial unified structure US0 and a dynamically recorded list of processed operations to perform comprehensive validity verification. Specifically, it checks whether a deletion operation targets a non-existent model element or whether there is duplicate deletion; simultaneously, for dependency deletion or insertion operations, the system rigorously verifies the existence of its endpoint elements in the initial unified structure US0 and throughout the entire operation sequence to ensure that no operation is performed on deleted elements. Whenever an inconsistency is found, the system records a detailed conflict and, after completing all checks, returns a sequence containing all identified conflicts, i.e., the conflict sequence described in this application embodiment.

[0159] In one feasible implementation, determining whether each operation conflicts with the original unified structure further includes:

[0160] If the original unified structure includes at least one fourth unified structure, then it is determined whether the current operation action conflicts with any of the fourth unified structures. If the current operation action is legal on the fourth unified structure, then it is determined that the current operation action is legal in the original unified structure. Wherein, the fourth unified structure is a substructure of the original unified structure. The above steps are executed repeatedly until the operation sequence is traversed.

[0161] Specifically, for the original unified structure US0 and the fourth unified structure US4, suppose there exists a valid operation sequence S on US4, meaning that the operations of deleting model elements, deleting dependencies, and adding dependencies will not cause conflicts on US4, because... Any operation that could cause a conflict, such as deleting a model element, removing a dependency, or adding a dependency, is actually executed on US0 when performed on US4. Therefore, the operation sequence S is also valid on US0. This helps reduce the computational cost of conflict detection and improves its efficiency.

[0162] There is another situation, if The original unified structure US0 can also be described as including at least one fourth unified structure US4. US5 here is essentially also the fourth unified structure in the embodiments of this application; however, it is referred to as US5 for ease of description. If the operation sequence S is valid on US4, it means that the operations of deleting model elements, deleting dependencies, and adding dependencies will not cause conflicts on US4, since US4 is... Substructures, any operations that can cause conflicts, such as deleting model elements, deleting dependencies, or adding dependencies, are actually executed in US4 within the substructure. Executed on, therefore, the operation sequence S is in It is also legal.

[0163] That is, the above shows that a valid sequence of operations on a substructure (including the operations contained therein) is also valid on its parent structure.

[0164] It should be noted that the difference and combination operations of the unified structures in this embodiment are reasonable and can ensure that the original information is not lost during model merging. For example, if there are two composable unified structures US0 and US1, and let US0US1 = US6, then US6 is a substructure of US0.

[0165]

[0166] The elements in ME1 must belong to ME6ME1, therefore, ME1ME6 ME1.

[0167] Similarly, 161; Therefore, US0 is Substructures of.

[0168] 104. Determine a conflict sequence based on the conflict judgment result of the operation sequence, wherein the conflict sequence is used to characterize the conflict issues existing in the modification operations performed by the user on the original software model and / or the original software document.

[0169] Based on the conflict judgment results of the above operation sequence on the original unified structure, a conflict sequence is determined. The conflict sequence is used to characterize the conflict problems existing in the modification operations performed by the user on the original software model and / or the original software document.

[0170] To verify the effectiveness of the conflict detection method based on software collaborative development provided in this application embodiment, a specific application example scenario is described below:

[0171] like Figure 8 and Figure 9 As shown, Figure 8 This is a UML class diagram of the e-commerce management system provided by developers A and B before modifications in this application embodiment. Figure 9 The UML class diagrams of the e-commerce management system modified by developers A and B respectively, provided in the embodiments of this application;

[0172] This example starts with a basic version of an e-commerce management system UML class diagram (i.e., the original software model) and simulates two developers (Developer A and Developer B, i.e., the users mentioned above) making parallel modifications based on a unified baseline version.

[0173] Developer A's task is to delete the User class and remove all its associated dependencies with the Admin and Customer classes.

[0174] Developer B's task is to delete the User class, remove all its dependencies on the Admin and Customer classes, and establish the association between the Product and Order classes.

[0175] Then, the aforementioned prototyping tool was used to record a series of operations performed by the two developers on the graphical interface. These operations were automatically converted by the system into two independent operation sequences. These two operation sequences contained the aforementioned four atomic operation actions and were used as direct input data for the conflict detection method in this application embodiment, thereby simulating a scenario in the real world where multiple users make concurrent modifications that need to be merged.

[0176] After preparing two sets of operation sequences representing modifications made by developers A and B, the conflict detection engine in the prototyping tool is activated. This engine implements the conflict detection method described in the embodiments of this application, and analyzes the two operation sequences after merging them to identify semantic conflicts.

[0177] like Figure 10 As shown, Figure 10 This diagram illustrates the conflict detection results for modifications made by developers A and B to the UML class diagram of the e-commerce management system, as provided in this embodiment of the application. It can be seen that the conflict detection method based on collaborative software development described in this embodiment can accurately detect three conflicts (conflict sequences) in this instance:

[0178] (1) Conflict in removing dependency relationship (the association dependency between User class and Admin class) because developers A and B are both operating on removing the association dependency between User class and Admin class at the same time.

[0179] (2) Conflict in removing dependency relationship (the association dependency between User class and Customer class) because developers A and B are both operating on removing the association dependency between User class and Customer class at the same time.

[0180] (3) Conflict in deleting the User class model element, because developer A deleted the User class, while developer B was also deleting the User class at the same time.

[0181] As can be seen, the conflict detection method based on software collaborative development described in this application embodiment can accurately and automatically identify deep-seated structured and semantic conflicts that are difficult for traditional version control systems to detect, thus powerfully verifying the practical value of the formal framework and detection algorithm of the conflict detection method based on software collaborative development described in this application embodiment in ensuring model consistency.

[0182] In summary, this application addresses the version conflict problem of software models and software documents caused by parallel modifications in multi-user software collaborative development. By constructing the aforementioned unified formal model, it provides precise mathematical definitions for the multi-dimensional elements of UML models and software documents, offering a solid theoretical foundation for conflict detection. Based on this unified formal model, operations between models can be further formally defined, and various deep semantic conflicts and their logical conditions that are difficult to identify in traditional version control tools, such as conflicts involving deleting model elements, deleting dependencies, and adding dependencies, can be precisely identified. Finally, through the design of prototype tools and case studies, the effectiveness of the conflict detection method based on collaborative software development described in this application in automatically identifying these structured conflicts was verified. The core purpose of this invention is to elevate conflict detection from traditional text syntax comparison to a formal structural and semantic analysis level, providing systematic conflict management support for collaborative software development and effectively promoting the efficient practice of model-driven engineering. It solves the technical problem that existing control tools cannot effectively identify and handle semantic conflicts that are missed or falsely detected due to changes in the structured features of software models or software documents, improves the accuracy of conflict identification at the model level, and is conducive to providing developers with clear conflict tracing and decision support.

[0183] Example 2

[0184] The above combination Figures 1 to 10 This application provides a detailed description of a conflict detection method based on software collaborative development, as illustrated in its embodiments. The following is in conjunction with... Figure 11 This document describes in detail a conflict detection system based on software collaborative development, which is used to implement a conflict detection method based on software collaborative development provided in the embodiments of this application. Figure 11 A schematic diagram of a conflict detection system based on software collaborative development is provided in this application embodiment; please refer to... Figure 11 The system includes the following:

[0185] The unified structure modeling module 1101 is used to perform unified formal modeling of the original software model and / or the original software document according to a preset structure to obtain the original unified structure corresponding to the original software model and / or the original software document.

[0186] The operation sequence determination module 1102 is used to determine the operation sequence on the original unified structure based on the modification operations performed by the user on the original software model and / or the original software document, wherein the operation sequence includes at least one operation action.

[0187] The operation conflict detection module 1103 is used to traverse the operation sequence and determine whether each operation action conflicts with the original unified structure.

[0188] The conflict sequence determination module 1104 determines a conflict sequence based on the conflict judgment result of the operation sequence. The conflict sequence is used to characterize the conflict problems existing in the modification operations performed by the user on the original software model and / or the original software document.

[0189] In a preferred embodiment, the original unified structure is a multivariate array, which includes a set of model elements, a set of inclusion relationships between model elements, a set of dependency relationship categories, a set of constraint conditions for model elements, a set of constraint conditions for dependency relationships, and a set of model element categories.

[0190] In a preferred embodiment, the operation sequence determination module 1102 is specifically used for: obtaining a modified first software model and / or first software document based on the user's modification operations on the original software model and / or the original software document; performing unified formal modeling on the first software model and / or the first software document according to the preset structure to obtain a first unified structure corresponding to the first software model and / or the first software document; determining the user's modification operations on the original software model and / or the original software document based on the original unified structure and the first unified structure; and combining all the user's modification operations on the original software model and / or the original software document in the order of operation to obtain an operation sequence on the original unified structure.

[0191] In a preferred embodiment, the operation sequence determination module 1102 is further configured to: subtract the first unified structure from the original unified structure to obtain a second unified structure; determine whether the model element set of the second unified structure is empty; if not, determine that the user has performed a first operation action of deleting model elements on the original software model and / or the original software document; determine whether the dependency classification set of the second unified structure is empty; if not, determine that the user has performed a second operation action of deleting dependencies on the original software model and / or the original software document; or,

[0192] Subtracting the original unified structure from the first unified structure yields a third unified structure; it is determined whether the model element set of the third unified structure is empty; if not, it is determined that the user has performed a third operation of adding model elements to the original software model and / or the original software document; it is determined whether the dependency classification set of the third unified structure is empty; if not, it is determined that the user has performed a fourth operation of adding dependencies to the original software model and / or the original software document.

[0193] In a preferred embodiment, the operation conflict detection module 1103 is specifically used for: identifying the type of the current operation action; if the current operation action is a first operation action of deleting a model element, then determining whether the deleted model element belongs to the model element set of the original unified structure; if yes, then determining that the current operation action is legal in the original unified structure; otherwise, determining that the current operation action conflicts in the original unified structure; if the current operation action is a second operation action of deleting a dependency relationship, then determining whether the deleted dependency relationship belongs to the dependency relationship classification set of the original unified structure; if yes, then determining that the current operation action is legal in the original unified structure; otherwise, determining that the current operation action conflicts in the original unified structure; if the current operation action is a third operation action of adding a model element, then determining that the current operation action is legal in the original unified structure; if the current operation action is a fourth operation action of adding a dependency relationship, then determining whether the dependent subject and the dependent object in the added dependency relationship both belong to the model element set of the original unified structure; if yes, then determining that the current operation action is legal in the original unified structure; otherwise, determining that the current operation action conflicts in the original unified structure; returning to the process of identifying the type of the current operation action until the operation sequence is traversed.

[0194] In a preferred embodiment, the operation conflict detection module 1103 is further configured to: if the original unified structure includes at least one fourth unified structure, determine whether the current operation action conflicts with any of the fourth unified structures; if the current operation action is legal on the fourth unified structure, determine that the current operation action is legal in the original unified structure; wherein, the fourth unified structure is a substructure of the original unified structure.

[0195] The specific implementation method and technical effects of the conflict detection system based on software collaborative development can be referred to the aforementioned conflict detection method based on software collaborative development, and will not be repeated here.

[0196] Example 3

[0197] This invention also provides an electronic device. Figure 12 This is a structural diagram of an electronic device according to an embodiment of the present invention, such as... Figure 12 As shown, the electronic device includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1202 or a program loaded from a storage section 1208 into a random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204. The following components are connected to the I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. Drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0198] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0199] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention is not limited to the specific combination of the above-described technical features, but also includes other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A conflict detection method based on software collaborative development, characterized in that, include: The original software model and / or the original software document are formally modeled according to a preset structure to obtain the original unified structure corresponding to the original software model and / or the original software document. Based on the user's modification operations on the original software model and / or the original software documentation, determine the operation sequence on the original unified structure, the operation sequence including at least one operation action; Traverse the operation sequence and determine whether each operation action conflicts with the original unified structure; Based on the conflict judgment results of the operation sequence, a conflict sequence is determined. The conflict sequence is used to characterize the conflict issues existing in the modification operations performed by the user on the original software model and / or the original software document.

2. The conflict detection method based on software collaborative development as described in claim 1, characterized in that, The original unified structure is a multivariate array, which includes a set of model elements, a set of inclusion relationships between model elements, a set of dependency relationship categories, a set of constraints on model elements, a set of constraints on dependencies, and a set of model element categories.

3. The conflict detection method based on software collaborative development as described in claim 2, characterized in that, Based on the user's modification operations on the original software model and / or the original software documentation, determine the operation sequence on the original unified structure, including: Based on the user's modification operations on the original software model and / or the original software document, obtain the modified first software model and / or the first software document; The first software model and / or the first software document are modeled in a unified formalized manner according to the preset structure to obtain the first unified structure corresponding to the first software model and / or the first software document. Based on the original unified structure and the first unified structure, determine the user's operation actions to modify the original software model and / or the original software documentation; All user actions that modify the original software model and / or the original software documentation are combined in the order of operation to obtain the operation sequence on the original unified structure.

4. The conflict detection method based on software collaborative development as described in claim 3, characterized in that, Based on the original unified structure and the first unified structure, determine the user's actions to modify the original software model and / or the original software documentation, including: Subtracting the first unified structure from the original unified structure yields the second unified structure; Determine whether the set of model elements of the second unified structure is empty; If not, then it is determined that the user has performed the first operation of deleting model elements on the original software model and / or the original software document; Determine whether the dependency classification set of the second unified structure is empty; If not, then it is determined that the user has performed a second operation to delete dependencies on the original software model and / or the original software documentation; or, Subtracting the original unified structure from the first unified structure yields the third unified structure; Determine whether the set of model elements of the third unified structure is empty; If not, then it is determined that the user has performed a third operation to add model elements to the original software model and / or the original software document; Determine whether the dependency classification set of the third unified structure is empty; If not, then it is determined that the user has performed a fourth operation that adds dependencies to the original software model and / or the original software documentation.

5. The conflict detection method based on software collaborative development as described in claim 4, characterized in that, Determine whether each operation conflicts with the original unified structure, including: Step 1: Identify the type of the current operation. Step 2: If the current operation is the first operation of deleting a model element, then determine whether the deleted model element belongs to the model element set of the original unified structure; if yes, then determine that the current operation is legal in the original unified structure; otherwise, determine that the current operation conflicts in the original unified structure. If the current operation is the second operation of deleting a dependency, then determine whether the dependency to be deleted belongs to the dependency classification set of the original unified structure; if yes, then determine that the current operation is legal in the original unified structure; otherwise, determine that the current operation conflicts in the original unified structure. If the current operation is the third operation that adds a model element, then the current operation is determined to be valid on the original unified structure. If the current operation is the fourth operation that adds a dependency, then it is determined whether the dependent subject and the dependent object in the added dependency both belong to the model element set of the original unified structure; if so, the current operation is determined to be legal in the original unified structure; otherwise, the current operation is determined to be conflicting in the original unified structure. Step 3: Return to Step 1 above and repeat until the operation sequence has been traversed.

6. A conflict detection method based on software collaborative development as described in any one of claims 1 to 5, characterized in that, Determining whether each operation conflicts with the original unified structure also includes: If the original unified structure includes at least one fourth unified structure, then it is determined whether the current operation action conflicts with any of the fourth unified structures. If the current operation action is legal on the fourth unified structure, then it is determined that the current operation action is legal in the original unified structure; wherein, the fourth unified structure is a substructure of the original unified structure.

7. A conflict detection system based on software collaborative development, characterized in that, include: The unified structure modeling module is used to perform unified formal modeling of the original software model and / or the original software document according to a preset structure, so as to obtain the original unified structure corresponding to the original software model and / or the original software document. An operation sequence determination module is used to determine an operation sequence on the original unified structure based on the user's modification operations on the original software model and / or the original software document, wherein the operation sequence includes at least one operation action. An operation conflict detection module is used to traverse the operation sequence and determine whether each operation action conflicts with the original unified structure. The conflict sequence determination module determines a conflict sequence based on the conflict judgment result of the operation sequence. The conflict sequence is used to characterize the conflict problems existing in the modification operations performed by the user on the original software model and / or the original software document.

8. An electronic device, characterized in that, The electronic device includes: at least one processor; a memory communicatively connected to the at least one processor; and a computer program stored in the memory and running on the at least one processor; wherein, when the at least one processor executes the computer program, it is used to implement a conflict detection method based on software collaborative development as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer program present in the computer-readable storage medium, when executed by a computer device, is used to implement the conflict detection method based on software collaborative development as described in any one of claims 1 to 6.

10. A computer program product, the computer program product comprising a computer program, characterized in that, When executed by a computer device, the computer program is used to implement a conflict detection method based on software collaborative development as described in any one of claims 1 to 6.

Images