A cross-project model merging method, system, computer device and medium

Abstract

The application provides a cross-project model merging method, system, computer device and medium, belongs to the field of model collaborative development, and comprises the following steps: constructing an element mapping table of a source project model and a target project model, determining elements to be changed and change types of the elements to be changed; performing conflict type identification on the elements to be changed to obtain a conflict type of each element to be changed; screening to obtain key elements; when the element to be changed is another element, performing merging at an attribute level according to the conflict type of the another element to obtain a merging decision of the another element; when the element to be changed is a key element, retaining the key element in the target project model, adding a key element with a change type of an added element type in the source project model to the target project model, and obtaining a merging decision of the key element; and performing cross-project model element copying according to the merging decisions to obtain a cross-project model merging result. The method meets the accurate merging requirement in a complex modeling scenario.

Description

Technical Field

[0001] This invention belongs to the field of collaborative model development, specifically involving a method, system, computer equipment, and medium for merging cross-project models. Background Technology

[0002] With the increasing prevalence of model-driven engineering and collaborative development, cross-project model merging has become a crucial systems engineering practice. It refers to integrating two or more independently developed models into a unified target model. Its core purpose is to address the "information silo" problem prevalent in the development of large and complex systems: models developed by different teams, at different project stages, or even by different organizations often contain different aspects of the same system's expertise and design outcomes. Through model merging, these scattered model assets can be integrated to form a complete and consistent global model covering the entire system, thereby supporting the overall analysis, verification, and evolution of the system. The effectiveness of the merging directly affects the completeness, consistency, and correctness of the final system model, and is a key technical step in achieving the "single data source" goal in model-driven development.

[0003] To address these needs, existing technologies often employ version control tools such as Git and SVN to perform text-level merging of model files. For example, model files such as ".mdzip" and ".uml" are treated as ordinary text or binary files for version management. A three-way merge algorithm is used to compare the baseline version, source branch, and target branch, and a text difference detection tool is used to identify conflicting lines and prompt the user to resolve them manually.

[0004] However, in this merging method, model files are usually stored in XML or binary format. The text-level differences between models cannot accurately reflect the deep semantic changes such as attribute modifications and relationship changes of model elements. This makes it difficult for the system to effectively identify the conflict type at the element level, which can easily lead to erroneous modification or deletion of the core architecture, resulting in the collapse of model semantics and making it difficult to meet the accurate merging requirements in complex modeling scenarios. Summary of the Invention

[0005] To address the problem that existing model merging methods cannot meet the accurate merging requirements in complex modeling scenarios, this invention provides a cross-project model merging method, system, computer equipment, and medium.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A method for merging cross-project models includes: Obtain the model elements of the source project model and the target project model, and construct an element mapping table between the source project model and the target project model based on the model elements; determine the elements to be changed and the change types of the elements to be changed based on the element mapping table between the source project model and the target project model. The conflict type of each element to be changed is identified. Each element is then filtered based on preset keywords and attributes to identify key elements. When the element to be changed is not a key element, attribute-level merging is performed based on the conflict type of the other elements to obtain a merging decision. When the element to be changed is a key element, the key elements in the target project model are retained, and key elements in the source project model whose change type is "new element" are added to the target project model to obtain a merging decision for the key elements. Based on the merging decision, cross-project model elements are copied between the source project model and the target project model to obtain the cross-project model merging result.

[0007] Optionally, the cross-project model merging method provided by the present invention further includes: When an element exists in the element mapping table of the source project model but not in the element mapping table of the target project model, the element is determined to be an element that needs to be changed, and the change type of the element that needs to be changed is the new element type. When an element exists in the element mapping table of the target project model but not in the element mapping table of the source project model, the element is determined to be an element that needs to be changed, and the change type of the element that needs to be changed is the element deletion type. When an element exists in both the element mapping table of the target project model and the element mapping table of the source project model, and there is a conflict in the element's attributes or type, the element is determined to be an element that needs to be changed, and the change type of the element that needs to be changed is to modify the element type.

[0008] Optionally, the cross-project model merging method provided by the present invention further includes: When the element to be changed has the same name in the source project model and the target project model, but different types or owners, the conflict type of the element to be changed is determined to be a name conflict. When the type of the element to be changed is different in the source project model and the target project model, the conflict type of the element to be changed is determined to be a type conflict. When the relationship between the element to be changed and the source project model is different in the target project model, the conflict type of the element to be changed is determined to be a relationship conflict. When the element to be changed does not have a reference relationship in the target project model, the conflict type of the element to be changed is determined to be a reference conflict. When the attributes of the element to be changed differ between the source project model and the target project model, the conflict type of the element to be changed is determined to be an attribute conflict.

[0009] Optionally, the cross-project model merging method provided by the present invention further includes: When the conflict type is name conflict, the names of other elements in the source project model are used as the base name. Candidate names are obtained by cyclically accumulating the suffix of the counter until a candidate name obtains a unique identifier in the target project model. Then, the renaming of other elements is determined. When the conflict type is attribute conflict, merge the text content of other elements in the source project model and the target project model, retain the union of stereotypes, and obtain the attribute information of other elements after merging. When the conflict type is a reference conflict, the corrected reference relationship of other elements is obtained by searching for logically equivalent candidate elements in the target project model based on the cross-project reference relationship of other elements in the source project model.

[0010] Optionally, the cross-project model merging method provided by the present invention further includes: The severity of conflict for each element to be changed is determined based on its conflict type and importance in the project model, and the elements are then marked as requiring manual intervention based on their conflict severity.

[0011] Optionally, the cross-project model merging method provided by the present invention further includes: When an element that needs to be changed is a key element, mark the element that needs to be changed; When the element to be changed is a non-critical element, the elements to be changed that need to be marked are determined based on the conflict type and scope of influence of the element to be changed.

[0012] Optionally, the cross-project model merging method provided by the present invention further includes: When the strategy for merging cross-project models is preset to the target-first strategy, all elements in the target project model are retained, and elements in the source project model that do not appear in the target project model are merged and extracted to obtain the target-first merging decision. When the cross-project model merging strategy is preset to the source-first strategy, all elements in the source project model are overwritten with the corresponding content in the target project model, and elements in the target project model that do not appear in the source project model are deleted, resulting in a source-first merging decision.

[0013] This invention also provides a cross-project model merging system, comprising: The element change identification module is used to obtain the model elements of the source project model and the target project model, construct an element mapping table between the source project model and the target project model based on the model elements, and determine the elements to be changed and the change type of the elements to be changed based on the element mapping table between the source project model and the target project model. The merge decision building module is used to identify the conflict type of each element to be changed; to filter each element to be changed based on preset keywords and attributes to obtain key elements; when the element to be changed is another element besides the key element, the merge is performed at the attribute level according to the conflict type of the other elements to obtain the merge decision of the other elements; when the element to be changed is a key element, the key element in the target project model is retained, and the key element in the source project model whose change type is a new element is added to the target project model to obtain the merge decision of the key element. The merge action module is used to copy cross-project model elements between the source project model and the target project model based on the merge decision, and obtain the cross-project model merge result.

