Architecture framework configuration and generation method based on kerML meta model

Abstract

The application relates to the technical field of data processing, and provides a kerML meta-model-based architecture framework configuration and generation method. The method comprises the following steps: determining candidate framework elements of an architecture framework by analyzing a kerML meta-model, performing natural language processing on a user demand text, and combining semantic similarity calculation to construct a mapping relationship between elements and intentions; constructing a constraint tensor by integrating instance intention constraints, environment constraints and business constraints, identifying a dominant conflict factor and an influence weight thereof; taking structure parameters and behavior parameters of the architecture framework as decision variables, fusing the dominant conflict factor and the influence weight thereof to construct a fitness function, combining a genetic algorithm iterative optimization to output a configuration scheme set; in an architecture component generation process, verifying interface consistency and constraint compliance of the architecture component, ensuring that the architecture component is qualified and usable, binding the verified architecture component, framework code and a dependency relationship view, and packing to generate an architecture framework instance.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method for configuring and generating an architecture framework based on the KerML metamodel. Background Technology

[0002] With the deepening of digital transformation, the architecture design of complex systems faces the demands of functional modularization, interactive collaboration, and diversified constraints. Standardized configuration and efficient generation of architecture frameworks have become core requirements for technological research and industrial applications. KerML, as a standardized architectural semantic framework released by the Object Management Organization, has been gradually applied to the standardized design of system architectures due to its clear hierarchical structure definition and element semantic specifications, providing a unified semantic foundation for architectural frameworks in different fields and scenarios.

[0003] At the requirement transformation level, natural language processing technology has been widely used for the structured extraction of user requirement texts, transforming ambiguous natural language requirements into reusable information for architecture design through word segmentation and keyword recognition. At the architecture optimization level, intelligent optimization algorithms such as genetic algorithms, with their global search and iterative optimization characteristics, are used to optimize the combination of architecture parameters to obtain configuration schemes with better adaptability. At the constraint handling level, existing technologies have attempted to integrate multi-dimensional constraints such as business constraints and environmental constraints, ensuring the feasibility of the architecture design through constraint verification. At the component-based construction level, the modular decomposition and reuse technology of architecture components has gradually matured, supporting the combination of components according to functional requirements to form customized architecture frameworks.

[0004] Despite the progress made in the design and generation of system architecture frameworks, existing technologies still have the following shortcomings: Although existing technologies introduce the KerML meta-model as a semantic reference, they mostly only utilize its basic structural definition and do not fully rely on the hierarchical characteristics and element association rules of the meta-model to standardize and screen candidate framework elements. This results in a chaotic system of architectural elements and insufficient coordination, making it difficult to ensure the standardization and consistency of the architectural framework. The transformation process from user needs to architectural constraints lacks systematicity and relies heavily on single-dimensional keyword matching without combining it with architectural intent for in-depth processing. This leads to a one-sided semantic matching between candidate framework elements and intent constraint features, which is prone to mismatch between user needs and elements.

[0005] To address the shortcomings of existing technologies, this application aims to solve the technical problem of how to achieve accurate element selection and conflict resolution configuration of the system architecture framework based on the KerML metamodel under complex intent requirements. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this application provides a method for configuring and generating system architecture frameworks based on the KerML metamodel. The method includes: parsing the KerML metamodel to determine candidate framework elements of the system architecture framework, performing natural language processing on user requirement text, identifying architecture intent and generating intent constraint features, determining the semantic similarity between candidate framework elements and intent constraint features, and forming a mapping relationship between elements and intents.

[0007] Based on the mapping relationship, the intent constraint features are analyzed and bound to the frame elements in the candidate frame elements to form instance intent constraints. The instance intent constraints, environmental constraints and business constraints are integrated to construct a constraint tensor. The constraint tensor is decomposed to identify the dominant conflict factors and their influence weights.

[0008] The structural and behavioral parameters of the system architecture framework are used as decision variables. A fitness function is constructed by combining the dominant conflict factor and its influence weight. The genetic algorithm is used to solve the problem to output a set of configuration schemes. Based on the intention priority reflected by the mapping relationship, a configuration scheme is selected from the set of configuration schemes and the framework code is generated.

[0009] Based on the KerML metamodel, the architecture component skeleton of the configuration scheme is generated sequentially, and the dependency relationship view between the architecture components is constructed. During the generation process, the interface consistency and constraint compliance of the architecture components are verified. The verified architecture components, framework code and dependency relationship view are packaged to generate an architecture framework instance.

[0010] As an optional implementation, the candidate framework elements for determining the system architecture framework include:

[0011] The KerML metamodel is hierarchically analyzed. Based on the functional descriptions of different hierarchical architectures and the functional matching degree of the system architecture framework, framework elements with a functional matching degree greater than the matching threshold are selected, and the hierarchical inheritance relationship of the framework elements is preserved.

[0012] Extract the functional attributes, constraint attributes, and adaptation attributes of the frame elements, and combine them with the hierarchical inheritance relationship to explore the inheritance, dependency, and composition relationships between the frame elements. Cluster them to form functionally collaborative element clusters and mark the association strength of the frame elements within the element clusters.

[0013] Dynamic pruning of element clusters is performed using grammatical and adaptation constraints and association strength of the KerML metamodel to determine candidate framework elements for the output architecture framework.

[0014] As an optional implementation, the generated intent constraint features include:

[0015] Natural language processing is used to identify the architectural intent of user requirement text, and the architectural intent is decomposed to obtain the functional implementation, performance indicators, deployment environment and compliance requirements, and to distinguish the constraint rigidity of the architectural intent.

[0016] The decomposed architectural intent is mapped to the functional attributes, constraint attributes, and adaptation attributes of the candidate framework elements. The mapped architectural intent is then quantified according to the architectural domain to generate constraint features.

[0017] The constraint strength of constraint features is quantified based on the constraint rigidity and domain importance of architectural intent, and the intent priority is marked. Potential conflicts between constraint features are identified and conflict labels are added to generate intent constraint features.

[0018] As an optional implementation, the mapping relationship between the forming element and the intent includes:

[0019] Based on the functional attributes, constraint attributes, and adaptation attributes of candidate frame elements, semantic similarity is determined with the functional implementation, performance indicators, deployment environment, and compliance requirements in the intent constraint features. The constraint adaptation degree between candidate frame elements and constraint features is simultaneously verified to obtain a two-dimensional matching value.

[0020] By combining the intent priority of intent constraint features with the association strength of candidate frame elements, the two-dimensional matching values ​​are weighted and fused to generate a comprehensive matching degree between elements and intents.

[0021] Based on the conflict labels of intent constraint features, check whether there are constraints corresponding to the same candidate frame element that are simultaneously bound to conflict labels, so as to determine whether to remove the combination of candidate frame element and intent constraint feature, and retain the effective combination with a comprehensive matching degree greater than a preset threshold.

[0022] The effective combinations are sorted in descending order of comprehensive matching degree to form a mapping relationship between candidate frame elements and intent constraint features, that is, the mapping relationship between elements and intent.

[0023] As an optional implementation, the instance formation intent constraint includes:

[0024] Based on the comprehensive matching degree and intent priority of the mapping relationship, the binding priority of intent constraint features is determined and ranked;

[0025] Based on the hierarchical inheritance relationship of the candidate frame elements, the sorted intent constraint features are bound to the corresponding frame elements one by one, and the compatibility between the intent constraint features and the frame element attributes is verified simultaneously.

[0026] The bound intent constraint features are instantiated and adapted, and the constraint parameter thresholds are refined based on the functional attributes, constraint attributes and adaptation attributes of the candidate frame elements to generate constraint instances.

[0027] Based on the conflict labels of intent constraint features and the verification results of adaptation consistency during the binding process, the binding conflicts of different framework elements between different architecture levels are resolved, forming instance intent constraints.

[0028] As an optional implementation, the identification of dominant conflict factors and their influence weights includes:

[0029] Instance intent constraints, environment constraints, and business constraints are standardized according to the architectural domain, and structurally encoded according to the constraint type and associated framework elements to construct constraint tensors;

[0030] The constraint tensor is decomposed into layers according to the constraint type, and binding conflicts within the same layer and between different layers are extracted, and residual conflicts that have not been resolved are filtered out.

[0031] Based on intent priority and overall matching degree, intent constraint features are divided into core intent constraints and non-core intent constraints, and residual conflicts corresponding to core intent constraints are retained.

[0032] For the remaining residual conflicts, they are graded and superimposed according to intent priority, constraint fit and conflict frequency. The influence weight of different conflict factors is quantified, and the conflict factors with influence weight greater than the weight threshold and related element clusters are selected as the dominant conflict factors.

[0033] As an optional implementation, the construction of the fitness function includes:

[0034] The structural and behavioral parameters of the system architecture framework are used as decision variables. The behavioral parameters are calibrated based on the constraint fit to form an associated response, and the structural parameters are calibrated based on the association strength of the framework elements.

[0035] By combining the dominant conflict factors and their influence weights, the priority of intent and the correlation strength of framework elements, optimization objectives including resolution adaptability, intent satisfaction and architectural synergy are determined.

[0036] Dynamic weights for the optimization objective are assigned based on the calibrated decision variables. The penalty intensity is adjusted according to the dominant conflict factors and their influence weights. The penalty term is calculated based on the number of unresolved residual conflicts and the penalty intensity.

[0037] The optimization objectives are weighted and fused according to dynamic weights, and the calculated penalty terms are superimposed to construct the fitness function.

[0038] As an optional implementation, the generated framework code includes:

[0039] The fitness function is solved using a genetic algorithm, and the combination of decision variables that maximizes the fitness value is obtained through iterative optimization, outputting a set of configuration schemes.

[0040] Extract the intent priority reflected by the mapping relationship, and combine the constraint adaptability and the association strength of the frame elements to filter the configuration scheme set to select the configuration scheme.

[0041] Based on the structural and behavioral parameters corresponding to the configuration scheme, the resolution logic corresponding to the constraint parameter threshold and the dominant conflict factor is embedded into the code of the corresponding frame element according to the hierarchical architecture of the kerML meta-model, and the collaborative calling rules of the component code are determined according to the association strength of the frame elements within the element cluster.

[0042] Based on the embedded constraint parameter thresholds, resolution logic, and collaborative calling rules of component code, framework code matching the hierarchical architecture of the KerML metamodel is generated.

[0043] As an optional implementation, the dependency view between the building architecture components includes:

[0044] The hierarchical architecture based on the KerML metamodel determines the hierarchical affiliation of architectural components, generates the architectural component skeleton of the configuration scheme in sequence, and divides the collaborative clusters of architectural components based on the association strength of framework elements, and marks the dependency relationship of architectural components within the collaborative cluster.

[0045] In the dependency relationships of architectural components, mark the conflict dependency nodes associated with the dominant conflict factor, mark the conflict risk level according to the impact weight, and mark the dependency adaptation risk of architectural components according to the constraint adaptability.

[0046] The architecture components are displayed hierarchically, with the results of the collaborative cluster division and risk labeling overlaid. The hierarchical display results are determined based on intent priority to construct a view of the dependencies between architecture components.

[0047] As an optional implementation, the generated system architecture framework instance includes:

[0048] During the generation of the architectural component skeleton, the architectural components are grouped according to the association strength of the framework elements, the interface consistency of architectural components within and between groups is verified, and the constraint compliance of the architectural components is verified based on the constraint parameter threshold, and the verified architectural components are selected.

