Architecture modeling data processing method, electronic device, and storage medium

Abstract

Embodiments of the present application provide a system architecture modeling data processing method, electronic equipment and storage medium. The method comprises: according to the modeling language meta-model specification information, mapping the architecture description information into a unified modeling data structure; determining the architecture domain based on the architecture domain definition information, and generating and outputting the modeling sequence result and the inter-domain dependency relationship result according to the domain sequence rule and the inter-domain dependency relationship determination rule; performing matching processing and constraint processing on the unified modeling data structure according to the modeling sequence result and the corresponding sub-domain modeling rule set of the architecture domain, obtaining and outputting the rule-based modeling result; performing cross-domain collaborative processing on the shared modeling elements in different architecture domains, generating and outputting the cross-domain association result; performing consistency detection and / or dependency integrity detection on the shared modeling elements between different architecture domains, and obtaining and outputting the detection result. The method is used to improve the consistency and usability of the modeling result.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for processing data for architecture modeling, an electronic device, and a storage medium. Background Technology

[0002] In the development and operation of large and complex engineering systems such as aerospace and air traffic management, system architecture modeling is used to form a unified system understanding across different levels and concerns, supporting activities such as requirements decomposition, capability planning, operational organization, resource allocation, and security assurance. As the system scales up, the number of participants increases, and the operating environment changes dynamically, the system architecture model often needs to cover multiple areas of concern and express the relationships between the same system elements from different perspectives.

[0003] In existing technologies, engineering practices typically rely on general architectural framework standards or industry framework specifications for modeling. These frameworks often provide domain-of-interest divisions, perspective / view templates, and suggested expressions. During implementation, modelers often use general modeling tools or multiple modeling languages ​​to construct models for different domains, establishing cross-perspective relationships through documentation, naming conventions, identifier references, table mappings, or manually maintained correspondences. Different teams select the modeling order and granularity based on experience, iterating and updating through reviews and version control. When upstream information changes, downstream models are typically modified or supplemented based on existing documentation and experience to ensure the relationships between perspectives remain usable in the project.

[0004] In existing solutions, the dependencies and correspondences between multi-domain and multi-perspective models are often scattered across different models and carriers. Relying on manual constraints and post-event checks can easily lead to problems such as unstable semantic correspondences and low integrity of dependencies between different modeling scopes. Summary of the Invention

[0005] This application provides an architecture modeling data processing method, electronic device, and storage medium to improve the consistency, dependency integrity, and availability of the results.

[0006] In a first aspect, embodiments of this application provide a method for processing system architecture modeling data, including:

[0007] It receives the architecture description information of the system to be modeled, the architecture domain definition information of the unified architecture framework, and the metamodel specification information of the modeling language;

[0008] Based on the modeling language metamodel specification information, the architecture description information is mapped to a unified modeling data structure;

[0009] Multiple architectural domains are determined based on the architectural domain definition information, and rules are determined according to preset domain order rules and inter-domain dependencies to generate modeling order results and inter-domain dependency results.

[0010] Obtain the domain-specific modeling rule set corresponding to each architecture domain. Based on the modeling order result, by sequentially calling the domain-specific modeling rule set corresponding to each architecture domain, perform matching and constraint processing on the unified modeling data structure to obtain the rule-based modeling result corresponding to each architecture domain.

[0011] Based on preset cross-domain collaboration rules, cross-domain collaborative processing is performed on shared modeling elements in different architecture domains to generate cross-domain association results;

[0012] Based on the inter-domain dependency results and the cross-domain association results, consistency and / or dependency integrity checks are performed on the shared modeling elements between different architecture domains to obtain the check results.

[0013] Output modeling order results, inter-domain dependency results, rule-based modeling results, cross-domain association results, and / or detection results.

[0014] Secondly, embodiments of this application provide an architecture modeling data processing apparatus, comprising:

[0015] The information receiving module is used to receive the architecture description information of the system to be modeled, the architecture domain definition information of the unified architecture framework, and the metamodel specification information of the modeling language.

[0016] The information processing module is used to map the architecture description information into a unified modeling data structure based on the modeling language metamodel specification information.

[0017] The result generation module is used to determine multiple architecture domains based on the architecture domain definition information, and to determine rules according to preset domain order rules and inter-domain dependency relationships to generate modeling order results and inter-domain dependency relationship results.

[0018] The result generation module is also used to obtain the domain-specific modeling rule set corresponding to each architecture domain. Based on the modeling order result, the unified modeling data structure is matched and constrained by sequentially calling the domain-specific modeling rule set corresponding to each architecture domain to obtain the rule-based modeling result corresponding to each architecture domain.

[0019] The result generation module is used to perform cross-domain collaborative processing on shared modeling elements in different architecture domains according to preset cross-domain collaboration rules, and generate cross-domain association results.

[0020] The result detection module is used to perform consistency detection and / or dependency integrity detection on shared modeling elements between different architecture domains based on the inter-domain dependency results and the cross-domain association results, and obtain the detection results.

[0021] The results output module is used to output modeling order results, inter-domain dependency results, rule-based modeling results, cross-domain association results, and / or detection results.

[0022] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0023] The memory stores computer-executed instructions;

[0024] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0026] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0027] This application provides an architecture modeling data processing method, electronic device, and storage medium. By receiving architecture description information of the system to be modeled, architecture domain definition information of a unified architecture framework, and modeling language meta-model specification information, a unified and complete processing input is established. By mapping the architecture description information to a unified modeling data structure, the original description content is transformed into a data expression that can be uniformly organized and invoked, improving the consistency of subsequent processing. Furthermore, by generating modeling sequence results and inter-domain dependency relationship results, multi-architecture domain modeling has a clear sequence and dependency basis. Matching and constraining the unified modeling data structure through a domain-specific modeling rule set forms rule-based modeling results corresponding to each architecture domain, improving the standardization and relevance of the modeling results. Cross-domain collaborative processing generates cross-domain association results, and consistency and / or dependency integrity checks are performed based on the inter-domain dependency relationship results and cross-domain association results, improving the degree of collaboration and result checkability of shared modeling elements between different architecture domains. By outputting various processing results, the usability of the modeling results is improved. In summary, this application achieves unification, sequencing, association, and checkability of the multi-architecture domain architecture modeling process for complex systems, improving the consistency, dependency integrity, and usability of the modeling results. It solves the technical problems of inconsistent modeling expressions, difficulty in effectively organizing the order and dependencies of architecture domains, difficulty in coordinating cross-domain shared modeling elements, and difficulty in checking the consistency and dependency integrity of modeling results during the modeling process of complex system multi-architecture domain architecture modeling. Attached Figure Description

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

[0029] Figure 1 This is a schematic diagram of the application architecture provided for an embodiment of this application;

[0030] Figure 2 A flowchart illustrating the system architecture modeling data processing method provided in this application embodiment;

[0031] Figure 3 This is a schematic flowchart of a method for analyzing the impact of changes provided in an embodiment of this application;

[0032] Figure 4 This is a schematic diagram of the architecture modeling data processing apparatus provided in the embodiments of this application;

[0033] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

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

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

[0036] Figure 1 This is a schematic diagram of the application architecture provided for an embodiment of this application. For example... Figure 1As shown, the application architecture of this application may include a terminal device 101 and a computer device 102. The terminal device 101 and the computer device 102 establish a communication connection through a wired communication network and / or a wireless communication network. The terminal device 101 can serve as a human-computer interaction carrier on the user side, used for modelers, architecture analysts, or other relevant users to input, submit, view, and manage processing content related to system architecture modeling. The computer device 102 can serve as a data processing entity, used to receive the architecture description information of the system to be modeled, the architecture domain definition information of the unified architecture framework, and the modeling language meta-model specification information submitted by the terminal device 101, and execute various processing procedures in the system architecture modeling data processing method of this application.

[0037] In practical applications, terminal device 101 can be a desktop computer, portable computer, workstation, tablet terminal, or other device capable of data input and result display. Users can input or import relevant architectural descriptions of the system to be modeled through terminal device 101 and initiate corresponding modeling processing requests. Upon receiving the relevant information, computer device 102 performs unified modeling data structure mapping, architectural domain determination, modeling order generation, inter-domain dependency generation, domain-specific modeling rule processing, cross-domain collaborative processing, and consistency and / or dependency integrity checks, resulting in modeling order results, inter-domain dependency results, rule-based modeling results, cross-domain association results, and / or detection results. After processing, computer device 102 can also return the corresponding processing results to terminal device 101 for users to view, analyze, and use subsequently.

[0038] Based on the above application architecture, this application is applicable to multi-architecture domain architecture modeling scenarios for air traffic management systems, aerospace systems, and other complex engineering systems. In such application scenarios, the system to be modeled typically involves multiple aspects, including strategic objectives, demand constraints, personnel configuration, operational activities, service capabilities, resource support, project implementation, and security control. Terminal device 101 can be used to carry the input of multi-source modeling information and display the processing results, while computer device 102 is used to perform unified processing and cross-domain correlation analysis on multi-architecture domain modeling data. Through this application architecture, architecture modeling can be transformed from a traditional decentralized, manually linked processing method to a data processing method centrally executed by computer device 102, improving the uniformity, consistency, and result verifiability of the multi-architecture domain modeling process.

[0039] Furthermore, in some embodiments, there may be one or more terminal devices 101, and the computer device 102 may be deployed as a server, a dedicated computing node, or other device with data processing capabilities. When multiple terminal devices 101 exist, different users can submit their respective modeling information or call processing results through different terminal devices 101, and the computer device 102 will uniformly execute the architecture modeling data processing method described in this application. In this way, this application is not only applicable to single-user modeling scenarios, but also to complex engineering system modeling scenarios involving multiple roles and positions, better meeting the application needs of architecture modeling in engineering practice.

[0040] The inventive concept of this application is to address the problems existing in the process of multi-architectural-domain architecture modeling of complex systems, such as inconsistent modeling expressions, unclear processing order of architectural domains, unclear inter-domain dependencies, difficulty in coordinating cross-domain modeling elements, and difficulty in effectively checking the consistency and dependency integrity of modeling results. This application proposes a data processing method for architecture modeling oriented towards a unified architectural framework. This method does not process the modeling content in different architectural domains in isolation. Instead, it first receives the architecture description information of the system to be modeled, the architectural domain definition information of the unified architectural framework, and the modeling language meta-model specification information, establishing a complete starting point for modeling processing based on a unified input. Subsequently, according to the modeling language meta-model specification information, the architecture description information is mapped to a unified modeling data structure, transforming the original architecture description content into a data expression form that can be uniformly organized, invoked, and processed, providing a consistent data foundation for subsequent multi-architectural-domain modeling.