[0014] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement any of the steps in a cross-project model merging method.

[0015] The present invention also provides a computer-readable storage medium storing a computer program that, when loaded by a processor, is capable of executing any step of a cross-project model merging method.

[0016] The cross-project model merging method provided by this invention has the following beneficial effects: This invention introduces a differentiation mechanism based on preset keywords and attribute filtering. Elements requiring modification are categorized into critical elements and ordinary elements. For critical elements, a more robust strategy is adopted: the original content of the target project is fully preserved, only newly added elements from the source project are included, while modifications or deletions are ignored, ensuring the stability of the model's core architecture. With the core architecture secured, ordinary elements undergo automated attribute-level merging without manual intervention, significantly improving the automation of the merging process. This process precisely protects the core architecture from damage while fully leveraging the high efficiency of automated processing, effectively ensuring the semantic consistency and structural integrity of the merged model. It overcomes the shortcomings of traditional text-level merging tools in model-driven development, and is well-suited to the complex and ever-changing design requirements of model-driven development. Attached Figure Description

[0017] To more clearly illustrate the embodiments and design schemes of the present invention, the accompanying drawings required for this embodiment will be briefly described below. The 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.

[0018] Figure 1 This is a schematic diagram of a cross-project model merging method provided in an embodiment of the present invention; Figure 2 This is an example of a cross-project model merging process provided in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand and implement the technical solutions of the present invention, the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. The following embodiments are only used to more clearly illustrate the technical solutions of the present invention and should not be construed as limiting the scope of protection of the present invention.

[0020] Existing methods for merging models across projects or versions include text-level merging based on version control systems, as well as merging methods built into modeling tools. For example, there are merging functions built into commercial modeling tools such as MagicDraw and Enterprise Architect. These methods require the two projects to be merged to have a common ancestor project. They identify model differences by comparing key attributes such as element ID, name, and type, and provide a graphical interface that allows users to accept or reject specific change instructions one by one. Another method involves manual copy-paste integration. For example, the user opens both the source and target projects simultaneously, manually selects specific model elements such as classes, packages, and interfaces, and uses copy-paste to move them from the source project to the target project. Finally, manual checks are used to correct reference errors and name conflicts.

[0021] However, in terms of topological constraints for model merging, the traditional "three-way merge" algorithm requires that the projects to be merged must have a common ancestor project. This makes it unable to handle the merging needs between two completely independently developed projects and makes it difficult to support model reuse scenarios across organizations and teams. This strong dependence on the baseline version not only limits the flexibility of the model in the process of reconstruction and migration, but also fails to meet the technical requirements for efficient integration between unrelated projects.

[0022] Regarding source management and traceability mechanisms, existing model merging methods generally lack complete recording means, resulting in the inability to effectively trace the source items of elements and the exact merging time after merging, and the inability to record detailed merging information such as operation type, success status or failure reason; due to the lack of query and auditing capabilities for merging history, users find it difficult to conduct post-merging impact analysis and cannot support necessary rollback operations, thereby affecting data security and maintainability during model evolution.

[0023] To address the aforementioned issues, this invention proposes a cross-project model merging method based on difference analysis and conflict resolution. By introducing a difference analyzer, a conflict resolver, a source manager, and a custom merging engine, the semantic comparison, conflict detection, intelligent merging, and source record processing of model elements are unified and automated.

[0024] Example 1 This invention provides a method for merging cross-project models, specifically as follows: Figure 1 As shown, it includes the following steps: Step 1: Obtain the model elements of the source project model and the target project model, and construct an element mapping table between the source project model and the target project model based on the model elements; determine the elements to be changed and the change types of the elements to be changed based on the element mapping table between the source project model and the target project model.

[0025] The type of change required for the element can be determined through the following steps: Step 11: When an element exists in the element mapping table of the source project model but not in the element mapping table of the target project model, the element is determined to be an element that needs to be changed, and the change type of the element that needs to be changed is the new element type.

[0026] Step 12: When an element exists in the element mapping table of the target project model but not in the element mapping table of the source project model, the element is determined to be an element that needs to be changed, and the change type of the element to be changed is the element deletion type.

[0027] Step 13: When an element exists in both the element mapping table of the target project model and the element mapping table of the source project model, and there is a conflict in the element's attributes or type, the element is determined to be the element that needs to be changed, and the change type of the element that needs to be changed is to modify the element type.

[0028] Specifically, such as Figure 2 As shown, the cross-project model merging method provided by the present invention first performs difference analysis and change identification based on element mapping, uses a difference analyzer (DiffAnalyzer) to extract model elements from the source project and the target project, constructs an element mapping table, and identifies additions, deletions, modifications and conflicts.

[0029] For example, first, iterate through all model elements (BaseElements) of the source and target projects, and generate a unique identifier key for each element in the format "element type: element name", thereby constructing the source project element mapping table "sourceMap".<key,element> "and target item element mapping table" targetMap<key,element> Among them, the specific element mapping table construction method also supports custom key generation strategies based on ID, path or signature.

[0030] For example, by using "element type: element name" as the unique key to build a hash map table, an element lookup with O(1) time complexity can be achieved, reducing the time complexity of subsequent difference comparisons from O(n²) to O(n).

[0031] Secondly, the source and target project element mapping tables are compared to identify the change types of model elements. For example, for elements that exist in the source mapping table but not in the target mapping table (i.e., elements with an Added change type), an "ElementChange" object of type "ADD" is created, recording the element's name, type, path, ID, and other complete information. For elements that exist in the target mapping table but not in the source mapping table (i.e., elements with a Deleted change type), an "ElementChange" object of type "DELETE" is created, and the need for deletion is determined based on the subsequent merging strategy. For elements that exist in both mapping tables but have different attributes (i.e., elements with a Modified change type), an "ElementChange" object of type "MODIFY" is created, and the attribute-level change (PropertyChange) is recorded. Furthermore, for elements with the same name but different types, or elements with the same name and type but conflicting key attributes, they are classified as conflicting elements, and a "Conflict" object containing references to both the source and target elements is created.

[0032] For elements with a change type of "Modified", this invention can further analyze attribute-level differences using a three-stage difference identification algorithm: The first stage is the addition and modification identification stage, which traverses the source item mapping table to identify added and modified elements. Elements that exist in the source mapping table but not in the target mapping table are marked as added; elements that exist in both mapping tables but have different attributes are marked as modified.