[0049] The verified architecture components, framework code, and dependency view are associated and bound with the resolution records of the dominant conflict factors and the verification results of constraint fit.

[0050] The results of the association and binding are verified for integrity, and the packaging directory structure is determined based on the hierarchical architecture, intent priority and comprehensive matching degree of the KerML meta-model, so as to encapsulate and generate an instance of the system architecture framework.

[0051] Compared with existing technologies, the beneficial effects of this application are: by parsing the KerML meta-model to determine the candidate framework elements of the system architecture framework, element confusion is avoided; by performing natural language processing on user requirement text, the architecture intent is accurately split and intent constraint features are generated; and by combining semantic similarity calculation to construct the mapping relationship between elements and intent, the matching accuracy between candidate framework elements and intent constraint features is greatly improved, ensuring a high degree of adaptation between the system architecture framework and user requirements.

[0052] By integrating instance intent constraints, environmental constraints, and business constraints to construct a constraint tensor, comprehensive identification of cross-constraint and cross-level conflicts is achieved. The dominant conflict factors and their influence weights are identified, providing a clear priority basis for conflict resolution. Using the structural and behavioral parameters of the system architecture framework as decision variables, the dominant conflict factors and their influence weights are fully integrated to construct a fitness function. Combined with iterative optimization using a genetic algorithm, the output configuration scheme can resolve conflicts to the greatest extent, improving the feasibility and operational stability of the system architecture framework. The configuration scheme is selected based on intent priority and framework code is generated, significantly reducing manual intervention, improving the efficiency of system architecture configuration and code generation, and reducing design costs.

[0053] During the generation of architecture components, the consistency of interfaces and compliance with constraints of the architecture components are verified to ensure that the architecture components are qualified and usable. The verified architecture components, framework code and dependency relationship views are bound to ensure the integrity and traceability of the instances. The packaged system architecture framework instances can be directly deployed to applications, providing clear support for subsequent operation and maintenance upgrades and iterative optimizations, and improving the smoothness of the entire life cycle management of the architecture. Attached Figure Description

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

[0055] Figure 1 This is a flowchart illustrating the method for configuring and generating a system architecture framework based on the KerML metamodel provided in this application embodiment.

[0056] Figure 2 This is a logical flowchart illustrating the mapping relationship between the forming elements and intents of the system architecture framework configuration and generation method based on the KerML metamodel provided in the embodiments of this application.

[0057] Figure 3This is a logical flowchart illustrating the dependency relationship view between architectural components in the configuration and generation method of the system architecture framework based on the KerML metamodel provided in this application embodiment. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of the embodiments of this application more apparent and understandable, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0059] like Figure 1 The diagram shown is a flowchart of a method for configuring and generating an architecture framework based on the KerML metamodel provided in this application embodiment. The method includes:

[0060] S1. Parse the KerML metamodel to determine candidate framework elements for the system architecture framework, perform natural language processing on the user requirement text, identify the architecture intent and generate intent constraint features, determine the semantic similarity between candidate framework elements and intent constraint features, and form a mapping relationship between elements and intents.

[0061] Furthermore, the candidate framework elements for the system architecture framework include:

[0062] The KerML metamodel is hierarchically analyzed. Based on the functional descriptions of different hierarchical architectures and the functional matching degree of the system architecture framework, framework elements with a functional matching degree greater than the matching threshold are selected, and the hierarchical inheritance relationship of the framework elements is preserved.

[0063] Extract the functional attributes, constraint attributes, and adaptation attributes of the frame elements, and combine them with the hierarchical inheritance relationship to explore the inheritance, dependency, and composition relationships between the frame elements. Cluster them to form functionally collaborative element clusters and mark the association strength of the frame elements within the element clusters.

[0064] Dynamic pruning of element clusters is performed using grammatical and adaptation constraints and association strength of the KerML metamodel to determine candidate framework elements for the output architecture framework.

[0065] The hierarchical architecture of the KerML metamodel inherently possesses clear functional boundaries and logical divisions of labor. Hierarchical parsing ensures that the extracted framework elements structurally adhere to the metamodel's design specifications, avoiding a chaotic element system. For the pre-defined infrastructure layer, business logic layer, and external adaptation layer of the KerML metamodel, the XMI file of the metamodel is parsed layer by layer. This file includes information such as element identifiers, functional description text, interface definitions, and hierarchical affiliation markers. By parsing and extracting data from each layer's elements, an unfiltered dataset of hierarchical elements is formed. Then, the functional requirements of the target architecture framework are analyzed, forming a requirement list including function names, functional implementation goals, application scenarios, and technical implementation requirements. For example, the data storage function, which saves business data and is applied to transaction record retention scenarios, needs to support the stability and security of data reading and writing. Based on the functional descriptions of the metamodel elements and the functional requirements of the requirement list, a qualitative judgment is made from three dimensions: consistency of functional implementation goals, suitability of application scenarios, and compatibility of technical implementation requirements. When the functional matching degree is greater than the matching threshold, the functional matching degree is considered satisfactory.

[0066] For example, the functional description of the data persistence unit element in the metamodel is to provide long-term storage services for structured data, supporting stable read / write and secure backup. Comparing this with the data storage function in the requirements list, the two elements share consistent functional goals, fit the application scenarios, and are compatible with the technical implementation requirements, thus meeting the functional matching standard. After selecting framework elements that meet the functional matching standard, based on the hierarchical attribution markers obtained from the metamodel parsing, a parent-child element association mapping is established through element identifiers, clarifying direct and indirect inheritance relationships. For example, the basic storage element in the infrastructure layer is associated with sub-elements such as the data persistence unit and cache storage unit, forming a hierarchical inheritance relationship to ensure traceable inheritance logic. Thus, through layered parsing and multi-dimensional functional matching determination, it is ensured that the selected framework elements not only conform to the hierarchical structure specifications of the KerML metamodel but also accurately match the functional requirements of the target system architecture framework, preventing mismatched framework elements from entering subsequent processes. The hierarchical inheritance relationship provides a structured basis for subsequent mining of deep relationships between elements, making the association analysis more targeted and improving the efficiency and accuracy of subsequent operations.

[0067] The filtered framework elements only possess basic information on hierarchical structure and functional matching, and the non-inheritance relationships between framework elements have not been explored. Isolated framework elements cannot form functional units with collaborative capabilities. The interface documentation, method definitions, and business logic descriptions of the framework elements are analyzed to clarify their functional boundaries and specific implementation methods. For example, the interface documentation of the order processing element is analyzed to extract its functional attributes as receiving order requests, verifying the integrity of order information, and triggering order flow, and the core business function tags are labeled. From the constraint descriptions and deployment environment requirements inherent in the metamodel, the operational limitations of the framework elements are identified. For example, the constraint attributes of the order processing element are that it must comply with data format specifications, only support requests of specified protocols, and return processing results within a specified response time, forming constraint attributes and associating them with element identifiers. The interface call process between framework elements and other framework elements is simulated to verify the compatibility of interface formats and data types. For example, the interface adaptability of the order processing element and the inventory management element is tested to confirm the compatibility of the order information transmission format and inventory adjustment instructions. Simultaneously, the adaptation requirements of framework elements for hardware resources and software dependencies are analyzed in conjunction with the deployment environment, and adaptation attributes such as cloud environment adaptation and distributed deployment adaptation are labeled.

[0068] Based on hierarchical inheritance relationships, details such as method rewriting and attribute reuse of framework elements are supplemented to clarify the inheritance depth. For example, the order processing element inherits from the business process element, which is direct inheritance. The interface call path and data transmission flow of the framework elements at runtime are tracked to form dependencies and mark the dependency types. For example, the order processing element needs to directly call the inventory management element to lock inventory, which is determined to be a direct strong dependency. The order processing element indirectly calls the account management element to obtain balance information through the payment settlement element, which is determined to be an indirect weak dependency. The functional complementarity and business process relevance of the framework elements are analyzed to determine the composition relationship. For example, the order creation, order payment and order delivery elements are executed continuously in the business process and have complementary functions, which is determined to be a core composition relationship. The order notification and message push elements are auxiliary composition relationships. Through density clustering algorithm, the consistency of the functional labels, the compatibility of constraint attributes and the matching degree of adaptation attributes of the framework elements are used as clustering conditions. Combined with the functional matching degree, framework elements with similar functional semantics, constraint compatibility, consistent adaptation and close relationship are grouped into one category. For example, framework elements that are strongly related to order business, such as order processing, inventory management, payment settlement and order query, are grouped into the order business element cluster.

[0069] Based on the relationship types of framework elements within an element cluster and the frequency of interactions in the business process, the strength of associations is comprehensively determined and labeled. Inheritance has higher priority than core combinations, core combinations have higher priority than strong dependencies, strong dependencies have higher priority than auxiliary combinations, and auxiliary combinations have higher priority than weak dependencies. For example, order processing and inventory management are core combinations with frequent interactions and are labeled as strong associations, while order processing and account management are indirect weak dependencies with less interaction and are labeled as weak associations. Multi-dimensional attribute extraction improves the core information of framework elements, providing a clear basis for subsequent constraint verification. Full-dimensional relationship mining clarifies the complex relationships between framework elements, avoiding logical breakpoints in collaborative design. Element clusters formed by targeted clustering focus on specific business functions, and the labeling of association strength provides an objective qualitative judgment standard for subsequent pruning, ensuring that the pruning process revolves around functional synergy.

[0070] The resulting element clusters may violate the syntax specifications or adaptation requirements of the KerML metamodel. Retaining them could lead to compatibility risks in the architecture framework. Furthermore, the association strength between framework elements within an element cluster is low, and functional synergy is insufficient. Additionally, some core functional element clusters exhibit minor constraint violations. Based on the publicly available syntax rules of the KerML specification, the interface format, data type definition, naming rules, and semantic description of all framework elements within an element cluster are validated. For example, it verifies whether the interface parameter naming of the order processing element conforms to the general requirements of the KerML specification and whether the data type is consistent with the standard type defined in the metamodel. A syntax violation report is generated, clearly identifying the violation type and violating element identifier. Adaptation constraint verification is conducted from three dimensions: deployment environment adaptation, resource consumption adaptation, and cross-cluster interaction adaptation. Scenario simulation testing methods are used. For example, the running process of the element cluster in the target deployment environment is simulated to verify whether its consumption of environmental resources meets the adaptation requirements. The interface calls between the element cluster and other element clusters are tested to ensure smoothness, generating an adaptation violation report.

[0071] During dynamic pruning, element clusters with severe syntax or adaptation violations, low correlation strength, and substandard functional matching are directly removed. For example, the log element cluster is directly removed because its core interface format violates the KerML specification, the cluster mainly consists of weakly correlated elements, and the functionality is only optional. For core element clusters with minor syntax or adaptation violations but high correlation strength and whose functionality belongs to the mandatory category, the element attributes are adjusted or the correlation relationships are optimized to meet the constraints. For example, the user authentication element cluster is retained because some interface parameter types are slightly different from the metamodel specification, but the cluster mainly consists of strongly correlated elements, the functionality is core and essential, and the matching degree with the architecture functionality is extremely high. The interface parameter types are modified to be metamodel compatible types.