[0041] Building upon this foundation, multiple architectural domains are further identified using the defined architectural domain information. Combined with pre-defined domain order rules and inter-domain dependencies, rules are determined to generate modeling order results and inter-domain dependency results. This ensures that the modeling processes in different architectural domains have both a clear sequential execution logic and a clear upstream and downstream dependency foundation. Subsequently, by obtaining the domain-specific modeling rule sets corresponding to each architectural domain, the corresponding rule sets are invoked sequentially according to the modeling order results. This performs matching and constraint processing on the unified modeling data structure, yielding rule-based modeling results for each architectural domain. Thus, the unified modeling data, upon entering different architectural domains, is no longer reused indiscriminately. Instead, it forms modeling results with domain boundaries and rule constraints based on the specific rule requirements of each architectural domain.

[0042] Furthermore, based on preset cross-domain collaboration rules, shared modeling elements in different architectural domains undergo cross-domain collaborative processing to generate cross-domain association results. In other words, for modeling elements with semantic correspondence, dependency, or reuse relationships between different architectural domains, cross-domain collaborative processing establishes a foundation for their cross-architectural domain association, enabling the modeling results of multiple architectural domains to maintain domain independence while forming a coherent architectural structure expression. Based on the generated inter-domain dependency and cross-domain association results, consistency and / or dependency integrity checks are further performed on shared modeling elements between different architectural domains to obtain the check results and determine whether semantic consistency, association consistency, and dependency chain integrity are maintained between different architectural domains. Through the above technical approach, this application achieves the unification, sequencing, rule-based approach, association, and detectability of the multi-architectural domain architecture modeling process for complex systems, improving the organization, consistency, and usability of multi-architectural domain modeling results.

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

[0044] Figure 2 A flowchart illustrating the system architecture modeling data processing method provided in this application embodiment is shown below. Figure 2 As shown, the method includes:

[0045] S21, receive the architecture description information of the system to be modeled, the architecture domain definition information of the unified architecture framework, and the metamodel specification information of the modeling language.

[0046] In this embodiment, the architecture description information of the system to be modeled is used to characterize the relevant content that the system needs to express during the architecture modeling process. This information may include information related to system objectives, components, business activities, operational relationships, constraints, and other architectural expression content. The architecture domain definition information of the unified architecture framework is used to characterize the basis for dividing each architecture domain within the unified architecture framework, its boundary scope, and the corresponding description requirements for each architecture domain. The modeling language metamodel specification information is used to characterize the semantic constraints, expression rules, and organizational specifications followed by the modeling language during the architecture modeling process, providing a unified expression basis for subsequent modeling processing. By receiving the above three types of information, subsequent processing no longer relies solely on information from a single source, but is carried out under the condition that the system description content, architecture framework constraint content, and modeling language specification content are all present. This achieves consistency in the starting point of modeling processing, which is beneficial for improving the coherence of subsequent processing and the uniformity of processing results.

[0047] In some implementations, the receiving process can uniformly acquire structured data, semi-structured data, or textual description information, and verify the integrity of the acquired information to ensure that the architecture description information of the system to be modeled, the architecture domain definition information of the unified architecture framework, and the metamodel specification information of the modeling language can all enter the subsequent processing flow.

[0048] S22, based on the metamodel specification information of the modeling language, maps the architecture description information into a unified modeling data structure.

[0049] In this embodiment, the unified modeling data structure refers to a data representation format established based on the modeling language metamodel specification information, capable of uniformly expressing, organizing, and processing architectural description information. Mapping involves converting various architectural semantic contents contained in the original architectural description information into standardized data representations that can be directly used in subsequent modeling processes, according to the expression rules, semantic boundaries, and organization methods defined by the modeling language metamodel specification information. Based on this, semantic recognition, expression transformation, and structural reorganization of architectural description information are performed according to the modeling language metamodel specification information. This transforms architectural description content, which may have differing source forms, expression methods, and organization methods, into data representations with consistent semantics and unified organization, providing a unified data foundation for subsequent modeling processes based on the unified architectural framework.

[0050] Specifically, the modeling language metamodel specification information serves as a mapping basis and semantic constraint basis in this process. The system-related content contained in the architecture description information typically exists in its original state as natural language descriptions, existing modeling results, structured fields, business descriptions, or other forms of expression. These different contents may differ in terms of granularity of expression, organizational hierarchy, and semantic orientation. By uniformly constraining the architecture description information through the modeling language metamodel specification information, the standardization of subsequent processing objects at the expression level is achieved, providing a unified entry point for subsequent sequential organization, rule processing, correlation processing, and detection processing.

[0051] Furthermore, the mapping process can include content parsing, semantic extraction, specification mapping, result organization, and data formation of the architecture description information. Content parsing is used to identify valid descriptive content related to architecture modeling from the architecture description information; semantic extraction is used to determine the meaning of each part of the descriptive content in the architecture expression; specification mapping is applied to map the identified descriptive content to the expression scope required by unified modeling based on the modeling language meta-model specification information; result organization is used to integrate the content that has been specification-mapped according to a unified data organization method; and data formation is used to output a unified modeling data structure that meets the requirements of subsequent processing. This is beneficial to improving the consistency, coherence, and processing efficiency of subsequent modeling processes.

[0052] In some implementations, the mapping process can also combine the contextual content in the architecture description information to uniformly process descriptions that have different expressions but similar semantics, and to associate and organize descriptions that have semantic dependencies, so as to ensure that the unified modeling data structure can not only preserve the original semantics of the architecture description information, but also reflect the inherent relationship between the descriptions, thereby improving the stability of the entire architecture modeling data processing process.

[0053] S23. Based on the architectural domain definition information, determine multiple architectural domains, and determine the rules according to the preset domain order rules and inter-domain dependencies to generate modeling order results and inter-domain dependency results.

[0054] In this embodiment, an architecture domain refers to a processing unit formed by dividing the architecture content according to different modeling concerns, representation objects, or analysis dimensions within a unified architecture framework. Domain order rules refer to a set of rules that constrain the sequential relationship of modeling processes among multiple architecture domains, determining the execution order of different architecture domains in subsequent processing flows. Inter-domain dependency determination rules refer to a set of rules that determine the input relationships, constraint relationships, support relationships, or association relationships between different architecture domains, determining the dependency direction and dependency relationships between each architecture domain. The modeling order result characterizes the sequential execution arrangement of multiple architecture domains in the modeling process, while the inter-domain dependency result characterizes the determined dependency relationships between different architecture domains.

[0055] Since the architectural description of the system to be modeled typically covers multiple aspects, and these different contents differ in their focus, level of expression, and processing objectives, it is necessary to first divide the processing scope corresponding to the relevant contents based on the architectural domain definition information to determine the multiple architectural domains participating in the subsequent process. This transforms the originally holistic architectural description into a set of architectural domains suitable for scoped organization and phased processing, enabling subsequent processing to unfold around clearly defined processing units. This achieves a scoped organization of the subsequent modeling processing objects, improving the systematic nature and clarity of processing boundaries in the subsequent processing. After determining multiple architectural domains, a sequential arrangement is established based on their positional relationships and processing connections within the overall modeling process, allowing subsequent processing to unfold in a predetermined order. This transforms the subsequent modeling processing from a disordered state to an ordered state, giving each architectural domain's processing a clear execution start point, execution location, and execution connection relationship, thus improving the coherence of the entire system architecture modeling data processing process.

[0056] Simultaneously, based on pre-defined inter-domain dependency determination rules, the dependency relationships between multiple architectural domains are analyzed and determined to generate inter-domain dependency results. This process clarifies whether there are input-output relationships, constraint transitive relationships, support relationships, or other dependencies between different architectural domains, and determines the direction and content of these dependencies. This clarifies the foundation of relationships between different architectural domains, which is beneficial for improving the stability and consistency of subsequent cross-architectural domain processing.

[0057] S24. Obtain the domain-specific modeling rule set corresponding to each architecture domain. Based on the modeling order, sequentially call the domain-specific modeling rule set corresponding to each architecture domain to perform matching and constraint processing on the unified modeling data structure, and obtain the rule-based modeling results corresponding to each architecture domain.

[0058] In this embodiment, the domain-specific modeling rule set refers to the set of rules set for each architecture domain, which defines the applicable scope of expression, processing basis, and result formation requirements for the corresponding architecture domain during the modeling process. The rule-based modeling result refers to the modeling result formed after matching and constraint processing, which conforms to the processing requirements of the corresponding architecture domain. Obtaining the domain-specific modeling rule set for each architecture domain aims to provide rule basis that is suitable for the modeling scope and processing objectives of different architecture domains. Since the modeling focus is different for different architecture domains, the content in the unified modeling data structure still needs to be specifically processed according to the rule requirements of each architecture domain when entering the specific architecture domain processing, so that subsequent processing has a clear domain-specific rule foundation.

[0059] After obtaining the domain-specific modeling rule sets corresponding to each architecture domain, the rule sets are then invoked sequentially according to the modeling order. This process of invoking rules for each architecture domain is organized in a unified sequence, ensuring that the processing of each architecture domain unfolds according to a predetermined order. In this way, the architecture domains processed earlier can provide a processing basis or reference for those processed later. This orderly organization of the domain-specific modeling process improves the overall flow and consistency of the processing workflow.

[0060] Subsequently, a matching process is performed on the unified modeling data structure. This matching process identifies modeling content related to the current architecture domain from the unified modeling data structure based on the rules of the current architecture domain, and determines the degree of correspondence between the relevant content and the rules of the current architecture domain. Content that meets the rules of the current architecture domain is allowed to proceed to subsequent constraint processing; content that does not meet the processing requirements of the current architecture domain or has no direct correspondence with the current architecture domain is not considered as the primary processing object of the current architecture domain. This achieves targeted screening of subsequent modeling processing objects, which helps improve processing efficiency and reduce unnecessary processing interference.

[0061] After the matching process is complete, the content that has entered the processing scope of the current architecture domain is subject to constraint processing. This constraint processing is used to impose corresponding normative requirements on the matched content based on the domain-specific modeling rule set corresponding to the current architecture domain, so that it conforms to the modeling requirements of the current architecture domain in terms of expression, association, processing boundaries, and result formation. This further transforms the modeling content, which originally only had a unified expression basis in the unified modeling data structure, into standardized results that conform to the processing requirements of a specific architecture domain, which is beneficial to improving the stability and usability of the processing results of each architecture domain.

[0062] As the above process is executed sequentially in each architectural domain according to the modeling order, the final rule-based modeling result for each architectural domain is obtained. This rule-based modeling result retains the architectural description semantics carried in the unified modeling data structure, while also reflecting the modeling requirements and processing boundaries of the corresponding architectural domain, forming domain-specific results suitable for subsequent cross-architectural domain processing and detection. This provides a foundation for subsequent cross-domain collaborative processing, consistency detection, and dependency integrity detection.

[0063] S25, based on preset cross-domain collaboration rules, performs cross-domain collaborative processing on shared modeling elements in different architecture domains to generate cross-domain association results.