[0033] The second stage is the deletion identification stage, which traverses the target item mapping table and identifies elements to be deleted. Elements that exist in the target mapping table but not in the source mapping table are marked as deletion types.

[0034] The third stage is the conflict detection stage, which performs conflict detection on all identified changes, identifies elements with the same name but different types or conflicting key attributes, and classifies them as conflicting elements.

[0035] Through the above three-stage difference identification, the system can comprehensively and accurately detect all changes between the source project and the target project, providing a complete data foundation for subsequent merging operations.

[0036] In summary, through the above steps, this invention constructs a complete difference analysis result (DiffResult) in memory, containing a list of all added, deleted, modified, and conflicting elements, providing a data foundation for subsequent conflict resolution and merging operations.

[0037] Step 2: Identify the conflict type of the elements to be changed to obtain the conflict type of each element; filter each element to be changed based on preset keywords and attributes to obtain key elements.

[0038] The conflict type can be determined through the following steps: Step 21: When the element to be changed has the same name in the source project model and the target project model, but different types or owners, determine that the conflict type of the element to be changed is a name conflict.

[0039] Step 22: When the type of the element to be changed is different in the source project model and the target project model, determine that the conflict type of the element to be changed is a type conflict.

[0040] Step 23: When the relationship between the element to be changed and the target project model are different, determine that the conflict type of the element to be changed is a relationship conflict.

[0041] Step 24: When the relationship between the element to be changed and the reference in the target project model does not exist, determine that the conflict type of the element to be changed is a reference conflict.

[0042] Step 25: When the attributes of the element to be changed are different in the source project model and the target project model, determine that the conflict type of the element to be changed is attribute conflict.

[0043] Specifically, after identifying the change type of the element to be changed, this invention uses a ConflictResolver to perform conflict detection on the difference analysis results and classifies them according to the conflict type and severity.

[0044] For example, the conflict type is first identified. Elements with the same name but different types, such as classes and interfaces with the same name, and elements with the same name but different owners, such as classes with the same name in different packages, are classified as Name Conflicts and their conflict level is set to high. Elements with inconsistent types in two projects, such as a class in the source project and an interface in the target project, are classified as Type Conflicts and their conflict level is set to high. Elements with inconsistent key attribute values, such as inconsistent visibility, abstraction, or staticity in the source and target projects, are classified as Property Conflicts and their conflict level is set to medium. Elements with inconsistent inheritance, dependency, or association relationships are classified as Relationship Conflicts and their conflict level is set to medium. Elements whose target does not exist in the target project or whose cross-project references cannot be resolved are classified as Reference Conflicts and their conflict level is set to low.

[0045] Furthermore, regarding the key element identification mechanism, this invention achieves precise positioning through configurable keywords and attribute rules. For example, it uses key element keywords such as "core," "critical," "important," and "main," as well as important element keywords such as "interface," "base class," and "service" for semantic filtering, and combines key attributes such as "id," "name," "type," and "owner" for multi-dimensional verification. Thus, the MergeConfig singleton manages the relevant configurations in a unified manner, which not only ensures the uniqueness and consistency of the configuration in the system, but also supports the import and export of configurations, thereby realizing the flexible migration and reuse of key identification rules.

[0046] For example, this invention can comprehensively assess the severity of a conflict through three dimensions: The first dimension is the critical element identification dimension, which checks whether the elements involved in the conflict are critical elements, such as core components like interfaces, base classes, and services. If they are critical elements, they are directly marked as CRITICAL.

[0047] The second dimension is the conflict type judgment dimension, which determines the priority based on the conflict type. Type conflict has the highest priority and is marked as HIGH.

[0048] The third dimension is the impact scope assessment dimension, which calculates the number of elements affected by the conflict. More than 10 elements are HIGH, more than 5 are MEDIUM, and the rest are LOW.

[0049] Through a comprehensive assessment of the above three dimensions, the system can accurately determine the severity of the conflict, providing a scientific basis for subsequent handling strategies.

[0050] In summary, the present invention achieves accurate identification and classification of conflicts through the above steps, providing a basis for decision-making in subsequent intelligent solutions.

[0051] Step 3: When the element to be changed is any element other than the key element, merge the other elements at the attribute level according to their conflict type to obtain the merge decision for the other elements; when the element to be changed is a key element, retain the key element in the target project model, and add the key element in the source project model whose change type is a new element to the target project model to obtain the merge decision for the key element.

[0052] When an element needs to be changed to another element, the attribute level can be merged through the following steps: Step 31: When the conflict type is name conflict, take the names of other elements in the source project model as the base name, and obtain candidate names by cyclically accumulating the suffix of the counter until the candidate name obtains a unique identifier in the target project model, then determine the renaming of other elements.

[0053] Step 32: When the conflict type is attribute conflict, merge the text content of other elements in the source project model and the target project model, retain the union of stereotypes, and obtain the attribute information of other elements after merging.

[0054] Step 33: When the conflict type is a reference conflict, based on the cross-project reference relationship of other elements in the source project model, retrieve logically equivalent candidate elements in the target project model to obtain the corrected reference relationship of other elements.

[0055] Step 4: Determine the conflict severity of each element to be changed based on its conflict type and importance in the project model. Mark the elements requiring manual intervention based on their conflict severity. For example, if an element is a critical element, mark it; if it is a non-critical element, determine which elements need to be marked based on their conflict type and scope of impact.

[0056] Step 5: When the cross-project model merging strategy is preset to target priority, all elements in the target project model are retained, and elements in the source project model that do not appear in the target project model are merged and extracted to obtain the target priority merging decision; when the cross-project model merging strategy is preset to source priority, all elements in the source project model are overwritten with the corresponding content in the target project model, and elements in the target project model that do not appear in the source project model are deleted to obtain the source priority merging decision.

[0057] Specifically, after completing the multi-strategy conflict detection and classification, the present invention can also automatically or semi-automatically resolve conflicts according to preset merging strategies and conflict types.

[0058] For example, the merging method provided by this invention supports multiple cross-project model merging strategies. Among them, the target-priority strategy (TARGET_PREFERRED) aims to retain all existing elements in the target project and only merge and extract newly added elements that are not present in the target project. It is mainly suitable for incremental update scenarios that supplement the functionality of existing models. The source-priority strategy (SOURCE_PREFERRED) completely covers the corresponding content in the target project with elements from the source project and simultaneously deletes redundant elements in the target project that are not present in the source project. It is mainly suitable for scenarios of complete model replacement or forced version alignment. The intelligent merging strategy (SMART_MERGE) can intelligently select based on the model element type and specific conflict characteristics. It adopts a manual interactive confirmation method for identified key elements, while performing automatic merging at the attribute level for ordinary elements. It is mainly suitable for complex collaborative development scenarios involving multiple parties. The manual resolution strategy (MANUAL_RESOLVE) marks all conflicts generated during the merging process as pending manual handling and automatically generates detailed conflict reports for users to review and make decisions item by item. It is mainly suitable for high-risk merging scenarios with extremely high requirements for model rigor and strict control of data change risks.