[0072] All pruned element clusters are integrated, and frame elements within these clusters are extracted. Duplicate elements are removed based on element identifiers. Attribute tags, hierarchical inheritance relationships, association strength annotations, and functional matching degrees of the associated frame elements are used to form candidate frame elements. These candidate frame elements are then sorted according to the hierarchical architecture of the KerML metamodel. Multi-dimensional constraint verification ensures the compliance of the candidate frame elements, avoiding compatibility issues in the system architecture framework. The flexibility of dynamic pruning eliminates low-quality and non-compliant element clusters while retaining key functions through core cluster optimization, balancing regulatory requirements and practical application needs. The structured candidate frame elements provide accurate and clear element objects for subsequent steps, making intent constraint feature binding and element mapping relationship construction more targeted, thus laying a solid foundation for the configuration and generation of the entire system architecture framework.

[0073] Furthermore, the features constraining the generation intent include:

[0074] Natural language processing is used to identify the architectural intent of user requirement text, and the architectural intent is decomposed to obtain the functional implementation, performance indicators, deployment environment and compliance requirements, and to distinguish the constraint rigidity of the architectural intent.

[0075] The decomposed architectural intent is mapped to the functional attributes, constraint attributes, and adaptation attributes of the candidate framework elements. The mapped architectural intent is then quantified according to the architectural domain to generate constraint features.

[0076] The constraint strength of constraint features is quantified based on the constraint rigidity and domain importance of architectural intent, and the intent priority is marked. Potential conflicts between constraint features are identified and conflict labels are added to generate intent constraint features.

[0077] User requirement texts are mostly presented in natural language, characterized by scattered expressions, semantic ambiguity, and a lack of structured information. Natural language processing (NLP) techniques are used to preprocess these texts, employing word segmentation, stop word removal, and keyword extraction from the architecture domain to filter out expressions directly related to the architecture design. For example, information such as the system's need to stably support real-time synchronization of business data, control resource consumption during runtime, deployment in an enterprise intranet environment, and compliance with data privacy regulations is extracted. Then, using publicly available terminology in the architecture domain, the extracted information is matched with four architecture design dimensions: functionality, performance, environment, and compliance, identifying the corresponding architectural intent. For instance, real-time business data synchronization matches functional implementation, resource consumption control matches performance metrics, enterprise intranet deployment matches the deployment environment, and data privacy protection matches compliance requirements.

[0078] The identified architectural intents are broken down according to the above dimensions to ensure that each intent belongs to a dimension without omission. Based on the tone of expression, industry practices, and mandatory compliance requirements in the user requirement text, constraints are distinguished as rigid. For example, compliance with data privacy protection regulations is considered a rigid constraint due to legal compliance requirements, while controlling resource consumption is considered a flexible constraint because there are no mandatory standards and it can be flexibly adjusted according to the deployment scenario. In this way, vague and scattered natural language requirements are transformed into clear and structured architectural intents, avoiding constraint distortion caused by misunderstanding of requirements in the subsequent mapping process. The distinction of constraint rigidity clarifies the mandatory attributes of different architectural intents, providing an objective basis for subsequent constraint strength quantification and priority labeling.

[0079] The decomposed architectural intent is at the requirement description level and has not been associated with candidate framework elements, so it cannot be directly transformed into a constraint to be followed. Based on the attribute types of candidate framework elements, a directional mapping rule for architectural intent is established. Functional implementation intent corresponds to the functional attributes of candidate framework elements, performance indicator intent corresponds to the constraint attributes, and deployment environment and compliance requirement intent corresponds to the adaptation attributes. For example, the functional implementation intent of real-time business data synchronization is mapped to the data transmission and synchronization functional attributes in candidate framework elements, the performance indicator intent of controlling resource consumption is mapped to the resource consumption limit constraint attributes in candidate framework elements, and the deployment environment intent of enterprise intranet deployment is mapped to the network environment adaptation attributes in candidate framework elements.

[0080] Following general standards and design conventions in the architecture field, the mapped architectural intent is quantified, transforming the intent described in natural language into constraint statements. For example, real-time synchronization of business data is quantified as supporting incremental and full synchronization modes for specified business data; resource consumption control is quantified as ensuring that the computing resources used during operation do not exceed the preset range of the deployment environment; and enterprise intranet deployment is quantified as supporting TCP / IP protocol communication within the enterprise intranet without relying on the public network environment, thus forming constraint characteristics. In this way, a precise association between architectural intent and candidate framework element attributes is established through targeted mapping, avoiding the disconnect between constraint characteristics and element attributes. The quantified constraint characteristics have structured and standardized features, which can be directly used for subsequent constraint strength determination and conflict identification, improving the smoothness of process transitions.

[0081] The initially generated constraint features lack a clear distinction in importance. If priorities are not assigned, core requirements may be squeezed out by secondary requirements during subsequent configuration. Furthermore, different constraint features may contain logical contradictions; if these are not identified and labeled beforehand, logical conflicts may arise in the subsequent architecture design, affecting its feasibility. Based on the distinction between the rigidity of architectural intent constraints and their importance within the architectural domain, the constraint strength of the constraint features is comprehensively quantified. Rigid constraints are stronger than flexible constraints, and constraints directly related to core architectural functions are stronger than those related to auxiliary functions. For example, constraints related to data privacy protection compliance are stronger than performance indicators for controlling resource consumption. Based on the strength of the constraints, intent priorities are assigned, forming a clear priority sequence to ensure that core constraint features are prioritized in subsequent configurations.

[0082] By comparing the expression logic and applicable scope of different constraint features, potential conflicts are identified. For example, the intention to support massive data storage may conflict with the intention to control performance indicators for resource consumption, and the intention to achieve cross-regional data sharing may conflict with the intention to meet compliance requirements for local data storage. For identified potential conflicts, corresponding conflict labels are used to clarify the constraint features and conflict types involved. Constraint features, constraint strength, intention priority, and conflict labels are integrated to generate intention constraint features. This clarifies the primary and secondary relationships of constraint features, providing a basis for subsequent configuration scheme selection. The identification and labeling of potential conflicts avoids logical contradictions in subsequent architecture design, reduces rework costs, and provides a comprehensive and accurate constraint basis for architecture configuration, ensuring that the architecture design meets user needs and is logically feasible. This provides a basis for eliminating conflict combinations, improving mapping accuracy and architecture feasibility.

[0083] Specifically, such as Figure 2 As shown, the mapping relationship between elements and intentions includes:

[0084] Based on the functional attributes, constraint attributes, and adaptation attributes of candidate frame elements, semantic similarity is determined with the functional implementation, performance indicators, deployment environment, and compliance requirements in the intent constraint features. The constraint adaptation degree between candidate frame elements and constraint features is simultaneously verified to obtain a two-dimensional matching value.

[0085] By combining the intent priority of intent constraint features with the association strength of candidate frame elements, the two-dimensional matching values ​​are weighted and fused to generate a comprehensive matching degree between elements and intents.

[0086] Based on the conflict labels of intent constraint features, check whether there are constraints corresponding to the same candidate frame element that are simultaneously bound to conflict labels, so as to determine whether to remove the combination of candidate frame element and intent constraint feature, and retain the effective combination with a comprehensive matching degree greater than a preset threshold.

[0087] The effective combinations are sorted in descending order of comprehensive matching degree to form a mapping relationship between candidate frame elements and intent constraint features, that is, the mapping relationship between elements and intent.

[0088] The matching of candidate framework elements with intent constraint features must simultaneously satisfy semantic fit and practical application adaptability. Single-dimensional judgment is prone to bias; semantic matching alone may result in similar descriptions but element attributes failing to meet constraint requirements, while adaptability verification alone may ignore the semantic demands of user needs. A directional correspondence rule between framework element attributes and architectural intent should be established. The functional attributes of candidate framework elements should only match the functional implementation in the intent constraint features, constraint attributes should only match performance indicators, and adaptability attributes should match the deployment environment and compliance requirements, ensuring the matching direction remains consistent. A multi-dimensional comparison of the attributes and constraint feature descriptions of framework elements should be performed, extracting core business terms, functional action terms, and constraint condition terms from both sides. Semantic similarity should be determined through a three-layer analysis of terminology overlap, semantic synonymy, and functional logic consistency. For example, if the functional attribute description of the high-concurrency data processing component in the candidate framework element is "supporting the parallel reception, verification, and distribution of massive business requests," when compared with the functional implementation description of high-concurrency real-time processing of business data in the intent constraint features, the core terms "high concurrency" and "data processing" overlap, the semantic association between "parallel reception" and "real-time processing" is consistent, and the functional logic is consistent, thus the semantic similarity is deemed satisfactory.

[0089] The framework element attributes are verified one by one according to the targeted matching rules to ensure they meet the specific requirements of the constraint features. Functional attribute verification focuses on whether the core functions required by the constraint features are present, such as whether the functional attributes of the candidate framework elements cover real-time processing capabilities. Constraint attribute verification focuses on whether the performance limitations of the constraint features are compatible, such as whether the single-node concurrent capacity of the candidate framework element's constraint attributes meets the performance indicators corresponding to high concurrency. Adaptability attribute verification focuses on whether the technical specifications of the deployment environment and compliance requirements are met, such as whether the network protocol support type of the candidate framework element's adaptability attributes matches the environment requirements of a private cloud deployment and whether the data encryption standards meet compliance requirements. Through these targeted verifications, qualitative matching results for semantic similarity and constraint adaptability are obtained, including high fit, medium fit, and low fit, i.e., two-dimensional matching values. The targeted matching rules ensure consistent matching between the attributes and constraint features of the framework elements, avoiding dimensional confusion, and allowing the two-dimensional matching values ​​to comprehensively reflect semantic similarity and actual adaptability, effectively avoiding the one-sidedness of single-dimensional judgment and improving the accuracy of the matching results.

[0090] Two-dimensional matching values ​​can only reflect the adaptation of a single dimension, failing to reflect the importance of requirements and the synergistic value of elements. This can lead to the combination of core requirements being squeezed out by combinations of secondary requirements. The intention priority of the intention constraint features is used as the primary weighting basis, and the association strength of candidate framework elements is used as the secondary weighting basis. The weight of intention priority is set based on the core requirements of the architecture design. For example, the high priority intentions corresponding to rigid constraints have a higher weight than the low priority intentions corresponding to flexible constraints, and the intentions directly related to the core functions of the architecture have a higher weight than the intentions of auxiliary functions. The weight of the association strength of framework elements is determined based on the association strength marked within the element cluster. Strongly associated elements have a higher weight than moderately and weakly associated elements, ensuring that the weight allocation is deeply bound to the association strength and intention priority of the framework elements within the element cluster.

[0091] In the weighted fusion process, the two-dimensional matching values ​​are first initially adjusted according to the weight of intent priority, and then optimized a second time according to the weight of association strength. For example, if a combination has high semantic similarity and high fit in its two-dimensional matching values, corresponding to high priority intent constraint features and strong association of related elements, then its comprehensive evaluation is improved by superimposing the double weights. If another combination has the same two-dimensional matching values, but low priority intent constraint features and weak association of related elements, then its comprehensive evaluation is relatively low, and the comprehensive matching degree between elements and intent is finally generated. This ensures that the generation of comprehensive matching degree has a clear basis, highlights the value of core combinations through double weights, avoids the weakening of core needs caused by treating all combinations indiscriminately, and makes comprehensive matching degree the core objective indicator for judging the value of combinations.