[0064] In this embodiment, cross-domain collaboration rules refer to pre-defined processing rules for collaborative processing between different architectural domains. These rules standardize the correspondence, collaboration, and organization of related modeling content in different architectural domains within a cross-domain scenario. Shared modeling elements refer to modeling content that has semantic, content, reference, or processing relationships in two or more architectural domains, serving as the foundational objects for collaborative processing between different architectural domains. Cross-domain collaborative processing refers to the process of identifying, corresponding, associating, and organizing shared modeling elements in different architectural domains according to pre-defined cross-domain collaboration rules. Cross-domain association results refer to the processing results formed after cross-domain collaborative processing, reflecting the association relationships between shared modeling elements in different architectural domains. By introducing pre-defined cross-domain collaboration rules to perform cross-domain collaborative processing on shared modeling elements in different architectural domains, related content that originally existed separately in different architectural domains can form a clear connection at the cross-domain level. This ensures that multi-architectural-domain modeling results not only have their own independent processing results but also have a basis for cross-domain connection. This achieves the associative organization between results from different architectural domains, which is beneficial for improving the continuity and consistency of the subsequent overall processing.

[0065] Furthermore, since different architectural domains focus on different content scopes, the expression position, processing stage, and organizational form of related modeling content may differ across architectural domains. However, some content may still semantically correspond to, support, or be related to each other. Cross-domain collaborative processing first identifies relevant modeling content in different architectural domains based on pre-defined cross-domain collaboration rules to determine which content constitutes shared modeling elements. On this basis, the identified shared modeling elements undergo corresponding and relational processing to form a clear relationship expression at the cross-domain level. This achieves an explicit expression of related content between different architectural domains, which is beneficial for improving the ability of subsequent processing to utilize cross-domain relationships.

[0066] Cross-domain collaboration rules serve as the basis for collaboration and the basis for association constraints in this process. When shared modeling elements across different architectural domains undergo cross-domain collaborative processing, they need to be judged and organized according to unified processing rules to avoid instability in the establishment of cross-domain relationships due to different processing standards in different architectural domains. By processing according to preset cross-domain collaboration rules, the cross-domain correspondence of shared modeling elements across different architectural domains can have a unified processing basis, giving the generated cross-domain association results a stable semantic and processing foundation. Subsequently, cross-domain association results are generated. This provides a foundation for subsequent consistency checks, dependency integrity checks, and further tracing and impact analysis around different architectural domains. It realizes the transition of multi-architectural domain modeling results from domain-independent organization to cross-domain associated organization, which can improve the collaboration between processing results of different architectural domains and enhance the integrity of the entire architecture modeling data processing process.

[0067] S26. Based on the inter-domain dependency results and cross-domain association results, perform consistency detection and / or dependency integrity detection on the shared modeling elements between different architecture domains, and obtain the detection results.

[0068] In this embodiment, consistency detection is used to check whether the related modeling content maintains a consistent semantic state, association state, or expression state under cross-domain conditions, focusing on shared modeling elements across different architectural domains. Since different architectural domains undergo the aforementioned rule processing to form their respective rule-based modeling results, and related content forms cross-domain associations in cross-domain collaborative processing, the shared modeling elements in different architectural domains, although originating from different domain-specific processing processes, should generally have a mutually coordinated correspondence in the overall modeling result. By conducting consistency detection based on inter-domain dependency results and cross-domain association results, it is possible to determine whether there are inconsistencies, non-correspondences, or inconsistencies in the shared modeling elements across different architectural domains under cross-domain association conditions, enabling subsequent processing to identify related problems based on the detection results. Dependency integrity detection is used to check whether the dependencies related to shared modeling elements between different architectural domains are fully established and maintained. By conducting dependency integrity detection, it is possible to determine whether there are missing, interrupted, or unfulfilled dependency relationships established between different architectural domains around shared modeling elements, ensuring that the detection results not only reflect the consistency state of the modeling content but also the integrity state of the dependency chain.

[0069] Furthermore, both consistency and dependency integrity checks are based on the combined effects of inter-domain dependency results and cross-domain association results. The former provides the basis for what relationships should exist between different architectural domains, while the latter provides the basis for what relationships have already formed between different architectural domains. By utilizing both types of results simultaneously, the detection process can remain grounded in the established dependencies between different architectural domains, as well as the actual association state formed by shared modeling elements after cross-domain processing. Thus, when dealing with multi-architectural-domain modeling results, the detection process is no longer just a local check of results within a single architectural domain, but can judge the overall relationship across architectural domains. This completes the foundation of the detection process and improves the reliability of the detection results. After completing consistency and / or dependency integrity checks, the detection results provide output on the state of shared modeling elements between different architectural domains, supporting the subsequent use, analysis, and adjustment of the overall modeling results.

[0070] S27 outputs modeling order results, inter-domain dependency results, rule-based modeling results, cross-domain association results, and / or detection results.

[0071] In this embodiment, output does not merely refer to the simple display or transmission of processing results, but rather to providing the various results generated in the aforementioned processing flow in a identifiable and usable manner. Since the modeling order results, inter-domain dependency results, rule-based modeling results, cross-domain association results, and detection results correspond to the results of different processing stages and have clear connections between them, outputting these results ensures the complete preservation and presentation of the entire processing flow's execution results. This not only reflects the organizational relationships of each architectural domain during the modeling process but also the dependencies between different architectural domains, domain-specific processing results, cross-domain association states, and detection states. This makes the output content of the architecture modeling data processing process holistic, improving the usability of the entire processing flow's results. Furthermore, the output can selectively include modeling order results, inter-domain dependency results, rule-based modeling results, cross-domain association results, and / or detection results, depending on actual needs. In different application scenarios, one, several, or all of these results can be output to meet the usage requirements of different stages.

[0072] In one embodiment, the unified modeling data structure includes at least object records, relation records, attribute records, and graph instance records. Based on this, and according to the modeling language metamodel specification information, the architecture description information is mapped to the unified modeling data structure, including:

[0073] S221, Based on the meta-model specification information of the modeling language, the modeling elements in the architecture description information are objectified and mapped to generate object records;

[0074] S222, Based on the metamodel specification information of the modeling language, perform relational mapping on the relationships between modeling elements in the architecture description information to generate relational records;

[0075] S223, Based on the modeling language metamodel specification information, perform attribute mapping on the modeling element attribute information in the architecture description information to generate attribute records associated with object records and / or relationship records;

[0076] S224. Based on the architecture view definition information of each architecture domain in the architecture domain definition information, organize the object records, relationship records and attribute records belonging to the same architecture view into graph instance records;

[0077] S225. Based on object records, relationship records, attribute records, and graph instance records, a unified modeling data structure corresponding to the architecture description information is formed.

[0078] Specifically, the modeling language metamodel specification information can adopt the KARMA language-based metamodel specification information. KARMA can be established based on a six-element modeling specification (Graph, Object, Point, Property, Relationship, Role, GOPPRRE), enabling different types of modeling content in the architecture description information to be split, classified, and organized within a unified semantic framework. Here, modeling elements refer to the basic content units in the architecture description information that can participate in the expression of the system architecture. By objectifying and mapping the modeling elements in the architecture description information, the system entities, capability units, job units, service units, resource units, constraint units, or other entity expressions in the original description can be converted into uniformly managed object records, giving the entity-class content in the original description a clear identification and organizational basis for subsequent processing.

[0079] Furthermore, relational mapping refers to the process of extracting and standardizing the relationships between modeling elements in the architecture description information. In the context of architecture modeling, different modeling elements in the architecture description information typically exhibit relationships such as structural associations, logical dependencies, behavioral associations, constraint propagation, support connections, or process connections. By performing relational mapping on the relationships between modeling elements according to the modeling language metamodel specification information, the related content in the original description can be converted from natural language expressions or non-standardized expressions into relational records, allowing the connection methods, directions of action, and semantic relationships between objects to be preserved in a unified form. This process enables subsequent dependency analysis, domain rule processing, and cross-domain collaborative processing to be based on explicit relational expressions. It achieves explicit and structured expression of the relationships between modeling elements, improving the ability of subsequent modeling processes to utilize relational information.

[0080] Furthermore, attribute mapping refers to the process of extracting attribute information from modeling elements and forming attribute records. Attribute information describes the feature content, constraint content, parameter content, or supplementary semantic content attached to object records and / or relationship records. By performing attribute mapping on the attribute information of modeling elements in the architecture description information according to the modeling language metamodel specification information, the scattered name information, state information, limitation information, rule information, parameter information, or other supplementary descriptions in the original description can be uniformly attached to the corresponding object records and / or relationship records. This enables object records and relationship records to not only have basic entity and association expression capabilities but also additional expression capabilities for characterizing detailed features. This processing method, in conjunction with the aforementioned object mapping and relation mapping, enables the entity content, association content, and attribute content in the architecture description information to form a semantically consistent record system under the constraints of the same modeling language metamodel specification information. This achieves standardized attachment and unified organization of modeling details, which is beneficial to improving the semantic integrity in subsequent domain-specific processing.

[0081] Further, based on the architectural view definition information of each architectural domain in the architectural domain definition information, object records, relationship records, and attribute records belonging to the same architectural view are organized into graph instance records. The architectural view definition information characterizes the view organization basis for carrying specific modeling content under each architectural domain, while the graph instance records characterize the view-level modeling results organized according to the corresponding architectural view definition information. By organizing object records, relationship records, and attribute records belonging to the same architectural view into graph instance records, the originally scattered basic records can be incorporated into organizational units corresponding to the architectural view. This allows subsequent processing to not only analyze individual records but also call, display, verify, and manage at the view hierarchy level. This achieves the transformation of basic modeling records into view organization results, enabling the unified modeling results to have the organizational capability for multi-view modeling.

[0082] Subsequently, the correspondences, dependencies, and organizational relationships among object records, relationship records, attribute records, and graph instance records are uniformly integrated to form a unified modeling data structure capable of supporting subsequent architecture domain partitioning, rule processing, cross-domain collaborative processing, and detection processing. This unified modeling data structure enables the multi-architecture domain modeling process based on a unified architecture framework to be built on a unified semantic and organizational foundation. This allows subsequent processing of different architecture domains, such as strategic domain, requirement domain, personnel domain, operational domain, service domain, resource domain, project domain, and security domain, to share a consistent data representation foundation and supports object reuse, relationship connection, and semantic transfer across architecture views. By forming a unified modeling data structure corresponding to the architecture description information, the transformation from the original architecture description to a standardized, structured, and organized modeling result is achieved, providing direct support for subsequent domain-specific modeling rule set processing and cross-domain collaborative processing.

[0083] In one embodiment, based on the above embodiments, multiple architectural domains are determined based on architectural domain definition information, and rules are determined according to preset domain order rules and inter-domain dependency relationships to generate modeling order results and inter-domain dependency relationship results, including:

[0084] S231, determine the set of architecture domains to be processed based on the architecture domain definition information; wherein, the set of architecture domains includes strategic domain, requirement domain, personnel domain, operation domain, service domain, resource domain, project domain and / or security domain;