[0059] The intelligent merging strategy follows these core rules: Rule 1 prioritizes retaining key elements from the target project. For deletions or modifications marked as key elements, the system automatically rejects these changes to ensure the stability of the model's core architecture. Key element identification is based on preset keyword and attribute rules.

[0060] Rule 2 accepts significant additions to the source project. For significant new functional elements added to the source project, the system automatically accepts these changes, enabling incremental updates. The identification of new elements is also based on keyword matching and attribute analysis.

[0061] By combining the two core rules mentioned above, the system can automatically absorb incremental improvements from the source project while maintaining the core stability of the target project, thus achieving intelligent model merging.

[0062] The above implementation method uses a singleton class to check whether the element name and attributes match preset keywords and key attributes.

[0063] For low-priority and medium-priority conflicts, intelligent merging strategies can resolve them automatically. For example, automatic renaming can be used to automatically eliminate name conflicts through pre-defined renaming logic. Specifically, when an element with the same name is detected in the target namespace, the original element name is extracted as the base name, and candidate names are generated by cyclically incrementing a counter's suffix until a unique identifier is obtained within the target namespace, thus avoiding conflict while preserving the original semantic context. Intelligent merging can also be used for attribute conflicts, employing differentiated merging strategies based on attribute types. For visibility conflicts, the system will automatically... To ensure element availability, more lenient access permissions are adopted. For document conflict, the system will merge and store the text content of both parties. For structural conflict, the system will integrate model features by retaining the union of the two, thereby preserving attribute information edited by multiple parties to the greatest extent. Automatic reference conflict repair is achieved by actively identifying cross-project reference relationships in the model and retrieving logically equivalent candidate elements in the target project. Once a match is found, the system will automatically update the reference pointer to point to the corresponding element within the target project, thereby restoring the integrity and closed loop of the model's logical structure and resolving the reference breakage problem during cross-project migration of the model.

[0064] For example, when an element with the same name already exists in the target namespace, the system uses an automatic renaming strategy to resolve the name conflict: first, the original element name is extracted as the base name, and then candidate names are generated by cyclically incrementing the suffix of the counter, such as OriginalName, OriginalName_1, OriginalName_2, until a unique identifier in the target space is obtained.

[0065] This algorithm effectively avoids naming conflicts while preserving the original semantic context. The counter has a maximum limit of 1000 times. If the limit is exceeded, a unique identifier is generated using a UUID to ensure the uniqueness of the name.

[0066] Furthermore, this invention provides several variations of conflict resolution strategies. For example, conflict severity assessment can be replaced from keyword matching and rule-based judgment to intelligent assessment based on machine learning models, using historical merged data to train a classifier to predict conflict priorities, as long as it still supports four-level classification (CRITICAL, HIGH, MEDIUM, LOW) and outputs ConflictResolutionRecord records. Automatic conflict resolution algorithms can be expanded from fixed rules such as adding suffixes to name conflicts and taking lenient values ​​for attribute conflicts to a configurable solution strategy library or automatic reasoning based on constraint solving, as long as the resolution process is still uniformly managed and recorded through ConflictResolver. Merging strategies can be expanded from four preset modes (target-first, source-first, intelligent merging, manual resolution) to user-defined strategy scripts such as Groovy, JavaScript, or DSL, as long as the overall pattern of "strategy selection - conflict detection - automatic resolution - manual confirmation" is still followed. The conflict resolution interface can be replaced from a Swing desktop interface to a web interface, command-line interface, IDE plugin, or mobile application, as long as interactive capabilities for conflict visualization, strategy selection, and resolution confirmation are still provided. The above conflict resolution strategies can be selected by those skilled in the art based on actual needs, and this invention does not impose any limitations.

[0067] Step 6: Based on the merge decision, perform cross-project model element replication between the source project model and the target project model to obtain the cross-project model merge result.

[0068] Specifically, after determining the conflict resolution or merge decision for each element through the above methods, the present invention can also utilize the CrossProjectMergeService to perform the actual element copying operation and repair cross-project references.

[0069] For example, you can first copy elements based on the official API, such as using the MagicDraw official MergeAPI to copy elements.

[0070] To ensure that copied elements have a complete hierarchical structure in the target project, the system employs an ancestor containment and child element recursion strategy: Among them, the upward traversal strategy or ancestor inclusion strategy means that for each selected element, the system traverses its owner chain upwards and includes all ancestor elements in the copy task, ensuring that the element can be mapped to the correct container in the target project, and avoiding model structure isolation or reference invalidation caused by the absence of parent containers.

[0071] The downward recursive strategy or sub-element recursive strategy means that for each selected element, the system recursively scans all its owned elements downwards to achieve synchronous migration of the entire hierarchical structure. During the copying process, the original subordinate relationships and nested structures are strictly maintained to ensure that the integrity of the internal logical units and the original topology are not distorted after the model is transferred across projects.

[0072] Subsequently, based on the MagicDraw official Merge API, precise change filtering is implemented, accepting only changes related to the selected elements to avoid unnecessary modifications, and manual intervention is supported through a conflict resolution interface. Furthermore, during element copying, the complete hierarchical relationship is maintained. For example, an ancestor element automatic inclusion mechanism is used to deeply identify the ownerchain of the target element, automatically including missing ancestor elements at all levels in the copying task list. This aims to ensure that each element to be merged can be mapped to the correct logical container in the target project, thereby avoiding model structure isolation or reference invalidation due to missing parent containers. Recursive copying of child elements performs recursive identification and scanning of all owned elements of the target element, achieving synchronous migration of the entire hierarchical structure. During the copying process, the system strictly maintains the original subordinate relationships and nested structures, ensuring that the integrity of the internal logical units and the original topology of the model remain unchanged after cross-project transfer. Top-level element identification filters the root element without a parent node from the selected element set and defines it as the top-level logical unit for this operation. By accurately identifying and relocating these top-level elements, the system can support the batch movement of large-scale element sets to specified target locations, thereby improving the operational efficiency and flexibility in the model structure reorganization process.

[0073] After element copying is complete, the system supports batch moving of elements to specified target locations. A dedicated operation session is created using SessionManager to ensure the atomicity of the operation; if the operation fails, it automatically rolls back. Then, result verification is performed, checking whether the element's owner has been correctly updated after the move. If this fails, a warning message is logged to facilitate user troubleshooting.