[0092] The intent constraint features contain associated combinations with conflicting labels. If the same candidate framework element is simultaneously bound to conflicting constraint features, it will lead to logical contradictions in the architecture design. Furthermore, the overall matching of some combinations is too low to meet the core requirements of the architecture design; retaining them would increase the complexity and redundancy of subsequent configurations. Based on the labeled conflicting labels, the pairwise relationships of conflicting constraint features are identified. For example, conflicting label A and conflicting label B correspond to two sets of contradictory constraint features, ensuring that conflict determination has a clear basis. When eliminating conflicting combinations, all constraint features bound to each candidate framework element are iterated one by one to verify whether there are constraint features that simultaneously contain paired associations with conflicting labels. For example, if a candidate framework element is simultaneously bound to the constraint features of cross-regional data sharing with conflicting label A and data local storage with conflicting label B, then all combinations of this framework element with these two sets of constraint features are directly eliminated to avoid logical conflicts.

[0093] The preset threshold is set based on the core requirements of the architecture design and industry-standard compatibility. For example, only valid combinations with a comprehensive matching degree greater than the preset threshold are retained to ensure that the screening criteria are objective and feasible. Finally, conflicting combinations are eliminated and valid combinations are retained to form conflict-free and highly compatible valid combinations. Conflict tag verification ensures the accuracy of conflict elimination and avoids missing potential logical contradictions. The preset threshold for screening is set based on core requirements and industry standards to ensure the quality of valid combinations, eliminate low-value redundant combinations, reduce the complexity of subsequent processes, and ensure that the screening of valid combinations meets both the conflict-free requirement and the high compatibility standard.

[0094] The lack of a clear priority order for effective combinations means that if they proceed to subsequent processing without order, resources will be squeezed out by secondary combinations, especially those with high-priority intents and high overall matching scores, hindering the implementation of core requirements. Effective combinations are sorted in descending order of overall matching score. If combinations with the same overall matching score are found during the sorting process, they are then sorted a second time by intent priority, with effective combinations corresponding to higher-priority intents appearing first. If intent priorities are also the same, they are then sorted a third time by the association strength of candidate frame elements, with effective combinations corresponding to strongly associated elements appearing first. This ensures that the sorting logic is progressive and based on clear criteria. Based on the sorting results, a mapping relationship is formed between candidate frame elements and intent constraint features, including the identifier of the candidate frame element and its corresponding intent constraint. The mapping relationship is traceable in every detail through features, two-dimensional matching values, comprehensive matching degree, intent priority, and the association strength between frame elements. The structure of the mapping relationship corresponds one-to-one with the attributes of candidate frame elements and the core information of intent constraint features, without adding any unfounded fields. The final mapping relationship is the mapping relationship between elements and intents, which can be directly used for subsequent constraint feature binding operations. Multi-level sorting logic ensures the priority of core effective combinations, avoids the weakening of core requirements, improves the operational efficiency of subsequent steps, avoids the disorder and subjectivity of effective combination selection, and deeply binds the mapping relationship with the preceding steps to ensure the coherence and consistency of technical logic and ensure that the constraint binding process is accurate and efficient.

[0095] S2. Based on the mapping relationship, the intent constraint features are analyzed and bound to the frame elements in the candidate frame elements to form instance intent constraints. The instance intent constraints, environmental constraints and business constraints are integrated to construct a constraint tensor. The constraint tensor is decomposed to identify the dominant conflict factors and their influence weights.

[0096] Furthermore, the formation of instance intent constraints includes:

[0097] Based on the comprehensive matching degree and intent priority of the mapping relationship, the binding priority of intent constraint features is determined and ranked;

[0098] Based on the hierarchical inheritance relationship of the candidate frame elements, the sorted intent constraint features are bound to the corresponding frame elements one by one, and the compatibility between the intent constraint features and the frame element attributes is verified simultaneously.

[0099] The bound intent constraint features are instantiated and adapted, and the constraint parameter thresholds are refined based on the functional attributes, constraint attributes and adaptation attributes of the candidate frame elements to generate constraint instances.

[0100] Based on the conflict labels of intent constraint features and the verification results of adaptation consistency during the binding process, the binding conflicts of different framework elements between different architecture levels are resolved, forming instance intent constraints.

[0101] The mapping relationship contains multiple effective combinations of framework elements and intent constraint features. Different combinations have different levels of importance. Intent constraint features with high intent priority are directly related to core requirements, and effective combinations with high comprehensive matching degree are more suitable for the attributes of framework elements. If the binding is out of order, it will lead to the delayed binding of core constraints or the occupation of element resources by secondary constraints, or even mismatch between intent constraint features and framework elements. The dual sorting logic of intent priority as the main factor and comprehensive matching degree as the secondary factor is used to extract the intent priority and comprehensive matching degree of each effective combination in the mapping relationship. The intent priority is the primary sorting criterion, and effective combinations of high-priority intent constraint features are ranked first. For example, effective combinations corresponding to rigid high-priority intent constraints such as data security compliance are given priority over effective combinations of flexible low-priority intent constraint features such as resource consumption optimization.

[0102] Under the same intent priority, a secondary sorting is performed based on the overall matching degree. Valid combinations with high overall matching degrees are ranked first. For example, among user identity authentication combinations with high intent priority, those with high overall matching degrees are ranked before those with medium matching degrees. If valid combinations with the same intent priority and overall matching degree are found, the association strength of candidate framework elements is used to supplement the sorting. Valid combinations corresponding to strongly associated elements are prioritized, ensuring that the sorting logic is progressive and free from subjective judgment. This ultimately forms a clear binding priority for intent constraint features, clarifying the order in which each set of intent constraint features is bound. The dual sorting logic accurately highlights the priority of core constraints and highly compatible combinations, preventing core needs from being squeezed out by secondary constraints, ensuring the objectivity and rationality of binding priority determination, providing clear operational guidance for subsequent layered binding, and avoiding disorder and chaos in the binding process.

[0103] Candidate frame elements possess a hierarchical inheritance relationship granted by the KerML metamodel. Elements at different levels have different functional positioning and attribute characteristics. Unordered binding across levels can lead to misalignment between intent constraint features and element functions. Furthermore, incompatibility between intent constraint features and frame element attributes may occur during binding; for example, binding high-concurrency intent constraint features to frame elements that do not support parallel processing can lead to accumulated conflicts if not validated in real-time. The hierarchical inheritance relationship is retrieved to clarify the hierarchical affiliation and parent-child element relationships of candidate frame elements. For example, basic security elements in the infrastructure layer are associated with user authentication elements and data encryption elements in the business logic layer. Binding is prioritized. The binding process begins with high-priority intent constraints and proceeds layer by layer. Framework elements in the infrastructure layer are bound to core intent constraints first, and then the binding extends downwards according to the hierarchical inheritance relationship, binding secondary constraint constraints to child elements in the business logic layer and external adaptation layer. For example, user authentication elements are bound to account password verification constraints. The binding process strictly follows the rule that parent element constraint characteristics can be inherited by child elements and that child element constraint characteristics do not violate the core constraints of the parent element. For example, for data transmission encryption constraints in the infrastructure layer, file transmission elements in the child elements can inherit this intent constraint characteristic and supplement and refine it, but must not bind intent constraint characteristics that violate the core constraints of the parent element, such as plaintext transmission.

[0104] During synchronous adaptation consistency verification, the compatibility of intent constraint features is verified one by one by comparing the functional attributes, constraint attributes, and adaptation attributes of candidate framework elements. Specifically, functional attributes verify whether the intent constraint feature is within the functional coverage of the framework element (e.g., whether high-concurrency processing constraints match the parallel processing functional attribute in the framework element); constraint attributes verify whether the intent constraint feature exceeds the operational limits of the framework element (e.g., whether 7x24-hour operation constraints are compatible with the continuous operation stability constraint attribute in the framework element); and adaptation attributes verify whether the intent constraint feature meets the deployment and compliance adaptation requirements of the framework element (e.g., whether private cloud deployment constraints are consistent with the cloud environment adaptation attributes in the framework element). If the verification fails, the binding of that intent constraint feature is paused, and the adaptation deviation type is recorded (e.g., functional non-coverage or constraint incompatibility) for subsequent processing. Layered binding strictly follows the hierarchical inheritance relationship of the metamodel to ensure accurate matching between the intent constraint feature and the functional positioning of the framework element, avoiding cross-level mismatches. Synchronous verification enables timely detection of adaptation deviations, avoids conflict accumulation, ensures consistency of constraints between levels, and avoids parent-child element constraint contradictions.

[0105] The intent constraint features after layered binding are still at the qualitative description level, lacking specific and implementable parameter thresholds and implementation details, and cannot be directly used for architecture configuration. Based on the intent constraint features after layered binding, and combined with the functional attributes, constraint attributes, and adaptation attributes of candidate framework elements, instantiation adaptation is carried out. For intent constraint features of functional implementation, the implementation scope and operation boundaries of constraints are clarified based on the functional attributes of framework elements. For example, user identity authentication constraints are refined into account password verification and third-party authorization verification covering personal accounts and enterprise accounts, combined with the functional attributes of supporting multi-account type verification in framework elements. For intent constraint features of performance indicators, the parameter boundaries and operating standards are refined based on the constraint attributes of framework elements. For example, high concurrency processing constraints are refined into the supported concurrent request types, request processing response logic, and peak load operating conditions, combined with the constraint attributes of parallel processing capabilities in framework elements.

[0106] For intent constraint characteristics related to deployment environment and compliance requirements, the adaptation scenarios and technical standards are clearly defined based on the adaptation attributes of framework elements. For example, for private cloud deployment constraints, the adaptation attributes of network protocol support and hardware resource adaptation in framework elements are combined to refine the supported private cloud platform types, adapted network communication protocols, and required hardware resource configuration standards. For all types of intent constraint characteristics, constraint effectiveness conditions and exception handling rules are added. For example, when a constraint is not met, an alarm is triggered and downgraded, ensuring the integrity and operability of constraint instances. Finally, the refined constraint parameter thresholds, effectiveness conditions, and exception handling rules are integrated to generate structured constraint instances. Each constraint instance is associated with a corresponding candidate framework element identifier and binding priority. Thus, by refining constraint parameter thresholds through framework element attributes, abstract constraints are transformed into concrete instances that can be implemented and verified, avoiding constraints becoming mere formalities. The addition of effectiveness conditions and exception rules improves the practicality and fault tolerance of constraint instances. The deep binding of constraint instances with framework element attributes ensures their adaptability and executability, providing accurate constraint basis for subsequent architecture configuration.

[0107] Even after layered binding and instantiation adaptation, constraint conflicts may still exist between elements at different levels or between elements at the same level. If these conflicts are not resolved, they can lead to chaotic constraint tensor construction and logical vulnerabilities in the architecture configuration. This requires integrating conflict tags from intent constraint features with deviation information recorded during the binding process's consistency verification, such as incompatibility between constraints and element functions. Conflicts should be investigated on a case-by-case basis for each constraint instance to identify the conflict type, the involved constraint instances, and the associated framework elements. Conflict types include cross-level and same-level conflicts. Conflict resolution follows three principles: core priority, adaptation priority, and level priority. For cross-level conflicts, the core constraint instances of the parent element are retained first. For example, the data security encryption constraint of the parent element takes precedence over the transmission efficiency optimization constraint of the child element. Conflicting constraint instances of child elements have their parameters adjusted to adapt to the parent element's constraints. For example, plaintext transmission is changed to encrypted transmission, or they are directly eliminated. For conflicts within the same level, they are sorted by binding priority. High-priority constraint instances are retained, while low-priority conflict instances have their constraint parameter thresholds optimized to avoid contradictions. For example, the effective time of high-concurrency constraints is adjusted to a non-overlapping period, or conflict instances with low adaptability are eliminated. For example, combinations with low overall matching degree are directly eliminated.