[0085] S232, Based on the domain order rules, determine the modeling execution order of the architectural domains in the architectural domain set and generate the modeling order result;

[0086] S233, determine the dependency direction and dependency type between each architectural domain according to the inter-domain dependency relationship determination rules, and generate the inter-domain dependency relationship results based on the dependency direction and dependency type between each architectural domain.

[0087] In this embodiment, the architecture domain definition information can come from the architecture domain partitioning definition in the Unified Architecture Framework (UAF), used to characterize the processing scope, processing boundaries, and interrelationships of various modeling contents during the architecture modeling process. The set of architecture domains to be processed refers to the set of architecture domains that actually participate in the sequential organization and dependency analysis in the current modeling process, which may include strategic domains, requirement domains, personnel domains, operational domains, service domains, resource domains, project domains, and / or security domains. Among them, the strategic domain is used to clarify the system's top-level goals, vision, capability direction, and constraints. The strategic domain represents the system's top-level goals, capability directions, and sources of constraints; the requirements domain represents business, functional, and performance requirements; the personnel domain represents organizational units, job roles, and personnel configurations based on strategic goals and requirements constraints; the operational domain defines operational activities, execution entities, and operational processes under personnel configuration and requirements constraints; the service domain represents the service capabilities and functions that can be provided; the resource domain represents the system resources, technical resources, and data resources that support service capabilities and operational activities; the project domain represents project activities, milestones, and implementation arrangements during engineering implementation; and the security domain represents risk identification, security capabilities, and security constraints. By determining the set of architecture domains to be processed based on the architecture domain definition information, the originally holistic architecture description can be divided into multiple modeling scopes that can be organized and processed separately. This ensures that the subsequent modeling execution order and dependency determination are based on clearly defined processing objects. This achieves a clear division of the modeling scope of multiple architecture domains under a unified architecture framework, improving the organizeability of subsequent processing.

[0088] Furthermore, the modeling execution order of the architectural domains in the set of architectural domains is determined, generating a modeling order result to establish an orderly processing arrangement among multiple architectural domains. For example, following the organizational principles of from abstract to concrete, from stable to variable, and from constraint to implementation, the position of each architectural domain in the overall modeling process is determined. For instance, the modeling execution order can be organized in the order of strategic domain, requirement domain, personnel domain, operational domain, service domain, resource domain, project domain, and security domain. Specifically, the strategic domain is processed first to clarify the system's top-level goals and capability directions. Then, based on the goal constraints formed by the strategic domain, the requirement domain is processed to form a traceable requirement foundation. Subsequently, the personnel and operational domains are processed in conjunction with requirement constraints to determine the executing entities and operational activities. Based on this, the service and resource domains are processed to establish service capabilities and their implementation support. Next, the project domain is processed to map the aforementioned modeling results to the engineering implementation level. The security domain is used to form a comprehensive risk analysis and security constraints based on the modeling results of the aforementioned architectural domains. In this way, the modeling sequence can characterize the sequential execution relationship of different architectural domains, giving the subsequent domain-specific modeling rule set invocation process a clear execution order and a basis for connection. This achieves a sequential organization of the multi-architectural-domain modeling process, which is beneficial for improving the coherence of subsequent processing.

[0089] Furthermore, the dependency directions and dependency types between each architectural domain are determined, and inter-domain dependency relationship results are generated based on these directions and types to establish a clear dependency foundation among multiple architectural domains. In this embodiment, the dependency direction is used to characterize the direction of dependency transmission between different architectural domains, and the dependency type is used to characterize the category of dependency relationship formed between different architectural domains. For example, the rules for determining inter-domain dependencies may include input dependency rules of the strategic domain on the demand domain, operational domain, and service domain, i.e., the goals and capabilities formed in the strategic domain serve as the source of constraints for downstream architectural domain processing; constraint dependency rules of the demand domain on the operational domain and service domain, i.e., the functional and performance requirements formed in the demand domain constrain subsequent operational activities and service capability configurations; support dependency rules of the personnel domain on the operational domain, i.e., personnel configuration and job capabilities serve as the supporting foundation for the feasibility of operational execution entities; realization dependency rules between the service domain and the resource domain, i.e., the realization of service capabilities depends on the system resources, technical resources, and data resources provided by the resource domain; and global constraint dependency rules of the security domain on the operational domain, service domain, and resource domain, i.e., the risk identification and security constraints formed by the security domain form global constraints on the processing results of related architectural domains. By determining the dependency direction and type according to the above rules, the previously implicit input-output relationships, constraint transitive relationships, and support relationships between different architectural domains can be clarified, enabling subsequent cross-domain collaborative processing and detection processing to be directly based on the established dependency foundation. This achieves a structured expression of dependency relationships between different architectural domains and improves the stability of subsequent cross-domain processing.

[0090] In this implementation, the modeling order results and inter-domain dependency results are not isolated from each other, but together form the organizational basis for subsequent modeling processing. The modeling order results address the question of "what to process first and what to process later" for each architectural domain, while the inter-domain dependency results address the question of "who depends on whom and what content they depend on" for each architectural domain. When combined, subsequent processing can invoke the corresponding domain-specific modeling rule sets for each architectural domain based on a clear order, while maintaining effective identification of inter-domain dependencies during processing. When the modeling results formed by the upstream architectural domain change, the inter-domain dependency results can also be used to identify the potential impact on the downstream architectural domain, providing prerequisites for subsequent cross-domain collaborative processing, consistency checks, dependency integrity checks, and change impact analysis. By simultaneously forming modeling order results and inter-domain dependency results, an orderly organization and dependency organization of the multi-architectural-domain modeling process under a unified architectural framework is achieved, providing a stable process and relational foundation for the entire architecture modeling data processing method.

[0091] In one embodiment, based on the above embodiments, matching and constraint processing are performed on the unified modeling data structure to obtain the rule-based modeling results corresponding to each architecture domain, including:

[0092] S241, determine the sequence of architecture domains to be processed based on the modeling order results, and select one architecture domain from the sequence as the current architecture domain.

[0093] S242, obtain the domain modeling rule set corresponding to the current architecture domain, and extract the object record, relation record and attribute record corresponding to the current architecture domain from the unified modeling data structure.

[0094] S243, extract object type items, relation type items and attribute configuration items from the domain modeling rule set, and determine the allowed object type set, allowed relation type set and allowed attribute configuration method set respectively.

[0095] S244, match the object type of the object record with the set of allowed object types, match the relationship type of the relationship record with the set of allowed relationship types, and / or match the attribute configuration method of the attribute record with the set of allowed attribute configuration methods to generate a matching result.

[0096] S245, Based on the matching process results, filter and obtain the matching object records, relationship records, and / or attribute records.

[0097] S246, and based on the domain constraints, modeling granularity constraints, and modeling output requirements, perform constraint processing on the matched object records, relation records, and / or attribute records to generate constraint processing results.

[0098] S247. Based on the matching and constraint processing results, generate the rule-based modeling result for the current architecture domain, and traverse the architecture domain sequence to obtain the rule-based modeling result for each architecture domain.

[0099] Specifically, the architecture domain sequence is used to represent the order in which multiple architecture domains are arranged in the current processing flow, and the current architecture domain is used to refer to the architecture domain participating in the domain-specific modeling process in the current round. By first forming the architecture domain sequence to be processed based on the modeling order result, and then selecting the current architecture domain one by one, the calling process of the domain-specific modeling rule set can be kept consistent with the aforementioned sequential organization result, ensuring that the multi-architecture domain modeling process unfolds step by step according to the predetermined sequence.

[0100] Domain-specific modeling rule sets can be configured according to the modeling requirements of different architecture domains within the Unified Architecture Framework (UAF), enabling each architecture domain to have its own processing boundaries and modeling basis. For example, in the strategy domain, the domain-specific modeling rule set can be used to limit the processing requirements of strategic goal objects and capability direction objects; in the requirements domain, it can be used to limit the processing requirements of business requirements, functional requirements, and performance requirements; in the personnel domain, it can be used to limit the processing requirements of organizational unit objects, job objects, and personnel objects; in the operation domain, it can be used to limit the processing requirements of operation architecture objects, operation executor objects, and operation activity objects; and in the service, resource, project, and security domains, the processing requirements of corresponding service objects, resource objects, project objects, and security objects can be limited respectively. By first obtaining the domain-specific modeling rule set corresponding to the current architecture domain, and then extracting the object records, relationship records, and attribute records corresponding to that architecture domain from the unified modeling data structure, subsequent processing of the current architecture domain revolves only around the content related to this architecture domain, reducing interference from irrelevant content in the current processing process.

[0101] Furthermore, object type items, relationship type items, and attribute configuration items are extracted from the domain-specific modeling rule set to determine the allowed object type set, allowed relationship type set, and allowed attribute configuration method set, respectively. Object type items characterize the object categories allowed in the current architecture domain, relationship type items characterize the relationship categories allowed in the current architecture domain, and attribute configuration items characterize the attribute configuration methods allowed in the current architecture domain. Object type items, relationship type items, and attribute configuration items can have different contents in different architecture domains. Correspondingly, relationship type items can limit the relationship categories allowed to be processed in the current architecture domain, such as derived relationships, refined relationships, assumption relationships, responsibility relationships, process relationships, dependency relationships, and support relationships. Attribute configuration items can limit the configuration methods suitable for attaching to object records and / or relationship records, such as capability requirement attributes, performance requirement attributes, resource configuration parameters, security constraint attributes, and other configuration methods. By splitting and aggregating the domain-specific modeling rule set, the basis for subsequent matching processing is clarified, improving the executability of rule application.

[0102] After obtaining the sets of allowed object types, allowed relation types, and allowed attribute configuration methods, the system matches the object type of an object record with the allowed object type set, the relation type of a relation record with the allowed relation type set, and / or the attribute configuration method of an attribute record with the allowed attribute configuration method set, generating matching results. If the object type of an object record falls into the allowed object type set, it indicates that the object record has the basis for entering the current schema domain for processing; if the relation type of a relation record falls into the allowed relation type set, it indicates that the relation record can be adopted in the current schema domain; if the attribute configuration method of an attribute record falls into the allowed attribute configuration method set, it indicates that the attribute record can participate in processing according to the attribute rules of the current schema domain. In this way, records related to the current schema domain in the unified modeling data structure are further refined and distinguished into two categories: matched and unmatched. For different schema domains, the matching process can reflect their own modeling boundaries. For example, in the requirements domain, the matching process allows records that express business requirements, functional requirements, and performance requirements to be processed; in the resource domain, the matching process allows records that express system resources, technical resources, and data resources to be processed; and in the security domain, the matching process allows records that express risk objects, security capability objects, and security constraint objects to be processed. This implements rule-based filtering of objects processed in the current architecture domain, which helps reduce the number of records that do not meet the requirements of the current architecture domain from entering subsequent processing.