[0074] Finally, reference repair and URI cleanup are performed. For example, cross-project reference repair and invalid URI cleanup mechanisms address local path redundancy in the model. This involves automatically identifying all string attributes containing the `local: / / ` protocol and replacing them with null or mapping them to equivalent references in the target project, thus stripping away environment-sensitive data. Simultaneously, the system deeply scans and cleans up local URIs in EMF (Eclipse Modeling Framework) resource references, ensuring that model files do not carry any invalid paths bound to the original host environment after cross-environment migration. Cross-project reference updates actively retrieve all external references pointing to elements in the source project within the model and perform a global lookup of equivalent elements within the target project space. Once a corresponding logical entity is identified at the target location, the system automatically redirects the reference pointer, ensuring it precisely points to the new element within the target project. This process effectively eliminates the "dangling reference" phenomenon after model merging and restores the integrity of the model's logical chain. A snapshot reference cleanup mechanism specifically optimizes snapshot data in model version management, automatically cleaning up residual local references in snapshot IDs and identifying and removing snapshot association information that has become invalid due to the merge operation. This move aims to streamline the model's metadata structure, avoid interference from invalid historical references on the current model state, and thus ensure the cleanliness and rigor of the model during version evolution.

[0075] In summary, through the above methods, the present invention can achieve complete and secure cross-project element copying, ensuring that the merged model structure is complete and correctly referenced.

[0076] Furthermore, after cross-project element copying is complete, this invention can also utilize the TraceabilityManager to record detailed information about the merge operation and generate traceability annotations. Standardized traceability annotations are generated for each successfully merged element, containing the following information:

[0077] Merge source: source project name, source path; merge time: timestamp accurate to the second; operation type: copy (COPY), move (MOVE), or merge (MERGE); name change: if a renaming occurs, record the original name and the new name.

[0078] Annotations are appended to the annotation attributes of elements in a structured text format. Users can directly view the merging history of elements in the modeling tools, enabling element-level source tracing.

[0079] The system persists the source information into the model. For example, it uses comment-based persistence to create associated Comment objects under specific model elements, storing the complete source information as a text description. This approach is advantageous because it is directly compatible with existing modeling tools, allowing users to intuitively view the historical change background of elements in a graphical interface without plugins, improving the readability and interactivity of the source information. Alternatively, it uses tag-based persistence, utilizing the TaggedValue attribute of model elements to store structured source metadata. By encapsulating information such as merge time, source project, and operation type into tag values, the system supports efficient programmatic queries and automated data analysis, providing a standardized data interface for subsequent batch generation of source audit reports and implementation of model quality assessments. Alternatively, it uses external file persistence to synchronously export source information to external configuration files in common formats such as JSON or XML, achieving decoupled storage of source data from the model ontology. This approach supports global source tracing across projects, facilitating independent auditing and compliance checks by third-party tools and providing a more scalable version tracking solution for ultra-large-scale model systems. The interface supports programmatic calls, making it easy to integrate into automated processes and compliance audits.

[0080] In summary, through the above steps, this invention achieves complete traceability management, ensuring that every merge operation is traceable. Furthermore, this invention provides several variations of the traceability management mechanism, such as tagging, external database storage (e.g., relational databases, graph databases), or blockchain storage, as long as complete traceability information such as element name, type, source path, target path, merge time, and operation type can still be recorded; the traceability record data structure is extended from the MergeRecord class to a multi-generation traceability graph supporting version chain tracing, recording the complete evolution history of elements and the lineage of multiple merges, as long as query interfaces for querying source by element, history by time, and elements by source project are still provided; the traceability annotation generation is replaced from fixed-format text to structured JSON, XML, or RDF formats, supporting semantic queries and automated analysis, as long as it can still be visualized in modeling tools and supports manual review; the traceability query interface is extended from a synchronous API to a high-performance interface supporting asynchronous queries, streaming processing, and distributed queries, as long as it still follows the TraceabilityQuery interface specification and returns a standard set of traceability records. The above traceability management mechanisms are selected by those skilled in the art based on actual needs, and this invention does not impose any limitations.

[0081] In addition, to address the issue of local path redundancy in the model, this invention also includes a three-level URI cleanup mechanism: First, there's the element-level cleanup mechanism. It iterates through each element in the project, uses reflection to identify all string attributes containing the local: / / protocol, and replaces them with empty values ​​to ensure that element attributes do not carry path information from the original environment.

[0082] Secondly, there is the EMF reference cleanup mechanism, which performs a deep scan of localURIs in Eclipse Modeling Framework resource references, cleans up local paths in cross-references, and ensures that model resource references do not depend on the original environment.

[0083] Finally, there is the snapshot reference cleanup mechanism, which is specifically optimized for snapshot data in model version management. It cleans up residual local references in snapshot IDs to ensure that snapshot data does not carry original environment information.

[0084] The above mechanism ensures that model files do not carry any invalid paths bound to the original host environment after cross-environment migration, thus avoiding model opening failures caused by path dependencies.

[0085] The project save strategy is as follows: Saves are performed using a secure transaction management mode. First, it checks if a session has already been created; if not, a dedicated save session is created. Then, ProjectsManager is called to perform the project save, and finally, the session is closed. If an exception occurs during the save process, the system will cancel the session and return a failure status, ensuring that project data is not corrupted due to save failure.

[0086] The system provides comprehensive error diagnosis capabilities, including the following checks: file permission check: verifying whether the file is writable; disk space check: verifying whether there is sufficient storage space; file locking check: verifying whether the file is occupied by other programs; model consistency check: verifying the integrity of the model's internal structure.

[0087] The recovery mechanism includes: releasing file locks: unlocking possible file locks; repairing model errors: attempting to repair detected model problems; this mechanism ensures that the cause can be quickly diagnosed and recovery attempts can be made when saving fails, improving the robustness of the system.

[0088] Through the above steps, this invention achieves secure and reliable project saving, ensuring the correct persistence of merged results. Furthermore, this invention provides several variations of the project saving mechanism. For example, project saving can be replaced from being based on the MagicDrawProjectsManager API to a saving mechanism based on EMF Resources, XMI serialization, or other modeling platforms, as long as it still supports standard saving, backup saving, and forced saving modes and provides SaveResult feedback; backup strategies can be expanded from timestamp-based file copying to Git version control-based automatic commits, snapshot-based incremental backups, or off-site backups based on cloud storage, as long as recovery capabilities are still provided in case of saving failure; saving error handling can be expanded from local diagnosis of file permissions, disk space, and file locking to conflict detection and collaborative saving in a distributed environment, supporting multi-user concurrent editing and optimistic locking mechanisms, as long as error diagnosis and recovery attempts can still be uniformly managed through SaveErrorHandler; saving verification can be expanded from a disable / enable switch to a configurable set of verification rules, supporting syntax verification, semantic verification, consistency verification, and custom constraint checks, as long as verification can still be bypassed in forced saving mode to handle special cases. The above project saving mechanisms are to be selected by those skilled in the art based on actual needs, and this invention does not impose any limitations.