[0108] If a conflict involves core intent constraints and cannot be resolved by adjusting constraint parameter thresholds, the process backtracks to the mapping relationship to re-select suitable combinations of framework elements and intent constraint features, ensuring no core requirements are overlooked. After resolution, the logical consistency and adaptability of all constraint instances are verified again. Once no conflicts are confirmed, all constraint instances are integrated according to the hierarchical architecture of the KerML metamodel to form instance intent constraints. The framework element associations, constraint parameter thresholds, effective rules, and resolution records for each constraint instance are clearly recorded. This ensures the comprehensiveness of conflict investigation and avoids overlooking potential contradictions. The three resolution rules clarify the priority of conflict handling, ensuring that core requirements and highly adaptable constraint instances are retained first. The backtracking mechanism provides remedial solutions for irreconcilable core conflicts, preventing damage to core requirements. The final instance intent constraints are logically conflict-free and highly adaptable, laying a solid foundation for subsequent constraint tensor construction and providing a clear constraint basis for identifying dominant conflict factors.

[0109] Specifically, identifying the dominant conflict factors and their influence weights includes:

[0110] Instance intent constraints, environment constraints, and business constraints are standardized according to the architectural domain, and structurally encoded according to the constraint type and associated framework elements to construct constraint tensors;

[0111] The constraint tensor is decomposed into layers according to the constraint type, and binding conflicts within the same layer and between different layers are extracted, and residual conflicts that have not been resolved are filtered out.

[0112] Based on intent priority and overall matching degree, intent constraint features are divided into core intent constraints and non-core intent constraints, and residual conflicts corresponding to core intent constraints are retained.

[0113] For the remaining residual conflicts, they are graded and superimposed according to intent priority, constraint fit and conflict frequency. The influence weight of different conflict factors is quantified, and the conflict factors with influence weight greater than the weight threshold and related element clusters are selected as the dominant conflict factors.

[0114] Instance intent constraints, environmental constraints, and business constraints originate from different dimensions. Direct integration can lead to confusion in conflict identification. Furthermore, the lack of a structured mapping between constraints and framework elements makes it impossible to accurately pinpoint the source of conflicts. To address this, instance intent constraints, environmental constraints, and business constraints are standardized according to architectural domains. The expression structure of the three types of constraints is unified, adopting a structured format of constraint type, constraint content, applicable scenario, and associated framework element identifier. For example, the memory limit for private cloud deployment in the environmental constraint is standardized as "Environmental Constraint - Memory Resource Adaptation - Production Deployment Scenario - Element Identifier"; the requirement for real-time inventory synchronization after order payment in the business constraint is standardized as "Business Constraint - Real-time Data Synchronization - Order Transaction Process - Element Identifier".

[0115] The structure is encoded according to constraint type and associated framework elements. Constraint type is encoded as Instance Intent Constraint = I, Environment Constraint = E, Business Constraint = B. Framework element hierarchy is encoded as Infrastructure Layer = C, Business Logic Layer = L, External Adaptation Layer = A. Constraint attribute is encoded as Function Implementation = F, Performance Indicator = P, Compliance Requirement = G. For example, the performance indicator of the Instance Intent Constraint in the Infrastructure Layer is encoded as "ICP". Based on the encoding results, constraint tensors are constructed. The dimensions of the constraint tensor are constraint type dimension, framework element hierarchy dimension, and conflict association dimension. Each constraint tensor corresponds to a set of constraints and associated framework elements, realizing the integration and accurate positioning of the three types of constraints, ensuring that all constraints are traceable and analyzable in a unified carrier. Standardization processing eliminates the differences in the expression of constraints in different dimensions, avoiding omissions or misjudgments caused by format confusion during conflict identification. The structural encoding establishes a strong association between constraints and framework elements, providing a positioning basis for subsequent layered decomposition. The constraint tensor makes the integration logic of multi-dimensional constraints clear and reusable, improving the systematic nature of conflict identification.

[0116] Constraint tensors integrate multiple types and levels of constraints. If conflicts are analyzed as a whole, the intertwined constraint dimensions can lead to unclear conflict localization. Furthermore, since previous steps have already resolved binding conflicts, it is necessary to selectively identify unresolved residual conflicts to avoid repeatedly analyzing resolved contradictions. Constraint tensors are decomposed into three independent analysis layers based on constraint type: instance intent constraint layer, environment constraint layer, and business constraint layer. First, binding conflicts within the same layer are analyzed, that is, the logical consistency of constraints within each layer is verified one by one. For example, in instance intent constraints, are there logical contradictions between high concurrency processing and low resource consumption constraints of the same framework element? In business constraints, are there conflicts between the timing requirements of real-time data synchronization and batch data processing?

[0117] Then, the binding conflicts between different layers are analyzed, that is, the compatibility of cross-layer constraints is verified. For example, whether the high-concurrency processing of instance intent constraints is compatible with the hardware resource limitations of environment constraints, and whether the local storage of data for business constraints is contradictory to the cross-regional deployment of environment constraints. During the decomposition process, the conflict resolution records are retrieved simultaneously. By comparing each identified binding conflict, residual conflicts that have not been resolved and have not been marked as resolved are filtered out. The constraint instances involved in the binding conflicts, the associated framework elements, and the conflict type are clearly recorded. Layered decomposition allows the conflict to be located precisely to the specific constraint type, avoiding the analysis chaos caused by the interweaving of multi-dimensional constraints. The residual conflicts are filtered by comparing the resolution records, which improves the efficiency of conflict analysis.

[0118] The residual conflicts involve intent constraints that fall into two categories: core and non-core. Conflicts corresponding to non-core intent constraints have a smaller impact on the overall feasibility of the architecture. Including all of them in subsequent analysis would dilute resources. Core intent constraints are directly related to the core requirements of the architecture. If their corresponding residual conflicts are not addressed first, core functions will not be implemented. Based on intent priority and comprehensive matching degree, the criteria for determining core intent constraints are clarified. Intent constraints with high intent priority and high comprehensive matching degree are defined as core intent constraints, such as the intent constraints corresponding to data security compliance and high concurrency processing of core business. The rest are non-core intent constraints, such as the intent constraints corresponding to resource optimization of log statistics and response speed of auxiliary functions. By comparing the selected residual conflicts, the intent constraints corresponding to each residual conflict are verified one by one to see if they belong to core intent constraints. Only residual conflicts associated with core intent constraints are retained, and residual conflicts corresponding to non-core intent constraints are directly excluded, ensuring that subsequent analysis focuses only on core contradictions. By defining core intent constraints with clear standards, confusion between core and non-core conflicts is avoided. Core conflicts are retained while secondary conflicts are excluded, allowing subsequent weight quantification and conflict handling to focus on key requirements, improving process efficiency and targeting.

[0119] Multiple conflict factors remain in the core residual conflicts, and the impact of different conflict factors on the architecture varies. If the impact weights are not distinguished, subsequent conflict resolution will lack priority, and residual conflicts with a wide range and deep impact cannot be dealt with first. The impact weight of conflict factors is quantified by grading and superimposing them according to intent priority, constraint fit, and conflict frequency. First, intent priority is the basic level, that is, the high priority of core intent constraints is given the highest basic weight, ensuring that conflicts related to core requirements are considered first. Second, constraint fit is superimposed. Conflicts with high constraint fit with related framework elements, that is, the constraint features involved in the residual conflict have a high degree of fit with the attributes of the framework elements, and the framework elements have a strong dependence on the constraint features, are superimposed with a higher impact weight. For example, the residual conflict between the high concurrency constraints of core business elements and hardware resource limitations has a higher impact weight than residual conflicts with low constraint fit because the constraint fit of the framework elements is high.

[0120] Finally, the frequency of conflicts is superimposed. Residual conflicts that repeatedly occur in different element clusters and different constraint combinations, such as conflicts between high concurrency and hardware resources in multiple core elements, are superimposed with additional impact weights to highlight the wide range of their impact. After quantifying the impact weights, a weight threshold is set based on whether the conflict significantly affects the core functions of the architecture and whether its impact covers multiple element clusters. Conflict factors with impact weights greater than the weight thresholds and related element clusters are selected. Among them, conflicts in related element clusters have a much wider impact range than conflicts in a single element because they affect the overall function of the collaborative unit. These conflict factors are ultimately identified as the dominant conflict factors. The three-dimensional, hierarchical superposition quantification logic comprehensively considers the importance, correlation strength, and impact range of residual conflicts, ensuring that the determination of impact weights is objective and in line with architectural requirements. Conflict factors in related element clusters are selected as dominant conflict factors to ensure that subsequent conflict resolution can resolve the contradiction between a wide impact range and strong coreity, improve the overall feasibility of the architecture design, and provide a clear basis for optimizing and adjusting the architecture configuration scheme.

[0121] S3. The structural and behavioral parameters of the system architecture framework are used as decision variables. A fitness function is constructed by combining the dominant conflict factor and its influence weight. The genetic algorithm is used to solve the problem to output a set of configuration schemes. Based on the intention priority reflected by the mapping relationship, a configuration scheme is selected from the set of configuration schemes and the framework code is generated.

[0122] Furthermore, constructing the fitness function includes:

[0123] The structural and behavioral parameters of the system architecture framework are used as decision variables. The behavioral parameters are calibrated based on the constraint fit to form an associated response, and the structural parameters are calibrated based on the association strength of the framework elements.

[0124] By combining the dominant conflict factors and their influence weights, the priority of intent and the correlation strength of framework elements, optimization objectives including resolution adaptability, intent satisfaction and architectural synergy are determined.

[0125] Dynamic weights for the optimization objective are assigned based on the calibrated decision variables. The penalty intensity is adjusted according to the dominant conflict factors and their influence weights. The penalty term is calculated based on the number of unresolved residual conflicts and the penalty intensity.

[0126] The optimization objectives are weighted and fused according to dynamic weights, and the calculated penalty terms are superimposed to construct the fitness function.

[0127] The structural and behavioral parameters of the system architecture framework are decision variables in the adaptability function. However, if their initial settings do not incorporate prior constraints and element association characteristics, incompatibility between behavior and constraints may occur, leading to a loose structure and inefficient collaboration. Structural parameters include the hierarchical affiliation of framework elements, the combination methods within element clusters, and the association logic across element clusters. Behavioral parameters include the triggering conditions for framework element execution, interaction response mechanisms, and resource scheduling strategies. Constraint adaptability is used to calibrate behavioral parameters, adjusting their compatibility with constraints. For example, in high-concurrency processing, if constraint adaptability shows insufficient adaptability between framework elements and hardware resource limitations, behavioral parameters are calibrated, and peak load offloading mechanisms are added to ensure behavioral responses meet constraint requirements. If constraint adaptability shows a high degree of adaptability between framework elements and real-time response constraints, low-latency interaction logic in the behavioral parameters is strengthened.

[0128] The structural parameters are calibrated based on the correlation strength of the framework elements to optimize the collaborative tightness of the structure. The structural parameters of strongly correlated element clusters are adjusted to prioritize deployment at the same level and direct interaction channels to improve collaborative efficiency; the structural parameters of moderately correlated element clusters are adjusted to reserve interaction interfaces and call on demand; and the structural parameters of weakly correlated element clusters are maintained to ensure independent deployment and low coupling to avoid structural redundancy. After calibration, decision variables are formed to ensure that the decision variables meet the constraints and adapt to the collaborative characteristics of the elements. The dual calibration eliminates the disconnect between the decision variables and the correlation between the preceding constraints and the framework elements, making the evaluation object of the fitness function practically feasible. The accurate calibration of structural parameters and behavioral parameters provides a reliable carrier for the implementation of subsequent optimization goals.