[0103] After generating the matching results, the matched object records, relationship records, and / or attribute records are filtered and retrieved. This allows subsequent constraint processing to focus on the set of records that already meet the basic type and configuration conditions, improving the efficiency and targeting of subsequent constraint processing. Furthermore, constraint processing is applied to the matched object records, relationship records, and / or attribute records based on domain-specific constraints, modeling granularity constraints, and modeling output requirements. Domain-specific constraints define the relationship, dependency, or association requirements that object records, relationship records, and attribute records within the current architecture domain should meet; modeling granularity constraints define the expression level and refinement of the modeling content within the current architecture domain; and modeling output requirements define the output organization requirements that the processed results of the current architecture domain should meet.

[0104] For example, the domain-specific modeling rule sets for each architecture domain need to clearly define the modeling output format requirements to ensure that the modeling results from different architecture domains can be uniformly integrated. For instance: the strategic domain output format is XML, containing a structured description of strategic objectives, capability directions, and constraints; the requirement domain output format is JSON, containing key-value pairs representing requirement objects, derivation relationships, and performance parameters; and the resource domain output format is a UML diagram, containing a graphical representation of resource objects, support relationships, and configuration parameters.

[0105] For example, in the strategic domain, domain constraints can require that capability-oriented objects must be associated with at least one strategic objective object, and strategic constraints are attached to the corresponding strategic object as attributes. In the requirement domain, domain constraints can require requirement objects to establish a traceability link through derivation or refinement relationships, and functional requirements must be associated with at least one strategic objective or capability-oriented object, with performance requirements attached to the corresponding functional requirement object as attributes. In the personnel domain, domain constraints can require that job objects be associated with capability requirement attributes, and personnel objects and job objects are connected through responsibility relationships. In the operational domain, domain constraints can require that operational executors are associated with operational activities through responsibility relationships. Furthermore, operational activities are connected through process relationships or dependencies. In the service domain, domain constraints can limit the association of service functions with the operational activities they support, and service interfaces are expressed as attributes or interface points. In the resource domain, domain constraints can limit the association of resource objects with service objects or operational activities through support relationships, and resource configuration parameters are expressed as attributes. In the project domain, domain constraints can limit the association of project activities with relevant objects in the operational and resource domains, and project time nodes and schedule requirements are expressed as attributes. In the security domain, domain constraints can limit the association of risk objects with the operational activities or service objects they affect, and security constraints act on relevant objects as attributes or relationships. By performing constraint processing on matching records based on the above domain constraints, modeling granularity constraints, and modeling output requirements, records entering the processing scope of the current architecture domain not only meet the type matching requirements but also further meet the rule requirements, granularity requirements, and output requirements within the current architecture domain. This achieves the standardized formation of domain-specific modeling results and improves the stability and consistency of the current architecture domain modeling results.

[0106] Subsequently, based on the matching and constraint processing results, the rule-based modeling result for the current architecture domain is generated, and the architecture domain sequence is traversed to obtain the rule-based modeling result corresponding to each architecture domain. The rule-based modeling result for the current architecture domain retains the original architecture semantics related to the current architecture domain in the unified modeling data structure, while also reflecting the modeling boundaries, granularity, and output requirements of the current architecture domain itself. As each architecture domain in the architecture domain sequence is selected as the current architecture domain and the above process is repeated, rule-based modeling results corresponding to the strategy domain, requirement domain, personnel domain, operation domain, service domain, resource domain, project domain, and security domain can be finally formed. This realizes the transformation from the unified modeling data structure to a domain-specific modeling result system, providing a direct foundation for subsequent cross-domain processing and detection processing.

[0107] In one embodiment, cross-domain collaboration rules include object reuse rules and relationship inheritance rules; correspondingly, based on the above embodiments, cross-domain collaboration processing is performed on shared modeling elements in different architectural domains to generate cross-domain association results, including:

[0108] S251, obtain the rule-based modeling results corresponding to each architecture domain, and identify shared modeling elements among the rule-based modeling results based on cross-domain collaboration rules; wherein, shared modeling elements include shared objects, shared relationships and / or shared attributes;

[0109] S252, based on shared objects, according to object reuse rules, establish a shared object mapping relationship between the rule-based modeling results of different architecture domains, and reuse the object records mapped to the same shared object as the same object instance to form cross-domain shared object mapping records;

[0110] S253, based on the relationship record corresponding to the shared object, establish a relationship inheritance relationship between different architectural domains according to the relationship inheritance rules, and pass the relationship record in the upstream architectural domain to the downstream architectural domain to form a relationship inheritance record;

[0111] S254, Based on the attribute records corresponding to the shared object or shared relationship, establish the correspondence between shared attributes according to the shared object mapping relationship and the relationship inheritance relationship, and generate attribute association records;

[0112] S255 organizes cross-domain shared object mapping records, relation inheritance records, and attribute association records into cross-domain association results.

[0113] In this embodiment, a shared object refers to an object record that has the same semantic orientation, the same modeling entity meaning, or the same instance origin in two or more architectural domains. A shared relationship refers to a relationship record formed around the aforementioned shared objects and having inheritance, continuation, transmission, or correspondence relationships between different architectural domains. A shared attribute refers to an attribute record attached to a shared object and / or a shared relationship and having corresponding meanings between different architectural domains. By checking the rule-based modeling results corresponding to each architectural domain based on cross-domain collaboration rules, the shared objects, shared relationships, and shared attributes that constitute the shared modeling elements can be identified. This allows subsequent cross-domain collaborative processing to revolve around these shared modeling elements, achieving the directional determination of cross-domain collaborative processing objects and providing a prerequisite for establishing cross-domain shared relationships.

[0114] Furthermore, based on shared objects and according to object reuse rules, a shared object mapping relationship is established between the rule-based modeling results of different architectural domains. Object records mapped to the same shared object are reused as the same object instance to form cross-domain shared object mapping records. When object records in different architectural domains are identified as corresponding to the same system entity, the same capability expression, the same job unit, the same service unit, the same resource unit, or other modeling objects with a unified semantic orientation, they are no longer considered as multiple independent objects. Instead, they are mapped to the same shared object according to object reuse rules and reused uniformly as the same object instance. Through this approach, capability direction objects formed in the strategic domain, requirement objects associated in the requirement domain, execution entity objects involved in the operational domain, service objects in the service domain, and support objects in the resource domain—all content with a unified object semantic foundation—can establish a shared object mapping relationship between different architectural domains. This process ensures that object records in different architectural domains have a unified instance foundation while maintaining their domain-specific expression positions, avoiding the redefinition or semantic drift of the same object in different architectural domains. It achieves the unification and reusability of cross-architecture domain object instances, and improves the semantic consistency between multi-architecture domain modeling results.

[0115] Furthermore, according to the relation inheritance rules, relation inheritance relationships are established between different architectural domains, and relation records in the upstream architectural domain are passed to the downstream architectural domain to form relation inheritance records. There is not only a need for reuse of shared objects between different architectural domains, but also a need for continuous transmission of relational semantics in cross-domain modeling. For example, the goal constraint relationship in the strategic domain can form a constraint basis for the requirement domain; the requirement traceability relationship in the requirement domain can form a constraint basis for the operation domain and service domain; the job assignment relationship in the personnel domain can form a supporting basis for the execution responsibility relationship in the operation domain; the service capability relationship in the service domain can form an implementation basis for the supporting relationship in the resource domain; and the risk constraint relationship in the security domain can form a global constraint basis for the operation domain, service domain, and resource domain. In this embodiment, for relation records corresponding to shared objects, not only is their relational meaning maintained within their respective architectural domains, but they are also transmitted along the predetermined upstream to downstream architectural domain direction according to the relation inheritance rules, so that the relevant relational semantics can be continued in cross-domain processing. In this way, relational semantics that originally only existed in the upstream architectural domain can be extended to the relevant downstream architectural domains, establishing a relational inheritance link between multiple architectural domains and improving the integrity of cross-domain collaborative processing.

[0116] Next, shared attribute correspondences are established based on shared object mappings and relational inheritance relationships, generating attribute association records. Specifically, when an attribute record is attached to a shared object, it needs to establish attribute correspondences around the same shared object across different architectural domains based on the shared object mapping relationship; when an attribute record is attached to a shared relation, it needs to establish attribute correspondences around the inheritance chain across different architectural domains based on the relational inheritance relationship. Attributes such as strategic constraints, performance requirements, job competency requirements, service interface attributes, resource configuration parameters, and security constraints can all participate in establishing correspondences as attribute records in cross-domain collaborative processing. In this way, the attribute semantics carried by shared objects or shared relations can form a correspondence basis across different architectural domains, enabling subsequent consistency checks and dependency integrity checks to examine not only the cross-domain status of objects and relations but also the cross-domain status of attributes, thus improving the semantic integrity of cross-domain association results.

[0117] In a specific implementation, the rules for cross-domain transfer of shared attributes are further explained as follows: When the attribute configuration method of a shared object is "attribute value inheritance," the downstream architectural domain must directly reuse the attribute value of the upstream architectural domain; when the attribute configuration method is "attribute value overriding," the downstream architectural domain can independently define the attribute value. For example, if the "capability direction" attribute defined in the strategic domain adopts the "attribute value inheritance" method, the corresponding attribute in the requirement domain must be consistent with the strategic domain value; if the "attribute value overriding" method is adopted, the requirement domain can redefine the attribute value based on business requirements.

[0118] Cross-domain association results directly reflect the established collaborative foundation between modeling results from multiple architectural domains. This allows subsequent consistency checks to examine object records mapped to the same shared object, inherited relationship records, and corresponding associated attribute records. It also enables subsequent dependency integrity checks to assess the transmission status of shared modeling elements between upstream and downstream architectural domains. Furthermore, cross-domain association results provide a foundation for subsequent cross-domain tracing chain construction and change impact analysis. When object records, relationship records, or attribute records in an upstream architectural domain change, this cross-domain association result can be used to locate the affected downstream architectural domain modeling content. This provides direct support for subsequent detection, tracing, and impact analysis.

[0119] In one embodiment, based on the above embodiments, consistency checks are performed on shared modeling elements between different architecture domains, and the check results are obtained, including:

[0120] S2611, convert the inter-domain dependency results into a dependency table; wherein, the dependency table includes the source architecture domain identifier, the target architecture domain identifier, and the dependency type;

[0121] S2612, Determine the set of architecture domain pairs based on the dependency table; wherein, the architecture domain pair consists of a source architecture domain and a target architecture domain.

[0122] S2613, Determine the set of shared modeling elements between architecture domain pairs based on the cross-domain association results; wherein, the set of shared modeling elements includes shared objects, shared relationships, and shared attributes;

[0123] S2614, Based on shared objects, compare whether object records mapped to the same shared object are consistent between architectural domain pairs, and generate object consistency detection sub-results;