[0089] Furthermore, this invention provides further performance optimization and distributed expansion variations, such as replacing the element mapping table from a HashMap-based in-memory structure with fast lookup based on Bloom filters, approximate matching based on LSH, or large-scale model processing based on distributed caching such as Redis or Memcached, as long as it still supports O(1) or near-O(1) element lookup complexity; and extending difference analysis from single-threaded sequential processing to parallel processing based on the Fork / Join framework, asynchronous processing based on the Actor model, or distributed processing based on MapReduce, as long as it can still correctly identify all differences and output consistent DiffR. The `conflictResolutionRecord` property extends conflict resolution from local processing to a remote resolution service based on a microservice architecture, supporting independent deployment and horizontal scaling of conflict detection services, strategy recommendation services, and automatic resolution services, as long as they still collaborate through a unified API interface and return a `ConflictResolutionRecord`. It also extends traceability management from single-machine storage to a global traceability network based on distributed graph databases such as Neo4jCluster and JanusGraph, supporting cross-organizational and cross-project traceability queries and lineage analysis, as long as they still adhere to the `MergeRecord` data structure and `TraceabilityQuery` interface specification.

[0090] This invention provides a semantic-level difference analysis algorithm based on element mapping. It constructs a unique element identifier using a combination of "element type + element name," and generates an element mapping table between the source and target models accordingly, enabling rapid location and matching of model elements. By comparing and analyzing the source and target mapping tables, it automatically identifies four types of changes during model evolution: additions, deletions, modifications, and conflicts, thus characterizing the differences in model structure at the semantic level. Building upon element matching, it further conducts attribute-level difference analysis, comparing key attributes such as name, type, visibility, documentation, stereotype, and relationship item by item to accurately identify attribute changes. A unified difference result data structure, DiffResult, is used to structurally manage all detected difference information, providing complete data support for subsequent change display, conflict handling, and automated merging processes. At the implementation level, the difference analysis process is completed using the DiffAnalyzer.analyzeDifferences() method, including core steps such as element mapping construction, change type identification, and conflict detection, achieving automated analysis of semantic-level model differences.

[0091] Furthermore, this invention provides a multi-strategy conflict detection and intelligent resolution mechanism. By comprehensively analyzing key semantic information such as the name, type, attribute, relationship, and reference of model elements, it identifies five typical conflict types that may arise during model merging: name conflict, type conflict, attribute conflict, relationship conflict, and reference conflict. This allows for systematic detection of potential inconsistencies at the semantic level. Based on the importance of elements in the model structure and the impact of the conflict on the system's semantic integrity, detected conflicts are categorized into four severity levels: Critical, High, Medium, and Low, allowing for different priority processing strategies during the merging process. Regarding conflict resolution strategies, it supports Target First, Source First, and Smart Merging. The system employs four basic merging strategies: Merge, Manual Resolution, and Conflict Resolution. These strategies provide flexible conflict resolution methods for different application scenarios. At the automation level, rule-driven conflict resolution algorithms automatically repair common conflicts, such as automatically renaming name conflicts, intelligently merging attribute conflicts, and automatically repairing reference relationships in reference conflicts, thus reducing manual intervention. In terms of implementation mechanism, the ConflictResolutionRecord data structure fully records the detection results and resolution process of each conflict, providing traceable audit information for the conflict handling process and supporting subsequent result rollback and change recovery.

[0092] Furthermore, this invention also provides a cross-project element copying and reference repair algorithm, based on the Merge algorithm provided by MagicDraw. The API implements a secure copying mechanism for model elements across projects. It uses standard interfaces such as ProjectDifference, Change, and ChangeState to uniformly manage model differences and change states, ensuring that the copying and merging process conforms to tool specifications. During element copying, it automatically maintains the hierarchical structure of model elements by identifying ancestor elements and automatically including their necessary context, recursively copying related child elements, and identifying and uniformly managing top-level elements to maintain the integrity of the model structure. Through an intelligent element relocation algorithm, it supports batch movement of elements to specified target locations after copying, while detecting and avoiding potential circular references during the movement process to ensure that the model structure does not generate logical conflicts due to relocation. For reference relationship handling, it constructs a multi-level reference repair mechanism, including cleaning up local: / / protocol references, updating cross-project element reference relationships, and cleaning up snapshot references to restore the correct associations between copied model elements. Through reference cleanup strategies at the element, project, and file levels, it uniformly verifies and repairs the copied and merged models, ensuring that the final generated model structure does not contain invalid or dangling references.