[0129] The fitness function needs to clearly define the core optimization direction. A single objective may lead to an architecture that meets requirements but experiences frequent conflicts or inefficient collaboration. The core definitions and judgment criteria for each optimization objective must be clearly defined. Among these, the resolution fitness focuses on the effectiveness of resolving the dominant conflict factor, judged by the compatibility between the conflict factor and the architecture design. For example, if the dominant conflict factor is hardware resource limitations in high concurrency, and the architecture design achieves compatibility through load balancing and dynamic resource expansion, then the resolution fitness meets the standard. The intent fulfillment focuses on the degree of implementation of core intent constraints, judged by intent priority and overall matching degree. Combinations with fully implemented high-priority intents and high overall matching degree have better intent fulfillment. The architecture collaboration focuses on the efficiency of the combination of framework elements, judged by the correlation strength of framework elements and the calibration results of structural parameters. An architecture with smooth collaboration of strongly correlated elements, clear cross-cluster interaction logic, and no redundant structures has better architecture collaboration. The three optimization objectives are clearly defined qualitatively, specifying whether they meet the standards or not, and the judgment logic for excellent, average, and poor performance. The three-dimensional optimization objectives comprehensively cover the core requirements of the architecture design, avoiding the one-sidedness caused by a single objective.

[0130] The importance of the three optimization objectives is not fixed. In scenarios where the dominant conflict factor has a significant impact, resolving adaptability should be prioritized. When the core intent has not been implemented, the weight of intent satisfaction needs to be increased. Static weights cannot adapt to the different needs of different scenarios, and unresolved residual conflicts will directly affect the feasibility of the architecture. Dynamic weight allocation is based on the calibrated decision variables, combined with the dominant conflict factor and its influence weight, intent priority and the correlation strength of framework elements. If the influence weight of the dominant conflict factor is high, the dynamic weight of resolving adaptability is increased. If the core intent has not been fully implemented, the dynamic weight of intent satisfaction is increased. If there are still shortcomings in coordination after the structural parameters are calibrated, the dynamic weight of architectural coordination is increased to ensure dynamic adaptation to the core contradictions of the current architecture design.

[0131] The penalty calculation focuses on unresolved residual conflicts. First, the penalty intensity is adjusted according to the influence weight of the dominant conflict factor, with residual conflicts with larger influence weights receiving stronger penalties. Then, the penalty is added based on the number of unresolved residual conflicts, which is qualitatively described as a small number, a medium number, and a large number. A small number of residual conflicts receives a lighter penalty, while a medium or large number of residual conflicts receive a significantly stronger penalty. The logic of the penalty is that the greater the impact and the greater the number of conflicts, the heavier the penalty, ensuring that unresolved conflicts are constrained by the fitness function. Dynamic weight allocation gives the fitness function scenario flexibility, avoiding the rigidity of static weights. The setting of the penalty strengthens the constraint rigidity of residual conflicts, ensuring that the architecture design prioritizes the resolution of core contradictions. Both the weights and penalty are adjusted based on prior features, ensuring logical consistency and objectivity in judgment.

[0132] The optimization objectives and penalty items need to be integrated into a unified evaluation index to form a practical fitness function. If they are evaluated separately, it is impossible to comprehensively determine the overall adaptability of the architecture design. First, the three optimization objectives are weighted and fused according to dynamic weights. The fusion logic is that the optimization objective with a high dynamic weight has a more significant impact on the function result. For example, when the dynamic weight of fitness reduction is the highest, its judgment result will dominate the overall positive score of the fitness function. Intent satisfaction and architecture synergy are added positively according to their corresponding dynamic weights to form the positive base score of the fitness function.

[0133] Then, penalty terms are added, incorporating the penalty intensity corresponding to unresolved residual conflicts into the fitness function. The negative impact corresponding to the penalty terms is deducted from the positive base score. If there are few unresolved conflicts and their impact is small, the score remains high after penalty; if there are many unresolved conflicts and their impact is large, the score decreases significantly. Finally, the fitness function is constructed based on the logic of positively reflecting the degree of achievement of the optimization goal and negatively constraining the negative impact of unresolved conflicts. The results of the fitness function are reflected through qualitative descriptions, such as high fitness, medium fitness, and low fitness. Weighted fusion achieves a comprehensive evaluation of the optimization goal, avoiding the one-sidedness of a single goal. The penalty terms are added to strengthen the conflict constraint, ensuring that the fitness function can identify poor solutions that meet the requirements but have frequent conflicts. Finally, the fitness function has a clear evaluation logic, which can provide a unified and objective judgment standard for the selection of architecture configuration solutions.

[0134] Specifically, the generated framework code includes:

[0135] The fitness function is solved using a genetic algorithm, and the combination of decision variables that maximizes the fitness value is obtained through iterative optimization, outputting a set of configuration schemes.

[0136] Extract the intent priority reflected by the mapping relationship, and combine the constraint adaptability and the association strength of the frame elements to filter the configuration scheme set to select the configuration scheme.

[0137] Based on the structural and behavioral parameters corresponding to the configuration scheme, the resolution logic corresponding to the constraint parameter threshold and the dominant conflict factor is embedded into the code of the corresponding frame element according to the hierarchical architecture of the kerML meta-model, and the collaborative calling rules of the component code are determined according to the association strength of the frame elements within the element cluster.

[0138] Based on the embedded constraint parameter thresholds, resolution logic, and collaborative calling rules of component code, framework code matching the hierarchical architecture of the KerML metamodel is generated.

[0139] The fitness function is the basis for evaluating the merits of architecture configuration schemes. However, the decision variables of the system architecture framework have many dimensions and complex logic, and a single calculation cannot find the optimal solution. The calibrated structural parameters and behavioral parameters are used as the initial population of the genetic algorithm. The qualitative evaluation results of the fitness function are used as the iterative guide, and iterative optimization is carried out according to the logic of the genetic algorithm. That is, in the selection stage, decision variable combinations with high fitness evaluation are retained and low fitness combinations are eliminated; in the crossover stage, the advantageous parameters of different high fitness combinations are integrated to generate new combinations. The advantageous parameters include structural parameters with strong architectural synergy and behavioral parameters with high constraint fitness; in the mutation stage, local adjustments are made to the shortcomings of the crossover combinations to ensure combination diversity.

[0140] After each iteration, the fitness function is used for re-evaluation until the iteration converges, meaning that no better combination is generated after multiple consecutive iterations. At this point, all decision variable combinations with high fitness are extracted and organized into a configuration scheme set according to the hierarchical architecture of the KerML meta-model. The configuration scheme set clearly defines the structural parameters, behavioral parameters, and fitness evaluation results for each combination. The iterative optimization characteristics of the genetic algorithm ensure the global optimality of the decision variable combinations, avoiding insufficient architecture adaptability caused by local optima. The output of the configuration scheme set provides a multi-choice space for subsequent screening, rather than being limited to a single solution, thus improving the accuracy of the final configuration scheme. The iteration process is guided by the fitness function to ensure that all schemes meet the optimization objective.

[0141] Although all configuration schemes are highly adaptable combinations, different schemes differ in their degree of fulfillment of core intents and their adaptability to framework elements. Directly selecting a particular configuration scheme may result in the resolution of issues where high adaptability is achieved but core intents are not prioritized or there is insufficient synergy. Therefore, we first extract the intent priorities marked in the mapping relationship and clarify the parameter requirements corresponding to the core intent constraints. For example, the structural parameters for data security compliance must satisfy the embedding of encryption logic, and the behavioral parameters must satisfy permission verification. Then, we retrieve the judgment results of the constraint adaptability and the correlation strength between framework elements, establish filtering dimensions, and retain the configuration schemes that fully cover high-priority intents, have highly compatible constraint features with framework element attributes, and have the optimal structural parameters for strongly correlated element clusters.

[0142] The configuration scheme set is filtered layer by layer according to the logic of prioritizing intent satisfaction, followed by constraint adaptability, and then supplementing with architectural synergy. That is, configuration schemes that do not cover the core intent are first eliminated, then configuration schemes with low constraint adaptability are eliminated, and finally the configuration scheme with the best architectural synergy is selected from the remaining configuration schemes. This ensures that the selected configuration scheme takes into account the core requirements, constraint adaptability, and element architectural synergy. The multi-dimensional filtering logic ensures that the selected configuration scheme is guided by the core requirements and avoids the problem of high adaptability but missing core requirements. The selected configuration scheme has both high adaptability and core requirement matching degree, laying a good foundation for subsequent code generation.

[0143] The selected configuration scheme only specifies the parameter framework, without implementing the constraints and conflict resolution logic at the code level. If code is generated directly, the component code will lack constraint rigidity and collaborative calling logic, failing to meet the architecture design requirements. First, based on the three-level architecture of the KerML metamodel—infrastructure layer, business logic layer, and external adaptation layer—the structural and behavioral parameters corresponding to the configuration scheme are mapped to the code modules of the framework elements at each level. For the framework element code of each level, the constraint parameter thresholds and the resolution logic corresponding to the dominant conflict factors are embedded. For example, in the data security element code of the infrastructure layer, compliance constraint thresholds such as data encryption algorithm type and key update cycle are embedded, and in the order processing element code of the business logic layer, performance constraint thresholds such as concurrent processing response logic and resource usage boundaries are embedded.

[0144] For example, to address the dominant conflict factor of hardware resource limitations in high concurrency, load balancing scheduling and peak rate limiting resolution logic is embedded in the business logic layer element code. Then, the collaborative calling rules of the component code are determined according to the correlation strength of the framework elements within the element cluster. Strongly correlated elements are set with collaborative calling rules for direct synchronous calls and real-time data interaction; moderately correlated elements are set with collaborative calling rules for asynchronous calls and non-core process triggers; and weakly correlated elements are set with collaborative calling rules for on-demand calls and low-priority interactions, ensuring that the collaborative calling rules match the element collaboration requirements. Content is embedded according to the KerML hierarchy to ensure that the code structure conforms to the meta-model specification and avoids hierarchical confusion. The embedding of constraint parameter thresholds gives the component code clear constraint execution basis, the embedding of resolution logic solves core conflict problems, and the collaborative calling rules based on correlation strength improve the collaboration efficiency of the component code and avoid performance loss caused by invalid interactions.

[0145] While the embedding of content and the setting of collaborative calling rules for element code at each level have been completed, the modules remain scattered and have not been integrated into framework code according to the hierarchical architecture of the KerML metamodel. Directly using these scattered modules would not result in a feasible system architecture framework. Using the hierarchical architecture of the KerML metamodel as the main thread, and following the order of infrastructure layer → business logic layer → external adaptation layer, the element code embedding constraint parameter thresholds, resolving logic, and clarifying collaborative calling rules at each level is integrated. The infrastructure layer code serves as the underlying support, and its integration and basic interaction interfaces are solidified first. The business logic layer code, based on the infrastructure layer interface, establishes a connection with the infrastructure layer according to the collaborative calling rules, while also integrating the calling logic of framework elements within the layer. The external adaptation layer code interfaces with the business logic layer interface to achieve adaptive interaction with the external environment.