[0124] S2615, Based on the shared relationship, compare whether the relationship inheritance records in the cross-domain association results are consistent between the architecture domain pairs, and compare whether the correspondence between the source object identifier and the target object identifier in the relationship inheritance records is consistent between the architecture domain pairs, and generate a relationship consistency detection sub-result;

[0125] S2616, based on shared attributes, compare whether attribute records are consistent between pairs of architectural domains and generate attribute consistency detection sub-results;

[0126] S2617. Obtain the consistency detection result based on the object consistency detection sub-result, the relation consistency detection sub-result, and the attribute consistency detection sub-result.

[0127] In this embodiment, the dependency table includes a source architecture domain identifier, a target architecture domain identifier, and a dependency type. The source architecture domain identifier represents the architecture domain that is upstream in the architecture domain dependency relationship, providing input, constraint, or support foundations for other architecture domains. The target architecture domain identifier represents the architecture domain that is downstream in the architecture domain dependency relationship, receiving relevant modeling semantics from the upstream architecture domain and utilizing them in subsequent processing. The dependency type represents the category of dependency relationships formed between different architecture domains. The process of converting the inter-domain dependency results into a dependency table involves organizing the previously determined inter-domain dependency directions and dependency types into a table structure. This allows subsequent consistency checks to no longer directly deal with the relatively scattered dependency results, but rather to retrieve and invoke the dependency foundations between different architecture domains based on unified table entries. For example, the dependency type can reflect the input dependency of the strategic domain on the demand domain, operational domain, and service domain; the constraint dependency of the demand domain on the operational domain and service domain; the support dependency of the personnel domain on the operational domain; the implementation dependency between the service domain and the resource domain; and the global constraint dependency of the security domain on the operational domain, service domain, and resource domain.

[0128] Next, the set of architectural domain pairs is determined based on the dependency table. This set represents the combination of architectural domains that actually require cross-domain checks during the current consistency check process. By determining the set of architectural domain pairs based on the dependency table, the scope of consistency checks can be limited to architectural domains with clear dependency foundations, ensuring that the objects to be checked are consistent with the aforementioned modeling order and dependency organization. This clarifies the scope of consistency checks, which is beneficial for improving processing efficiency.

[0129] Furthermore, the set of shared modeling elements between architectural domain pairs is determined based on the cross-domain association results. Specifically, for the same architectural domain pair, its set of shared objects can be determined from the cross-domain shared object mapping record, its set of shared relationships can be determined from the relationship inheritance record, and its set of shared attributes can be determined from the attribute association record. These are then organized into the set of shared modeling elements for the corresponding architectural domain pair. This centralizes and clarifies the input content for architectural domain pair consistency detection, providing a direct basis for subsequent itemized detection.

[0130] Based on shared objects, the consistency check sub-result is generated by comparing whether object records mapped to the same shared object are consistent across architectural domain pairs. Consistency here can refer to the consistency of object records in terms of object semantics, object instance affiliation, object type positioning, name expression, or object association. Since shared object mapping relationships have been established between different architectural domains according to object reuse rules, and object records mapped to the same shared object are reused as the same object instance, the consistency check phase needs to further determine whether the object records of the shared object remain consistent across the relevant architectural domain pairs. For example, if a capability direction object exists as a strategic layer object in the strategy domain, and is associated with a requirement object in the requirement domain, and if it has been mapped to the same shared object, it is necessary to check whether the object records of this shared object in the two architectural domains are consistent in terms of semantic affiliation and instance. Similarly, if a position object exists as a position configuration object in the personnel domain and is reused in the operation domain through execution subject-related objects, it is also necessary to check whether its object records remain consistent across the architectural domain pairs. By comparing shared objects item by item, it is possible to identify whether there is semantic drift, mismatch of object instances, or mismatch of object records in cross-domain object-level collaboration.

[0131] For example, by comparing the instance identifiers (such as object IDs or globally unique identifiers) of the same shared object in different architectural domains, if the instance identifiers are inconsistent, it is determined to be a semantic conflict. For instance, if the identifier of the "radar equipment" object in the strategic domain is "STR-001", while the identifier of the same object in the resource domain is "RES-001", a consistency detection alarm will be triggered, indicating that a semantic conflict needs to be manually reviewed.

[0132] Furthermore, based on shared relationships, the consistency of relationship inheritance records across architectural domain pairs is compared according to the relationship inheritance records in the cross-domain association results. Additionally, the correspondence between the source object identifier and the target object identifier in the relationship inheritance records is compared across architectural domain pairs to generate a relationship consistency detection sub-result. Specifically, when a relationship record in an upstream architectural domain is passed to a downstream architectural domain, if its relationship semantics are continued in the downstream architectural domain, it indicates that the relationship inheritance record has a consistent foundation. If, during the transmission process, the relationship type changes, the inheritance chain is broken, or the correspondence between the source object and the target object no longer matches, it indicates that there is a consistency problem between the shared relationship and the architectural domain pairs. By simultaneously comparing the consistency of the relationship inheritance record itself and the consistency of the correspondence between the source object identifier and the target object identifier, the cross-domain check at the relationship level not only focuses on the existence of the relationship but also on whether the relationship correctly connects the corresponding shared objects. This achieves a dual check of cross-architectural domain relationship semantics and object connection relationships, improving the completeness of relationship-level consistency detection.

[0133] Furthermore, the consistency of attribute records across architectural domain pairs is compared to generate attribute consistency detection sub-results. In specific processing, the existence state, attribute semantics, attribute configuration attribution, and the attachment state between attributes and corresponding shared objects or relationships of related attribute records can be compared across architectural domain pairs, focusing on the same shared object or shared relationship. If an attribute record has already been formed in the upstream architectural domain, but should have a corresponding expression in the downstream architectural domain through shared object mapping or relationship inheritance, yet no corresponding attribute association has been formed, or the formed attribute content is inconsistent with the original attribute semantics, then an attribute consistency anomaly can be determined. By generating attribute consistency detection sub-results, cross-architectural domain attribute semantic checks are achieved, improving the overall granularity of consistency detection.

[0134] Consistency detection results are obtained based on the aforementioned sub-results. This synthesis process can merge the sub-results according to architectural domain pairs, or organize them according to the association chains of shared objects, shared relationships, and shared attributes. This ensures that the final consistency detection results reflect both individual detection conclusions and the overall consistency status of a particular architectural domain pair. Thus, when the objects, relationships, and attributes within an architectural domain pair are consistent, the consistency status of that pair at the shared modeling element level is deemed to meet the requirements. If any sub-result reflects inconsistencies, the corresponding anomaly status can be indicated in the consistency detection results, providing a basis for subsequent processing or adjustments. This achieves a comprehensive determination of the consistency status of shared modeling elements across architectural domains, providing a reliable detection foundation for subsequent dependency integrity checks, cross-domain traceability chain establishment, and change impact analysis.

[0135] In one embodiment, based on the above embodiments, dependency integrity checks are performed on shared modeling elements between different architecture domains, and the check results are obtained, including:

[0136] S2621, convert the inter-domain dependency results into a dependency table, and convert the modeling order results into a sequence table;

[0137] S2622, determine the target architecture domain according to the sequence list, and determine the set of dependent source architecture domains and dependency types corresponding to the target architecture domain according to the dependency relationship table;

[0138] S2623, Based on the target architecture domain, determine the shared modeling elements in the target architecture domain from the cross-domain association results, and determine the rule-based modeling results corresponding to each dependent source architecture domain in the dependent source architecture domain set;

[0139] S2624, detect whether the shared modeling elements establish cross-domain association relationships with the regularized modeling results of each dependent source architecture domain corresponding to the dependency type, and obtain the dependency integrity detection results.

[0140] In this embodiment, the dependency table is used to structurally organize the determined dependency directions and types between different architectural domains. Its entries can at least represent the source architectural domain, the target architectural domain, and the corresponding dependency type, transforming the results originally used to describe the basis of inter-domain dependencies into searchable, callable, and comparable table-structured data. By forming the dependency table and sequence table, a structured expression of the basic data for dependency integrity detection is achieved, improving the standardization and executability of subsequent detection processing.

[0141] The target architecture domain is determined based on the sequence list, and the set of dependent source architecture domains and dependency types corresponding to the target architecture domain are determined based on the dependency relationship table. The target architecture domain refers to the architecture domain that is the object of inspection in the current dependency integrity check round, and the set of dependent source architecture domains refers to one or more architecture domains that are upstream of the target architecture domain in the inter-domain dependency relationship and provide input, constraint, or support foundations for the target architecture domain. Different target architecture domains have different sets of dependent source architecture domains and dependency types. For example, when the target architecture domain is a requirement domain, its dependent source architecture domains may include strategic domains, and the corresponding dependency types may be input dependencies or constraint dependencies; when the target architecture domain is an operational domain, its dependent source architecture domains may include requirement domains and personnel domains, and the corresponding dependency types may be constraint dependencies and support dependencies; when the target architecture domain is a resource domain, its dependent source architecture domains may include service domains, and the corresponding dependency type may be implementation dependencies; when the target architecture domain is an operational domain, service domain, or resource domain, its dependent source architecture domains may also include security domains, and the corresponding dependency type may be global constraint dependencies. By defining the target architecture domain, the set of dependent source architecture domains, and the dependency types, the dependency integrity detection objects and their dependency sources are clearly defined, improving the targeting of the detection process.

[0142] Since dependency integrity testing does not indiscriminately check all modeling content in the target architecture domain, but focuses on checking whether shared modeling elements in the target architecture domain that should maintain dependencies with upstream dependent source architecture domains have established corresponding cross-domain associations, it is necessary to first determine the set of shared modeling elements within the target architecture domain from the cross-domain association results. Simultaneously, to determine whether these shared modeling elements have formed the necessary dependency chains with their respective upstream architecture domains, it is also necessary to obtain the rule-based modeling results corresponding to each dependent source architecture domain in the dependent source architecture domain set, serving as the upstream benchmark for subsequent comparisons and judgments. For example, shared modeling elements in the requirement domain can maintain a traceability basis with the goals and capability directions in the strategy domain; shared modeling elements in the operation domain can maintain a supporting basis with the functional requirements in the requirement domain and the positions and personnel configurations in the personnel domain; shared modeling elements in the resource domain can maintain an implementation basis with the service capabilities in the service domain; and shared modeling elements related to the security domain can form a constraint basis for the relevant modeling content in the operation, service, and resource domains.

[0143] Based on this, the system checks whether shared modeling elements have established cross-domain relationships with the regularized modeling results of each dependent source architecture domain, corresponding to the dependency types, to obtain dependency integrity detection results. If a cross-domain relationship corresponding to the dependency type has been established, it indicates that the modeling result of the shared modeling element in the target architecture domain has a complete upstream dependency foundation; if no corresponding cross-domain relationship has been established, or the established cross-domain relationship does not match the dependency type, it indicates that the dependency chain of the shared modeling element in the target architecture domain is missing, interrupted, or not implemented. This detection can be used to implement execution requirements such as "subsequent architecture domain modeling activities must use the modeling results of the preceding architecture domain as input," "downstream architecture domain modeling is not allowed to be carried out directly in the absence of necessary upstream modeling results," and "when the modeling results of the upstream architecture domain change, the subsequent architecture domain models constrained by them must be re-evaluated."