[0093] Furthermore, this invention provides a complete traceability management and tracking mechanism. By constructing a standardized traceability record data structure, MergeRecord, it uniformly manages key operational information during the model merging process, including core fields such as element name, element type, model path, operation time, operation type, and merge result status, thus forming a complete traceability data foundation. After successful element merging, the system automatically generates traceability annotations for the corresponding model elements, recording key metadata such as source project information, source model path, merge time, executed operation type, and possible renaming information, to achieve element-level source tracing. Regarding the persistence of traceability information, it supports multiple storage methods, including through model annotations (Com... The system records traceability information, embeds traceability metadata into model elements via tag attributes (TaggedValue), and stores it independently via external files (JSON / XML) to adapt to different system integration and management needs. It provides a unified traceability query interface to support multi-dimensional traceability information retrieval and analysis, such as querying source information by element, querying historical merge records by time range, locating related elements by source project, and automatically generating complete traceability reports. In terms of implementation mechanism, traceability information is tightly bound to model elements, allowing users to directly view and verify element sources and merge history in modeling tool environments such as MagicDraw, thereby improving the transparency and auditability of model management.

[0094] The cross-project model merging method provided by this invention enables semantic-level difference analysis and accurately identifies model changes. Specifically, the document structure tree used in this invention is directly derived from the viewpoint method and model structure. The chapter hierarchy is automatically determined by the parent-child relationship of Sections, and the chapter number is automatically calculated and maintained during the output stage. The difference analysis algorithm based on the element mapping table can accurately identify element-level additions, deletions, modifications, and conflicts, and supports attribute-level difference analysis, which can identify changes in various attributes such as name, type, visibility, document, stereotype, and relationship. The difference analysis results are represented by a structured "DiffResult" object, which facilitates subsequent processing and visualization, thereby accurately reflecting the semantic changes of the model and avoiding false positives and false negatives.

[0095] Furthermore, the cross-project model merging method provided by this invention offers multiple conflict resolution strategies and supports both automated and manual intervention. Specifically, this invention defines five conflict types and four severity levels, enabling precise classification and assessment of conflicts, and supports four merging strategies: target-first, source-first, intelligent merging, and manual resolution, adapting to different business scenarios. Moreover, it can automatically handle name conflicts, attribute conflicts, and reference conflicts, implementing an automatic conflict resolution algorithm. For high-priority and critical conflicts, a visual conflict resolution interface is provided, supporting manual review and decision-making. In addition, all conflict resolution processes are fully recorded, supporting auditing and rollback.

[0096] Moreover, the cross-project model merging method provided by this invention does not require an ancestor project and supports merging any two projects. Specifically, addressing the limitation of traditional three-way merging, which requires a common ancestor project and restricts merging flexibility, this invention, based on a two-way merge algorithm, achieves merging without an ancestor project through difference analysis and conflict resolution; it supports merging two independently developed projects, making it suitable for model reuse scenarios across organizations and teams; and it supports model reconstruction and migration scenarios, such as migrating old versions of models to new versions or splitting monolithic models into multiple modules, thereby significantly improving the applicability and flexibility of model merging.

[0097] Furthermore, the cross-project model merging method provided by this invention enables complete traceability management and supports tracing the merging history. Specifically, this invention can automatically generate traceability annotations for each successfully merged element, recording complete information such as the source project, source path, merging time, and operation type; it supports three methods for persisting traceability information: annotations viewed directly in the modeling tool, tags queried programmatically, and external files queried across projects; it provides a traceability query interface, supporting functions such as querying the source by element, querying history by time, querying elements by source project, and generating traceability reports; traceability information is tightly bound to model elements, ensuring that the merged model has complete traceability; it supports compliance checks and auditing requirements, meeting the quality management requirements of systems engineering and software engineering.

[0098] Furthermore, the cross-project model merging method provided by this invention can intelligently repair references to ensure model consistency. Specifically, this invention implements a multi-level URI cleanup strategy: element-level cleanup, project-level cleanup, and file-level cleanup; automatically identifies and cleans up `local: / / ` protocol references to avoid cross-project reference errors; automatically updates cross-project references, updating references pointing to the source project to equivalent elements pointing to the target project; cleans up snapshot references and invalid EMF resource references to ensure the integrity of model files; and through multiple verification and repair mechanisms, ensures that the merged model can be opened and edited normally in modeling tools.

[0099] Example 2 Based on Example 1, this example further illustrates the implementation process of the present invention based on several specific scenarios.

[0100] In a cross-team collaborative development scenario, an aviation systems research institute is simultaneously developing three related projects: an infrastructure library (AircraftPlatform), a functional module library (AircraftFunction), and a system integration library (AircraftSystem). Team A added an "engine monitoring" interface and a "fuel management" class to the AircraftPlatform project; Team B modified the properties of the "flight control" class in the AircraftFunction project, adding a "maximum speed" parameter; and Team C deleted the "old navigation module" in the AircraftSystem project.

[0101] When cross-project merging is required, the elements of the three projects are first analyzed to construct a mapping table and identify the following: AircraftPlatform has two newly added elements, "Engine Monitoring Interface" and "Fuel Management Class"; AircraftFunction has one modified element, "Flight Control Class"; and AircraftSystem has one deleted element, "Old Navigation Module".

[0102] Secondly, a conflict detection was performed, and a conflict was detected between the "Flight Control" class in AircraftFunction and the Flight Control class in AircraftSystem. The severity of the conflict was assessed as HIGH, and manual handling was recommended.

[0103] Then, the models are merged according to the preset strategy. New elements added to AircraftPlatform are automatically copied to the AircraftSystem project; modifications to AircraftFunction are automatically updated to the AircraftSystem project; and for attribute conflicts, a visual interface pops up for team C to confirm.

[0104] Once the merge is complete, source traceability notes are automatically generated in the target project, recording the source project, merge time, and operation type for each element, thus completing the source traceability record.

[0105] In a model migration scenario without a common ancestor project, an enterprise needs to migrate the UML model of an old system to a new platform. The old model library, containing approximately 500 classes, is completely independent of the new platform and has no common ancestor project. Traditional methods require manually exporting all model elements, creating them one by one on the target platform, and manually fixing all reference relationships, which is expected to take 2-3 weeks and is prone to errors. However, the cross-project model merging method provided by this invention can use the old project as the source project and the new project as the target project. By identifying all elements through the aforementioned difference analysis and performing element copying and reference repair, the time is reduced to 2-3 hours, and the model migration has a high degree of automation and a low error rate.

[0106] Example 3 This invention also provides a cross-project model merging system, comprising: The element change identification module is used to obtain the model elements of the source project model and the target project model, construct an element mapping table of the source project model and the target project model based on the model elements, and determine the elements to be changed and the change type of the elements to be changed based on the element mapping table of the source project model and the target project model.

[0107] The merge decision building module is used to identify the conflict type of the elements to be changed, and obtain the conflict type of each element; it filters each element to be changed based on preset keywords and attributes to obtain key elements; when the element to be changed is another element, it merges the other elements at the attribute level according to the conflict type of the other elements to obtain the merge decision of the other elements; when the element to be changed is a key element, it retains the key elements in the target project model, adds the key elements in the source project model whose change type is new element type to the target project model, and obtains the merge decision of the key elements.

[0108] The merge action module is used to copy cross-project model elements between the source project model and the target project model based on the merge decision, and obtain the cross-project model merge result.

[0109] For example, the model merging process can be divided into multiple collaborative functional modules to achieve a modular system structure. These modules include a DiffAnalyzer module, a ConflictResolver module, a CrossProjectMergeService module, a TraceabilityManager module, a URICleaner module, and a SaveErrorHandler module. Each module works collaboratively through clearly defined interfaces, thereby improving system maintainability and scalability. In terms of process control, key parameters are centrally managed through the MergeConfig configuration file, supporting… It supports customizable key element keywords, important element keywords, key attribute sets, and default merging strategies, giving the entire model merging process a "configuration-driven" characteristic, allowing for flexible adjustments based on different application needs. At the user interaction level, it provides a visual merging configuration interface, MergeConfigDialog, supporting the editing, importing, and exporting of configuration items, as well as one-click restoration of default configurations, thus simplifying user management of merging strategies and rules. Based on this modular and configuration-driven system architecture, the merging mechanism can be smoothly extended to more model management scenarios, such as internal project model merging, branch model merging, and version model merging. Furthermore, this architecture design has good versatility and portability, supporting multiple model types such as Unified Modeling Language (UML), Systems Modeling Language (SysML), and Business Process Model and Notation (BPMN), and can be migrated to different model modeling platform environments.

[0110] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps in an embodiment of a cross-project model merging method. Specific implementation methods can be found in the method embodiments, and will not be repeated here.

[0111] Furthermore, the present invention also provides a non-transitory computer-readable storage medium containing instructions on which a computer program is stored. For example, a memory containing instructions that can be executed by a processor of a computer device to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc. When the computer program is executed by the processor, it can implement the steps in an embodiment of a cross-project model merging method. Specific implementation methods can be found in the method embodiments, which will not be repeated here.

[0112] Those skilled in the art will understand that embodiments of the present invention can provide methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention 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.

[0113] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as 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.

[0114] 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.

[0115] 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 1The steps of the function specified in one or more boxes.

[0116] It should be noted that the specific embodiments described above enable those skilled in the art to more fully understand the present invention, but do not limit the present invention in any way. Therefore, although the present invention has been described in detail in this specification and embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention; and all technical solutions and improvements that do not depart from the spirit and scope of the present invention are covered within the protection scope of the present invention patent. No reference numerals in the claims should be construed as limiting the scope of the claims. Any simple variations or equivalent substitutions of technical solutions that can be readily obtained by those skilled in the art within the scope of the technology disclosed in the present invention are within the protection scope of the present invention.

Claims

1. A method for merging cross-project models, characterized in that, include: Obtain the model elements of the source project model and the target project model, and construct an element mapping table between the source project model and the target project model based on the model elements; The elements to be changed and the types of changes to the elements to be changed are determined based on the element mapping table of the source project model and the target project model. The conflict type of each element to be changed is identified by performing conflict type identification. Each element that needs to be changed is filtered based on preset keywords and attributes to obtain key elements; When the element to be changed is an element other than the key element, the attribute level is merged according to the conflict type of the other elements to obtain the merging decision of the other elements; when the element to be changed is a key element, the key element in the target project model is retained, and the key element in the source project model whose change type is new element is added to the target project model to obtain the merging decision of the key element. Based on the merging decisions of the key elements and other elements, cross-project model element replication is performed between the source project model and the target project model to obtain the cross-project model merging result.

2. The method for merging cross-project models according to claim 1, characterized in that, Based on the element mapping table of the source project model and the target project model, the elements to be changed and the types of changes to those elements are determined, including: When an element exists in the element mapping table of the source project model but does not exist in the element mapping table of the target project model, the element is determined to be an element that needs to be changed, and the change type of the element that needs to be changed is a new element type. When an element exists in the element mapping table of the target project model but does not exist in the element mapping table of the source project model, the element is determined to be an element that needs to be changed, and the change type of the element that needs to be changed is the element deletion type. When an element exists in both the element mapping table of the target project model and the element mapping table of the source project model, and the element's attributes or types conflict, the element is determined to be an element that needs to be changed, and the change type of the element that needs to be changed is to modify the element type.

3. The method for merging cross-project models according to claim 1, characterized in that, The conflict type of each element to be changed is identified by performing conflict type identification. When the element to be changed has the same name in the source project model and the target project model, but different types or owners, the conflict type of the element to be changed is determined to be a name conflict. When the type of the element to be changed is different in the source project model and the target project model, the conflict type of the element to be changed is determined to be a type conflict. When the relationship between the element to be changed and the target project model are different, the conflict type of the element to be changed is determined to be a relationship conflict. When the element to be changed does not have a reference relationship in the target project model, the conflict type of the element to be changed is determined to be a reference conflict. When the attributes of the element to be changed are different in the source project model and the target project model, the conflict type of the element to be changed is determined to be an attribute conflict.

4. The method for merging cross-project models according to claim 3, characterized in that, Merging attributes based on the conflict type of the other elements includes: When the conflict type is a name conflict, the names of other elements in the source project model are used as the base names. Candidate names are obtained by cyclically accumulating the suffix of the counter until the candidate name obtains a unique identifier in the target project model. Then, the renaming of other elements is determined. When the conflict type is attribute conflict, the text content of the other elements in the source project model and the target project model is merged, the stereotype is retained as a union, and the attribute information of the other elements is obtained after merging. When the conflict type is a reference conflict, the logically equivalent candidate elements are retrieved in the target project model based on the cross-project reference relationships of the other elements in the source project model, and the corrected reference relationships of the other elements are obtained.

5. The method for merging cross-project models according to claim 1, characterized in that, After filtering each element to be changed based on preset keywords and attributes to obtain the key elements, the process further includes: The severity of conflict for each element to be changed is determined based on its conflict type and importance in the project model, and the elements are then marked as requiring manual intervention based on their conflict severity.

6. The method for merging cross-project models according to claim 5, characterized in that, The severity of the conflict for each element requiring change is determined based on its conflict type and importance within the project model. The states requiring manual intervention are then marked based on the severity of the conflict. When the element to be changed is a key element, the element to be changed is marked. When the element to be changed is a non-critical element, the elements to be changed that need to be marked are determined according to the conflict type and scope of influence of the element to be changed.

7. The method for merging cross-project models according to claim 1, characterized in that, Before performing cross-project model element copying between the project model and the target project model based on the merge decision, the following is also included: When the cross-project model merging strategy is preset to a target-first strategy, all elements in the target project model are retained, and elements in the source project model that do not appear in the target project model are merged and extracted to obtain a target-first merging decision. When the cross-project model merging strategy is preset to a source-first strategy, all elements in the source project model are overwritten with the corresponding content in the target project model, and elements in the target project model that do not appear in the source project model are deleted, resulting in a source-first merging decision.

8. A cross-project model merging system, characterized in that, include: The element change identification module is used to obtain the model elements of the source project model and the target project model, construct an element mapping table of the source project model and the target project model based on the model elements, and determine the elements to be changed and the change type of the elements to be changed based on the element mapping table of the source project model and the target project model. The merge decision construction module is used to identify the conflict type of the elements to be changed and obtain the conflict type of each element to be changed. Each element that needs to be changed is filtered based on preset keywords and attributes to obtain key elements; When the element to be changed is an element other than the key element, the attribute level is merged according to the conflict type of the other elements to obtain the merging decision of the other elements; when the element to be changed is a key element, the key element in the target project model is retained, and the key element in the source project model whose change type is new element is added to the target project model to obtain the merging decision of the key element. The merge action module is used to copy cross-project model elements between the source project model and the target project model according to the merge decision, so as to obtain the cross-project model merge result.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the cross-project model merging method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is loaded by the processor, it is able to execute the steps of the cross-project model merging method according to any one of claims 1 to 7.

Images