[0146] During the integration process, the logical consistency of code at each level is verified to ensure that constraint parameter thresholds are conflict-free in cross-level calls, that conflict resolution logic is effective across levels, and that collaborative call rules cover all element cluster interaction scenarios. The hierarchical structure of the framework code matches the KerML metamodel. The framework code includes constraint execution logic, conflict resolution logic, and collaborative call rules, and each module is traceable to the configuration scheme and constraint requirements. The code is integrated according to the KerML hierarchy to ensure that the framework code has a standardized structure and logical coherence, meets the design requirements of the metamodel, and that logical verification during the integration process avoids cross-level conflicts, ensuring the executability of the framework code. All constraints, resolution, and collaborative requirements are implemented before the framework code is fully deployed, achieving a closed loop from architecture design to code deployment. It can be directly used for the deployment, testing, and application of the system architecture framework.

[0147] S4. Generate the architecture component skeleton of the configuration scheme sequentially based on the kerML metamodel, and build a dependency relationship view between the architecture components. During the generation process, verify the interface consistency and constraint compliance of the architecture components, and package the verified architecture components, framework code and dependency relationship view to generate an architecture framework instance.

[0148] Furthermore, such as Figure 3 As shown, the view of dependencies between architectural components includes:

[0149] The hierarchical architecture based on the KerML metamodel determines the hierarchical affiliation of architectural components, generates the architectural component skeleton of the configuration scheme in sequence, and divides the collaborative clusters of architectural components based on the association strength of framework elements, and marks the dependency relationship of architectural components within the collaborative cluster.

[0150] In the dependency relationships of architectural components, mark the conflict dependency nodes associated with the dominant conflict factor, mark the conflict risk level according to the impact weight, and mark the dependency adaptation risk of architectural components according to the constraint adaptability.

[0151] The architecture components are displayed hierarchically, with the results of the collaborative cluster division and risk labeling overlaid. The hierarchical display results are determined based on intent priority to construct a view of the dependencies between architecture components.

[0152] The hierarchical classification of architectural components is a structural feature of the KerML metamodel. If the classification is unclear, it can lead to a chaotic view hierarchy or an inability to reflect the metamodel design specifications. The architectural component skeleton is the foundational framework of the dependency view; without it, subsequent dependency annotation and cluster division become unpredictable. First, the hierarchical architecture of the KerML metamodel is retrieved, and the hierarchical classification of each architectural component is clarified. For example, the data encryption component belongs to the infrastructure layer, the order processing and payment verification components belong to the business logic layer, and the cloud environment adaptation component belongs to the external adaptation layer. Following the hierarchical order of infrastructure layer → business logic layer → external adaptation layer, the architectural component skeleton corresponding to the configuration scheme is generated. The architectural component skeleton clearly defines the name, functional positioning, and hierarchical relationships of each architectural component, forming the basic structure of the dependency view. Then, based on the strength of association between framework elements, the architectural components are divided into collaborative clusters. Components with strong associations and collaborative functions are grouped into the same cluster. For example, the order processing component, payment verification component, and order query component are grouped into the order business collaborative cluster due to their high association strength and shared order business functions.

[0153] Medium-related components are divided into secondary collaborative clusters based on their functional relevance; weakly related components maintain their independent affiliation and are not forced to be included in the cluster structure; based on the inheritance, dependency, and composition relationships between architectural components reflected by the mapping relationship, the dependency relationships of architectural components within and across collaborative clusters are marked. Inheritance relationships are marked as hierarchical dependencies of parent component → child component, such as business foundation component → order processing component; direct dependencies are marked as component A directly calling component B, such as the order processing component directly depending on the payment verification component; indirect dependencies are marked as component A indirectly calling component B through component C, such as the order processing component indirectly depending on the account query component through the payment verification component. This ensures that all dependencies are clear and traceable. The clear hierarchical affiliation and the generation of architectural component skeletons ensure that the dependency relationship view conforms to the KerML metamodel specification, avoiding hierarchical confusion. The division of collaborative clusters accurately reflects the functional collaboration logic of architectural components, allowing the dependency relationship view to focus on core business units. The clear dependency relationship marking presents the interaction relationships between architectural components, providing a structured foundation for subsequent risk identification and dependency relationship view display.

[0154] The dependencies corresponding to the dominant conflict factors are the core risk points of the architecture operation. If they are not marked, the risks will be hidden, affecting the stability of the architecture. The risk level can intuitively reflect the impact of conflict dependencies, helping users to prioritize high-risk points. Dependency adaptation risk is related to the compatibility between architectural components and constraints. If not marked, adaptation issues will be ignored. First, the identified dominant conflict factors and their impact weights are retrieved and compared with the dependencies in the skeleton of architectural components one by one. Conflict dependency nodes directly related to the dominant conflict factors are marked. For example, the dependency relationship between the order processing component and the load balancing component corresponding to the hardware resource limit for high-concurrency processing in the dominant conflict factors is a conflict dependency node. The conflict type involved in this conflict dependency node is clearly marked. Then, the conflict risk level is marked according to the impact weight of the dominant conflict factors. Conflict dependency nodes with significant impact weights are marked as high risk, those with medium impact weights are marked as medium risk, and those with low impact weights are marked as low risk. For example, the order processing component and the load balancing component are marked as high risk because they are related to the core business and the core hardware resources.

[0155] Finally, based on the constraint adaptability assessment results, the dependency adaptability risks of architectural components are marked. Dependencies with high constraint adaptability are marked as having no adaptability risk. For example, the order processing component → payment verification component has no adaptability risk due to high constraint adaptability. Dependencies with medium constraint adaptability are marked as potential adaptability risks, requiring attention to parameter compatibility. Dependencies with low constraint adaptability are marked as high dependency adaptability risks, explicitly indicating that the dependency relationship may have constraint incompatibility issues. For example, an auxiliary component → core security component is marked as high adaptability risk due to low constraint adaptability. The marking of conflicting dependency nodes makes core risk points visible, avoiding risk hiding. The marking of conflict risk level and dependency adaptability risk provides users with risk priority guidance, making it easier to deal with high-risk issues first. All three types of marking are based on previous objective results to ensure the accuracy and reliability of risk warnings.

[0156] The previous steps have completed the core content of the architecture component skeleton, collaboration clusters, and risk labeling. However, this information is scattered and lacks targeted display logic. Direct integration would lead to cluttered dependency view information and obscure the core content. According to the hierarchical architecture of the KerML metamodel, the architecture component skeleton is displayed layer by layer in the dependency view. Each layer of architecture components is grouped and presented by collaboration clusters. For example, the business logic layer is grouped and laid out by order business collaboration clusters and user management collaboration clusters. Different collaboration clusters are distinguished by differentiated visual identifiers, such as different colors or borders, to ensure that the hierarchy and collaboration cluster structure are clearly distinguishable. The labeling results of conflicting dependency nodes, conflict risk levels, and dependency adaptation risks are overlaid on the corresponding levels and collaboration clusters. Intuitive visual symbols are used to distinguish risk levels, such as special identifiers for high risks and warning identifiers for potential risks.

[0157] Finally, based on intent priority, the focus of the hierarchical display results is determined. The hierarchy and collaboration clusters corresponding to core intent constraints are highlighted in the dependency relationship view. For example, the order business collaboration cluster corresponding to the core business logic layer is placed in the core position of the dependency relationship view, and the layout of the dependency relationship view is adjusted to make its visual proportion larger and the label clearer. The hierarchy and collaboration clusters corresponding to non-core intents are appropriately weakened in display to ensure that users can quickly focus on the dependencies and risk status of the core business. In the end, a dependency relationship view between architectural components is constructed with clear hierarchy, clear clusters, visualized risks, and a focus on key points. The hierarchical display and cluster differentiation ensure the structure and logic of the dependency relationship view, avoid information clutter, and the superposition of risk labels realizes the integrated presentation of dependencies and risk status, improves the usability of the view, and the highlighting design based on intent priority makes the view targeted, making it easy for users to quickly grasp core information, improve the efficiency of architecture maintenance and optimization, and ensure that there is clear dependency and risk guidance for the entire life cycle management of the architecture.

[0158] Specifically, generating system architecture framework instances includes:

[0159] During the generation of the architectural component skeleton, the architectural components are grouped according to the association strength of the framework elements, the interface consistency of architectural components within and between groups is verified, and the constraint compliance of the architectural components is verified based on the constraint parameter threshold, and the verified architectural components are selected.

[0160] The verified architecture components, framework code, and dependency view are associated and bound with the resolution records of the dominant conflict factors and the verification results of constraint fit.

[0161] The results of the association and binding are verified for integrity, and the packaging directory structure is determined based on the hierarchical architecture, intent priority and comprehensive matching degree of the KerML meta-model, so as to encapsulate and generate an instance of the system architecture framework.

[0162] The strength of the association between framework elements directly determines the tightness of collaboration among architectural components, avoiding inefficiency caused by fragmented architectural components. Interface consistency is the foundation for interaction between architectural components; inconsistent interfaces will prevent architectural components from communicating properly. Constraint compliance is the core of the architecture meeting user needs and specification requirements; if architectural components do not meet constraint parameter thresholds, instances will lack practical application value. First, based on the strength of the association between framework elements, architectural components are grouped. Strongly related and functionally collaborative architectural components are grouped into the core collaboration group, such as the order processing component and the payment verification component forming the order core collaboration group; moderately related components are grouped into the secondary collaboration group; and weakly related components are grouped into the independent component group, ensuring that architectural components within a group have a natural basis for collaboration.

[0163] By comparing the interface design specifications of the KerML metamodel with the interface definitions in the preceding configuration scheme, the interface format, data transmission protocol, and call parameter specifications of each component within a group are verified to ensure consistency. This verifies the interface consistency of architectural components within the group. For example, it verifies whether the interface call parameter names and data types of the order processing component and the payment verification component are consistent. Inter-group verification checks the interface compatibility of cross-group architectural components, such as whether the interface connection logic between the core collaboration group and the secondary collaboration group components is smooth. Based on constraint parameter thresholds, the constraint compliance of architectural components is verified. Each architectural component is checked to ensure it meets functional, performance, deployment, and compliance constraints. For example, it verifies whether the data security component meets compliance constraint thresholds such as encryption algorithm type and key update cycle, and whether the high-concurrency processing component meets performance constraint requirements such as response logic and resource usage boundaries. Architectural components that meet the interface consistency and constraint compliance standards are selected and marked as qualified components. Grouping by association strength ensures the natural adaptability of architectural component collaboration, improves instance operating efficiency, and provides dual checks on interaction feasibility and requirement compliance to prevent unqualified components from entering subsequent processes, reducing the risk of rework after instance deployment. Qualified components provide the core carrier for subsequent association binding, ensuring the reliability of the instance foundation.

[0164] Qualified components, framework code, dependency view, records of resolving dominant conflict factors, and constraint fit verification results are all independent deliverables from previous processes. If they exist separately, they cannot form a complete system architecture framework instance, and it is also inconvenient for subsequent traceability and maintenance. Using the identifier of qualified components as the core link, a unified association and binding of multiple deliverables is achieved. That is, firstly, qualified components are bound to the generated framework code, with each architecture component corresponding to a dedicated code module, clarifying the code implementation logic of the architecture component's function. For example, the order processing component is bound to the corresponding order business code module. Then, they are bound to the dependency view, marking the hierarchical affiliation, collaborative cluster classification, and dependency association information of each building component in the dependency view. For example, the payment verification component is associated with the conflict dependency node of the order business collaborative cluster in the dependency view.