[0144] Specifically, when the relevant shared modeling elements in the demand domain do not establish an input dependency or constraint dependency with the corresponding rule-based modeling results in the strategic domain, it can be determined that the demand domain lacks sufficient dependency integrity on the corresponding shared modeling elements. Similarly, when the relevant shared modeling elements in the operational domain do not establish a supporting dependency with the corresponding rule-based modeling results in the personnel domain, or a constraint dependency with the corresponding rule-based modeling results in the demand domain, it can be determined that the operational domain lacks sufficient dependency integrity on the corresponding shared modeling elements. Furthermore, when the relevant shared modeling elements in the resource domain do not establish an implementation dependency with the corresponding rule-based modeling results in the service domain, it can be determined that the resource domain lacks sufficient dependency integrity on the corresponding shared modeling elements. Finally, when the relevant shared modeling elements in the operational, service, or resource domains do not establish a global constraint dependency with the corresponding rule-based modeling results in the security domain, it can also be determined that the relevant dependency chain is missing. By obtaining dependency integrity detection results, explicit checks on the implementation of dependency chains during multi-architecture domain modeling are achieved, improving the dependency integrity of the overall modeling process and the traceability of processing results, and providing a reliable foundation for subsequent cross-domain traceability chain construction and change impact analysis.

[0145] Figure 3 This is a schematic flowchart illustrating the method for change impact analysis provided in an embodiment of this application. Based on the above embodiments, as follows... Figure 3 As shown, the method also includes:

[0146] S31, based on preset cross-domain tracing rules, performs tracing and association processing on the rule-based modeling results and cross-domain association results of different architecture domains to generate a cross-domain tracing chain;

[0147] S32, when the unified modeling data structure or rule-based modeling results change, perform change impact analysis based on inter-domain dependency results, cross-domain association results, and cross-domain tracing chains to obtain change impact analysis results and generate a set of modeling items to be adjusted;

[0148] S33 outputs the cross-domain traceability chain, change impact analysis results, and a set of modeling items to be adjusted.

[0149] In this embodiment, cross-domain tracing rules are used to characterize the rules followed when establishing tracing relationships between different architectural domains around shared modeling elements. These rules define the starting point, direction, scope, and termination conditions of the tracing. Cross-domain tracing chains characterize the continuous tracing paths formed by rule-based modeling results across different architectural domains through cross-domain association results. These chains reflect the source, transmission, inheritance, and constraint relationships of a shared modeling element across multiple architectural domains. Cross-domain tracing chains can support the tracing of modeling results from the strategic layer to the operational layer, and from upstream to downstream architectural domains, enabling related content in the multi-architectural-domain architecture modeling process to form a continuous chain of associations across different architectural domains. By establishing cross-domain tracing chains based on rule-based modeling results and cross-domain association results, subsequent change impact analysis can be built on a clear tracing foundation, improving the traceability of subsequent change impact analysis.

[0150] Furthermore, the rule-based modeling results and cross-domain association results across different architectural domains undergo traceability and association processing. Specifically, relevant modeling items in the rule-based modeling results are combined with cross-domain relationships in the cross-domain association results, enabling the domain-specific expressions of the same shared modeling element in different architectural domains to be linked together according to predetermined traceability rules. This traceability and association processing can be manifested as: establishing object-level traceability paths around shared objects, relationship-level traceability paths around relational inheritance records, and attribute-level traceability paths around attribute association records, forming a cross-domain traceability chain covering the strategic domain, requirement domain, personnel domain, operational domain, service domain, resource domain, project domain, and security domain. For example, goals and capability directions in the strategic domain can establish traceability links to requirement objects in the requirement domain through cross-domain association results; relevant objects in the requirement domain can further establish traceability links to corresponding objects in the operational and service domains; relevant objects in the service domain can establish traceability links to supporting objects in the resource domain; and risk objects and security constraint objects in the security domain can form constraint-type traceability links with relevant objects in the operational, service, and resource domains.

[0151] Furthermore, when changes occur in the unified modeling data structure or rule-based modeling results, a change impact analysis is performed based on inter-domain dependency results, cross-domain association results, and cross-domain tracing chains to obtain change impact analysis results and generate a set of modeling items to be adjusted. Here, "change" represents the addition, deletion, replacement, update, or reorganization of object records, relationship records, attribute records, and graph instance records in the unified modeling data structure, and also represents changes in the object representations, relationship representations, attribute representations, or output organization results already formed in the rule-based modeling results. Change impact analysis refers to the process of determining whether the change will propagate along existing dependencies, cross-domain associations, and tracing paths to other architectural domains and their related modeling items after the aforementioned changes occur. When a modeling item in the unified modeling data structure or rule-based modeling results changes, it is not limited to a local update of the modeling item itself, but further analyzed based on inter-domain dependency results, cross-domain association results, and cross-domain tracing chains to determine whether the change will affect shared modeling elements, inheritance relationships, attribute correspondences, and related rule-based modeling results in other architectural domains. This enables the modeling results to be extended from static representation to dynamic and interconnected analysis, improving the responsiveness of the multi-architecture domain architecture modeling process to changes.

[0152] When conducting change impact analysis, inter-domain dependency results provide the direction and type of dependencies between different architectural domains, determining the basic direction in which changes may propagate. Cross-domain association results provide the actual association basis formed between different architectural domains around shared objects, shared relationships, and shared attributes, determining the specific association carriers on which changes may act. Cross-domain tracing chains provide continuous tracing paths from the current change item to other related modeling items, determining the specific modeling scope that the change may reach. In other words, inter-domain dependency results address the question of "along which architectural domain relationships the change may propagate," cross-domain association results address the question of "which shared modeling elements the change may affect," and cross-domain tracing chains address the question of "which specific paths the change may take to which modeling items." These three elements work together to provide a directional basis at the architectural domain level, an association basis at the shared modeling element level, and a tracing basis at the modeling item level. By jointly utilizing inter-domain dependency results, cross-domain association results, and cross-domain tracing chains, the basis for change impact analysis is made more complete, improving the reliability of the results.

[0153] Furthermore, based on the results of the change impact analysis, a set of modeling items to be adjusted is generated. The modeling items in this set can include object records, relationship records, attribute records, and graph instance records affected by the change, as well as object items, relationship items, attribute items, constraint items, output organization items, or other modeling expressions from the affected rule-based modeling results. The purpose of forming this set of modeling items is to further transform the analysis results, which were originally only at the level of impact judgment, into a clearly defined scope of adjustment objects that can be processed subsequently, providing a direct input basis for the re-evaluation, re-constraint, re-modeling, or re-testing of the relevant architectural domains after the change occurs. For example, when a cross-domain tracing chain indicates that a change in a strategic domain target object will affect functional requirement objects in the requirement domain and service function objects in the service domain, these objects and their related relationship items and attribute items can be included in the set of modeling items to be adjusted.

[0154] The system further outputs cross-domain tracing chains, change impact analysis results, and a set of modeling items to be adjusted. These cross-domain tracing relationships, change impact judgment results, and the scope of objects to be adjusted are provided to subsequent processing stages or uses in a callable, viewable, and usable format. By outputting cross-domain tracing chains, change impact analysis results, and a set of modeling items to be adjusted, the system achieves the final provision of cross-domain tracing and change linkage analysis results, enhancing the overall system architecture modeling data processing method's ability to support the continuous evolution of complex engineering systems.

[0155] Based on the above embodiments, the domain-specific modeling rule set corresponding to each architecture domain is obtained, including: constructing corresponding domain-specific modeling rule sets for the set of architecture domains to be processed based on the modeling language meta-model specification information, so that each domain-specific modeling rule set contains the object types, relation types, attribute configuration methods, domain constraints and modeling output requirements allowed by the architecture domain, and organizing the domain-specific modeling rule sets into the rule basis for subsequent object type matching, relation constraint checking, attribute configuration checking and modeling output requirement checking.

[0156] The rule set for sub-domain modeling constructed for the strategic domain includes at least: strategic goal objects and capability direction objects; each capability direction object is associated with at least one strategic goal object; strategic constraints are attached to the corresponding strategic object as attributes. The rule set for sub-domain modeling constructed for the requirement domain includes at least: business requirement objects, functional requirement objects, and performance requirement objects; requirement objects are linked through derivation or refinement relationships; each functional requirement object is associated with at least one strategic goal object or capability direction object; performance requirements are attached to the corresponding functional requirement object as attributes. The rule set for sub-domain modeling constructed for the personnel domain includes at least: organizational unit objects, job objects, and personnel objects; job objects are associated with capability requirement attributes; personnel objects and job objects are connected through responsibility relationships; and the output of personnel domain modeling is specified as the personnel configuration input for operational domain modeling. The domain-specific modeling rule set built for the operation domain includes at least: operation architecture object, operation executor object, and operation activity object; the operation executor object is associated with the operation activity object through responsibility relationship; the operation activity objects are connected through process relationship or dependency relationship; and it is stipulated that the operation domain modeling output can be reused by service domain and project domain.

[0157] The domain-specific modeling rule set for the service domain should at least include: service objects and service function objects; service function objects should be associated with the operational activity objects they support; service interfaces should be expressed as attributes or interface points; and the service domain modeling output should be specified as the service implementation requirements for resource domain modeling. The domain-specific modeling rule set for the resource domain should at least include: system resource objects, technical resource objects, and data resource objects; resource objects should be associated with service objects or operational activity objects through support relationships; resource configuration parameters should be expressed as attributes; and the resource domain modeling output should be specified as supporting the project domain implementation plan. The domain-specific modeling rule set for the project domain should at least include: project objects, milestone objects, and project activity objects; project activity objects should be associated with relevant objects in the operational and resource domains; project time nodes and schedule requirements should be expressed as attributes. The domain-specific modeling rule set for the security domain should at least include: risk objects, security capability objects, and security constraint objects; risk objects should be associated with the operational activity objects or service objects they affect; security constraints should act on relevant objects in the form of attributes or relationships; and the security domain modeling output should be specified as forming global constraints on other architectural domains.

[0158] In one embodiment, for different types of systems to be modeled, the applicable architecture domain, rule items, and processing flow can be selected according to actual modeling needs within the overall processing framework of unified modeling data structure, modeling order results, inter-domain dependency results, domain-specific modeling rule sets, cross-domain association results, and detection results. When the system to be modeled involves all architecture domains in the strategic domain, requirement domain, personnel domain, operation domain, service domain, resource domain, project domain, and security domain, complete domain-specific processing, cross-domain collaborative processing, and detection processing can be executed sequentially according to the predetermined modeling order results. When the system to be modeled only involves some of these architecture domains, the domain-specific modeling rule set, cross-domain collaborative rules, and consistency and / or dependency integrity detection processes corresponding to the target architecture domain can be called only while retaining the unified modeling data structure mapping processing and the corresponding inter-domain dependency processing logic, without needing to perform complete processing on the uninvolved architecture domains. In this way, it can be applied to both large and complex engineering system modeling scenarios covering all architecture domains and local modeling scenarios that only perform modeling processing on some architecture domains, improving the adaptability of the entire system architecture modeling data processing method under different project scales, different modeling scopes, and different implementation needs.

[0159] Furthermore, in method reuse scenarios, existing modeling sequence results, inter-domain dependency relationship results, and domain-specific modeling rule sets can be repeatedly invoked as basic templates for subsequent modeling of similar systems. In method pruning scenarios, relevant rule processing, cross-domain collaborative processing, and detection processing can be selectively retained or omitted based on the target architecture domain scope. Through these settings, the architecture modeling data processing method maintains a unified processing logic while possessing good flexibility and engineering applicability.

[0160] Figure 4 This is a schematic diagram of the architecture modeling data processing device provided in the embodiments of this application, such as... Figure 4 As shown, the architecture modeling data processing device 40 provided in this embodiment includes:

[0161] The information receiving module 401 is used to receive the architecture description information of the system to be modeled, the architecture domain definition information of the unified architecture framework, and the metamodel specification information of the modeling language.

[0162] The information processing module 402 is used to map the architecture description information into a unified modeling data structure based on the modeling language metamodel specification information.

[0163] The result generation module 403 is used to determine multiple architectural domains based on architectural domain definition information, and to determine rules according to preset domain order rules and inter-domain dependency relationships, and generate modeling order results and inter-domain dependency relationship results.

[0164] The result generation module 403 is also used to obtain the domain-specific modeling rule set corresponding to each architecture domain. Based on the modeling order result, the unified modeling data structure is matched and constrained by sequentially calling the domain-specific modeling rule set corresponding to each architecture domain to obtain the rule-based modeling result corresponding to each architecture domain.

[0165] The result generation module 403 is used to perform cross-domain collaborative processing on shared modeling elements in different architecture domains according to preset cross-domain collaboration rules, and generate cross-domain association results.

[0166] Result detection module 404 is used to perform consistency detection and / or dependency integrity detection on shared modeling elements between different architecture domains based on inter-domain dependency results and cross-domain association results, and obtain detection results.

[0167] The results output module 405 is used to output the modeling order results, inter-domain dependency results, rule-based modeling results, cross-domain association results, and / or detection results.

[0168] The architecture modeling data processing device 40 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0169] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0170] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0171] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0172] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0173] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0174] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0175] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0176] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0177] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0178] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0179] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A data processing method for architecture modeling, characterized in that, include: It receives the architecture description information of the system to be modeled, the architecture domain definition information of the unified architecture framework, and the metamodel specification information of the modeling language; Based on the modeling language metamodel specification information, the architecture description information is mapped to a unified modeling data structure; Multiple architectural domains are determined based on the architectural domain definition information, and rules are determined according to preset domain order rules and inter-domain dependencies to generate modeling order results and inter-domain dependency results. Obtain the domain-specific modeling rule set corresponding to each architecture domain. Based on the modeling order result, by sequentially calling the domain-specific modeling rule set corresponding to each architecture domain, perform matching and constraint processing on the unified modeling data structure to obtain the rule-based modeling result corresponding to each architecture domain. Based on preset cross-domain collaboration rules, cross-domain collaborative processing is performed on shared modeling elements in different architecture domains to generate cross-domain association results; Based on the inter-domain dependency results and the cross-domain association results, consistency and / or dependency integrity checks are performed on the shared modeling elements between different architecture domains to obtain the check results. Output modeling order results, inter-domain dependency results, rule-based modeling results, cross-domain association results, and / or detection results.

2. The method according to claim 1, characterized in that, The unified modeling data structure includes object records, relation records, attribute records, and graph instance records; Accordingly, mapping the architecture description information to a unified modeling data structure based on the modeling language metamodel specification information includes: Based on the modeling language metamodel specification information, the modeling elements in the architecture description information are objectified and mapped to generate object records. Based on the modeling language metamodel specification information, the relationships between the modeling elements in the architecture description information are mapped in a relational manner to generate relational records; Based on the modeling language metamodel specification information, attribute mapping is performed on the modeling element attribute information in the architecture description information to generate attribute records associated with object records and / or relationship records; Based on the architecture view definition information of each architecture domain in the architecture domain definition information, the object records, relationship records and attribute records belonging to the same architecture view are organized into graph instance records; Based on the object record, the relationship record, the attribute record, and the graph instance record, a unified modeling data structure corresponding to the architecture description information is formed.

3. The method according to claim 1, characterized in that, The process of determining multiple architectural domains based on the architectural domain definition information, and generating modeling order results and inter-domain dependency results according to preset domain order rules and inter-domain dependency relationships, includes: The set of architecture domains to be processed is determined based on the architecture domain definition information; wherein, the set of architecture domains includes strategic domain, requirement domain, personnel domain, operation domain, service domain, resource domain, project domain and / or security domain; Based on the domain order rules, the modeling execution order of the architecture domains in the architecture domain set is determined, and a modeling order result is generated; Based on the inter-domain dependency determination rules, the dependency direction and dependency type between each of the architecture domains are determined, and the inter-domain dependency result is generated based on the dependency direction and dependency type between each architecture domain.

4. The method according to claim 2, characterized in that, Based on the modeling order, the unified modeling data structure is matched and constrained by sequentially calling the domain-specific modeling rule sets corresponding to each architecture domain, resulting in rule-based modeling results for each architecture domain, including: The architecture domain sequence to be processed is determined based on the modeling order result, and one architecture domain in the architecture domain sequence is selected as the current architecture domain in turn; Obtain the domain-specific modeling rule set corresponding to the current architecture domain, and extract the object records, relationship records, and attribute records corresponding to the current architecture domain from the unified modeling data structure; Extract object type items, relationship type items, and attribute configuration items from the domain modeling rule set, and determine the allowed object type set, allowed relationship type set, and allowed attribute configuration method set, respectively. The object type of the object record is matched with the set of allowed object types, the relationship type of the relationship record is matched with the set of allowed relationship types, and / or the attribute configuration method of the attribute record is matched with the set of allowed attribute configuration methods to generate a matching result; Based on the matching results, filter and obtain the object records, relationship records, and / or attribute records that have passed the matching process; Extract intra-domain constraint items, modeling granularity constraint items, and modeling output requirement items from the domain modeling rule set, and perform constraint processing on the matched object records, relationship records, and / or attribute records based on the intra-domain constraint items, modeling granularity constraint items, and modeling output requirement items to generate constraint processing results; Based on the matching and constraint processing results, a rule-based modeling result for the current architecture domain is generated, and the rule-based modeling result for each architecture domain is obtained by traversing the architecture domain sequence.

5. The method according to claim 2, characterized in that, The cross-domain collaboration rules include object reuse rules and relation inheritance rules; Accordingly, the step of performing cross-domain collaborative processing on shared modeling elements in different architectural domains according to preset cross-domain collaboration rules to generate cross-domain association results includes: Obtain the rule-based modeling results corresponding to each architecture domain, and identify shared modeling elements among the rule-based modeling results based on the cross-domain collaboration rules; wherein, the shared modeling elements include shared objects, shared relationships and / or shared attributes; Based on the shared object, according to the object reuse rules, a shared object mapping relationship is established between the rule-based modeling results of different architecture domains, and the object records mapped to the same shared object are reused as the same object instance to form a cross-domain shared object mapping record; Based on the relationship record corresponding to the shared object, and in accordance with the relationship inheritance rules, a relationship inheritance relationship is established between different architectural domains, and the relationship record in the upstream architectural domain is passed to the downstream architectural domain to form a relationship inheritance record; Based on the attribute records corresponding to the shared object or the shared relationship, a shared attribute correspondence relationship is established according to the shared object mapping relationship and the relationship inheritance relationship, and an attribute association record is generated. The cross-domain shared object mapping record, the relationship inheritance record, and the attribute association record are organized into a cross-domain association result.

6. The method according to claim 2, characterized in that, Based on the inter-domain dependency results and the cross-domain association results, consistency checks are performed on shared modeling elements across different architectural domains, and the check results are obtained, including: The inter-domain dependency results are converted into a dependency table; wherein the dependency table includes the source architecture domain identifier, the target architecture domain identifier, and the dependency type; The set of architecture domain pairs is determined based on the dependency table; wherein, the architecture domain pair consists of a source architecture domain and a target architecture domain. The set of shared modeling elements between the architecture domain pairs is determined based on the cross-domain association results; wherein, the set of shared modeling elements includes shared objects, shared relationships, and shared attributes; Based on the shared object, compare whether the object records mapped to the same shared object are consistent across the architecture domain pairs, and generate an object consistency detection sub-result; Based on the shared relationship, according to the relationship inheritance record in the cross-domain association result, compare whether the relationship inheritance record is consistent between the architecture domain pairs, and compare whether the correspondence between the source object identifier and the target object identifier in the relationship inheritance record is consistent between the architecture domain pairs, and generate a relationship consistency detection sub-result; Based on the shared attributes, compare whether the attribute records are consistent between the architecture domain pairs to generate attribute consistency detection sub-results; Based on the object consistency detection sub-result, the relationship consistency detection sub-result, and the attribute consistency detection sub-result, obtain the consistency detection result.

7. The method according to claim 1, characterized in that, Based on the inter-domain dependency results and the cross-domain association results, dependency integrity checks are performed on shared modeling elements between different architectural domains to obtain the check results, including: The inter-domain dependency results are converted into a dependency table, and the modeling order results are converted into a sequence table; The target architecture domain is determined according to the sequence table, and the set of dependent source architecture domains and dependency types corresponding to the target architecture domain are determined according to the dependency relationship table. Based on the target architecture domain, the shared modeling elements in the target architecture domain are determined from the cross-domain association results, and the rule-based modeling results corresponding to each dependent source architecture domain in the dependent source architecture domain set are determined. The system detects whether the shared modeling elements establish cross-domain associations with the rule-based modeling results of each dependent source architecture domain, corresponding to the dependency type, and obtains the dependency integrity detection results.

8. The method according to any one of claims 1-6, characterized in that, The method further includes: Based on preset cross-domain tracing rules, the rule-based modeling results and cross-domain association results of different architecture domains are traced and associated to generate a cross-domain tracing chain; When the unified modeling data structure or the rule-based modeling result changes, an impact analysis is performed based on the inter-domain dependency results, the cross-domain association results, and the cross-domain tracing chain to obtain the impact analysis results and generate a set of modeling items to be adjusted. Output the cross-domain tracing chain, the change impact analysis results, and the set of modeling items to be adjusted.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 8.

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

Images