[0165] Next, it is bound to the resolution record of the dominant conflict factor, recording the conflict type, resolution logic, and processing result involved in the architecture component. For example, the load balancing component is associated with the resolution record of hardware resource limitation conflict in high concurrency. Finally, it is bound to the verification result of constraint adaptability, marking the adaptability of the architecture component with each constraint feature. For example, the cloud environment adaptation component is associated with the adaptation verification result of its private cloud deployment constraints. In the end, a set of associated bindings of architecture components, framework code, dependency relationship view, resolution record, and adaptation result is formed, and the full lifecycle information of each architecture component can be traced. The multi-results association binding realizes the full-link logic connection from architecture components to framework code, from dependencies to conflict handling, so that the instance has complete technical support. The structured integration ensures the orderliness of information, which is convenient for subsequent integrity verification and directory planning. The traceability design provides a clear query basis for the testing and operation and maintenance of the system architecture framework instance, reducing management costs.

[0166] Information omissions may occur after association and binding. Integrity verification can promptly fill gaps and prevent functional defects in instances. First, integrity verification is carried out. By comparing with the association and binding set, each qualified component is checked one by one to see if it has been associated with all necessary deliverables and whether there are any missing deliverables or association errors. For example, it verifies whether the data security component has been bound to encryption code, dependent view nodes, compliance conflict resolution records, and adaptation verification results. If any omissions are found, the previous process is traced back to fill in the missing ones to ensure that the association and binding set is complete and mismatched. Then, the packaging directory structure is determined. The hierarchical architecture of the KerML metamodel is used as the directory trunk. Each directory is divided into subdirectories according to collaboration clusters. For example, the business logic layer is set with subdirectories for the order business collaboration cluster and the user management collaboration cluster. Combined with intent priority, the architecture components and deliverables corresponding to the core intents are placed in the priority position of the directory. For example, the architecture component directory corresponding to the core intent of data security compliance is placed at the top of the infrastructure layer.

[0167] Based on the overall matching degree, architectural components with high overall matching degree are highlighted in the directory to facilitate quick location of core functional modules. Finally, all related and bound results are integrated according to the directory structure, including qualified components, framework code, dependency relationship views, resolution records, and constraint adaptation verification results, and packaged into standardized system architecture framework instances. The system architecture framework instances have the characteristics of direct deployment, traceability, and maintainability. Integrity verification ensures the functional completeness and information accuracy of the instances, avoiding the loss of core content after deployment. The directory structure conforms to the meta-model specification and core requirement orientation, improving the usability of the instances. Standardized encapsulation gives the instances a unified delivery form, which can be directly applied to actual deployment scenarios, completing the entire closed loop from architecture design to instance deployment. It also provides clear technical support for subsequent instance iteration optimization and operation and maintenance upgrades, ensuring the smooth management of the entire lifecycle of the system architecture framework instances.

Claims

1. A method for configuring and generating a system architecture framework based on the KerML metamodel, characterized in that, include: The KerML metamodel is analyzed to determine candidate framework elements for the system architecture framework. Natural language processing is performed on the user requirement text to identify the architecture intent and generate intent constraint features. The semantic similarity between the candidate framework elements and the intent constraint features is determined to form a mapping relationship between elements and intents. Based on the mapping relationship, the intent constraint features are analyzed and bound to the frame elements in the candidate frame elements to form instance intent constraints. The instance intent constraints, environmental constraints and business constraints are integrated to construct a constraint tensor. The constraint tensor is decomposed to identify the dominant conflict factors and their influence weights. The structural and behavioral parameters of the system architecture framework are used as decision variables. A fitness function is constructed by combining the dominant conflict factor and its influence weight. The genetic algorithm is used to solve the problem to output a set of configuration schemes. Based on the intention priority reflected by the mapping relationship, a configuration scheme is selected from the set of configuration schemes and the framework code is generated. Based on the KerML metamodel, the architecture component skeleton of the configuration scheme is generated sequentially, and the dependency relationship view between the architecture components is constructed. During the generation process, the interface consistency and constraint compliance of the architecture components are verified. The verified architecture components, framework code and dependency relationship view are packaged to generate an architecture framework instance.

2. The system architecture framework configuration and generation method based on the KerML metamodel as described in claim 1, characterized in that, The candidate framework elements for determining the system architecture framework include: The KerML metamodel is hierarchically analyzed. Based on the functional descriptions of different hierarchical architectures and the functional matching degree of the system architecture framework, framework elements with a functional matching degree greater than the matching threshold are selected, and the hierarchical inheritance relationship of the framework elements is preserved. Extract the functional attributes, constraint attributes, and adaptation attributes of the frame elements, and combine them with the hierarchical inheritance relationship to explore the inheritance, dependency, and composition relationships between the frame elements. Cluster them to form functionally collaborative element clusters and mark the association strength of the frame elements within the element clusters. Dynamic pruning of element clusters is performed using grammatical and adaptation constraints and association strength of the KerML metamodel to determine candidate framework elements for the output architecture framework.

3. The system architecture framework configuration and generation method based on the KerML metamodel as described in claim 2, characterized in that, The generation intent constraint features include: Natural language processing is used to identify the architectural intent of user requirement text, and the architectural intent is decomposed to obtain the functional implementation, performance indicators, deployment environment and compliance requirements, and to distinguish the constraint rigidity of the architectural intent. The decomposed architectural intent is mapped to the functional attributes, constraint attributes, and adaptation attributes of the candidate framework elements. The mapped architectural intent is then quantified according to the architectural domain to generate constraint features. The constraint strength of constraint features is quantified based on the constraint rigidity and domain importance of architectural intent, and the intent priority is marked. Potential conflicts between constraint features are identified and conflict labels are added to generate intent constraint features.

4. The system architecture framework configuration and generation method based on the KerML metamodel as described in claim 3, characterized in that, The mapping relationship between the forming elements and the intention includes: Based on the functional attributes, constraint attributes, and adaptation attributes of candidate frame elements, semantic similarity is determined with the functional implementation, performance indicators, deployment environment, and compliance requirements in the intent constraint features. The constraint adaptation degree between candidate frame elements and constraint features is simultaneously verified to obtain a two-dimensional matching value. By combining the intent priority of intent constraint features with the association strength of candidate frame elements, the two-dimensional matching values ​​are weighted and fused to generate a comprehensive matching degree between elements and intents. Based on the conflict labels of intent constraint features, check whether there are constraints corresponding to the same candidate frame element that are simultaneously bound to conflict labels, so as to determine whether to remove the combination of candidate frame element and intent constraint feature, and retain the effective combination with a comprehensive matching degree greater than a preset threshold. The effective combinations are sorted in descending order of comprehensive matching degree to form a mapping relationship between candidate frame elements and intent constraint features, that is, the mapping relationship between elements and intent.

5. The system architecture framework configuration and generation method based on the KerML metamodel as described in claim 4, characterized in that, The constraints on the intention to form instances include: Based on the comprehensive matching degree and intent priority of the mapping relationship, the binding priority of intent constraint features is determined and ranked; Based on the hierarchical inheritance relationship of the candidate frame elements, the sorted intent constraint features are bound to the corresponding frame elements one by one, and the compatibility between the intent constraint features and the frame element attributes is verified simultaneously. The bound intent constraint features are instantiated and adapted, and the constraint parameter thresholds are refined based on the functional attributes, constraint attributes and adaptation attributes of the candidate frame elements to generate constraint instances. Based on the conflict labels of intent constraint features and the verification results of adaptation consistency during the binding process, the binding conflicts of different framework elements between different architecture levels are resolved, forming instance intent constraints.

6. The system architecture framework configuration and generation method based on the KerML metamodel as described in claim 5, characterized in that, The identification of dominant conflict factors and their influence weights includes: Instance intent constraints, environment constraints, and business constraints are standardized according to the architectural domain, and structurally encoded according to the constraint type and associated framework elements to construct constraint tensors; The constraint tensor is decomposed into layers according to the constraint type, and binding conflicts within the same layer and between different layers are extracted, and residual conflicts that have not been resolved are filtered out. Based on intent priority and overall matching degree, intent constraint features are divided into core intent constraints and non-core intent constraints, and residual conflicts corresponding to core intent constraints are retained. For the remaining residual conflicts, they are graded and superimposed according to intent priority, constraint fit and conflict frequency. The influence weight of different conflict factors is quantified, and the conflict factors with influence weight greater than the weight threshold and related element clusters are selected as the dominant conflict factors.

7. The system architecture framework configuration and generation method based on the KerML metamodel as described in claim 6, characterized in that, The fitness function is constructed as follows: The structural and behavioral parameters of the system architecture framework are used as decision variables. The behavioral parameters are calibrated based on the constraint fit to form an associated response, and the structural parameters are calibrated based on the association strength of the framework elements. By combining the dominant conflict factors and their influence weights, the priority of intent and the correlation strength of framework elements, optimization objectives including resolution adaptability, intent satisfaction and architectural synergy are determined. The dynamic weights of the optimization objective are assigned based on the calibrated decision variables, and the penalty intensity is adjusted according to the dominant conflict factors and their influence weights. The penalty term is calculated based on the number of unresolved residual conflicts and the penalty intensity. The optimization objectives are weighted and fused according to dynamic weights, and the calculated penalty terms are superimposed to construct the fitness function.

8. The system architecture framework configuration and generation method based on the KerML metamodel as described in claim 7, characterized in that, The generated framework code includes: The fitness function is solved using a genetic algorithm, and the combination of decision variables that maximizes the fitness value is obtained through iterative optimization, outputting a set of configuration schemes. Extract the intent priority reflected by the mapping relationship, and combine the constraint adaptability and the association strength of the frame elements to filter the configuration scheme set to select the configuration scheme. Based on the structural and behavioral parameters corresponding to the configuration scheme, the resolution logic corresponding to the constraint parameter threshold and the dominant conflict factor is embedded into the code of the corresponding frame element according to the hierarchical architecture of the kerML meta-model, and the collaborative calling rules of the component code are determined according to the association strength of the frame elements within the element cluster. Based on the embedded constraint parameter thresholds, resolution logic, and collaborative calling rules of component code, framework code matching the hierarchical architecture of the KerML metamodel is generated.

9. The system architecture framework configuration and generation method based on the KerML metamodel as described in claim 8, characterized in that, The dependency view between the building architecture components includes: The hierarchical architecture based on the KerML metamodel determines the hierarchical affiliation of architectural components, generates the architectural component skeleton of the configuration scheme in sequence, and divides the collaborative clusters of architectural components based on the association strength of framework elements, and marks the dependency relationship of architectural components within the collaborative cluster. In the dependency relationships of architectural components, mark the conflict dependency nodes associated with the dominant conflict factor, mark the conflict risk level according to the impact weight, and mark the dependency adaptation risk of architectural components according to the constraint adaptability. The architecture components are displayed hierarchically, with the results of the collaborative cluster division and risk labeling overlaid. The hierarchical display results are determined based on intent priority to construct a view of the dependencies between architecture components.

10. The system architecture framework configuration and generation method based on the KerML metamodel as described in claim 9, characterized in that, The generated system architecture framework examples include: During the generation of the architectural component skeleton, the architectural components are grouped according to the association strength of the framework elements, the interface consistency of architectural components within and between groups is verified, and the constraint compliance of the architectural components is verified based on the constraint parameter threshold, and the verified architectural components are selected. The verified architecture components, framework code, and dependency view are associated and bound with the resolution records of the dominant conflict factors and the verification results of constraint fit. The results of the association and binding are verified for integrity, and the packaging directory structure is determined based on the hierarchical architecture, intent priority and comprehensive matching degree of the KerML meta-model, so as to encapsulate and generate an instance of the system architecture framework.

Images