Software architecture framework configuration and generation method based on UML meta-model extension technology

Abstract

The application relates to the technical field of model configuration, in particular to a software architecture framework configuration and generation method based on UML meta-model extension technology. The application proposes the following scheme: a UML activity diagram is constructed to depict function execution flow, and UML interaction constraint conditions containing time sequence, concurrency, branching and interface constraint are generated from the activity diagram; under the constraint of the interaction constraint, a UML component meta-class is extended, meta-attributes such as framework semantic type, running environment and generation configuration are introduced, and an initial software architecture framework model is constructed; in combination with a component knowledge graph library, an outwardly-biased distribution strategy is adopted to distribute activity nodes to reusable components or newly-built components, and a software architecture framework meeting interaction consistency and generation constraint is generated. The application can improve the traceability, reuse stability and engineering generability of architecture configuration.

Description

Technical Field

[0001] This application relates to the field of model configuration technology, and in particular to a method for configuring and generating software architecture frameworks based on UML metamodel extension technology. Background Technology

[0002] As software scale and complexity continue to increase, software architecture plays an increasingly crucial role in engineering practice, especially in application scenarios that need to simultaneously support complex functional logic, frequent requirement changes, and multi-platform deployment. The rationality of the architecture configuration directly affects subsequent implementation and maintenance costs. In existing technologies, software architecture design typically relies on modeling languages ​​such as UML to describe the system structure and interaction relationships through component diagrams, sequence diagrams, or related documents.

[0003] However, in practical applications, existing architecture modeling methods often directly provide the components and their interface structures, lacking a systematic generation process based on requirements and functional execution. This makes it difficult to guarantee the functional coverage and interaction integrity of the resulting architecture. For software containing complex execution logic such as sequence, concurrency, and conditional branching, existing methods struggle to accurately reflect the actual interaction constraints at the architecture level, easily leading to problems such as inconsistent message order between components, missing concurrency semantics, or unclear interface call relationships.

[0004] To address the above issues, this application designs a software architecture framework configuration and generation method based on UML metamodel extension technology. Summary of the Invention

[0005] The technical problem this application aims to solve is to address the shortcomings of existing technologies by providing a method for configuring and generating software architecture frameworks based on UML metamodel extension technology. This method involves constructing UML activity diagrams to depict functional execution flows and generating UML interaction constraints, including timing, concurrency, branching, and interface constraints, from these activity diagrams. Under these interaction constraints, UML component metaclasses are extended, introducing meta-attributes such as framework semantic types, runtime environments, and generation configurations to construct an initial software architecture framework model. Combining this with a component knowledge graph library, a middle-outward trade-off allocation strategy is used to assign activity nodes to reusable or newly created components, generating a software architecture framework that satisfies interaction consistency and generation constraints. This method improves the traceability, reusability, and engineering generative capabilities of the architecture configuration.

[0006] To achieve the above objectives, this application provides the following technical solution:

[0007] A method for configuring and generating a software architecture framework based on UML metamodel extension technology, the method comprising:

[0008] Obtain the requirements information of the software system to be developed, and construct a UML activity diagram to represent the functional execution flow logic based on the requirements information;

[0009] Based on the UML activity diagram, UML interaction constraints are generated according to preset interaction transformation rules, wherein the UML interaction constraints include at least UML timing constraints.

[0010] Under the UML interaction constraints, the component metaclasses in the preset UML metamodel are extended to obtain the extended component metamodel, and the initial software architecture framework model is constructed based on the extended component metamodel.

[0011] According to the UML activity diagram, the corresponding activity nodes are assigned to the target components in the initial extended component metamodel. The assignment is carried out through a middle-outward trade-off allocation strategy, which includes: searching for reusable components corresponding to the activity nodes to be assigned in the component asset library; if a reusable component is found, the activity nodes to be assigned are assigned to the reusable component and the corresponding component definition is reused; if no reusable component is found, a new component is created and the framework semantic type of the new component is determined according to the extended component metamodel.

[0012] Based on the allocation results and the initial software architecture framework model, a configured software architecture framework is generated.

[0013] The requirement information includes use case information, scenario information, functional requirement information, non-functional requirement information, and interface requirement information for hardware interaction. The requirement information is obtained by parsing requirement documents, system specifications, and user input information to generate structured requirements.

[0014] Based on the aforementioned requirements information, a UML activity diagram is constructed to represent the functional execution flow logic, including:

[0015] The use case information and scenario information in the requirement information are parsed to determine the functional boundaries and triggering conditions corresponding to each use case;

[0016] Based on the functional requirements information, extract the functional behaviors under the use cases and map the functional behaviors to UML activity nodes;

[0017] Based on the non-functional requirement information and the interface requirement information for hardware interaction, constraints are applied to the control flow, concurrency relationships, and conditional branches between the UML active nodes to obtain the functional execution flow logic.

[0018] A UML activity diagram is generated based on the functional execution flow logic, functional boundaries, and triggering conditions.

[0019] The step of generating UML interaction constraints according to preset interaction transformation rules includes:

[0020] The UML activity graph is analyzed using a topology sorting algorithm to extract activity nodes, control flow edges, decision branches, concurrent structures, and interaction identifiers corresponding to external interfaces, thereby generating a set of activity semantic elements.

[0021] Based on the set of activity semantic elements, an interaction participant set and an interaction relationship graph corresponding to the interaction participants are constructed by extracting endpoints of interaction identifiers and clustering them together. The interaction participants include at least one of software objects, software components and hardware interface entities.

[0022] The partial order relationship of the interaction events is determined based on the control flow edge, and the branch interaction constraints are generated based on the decision branch. The concurrent interaction constraints are generated based on the concurrent structure to obtain the set of interaction behavior constraints.

[0023] The UML interaction constraints are generated based on the set of interaction behavior constraints. The UML interaction constraints include at least: UML timing constraints for limiting the order of message interactions, synchronous and asynchronous methods and message matching relationships; concurrency constraints for limiting concurrent interactions; selection constraints for limiting branch paths; and interface constraints for limiting interface call triggering conditions and parameter consistency.

[0024] The graphical analysis of the UML activity diagram using a topology sorting algorithm includes:

[0025] The UML activity graph is converted into a control flow directed graph, and the initial node and the terminal node are set as the source and sink of the control flow directed graph, respectively.

[0026] Identify the decision branch structure and concurrent structure in the directed graph of the control flow, and generate structure identifiers corresponding to the decision branch structure and concurrent structure respectively;

[0027] Cycle detection is performed on the directed graph of the control flow. If a cycle is detected, the control flow edges corresponding to the cycle are iteratively expanded to obtain a directed acyclic graph that is adapted to the topological sorting constraint.

[0028] A topological sort is performed on the directed acyclic graph to obtain a topological sequence of active nodes. Based on the topological sequence, the main path is extracted and the branch path is enumerated to generate a path set to represent sequential relationships, branch relationships and concurrent relationships.

[0029] Based on the path set, the interaction identifiers corresponding to the external interfaces are extracted from the UML activity diagram to obtain the activity semantic element set.

[0030] The step of constructing a set of interaction participants and an interaction relationship graph corresponding to the interaction participants by extracting endpoints of interaction identifiers and clustering them into associations includes:

[0031] The interaction identifiers are extracted using named entity recognition and pattern matching algorithms to obtain a candidate set of endpoints.

[0032] An endpoint similarity matrix is ​​constructed based on the endpoint candidate set, and the endpoint candidates are clustered using the DBSCAN density clustering algorithm to obtain endpoint clusters;

[0033] Each endpoint cluster is identified as an interaction participant, and the interaction relationship graph is generated based on the message pointing relationship between endpoint clusters.

[0034] The step of extending the component metaclasses in the preset UML metamodel to obtain an extended component metamodel, and constructing an initial software architecture framework model based on the extended component metamodel, includes:

[0035] Define extended stereotypes and corresponding meta-attribute sets on the component meta-classes of the preset UML meta-model. The meta-attribute sets include framework semantic type attributes, interface type attributes, runtime environment attributes, and code generation configuration attributes.

[0036] Construct the integrity constraints and consistency constraints of the extended stereotype, wherein the integrity constraints are used to limit the value range of the framework semantic type attribute, and the consistency constraints are used to limit the matching relationship between the interface type attribute and the runtime environment attribute;

[0037] Construct an initial software architecture framework model based on the extended stereotype and the corresponding set of meta-attributes;

[0038] The UML interaction constraints are mapped to the constraints of the initial software architecture framework model.

[0039] The component asset library is a component knowledge graph library, which is built using UML component models, interface specification documents, and code generation configuration files from historical projects.

[0040] Based on the UML activity diagram, the corresponding activity nodes are assigned to the target components in the initial extended component metamodel, including:

[0041] Based on the UML activity diagram and the UML interaction constraints, extract the function labels, interface call identifiers, input and output parameter sets, and interaction relationships with adjacent activity nodes of each activity node to generate an activity feature set;

[0042] Retrieve candidate reusable components that match the activity feature set from the component asset library to obtain a candidate component set, and calculate the matching degree of each candidate reusable component to the activity node;

[0043] Based on the matching degree, at least one anchorable reusable component is determined, and with the anchorable reusable component as the center, according to the message interaction order and interaction frequency defined by the UML interaction constraints, adjacent active nodes that are strongly related to the anchorable reusable component are assigned to the anchorable reusable component.

[0044] For unassigned active nodes, clustering is performed according to preset grouping rules to generate new component candidate groups. The grouping rules include at least one of functional similarity, data sharing degree and interaction coupling degree. New components are created according to each new component candidate group, and the corresponding active nodes are assigned to the new components.

[0045] The framework semantic types of the new component and the anchored reusable component are determined based on the extended component metamodel, and the interface connection relationships corresponding to the new component and the anchored reusable component are generated in the initial software architecture framework model.

[0046] The adjacent activity nodes refer to the predecessor and successor activity nodes that have a direct control flow connection with the activity node in the UML activity diagram. The strong correlation is determined by correlation calculation, which is based on at least two or more of the following indicators: the frequency of message interaction between the adjacent activity nodes and the activity node, the strength of message interaction order constraint, the number of shared data objects, and the overlap of interface call parameters. When the correlation is greater than or equal to a preset correlation threshold, it is determined to be a strong correlation.

[0047] Compared with the prior art, the beneficial effects of this application are:

[0048] This application introduces UML interaction constraints and an extended component metamodel to explicitly constrain the software architecture configuration process and provide a verifiable foundation. Employing a component knowledge graph-based trade-off allocation strategy, it improves the reusability and stability of historical component assets while ensuring consistency in functional execution logic and interactions, and reduces the introduction of unnecessary new components. By uniformly describing component semantics, runtime environments, and generated configurations at the model level, the generated software architecture framework can directly support subsequent implementation and code generation, improving the traceability, consistency, and engineering generative capabilities of the architecture results, making it suitable for the architecture configuration and evolution of complex software. Attached Figure Description

[0049] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0050] Figure 1 A flowchart illustrating the software architecture framework configuration and generation method based on UML metamodel extension technology provided in this application embodiment;

[0051] Figure 2 This is a schematic diagram of the UML interaction constraints provided in the embodiments of this application. Detailed Implementation

[0052] The technical solutions in 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.

[0053] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0054] This embodiment is applicable to software systems that need to complete the closed loop of requirements-interaction-architecture-reuse-generation under a unified modeling semantics, especially for engineering scenarios where software functions span hardware control domain and service communication domain, and the architecture changes frequently with platform and project tailoring.

[0055] In such engineering scenarios, the system architecture is often not built from scratch:

[0056] On the one hand, demand-side features are constantly iterated by use cases and scenarios, and behavioral logic exhibits obvious sequential, branching, and concurrent characteristics;

[0057] On the other hand, the engineering side has accumulated reusable component assets and interface implementations over a long period of time, but these assets are scattered across different projects, different platform semantics and different code generation chains, making it difficult for reuse and correct decomposition to be achieved at the same time.

[0058] Taking typical automotive software as an example, the same set of functions may require the generation of hardware-oriented control code as well as service-oriented communication or platform service code. When the system contains both types of implementation paths, relying solely on traditional UML component diagrams to directly provide component and interface results often makes it difficult to provide verifiable evidence for the integrity, consistency of interaction, and generativeness of the architecture.

[0059] Based on the aforementioned engineering facts, the core logic of the method in this application stems from a verifiable observation:

[0060] The correctness of the architecture of a complex system depends first on whether the behavioral logic is fully captured, and second on whether the interaction constraints can be explicitly expressed and used to generate the constraint structure. The effectiveness of reuse depends on whether the allocation process can weigh existing assets and ensure that new parts only occur where they are truly necessary.

[0061] Therefore, this embodiment does not take a fixed module division, a predetermined structural partition, or a preset cavity component boundary as a premise, but is oriented towards modeling and generation scenarios with typical engineering characteristics:

[0062] Requirements can be organized into use cases / scenarios, functional execution flows can be characterized by activity diagrams, and interaction sequences and interface relationships can be extracted as explicit constraints from the transformation rules from activities to interactions. Based on this, by extending the UML meta-model, computable attributes such as framework semantic types, interface types, runtime environments, and generation configurations are introduced to components. This makes the subsequent allocation from activities to components no longer a purely manual split, but rather driven by interaction constraints, anchored by the reuse of component asset libraries, and using a middle-outward trade-off strategy to complete the configuration and generation of the architecture framework.

[0063] It is understood that the application scenarios applicable to this application include, but are not limited to:

[0064] Systems that simultaneously possess embedded control software and service-oriented software that interact across hardware and software and require different outputs; systems driven by use cases with rapid iteration and behavior flows involving numerous branches and concurrency, requiring consistency to be ensured through interaction constraints; systems with large-scale historical component assets where reuse decisions need to be explainable, measurable, and rollbackable; and systems that, when switching or coexisting with platform semantics (such as service-oriented components, control components, or standardized platform component semantics), require UML metamodel extensions to bring platform constraints forward to the architecture configuration stage, thereby improving generativeability and engineering consistency.

[0065] Next, with reference to the accompanying drawings, the software architecture framework configuration and generation method based on UML metamodel extension technology provided in the embodiments of this application will be further described. Figure 1 The methods shown include:

[0066] S1: Obtain the requirements information of the software system to be developed, and construct a UML activity diagram to represent the functional execution flow logic based on the requirements information;

[0067] In this embodiment, the requirement information is not merely used as static descriptive material, but is parsed into structured input that can be used for behavioral modeling. This input includes at least use case information, scenario information, functional requirement information, non-functional requirement information, and interface requirement information related to hardware interaction. By parsing the above requirement information, the triggering conditions, execution boundaries, and key behavioral steps of the function are clarified. These behavioral steps are then organized into a functional execution flow with sequential relationships, conditional branches, and concurrent relationships, thereby generating a UML activity diagram to characterize the functional execution flow logic.

[0068] Understandably, moving the semantic information from the requirements phase forward and explicitly mapping it to specific activities and behaviors allows subsequent architecture generation to no longer rely on manual experience for functional decomposition, which helps improve the completeness of functional coverage and the consistency of behavioral expression.

[0069] Those skilled in the art will understand that the parsing method, data source, and specific format of the requirement information can be adjusted according to the actual engineering situation, as long as it can support the construction of the functional execution flow logic. This application does not limit this.

[0070] S2: Based on the UML activity diagram, generate UML interaction constraints according to preset interaction transformation rules;

[0071] The UML interaction constraints mentioned therein include at least UML timing constraints;

[0072] S3: Under the UML interaction constraints, the component metaclasses in the preset UML metamodel are extended to obtain the extended component metamodel, and the initial software architecture framework model is constructed based on the extended component metamodel.

[0073] In this embodiment, to address the issue that the native UML component metaclass only has structural description capabilities and is difficult to carry platform semantics and generation information, the component metaclass is extended by introducing meta-attributes such as framework semantic types, interface types, runtime environment attributes, and code generation configurations, and integrity constraints and consistency constraints are established for the extended stereotype.

[0074] Based on this, and combined with the aforementioned generated UML interaction constraints, an initial software architecture framework model is constructed, so that component instances not only have structure and interface definitions, but also naturally meet the constraints of interaction order, concurrency relationship and interface consistency.

[0075] S4: Based on the UML activity diagram, assign the corresponding activity nodes to the target components in the initial extended component metamodel;

[0076] The allocation is carried out through a middle-outward trade-off allocation strategy, which includes: retrieving reusable components corresponding to the activity node to be allocated in the component asset library; if a reusable component is found, allocating the activity node to be allocated to the reusable component and reusing the corresponding component definition; if no reusable component is found, creating a new component and determining the framework semantic type of the new component according to the extended component metamodel.

[0077] Understandably, by using mature components in the asset library as allocation anchors and gradually absorbing functional activities outwards, a balance can be achieved between maximizing component reuse and minimizing the addition of new components, while ensuring that interaction constraints are not violated. This effectively solves the problems of difficulty in quantifying reuse and difficulty in stabilizing splitting boundaries in engineering practice.

[0078] S5: Based on the allocation results and the initial software architecture framework model, generate the configured software architecture framework;

[0079] In this embodiment, based on the final allocation results of active nodes and components, the initial software architecture framework model is configured and updated to generate a fully configured software architecture framework containing component instances, interface connection relationships, and semantic attribute values. The generated software architecture framework satisfies functional coverage requirements at the structural level, UML interaction constraints at the interaction level, and the framework and runtime environment constraints defined by the extended component metamodel at the semantic level.

[0080] Understandably, the resulting software architecture framework is ready to be used directly for subsequent code generation, platform deployment, or further analysis and verification, effectively reducing the reliance on human experience in architecture design and improving the traceability, consistency, and engineering reusability of the architecture results.

[0081] Before delving into the specific technical details of the steps, the embodiments of this application need to be emphasized again.

[0082] The architecture generation process for complex software also has an engineering counterpart that is not based on real structural information:

[0083] In the mapping chain between requirements, behaviors, and architecture, pseudo-structural relationships may emerge, introduced by differences in expression granularity, perspective bias, and reuse priors. These relationships are not true architectural dependencies, but they can present a form highly similar to real dependencies at the model level. For example, they can form regular, repeatable call chains between activity nodes, and in the interaction model, they can appear as message pairs with strict order and complete parameters. Consequently, during the component allocation phase, they may be misjudged as stable interface relationships and solidified into component boundaries.

[0084] Unlike true architectural dependencies, these pseudo-structural relationships typically stem from multiple representations of the same behavior, different named projections of the same interface, or structural alignment of historical assets, exhibiting significant symmetry and replicability within the model space.

[0085] A reasonable reuse anchor point can be mapped indiscriminately to multiple adjacent behavior segments, resulting in interaction constraints that are formally satisfied but semantically create redundant constraints and coupling. If only conventional structural consistency checks or interface type matching are relied upon, it is often difficult to distinguish between such pseudo-structural associations and real dependencies, leading to engineering problems such as boundary drift, interface bloat, or abnormally increased cross-component communication in the subsequent evolution of the architecture.

[0086] The method logic in this embodiment does not focus on the static fact of whether there is interaction, but introduces the characterization of the changing trends of interaction and allocation behavior as an additional criterion for architecture generation.

[0087] Specifically, the constraints obtained from the interaction transformation are not only used to describe the order of messages, but also to reflect the convergence or divergence trend of the behavior segment in time and control flow. Accordingly, the process of assigning activities to components does not take the local optimal interface matching as the only criterion, but judges whether a certain assignment promotes interaction aggregation or interaction diffusion by comprehensively evaluating indicators such as interaction intensity, shared data, and constraint tightness.

[0088] It is understandable that real component boundaries are usually accompanied by local clustering of interactions and monotonous convergence of constraints. Pseudo-structural associations caused by representation copying or named projection often manifest as interactions appearing in pairs in adjacent areas, mirroring each other, and their constraints pointing to each other in a symmetrical relationship of mutual attraction. When such symmetrical attraction features are detected, it can be deduced from the generation logic that they are more likely to be the result of repeated mapping or reuse projection at the model representation level, rather than real architectural dependence. Therefore, a higher confidence resolution strategy can be adopted in the allocation and constraint mapping stage, such as prioritizing the regression of the original interface boundaries of the asset library anchor point, or triggering local redistribution to avoid redundant coupling solidification.

[0089] It should be further noted that the extension of the UML metamodel in this embodiment is not merely a static set of fields set up to carry platform labels, but rather is used to incorporate the aforementioned trend discrimination into an executable constraint system:

[0090] The framework semantic type, interface type, and runtime environment attributes in the extended stereotype constitute explicit constraints on the feasible domain of allocation; the timing, concurrency, branching, and interface consistency constraints in the interaction constraints constitute dynamic constraints on the allocation results; the combination of the two makes the introduction of reusable components and the growth of new components no longer an empirical boundary choice, but a configuration process that seeks optimization within the constraint space and can be rolled back and corrected.

[0091] Those skilled in the art will understand that the calculation methods for indicators such as interaction intensity, shared data, and constraint tightness can be selected based on the availability of engineering data. The running data can be collected according to the actual situation, and the specific types can be interface call frequency, message edge quantity, parameter overlap, or constraint conflict count, etc. It is only necessary to support the judgment of interaction aggregation / divergence trends to a minimum. This application does not impose any further limitations.

[0092] Next, we will further elaborate on the technical aspects of the UML activity diagram method in this application.

[0093] In one example, the requirement information includes use case information, scenario information, functional requirement information, non-functional requirement information, and interface requirement information for hardware interaction. The requirement information is obtained by parsing requirement documents, system specifications, and user input information to generate structured requirements.

[0094] Understandably, UML activity diagrams are not merely schematic models describing functional flows, but rather serve as a core intermediate model throughout requirements analysis, interaction constraint generation, and architecture allocation. Their construction process needs to simultaneously reflect functional logic, control relationships, and their connectivity with subsequent modeling steps. Therefore, when processing structured requirements, the modeling scope of the activity diagram is first determined based on use case and scenario information. This involves clearly defining the functional boundaries, triggering conditions, and termination conditions covered by a single activity diagram, ensuring that each activity diagram corresponds to a semantically complete and relatively independent functional execution unit. This avoids introducing overly broad or overlapping functional descriptions at the activity diagram level.

[0095] It should be noted that the aforementioned requirement information is not directly used in the modeling process in the form of natural language, but is converted into structured data units with clear semantic labels and constraint attributes in order to support the automatic construction and consistency verification of subsequent UML activity diagrams. The structure conversion process can be implemented by referring to existing requirement modeling methods or requirement semantic modeling techniques in model-driven engineering, which will not be elaborated here.

[0096] In yet another example, a UML activity diagram is constructed based on the aforementioned requirement information to characterize the functional execution flow logic, including:

[0097] The use case information and scenario information in the requirement information are parsed to determine the functional boundaries and triggering conditions corresponding to each use case;

[0098] Specifically, the parsing of use case information and scenario information is first used to identify the effective scope of behavioral modeling:

[0099] By analyzing the triggering events, participating roles, and scenario constraints of use cases, the functional boundaries covered by the activity diagram are determined, and the start and end conditions of the activity diagram are clarified. In this process, use cases do not necessarily correspond one-to-one with a single activity diagram. Instead, they are trimmed and merged according to functional closure and execution integrity, so that each activity diagram can fully reflect an independently understandable functional execution process, thereby avoiding the introduction of implicit dependencies across use cases at the activity diagram level.

[0100] Those skilled in the art will understand that the determination of the above-mentioned functional boundaries and triggering conditions can be adjusted according to engineering specifications or existing modeling habits, as long as the activity diagram has a clear entry and exit point in semantics.

[0101] Based on the functional requirements information, extract the functional behaviors under the use cases and map the functional behaviors to UML activity nodes;

[0102] In some optional implementations, statements in the requirements description that represent actions, processing, judgments, or invocations are analyzed and abstracted into functional behaviors, which are then mapped to UML activity nodes according to preset granularity rules. These granularity rules constrain the scale of activity node decomposition, ensuring that each activity node is neither too coarse to reflect the actual execution logic nor too fragmented to cause uncontrolled model complexity. Typically, one activity node corresponds to a functional step that can be individually scheduled, invoked, or implemented at the implementation level; multiple activity nodes form a complete execution path through control flow relationships.

[0103] Based on the non-functional requirement information and the interface requirement information for hardware interaction, constraints are applied to the control flow, concurrency relationships, and conditional branches between the UML active nodes to obtain the functional execution flow logic.

[0104] It should be noted that non-functional requirement information and interface requirement information for hardware interaction are used in this embodiment to modify and constrain the connection relationship between active nodes, rather than as additional descriptions independent of the behavior model.

[0105] For example, real-time or sequential requirements can be used to define the order of execution between activity nodes, while mutual exclusion or concurrency requirements can be used to introduce parallel branches or synchronization nodes. For functional behaviors involving hardware access or external interface calls, interaction identifiers or interface attributes are attached to the corresponding activity nodes to distinguish between internal computational behaviors and external interactive behaviors. By introducing these constraints during the activity graph construction phase, the final functional execution flow logic not only describes what to do but also implicitly expresses how to execute and under what constraints, thereby ensuring that the activity graph has sufficient information density at the semantic level.

[0106] A UML activity diagram is generated based on the functional execution flow logic, functional boundaries, and triggering conditions.

[0107] Next, we will further elaborate on the technical content of the UML interaction constraints in this application.

[0108] refer to Figure 2 , Figure 2 This is a schematic diagram of the UML interaction constraints provided in the embodiments of this application.

[0109] Figure 2 The diagram illustrates UML interaction constraints, including UML timing constraints to define the order of message interactions, synchronous / asynchronous modes, and message matching relationships; concurrency constraints to define concurrent interactions; branch path selection constraints; and interface constraints to define interface call triggering conditions and parameter consistency.

[0110] Timing constraints originate from the analysis of control flow relationships in UML activity diagrams. By mapping the sequential dependencies between activity nodes to the order of message sending and receiving, the interaction order between components during subsequent architecture modeling can be kept consistent with the functional execution flow. This effectively avoids problems such as uncertain message order, ambiguous synchronization relationships, or unclear message matching relationships after component partitioning. Those skilled in the art will understand that the timing constraints can be manifested as strict sequential constraints or weak sequential constraints that allow asynchronous interactions; the specific form can be configured according to engineering needs.

[0111] When parallel branches or synchronous nodes exist in the activity graph, the corresponding interactions are marked as concurrent relationships and explicitly represented in the interaction constraints. By introducing concurrency constraints, the execution mode of interactions between components can be constrained during the subsequent architecture framework configuration phase, ensuring that they meet the requirements of parallel execution or synchronous merging, thereby avoiding the destruction of the original concurrency semantics due to improper component deployment or interface design.

[0112] Selection constraints, by associating branch conditions with interaction paths, enable clear differentiation of message interactions triggered under different conditions and maintain condition consistency at the architectural level. This prevents the incorrect merging or omission of interactions from different branch paths during component allocation or interface reuse, thereby ensuring the correctness of functional logic in multi-path execution scenarios.

[0113] Interface constraints primarily originate from interface requirements for hardware interaction and external call behaviors identified in active nodes. They are used to constrain the legality of message interactions at the interface level. For example, they are used to limit the consistency of message parameters between the sender and receiver, the preconditions for interface calls, and the matching relationship between interface types and the runtime environment. By introducing interface constraints into the interaction constraints, potential interface inconsistencies can be identified in advance during the architecture framework generation phase, reducing the adjustment costs in subsequent integration and verification phases.

[0114] In one example, generating UML interaction constraints according to preset interaction transformation rules includes:

[0115] The UML activity graph is analyzed using a topology sorting algorithm to extract activity nodes, control flow edges, decision branches, concurrent structures, and interaction identifiers corresponding to external interfaces, thereby generating a set of activity semantic elements.

[0116] Based on the set of activity semantic elements, an interaction participant set and an interaction relationship graph corresponding to the interaction participants are constructed by extracting endpoints of interaction identifiers and clustering them together. The interaction participants include at least one of software objects, software components and hardware interface entities.

[0117] The partial order relationship of the interaction events is determined based on the control flow edge, and the branch interaction constraints are generated based on the decision branch. The concurrent interaction constraints are generated based on the concurrent structure to obtain the set of interaction behavior constraints.

[0118] The UML interaction constraints are generated based on the set of interaction behavior constraints.

[0119] In yet another example, the graphical analysis of the UML activity diagram using a topology sorting algorithm includes:

[0120] The UML activity graph is converted into a control flow directed graph, and the initial node and the terminal node are set as the source and sink of the control flow directed graph, respectively.

[0121] Identify the decision branch structure and concurrent structure in the directed graph of the control flow, and generate structure identifiers corresponding to the decision branch structure and concurrent structure respectively;

[0122] Cycle detection is performed on the directed graph of the control flow. If a cycle is detected, the control flow edges corresponding to the cycle are iteratively expanded to obtain a directed acyclic graph that is adapted to the topological sorting constraint.

[0123] A topological sort is performed on the directed acyclic graph to obtain a topological sequence of active nodes. Based on the topological sequence, the main path is extracted and the branch path is enumerated to generate a path set to represent sequential relationships, branch relationships and concurrent relationships.

[0124] Based on the path set, the interaction identifiers corresponding to the external interfaces are extracted from the UML activity diagram to obtain the activity semantic element set.

[0125] Understandably, the purpose of introducing topological sorting algorithms into UML activity diagrams is not simply to obtain the linear execution order of nodes, but to transform the functional execution flow, originally expressed graphically, into a computationally computable, enumerable, and constraint-derivative formal structure. In practice, the relationship between activity nodes and control flow in the UML activity diagram is first abstracted into a directed control flow graph, where activity nodes correspond to vertices, control flow edges correspond to directed edges, and the initial and final nodes are explicitly set as the source and sink, respectively. This transformation converts the process structure, which previously relied on manual interpretation, into a standard graph structure, providing a foundation for subsequent algorithm analysis.

[0126] Those skilled in the art will understand that the construction of a directed graph of control flow does not depend on any specific UML tool; it only requires maintaining the consistency of control dependencies between active nodes.

[0127] Based on this, the structure of the directed graph of the control flow is identified to distinguish different control modes such as sequential, branching and concurrent.

[0128] Specifically, branching structures are determined by identifying nodes with an in-degree or out-degree greater than one, concurrent structures are determined by identifying paired forking and merging nodes, and corresponding structure identifiers are generated for different structure types. Since UML activity graphs may contain loops or cycles in actual modeling, and topology sorting requires a directed acyclic graph (DAG) as input, cycle detection is performed on the control flow directed graph before sorting. When a loop is detected, the loop structure is converted into an equivalent expanded path by iteratively expanding or logically decomposing the control flow edges corresponding to the loop. This obtains a DAG adapted to topology sorting constraints while maintaining semantic consistency. This allows loop behavior to be uniformly incorporated into the path enumeration and constraint derivation process in subsequent analysis without compromising the algorithm's executability.

[0129] Furthermore, based on this topological sequence, the control flow path can be further analyzed:

[0130] By identifying the main path from the source to the sink, the main path of function execution is determined. Simultaneously, combined with the aforementioned structural identifiers, branch paths and concurrent paths are enumerated to form a path set that fully covers sequential, branching, and concurrent relationships. This path set not only reflects the possible combinations of function execution paths but also provides a direct basis for the subsequent generation of interaction constraints.

[0131] Furthermore, by associating the external interface call information identified in the activity nodes during the path analysis process, the interaction identifiers corresponding to the external interfaces can be extracted from the path set to form a set of activity semantic elements.

[0132] In yet another example, the construction of a set of interaction participants and an interaction relationship graph corresponding to the interaction participants through endpoint extraction and association clustering of interaction identifiers includes:

[0133] The interaction identifiers are extracted using named entity recognition and pattern matching algorithms to obtain a candidate set of endpoints.

[0134] An endpoint similarity matrix is ​​constructed based on the endpoint candidate set, and the endpoint candidates are clustered using the DBSCAN density clustering algorithm to obtain endpoint clusters;

[0135] Each endpoint cluster is identified as an interaction participant, and the interaction relationship graph is generated based on the message pointing relationship between endpoint clusters.

[0136] Understandably, the purpose of introducing endpoint extraction and association clustering is to solve the engineering problem of the difficulty in stably identifying interactive participants during the interaction analysis process.

[0137] Since interaction identifiers usually originate from interface call descriptions, message annotations, or external interface references in activity nodes, their expression may be inconsistent due to differences in modeling granularity, naming conventions, or historical assets. If interaction identifiers are directly mapped one-to-one to interaction participants, it is easy for the same logical participant to be split into multiple entities in the model, thereby disrupting the consistency of subsequent interaction constraints and component allocation.

[0138] In this embodiment, the interaction identifier is first parsed at the endpoint level. A named entity recognition algorithm is used to identify key fields with entity semantics, such as object names, component identifiers, interface names, or hardware port identifiers. A pattern matching algorithm is then used to identify fragments that conform to predefined call patterns or interface description patterns, thereby obtaining a candidate set of endpoints containing message senders, message receivers, and related attributes. This explicitly extracts the interaction participation information that was originally mixed in with descriptive text or annotation information, providing a unified data foundation for subsequent clustering analysis.

[0139] Furthermore, after obtaining the endpoint candidate set, to eliminate the impact of naming differences or redundant expressions, this embodiment further constructs an endpoint similarity matrix to characterize the degree of association between different endpoint candidates. The similarity can comprehensively consider factors such as the string similarity of endpoint names, the consistency of interface parameter structures, the consistency of the calling context, and the proximity relationship of the associated active nodes in the path set.

[0140] Those skilled in the art will understand that the specific calculation method for the above similarity can be selected based on the characteristics of the engineering data, as long as it can reflect the degree of similarity between endpoints in terms of semantics and calling behavior.

[0141] Building upon this, the DBSCAN density clustering algorithm is employed to cluster candidate endpoints, grouping densely distributed endpoints with high similarity into the same endpoint cluster. Since the DBSCAN algorithm does not rely on a pre-specified number of clusters and can identify outliers, it is particularly suitable for interactive analysis scenarios where the number of endpoints is uncertain and noisy endpoints may exist.

[0142] Furthermore, by analyzing the message pointing relationships between different endpoint clusters in the interaction identifiers, an interaction relationship graph corresponding to the interaction participants can be constructed. Nodes represent interaction participants, and edges represent message interaction relationships and their directions. This interaction relationship graph semantically reflects the interaction topology among the participants during function execution, providing an intuitive and computable basis for generating subsequent interaction constraints and determining the interface relationships between components.

[0143] Next, we will further elaborate on the technical content of the method of this application regarding the extended component metamodel.

[0144] It should be noted that the preset UML metamodel in this application can be understood as a basic metamodel that conforms to UML specifications and is used to define the types of modeling elements and their relationships. Its specific acquisition method can be achieved through existing UML modeling specifications, metamodel definition documents, or general modeling frameworks in model-driven engineering, which will not be elaborated upon here. This embodiment does not focus on the construction method of the UML metamodel itself, but rather on how to adapt an existing metamodel to the software architecture configuration and generation requirements of complex engineering scenarios.

[0145] In this embodiment, the starting point for extending the UML metamodel is:

[0146] Traditional UML component metaclasses are primarily used to express structural composition and interface relationships, with their semantic focus on structural description. However, they lack effective expression capabilities for the role attributes, operational constraints, and generation behaviors of components in actual engineering. When the architecture needs to support different types of functional implementation paths simultaneously, relying solely on native component semantics often requires introducing a large number of implicit conventions or manual specifications outside the model, leading to an unstable mapping relationship between the architecture model and subsequent implementations. Based on this engineering reality, this embodiment extends the semantics at the component metaclass level by introducing meta-attributes such as framework semantic types, interface types, runtime environment attributes, and code generation configuration attributes. This enables components to possess distinguishable, constrainable, and derivable engineering semantics at the model level.

[0147] It is important to emphasize that the extended component metamodel is not only used to carry additional attributes, but also to explicitly restrict the modeling behavior of component instances by defining integrity constraints and consistency constraints for extended stereotypes.

[0148] For example, by limiting the range of values ​​for framework semantic type attributes through integrity constraints, we can avoid the emergence of semantically ambiguous or ungenerable component types in the same architecture model; by limiting the matching relationship between interface type attributes and runtime environment attributes through consistency constraints, we can identify potential incompatible combinations in advance during the modeling phase. Problems that originally relied on later manual inspection or code generation failures to be exposed are moved to the constraint verification at the meta-model level, thereby significantly reducing the uncertainty in the architecture configuration process.

[0149] In one example, extending the component metaclasses in the preset UML metamodel to obtain an extended component metamodel, and constructing an initial software architecture framework model based on the extended component metamodel, includes:

[0150] S3.1: Define extended stereotypes and corresponding meta-attribute sets on the component meta-classes of the preset UML meta-model. The meta-attribute sets include framework semantic type attributes, interface type attributes, runtime environment attributes, and code generation configuration attributes.

[0151] Specifically, in UML semantics, component metaclasses primarily carry general expressions of structure and interfaces. However, during the engineering implementation phase, components often need to carry constraint information related to the architecture framework, runtime environment, and code generation chain. Otherwise, the subsequent component allocation and generation process can only rely on implicit rules outside the model, leading to inconsistent interpretations of the same component under different projects or platforms. To enable components to express key engineering elements such as the framework semantics they belong to, the type of interface they should follow, the environment they run in, and the corresponding generation configuration during the modeling phase, this embodiment introduces extended stereotypes at the component metaclass level and solidifies the above elements into a set of meta-attributes that can be processed by tools, so as to form a verifiable, inheritable, and traceable semantic carrier in the subsequent architecture configuration phase.

[0152] In this embodiment, the extended stereotype is mounted on the Component metaclass using the UMLProfile method or an equivalent metamodel extension method, and a set of meta-attributes is defined for the extended stereotype. The framework semantic type attribute is used to classify and label the engineering roles of components, including at least category identifiers for control components and service components, and can be extended to standardized platform component categories; the interface type attribute is used to label the interface paradigms of the components' externally provided interfaces and internally dependent interfaces, such as procedure call, message, signal, or service interfaces, so that matching interaction expressions can be selected during subsequent interaction constraint mapping; the runtime environment attribute is used to describe the component's deployment domain or execution domain, including but not limited to operating system type, task / thread model, ECU / domain controller identifier, or containerized runtime unit identifier, so that functional activities with runtime environment conflicts can be forcibly merged during the component allocation phase; the code generation configuration attribute is used to solidify the key parameters required for the generation chain, such as generation language type, generation template identifier, interface glue code strategy, scheduling method, and configuration file reference path, so that the modeling results can directly drive subsequent output.

[0153] Those skilled in the art will understand that the above-mentioned meta-attributes can be represented by enumerated values, key-value pairs, or structured configuration objects, as long as they can be read at the model level and used for constraint verification and configuration generation.

[0154] S3.2: Construct the integrity constraints and consistency constraints of the extended stereotype, wherein the integrity constraints are used to limit the value range of the framework semantic type attribute, and the consistency constraints are used to limit the matching relationship between the interface type attribute and the runtime environment attribute;

[0155] Specifically, even after components incorporate meta-attributes such as framework semantic types, interface types, runtime environments, and generation configurations, a lack of a constraint system can still lead to missing attributes, arbitrary values, or incompatible combinations. This can result in unexecutable or ungenerateable issues during subsequent architecture configuration or code generation phases. To avoid these problems being discovered later, this embodiment moves engineering feasibility requirements forward to the meta-model layer. Through integrity and consistency constraints, it solidifies which fields must be present, which values ​​can appear, and which combinations can coexist into verifiable rules, ensuring the model meets the minimum prerequisites for subsequent processing from the outset.

[0156] In this embodiment, integrity constraints are used to limit the value range and filling requirements of framework semantic type attributes. For example, it is stipulated that each component instance must select a unique framework semantic type; when the framework semantic type is a control component, the code generation configuration attribute must include a hardware-oriented generation template identifier and header file generation options; when the framework semantic type is a service component, the interface type attribute must not be empty and must include a service interface description or service contract reference identifier; when the component is marked as a standardized platform component category, the runtime environment attribute must include a platform identifier and a deployment domain identifier to support subsequent platform configuration file generation. The above integrity constraints can be expressed through OCL rules or implemented through the rule table in the model validator. The validator performs validation before saving, exporting, or generating the model and outputs the location information of unsatisfied items. The location information includes at least the component identifier, missing attribute items, and suggested value range.

[0157] S3.3: Construct an initial software architecture framework model based on the extended stereotype and the corresponding set of meta-attributes;

[0158] In this embodiment, the construction of the initial software architecture framework model includes the establishment of component hierarchies and interface skeletons. Component hierarchies can be determined based on use case boundaries, functional domain divisions, or existing platform layering principles, for example, forming a hierarchical structure of top-level modules, sub-modules, and component instances, and assigning meta-attributes such as identifiers, versions, and applicable domains to each level entity. Component instance creation follows extended stereotype requirements: upon creation, default values ​​for framework semantic types, runtime environments, and code generation configurations are bound, and configurable items are reserved for interface type attributes. Interface skeleton establishment generates placeholders for provided interfaces and required interfaces according to preset interface naming and classification rules, and associates these placeholders with component instances; each interface placeholder includes at least an interface identifier, direction attribute, parameter set reference, and message type reference to support parameter consistency verification and message matching verification during subsequent interaction constraint mapping. If reusable component interface definitions exist in the asset library, their interface skeletons can be directly imported as part of the initial model to ensure that the interface form of reusable components is consistent with historical versions.

[0159] S3.4: Map the UML interaction constraints to the constraints of the initial software architecture framework model;

[0160] In this embodiment, the mapping process uses interaction participants and interface placeholders as bridging objects. For UML timing constraints, based on the message pairs and sequence relationships defined in the interaction constraints, corresponding message link constraints are established in the architecture framework model. This constraint binds at least the interface placeholder provided by the message sending component, the interface placeholder required by the message receiving component, and the message type identifier, and records the message sequence requirements with sequence relationship markers. When the interaction constraint indicates synchronous / asynchronous mode, it maps to the call semantic attribute of the interface placeholder or the interaction mode attribute of the connection relationship, so that a matching call template can be selected in the code generation configuration later. For concurrency constraints, concurrent segments are mapped to parallel interaction group constraints in the structure layer, constraining message links within the same parallel group to be allowed to occur in parallel in the execution model, and requiring the establishment of synchronization markers at the interface or component internal synchronization point corresponding to the convergence point. For selection constraints, branch conditions are mapped to guard conditions or interface trigger conditions of the connection relationship, so that message links corresponding to different branch paths are explicitly distinguished and condition consistency is maintained. For interface constraints, the interface triggering conditions and parameter consistency requirements are mapped to the parameter contract and precondition fields of the interface placeholder. During the model verification stage, the parameter set references of the sending end and the receiving end are compared for consistency to avoid parameter drift caused by subsequent allocation or reuse.

[0161] Next, we will further elaborate on the technical aspects of the method in this application regarding the trade-off allocation strategy.

[0162] It should be noted that the component asset library is a component knowledge graph library, built using UML component models, interface specification documents, and code generation configuration files from historical projects, wherein:

[0163] The component asset library is not a simple list of components or a collection of static templates, but a component knowledge graph library gradually accumulated in engineering practice. This knowledge graph library is constructed by parsing and integrating UML component models, interface specification documents, and code generation configuration files from historical projects. This ensures that each component not only has a structural definition but also is associated with its functional semantics, interface capabilities, runtime environment compatibility, and past generation and usage experience, thus providing a calculable and comparable knowledge base for subsequent allocation decisions.

[0164] Specifically, when constructing the component knowledge graph library, the UML component models from historical projects are first parsed to extract information such as component names, component hierarchical relationships, provided interfaces and required interfaces, component semantic types, and inter-component dependencies. This information is then stored as entity nodes and relational edges in the graph. Next, the interface specification files are parsed, associating the interface calling methods, parameter sets, data directions, and constraints with the corresponding component nodes to form an explicit mapping relationship between components, interfaces, and capabilities. Simultaneously, the code generation configuration files are parsed, recording the component's generation language type, generation template, configuration parameters, and generation result characteristics in different project or platform environments as the component's historical generation attributes. This ensures that the component in the graph not only represents what it can do but also reflects how it is implemented under what conditions.

[0165] In one example, based on the UML activity diagram, the corresponding activity nodes are assigned to the target components in the initial extended component metamodel, including:

[0166] S4.1: Based on the UML activity diagram and the UML interaction constraints, extract the function labels, interface call identifiers, input and output parameter sets, and interaction relationships with adjacent activity nodes of each activity node to generate an activity feature set;

[0167] Specifically, if activity node allocation is based solely on matching activity node names or brief descriptions, misallocation can easily occur when functions are similar but constraints differ, or interfaces are similar but call semantics differ. This can lead to the incorrect selection of reusable components or difficulty in implementing subsequent interaction constraints. Therefore, the construction of the activity feature set is based on the principles of matchability, verifiability, and traceability. It extracts key information from activity nodes across three dimensions—functional semantics, interface semantics, and interaction semantics—as structured features, enabling subsequent retrieval and allocation to consider both functional coverage and interaction consistency, rather than relying solely on textual similarity.

[0168] In this embodiment, based on UML activity diagrams and UML interaction constraints, a corresponding feature record is established for each activity node. Functional tags are extracted from functional behavior fields in structured requirements, action semantic identifiers of activity nodes, or use case step identifiers associated with activity nodes. These tags are then standardized using a domain dictionary or a pre-defined tag set to converge synonymous expressions into a unified tag space. Interface call identifiers are extracted from interface annotations on activity nodes, external call tags, or interface name / direction / trigger condition fields in interface requirement information, forming an index key that can be used to locate interface definitions and parameter contracts. Input and output parameter sets are extracted from interface descriptions or activity node parameter annotations. Parameters include at least name, data type, direction attribute, and constraint identifier, and parameter names are standardized to eliminate naming differences from historical projects. The interaction relationship between adjacent activity nodes is determined by the predecessor / successor relationship of the control flow and the message edge relationship in the interaction constraints. The interaction relationship includes at least the interaction object identifier, message type identifier, synchronous / asynchronous identifier, and relative position in the topology sequence. These features are organized into a data structure that can be called by the retrieval module. A unified identifier system is maintained among the feature fields to support cross-project reuse retrieval.

[0169] S4.2: Retrieve candidate reusable components that match the activity feature set in the component asset library to obtain a candidate component set, and calculate the matching degree of each candidate reusable component to the activity node;

[0170] Specifically, components with the same name in the component asset library may have version differences, and similar functions may have multiple implementation paths. Relying on a single dimension for retrieval can easily introduce candidates that seem reusable but have high implementation costs. Therefore, the retrieval and matching degree calculation of candidate reusable components must simultaneously reflect the component's functional coverage, interface contract compatibility, and adaptability to the runtime environment and generated configuration. This ensures that the allocation decision has an interpretable basis and avoids the diffusion of interface modifications caused by reuse.

[0171] In this embodiment, candidate component retrieval is performed using a hierarchical retrieval approach. The first layer of retrieval uses functional tags as the primary index to locate component nodes in the component knowledge graph that match or are synonymously mapped to the activity's functional tags. Simultaneously, it filters obviously irrelevant components using component capability tags and applicable scenario tags. The second layer of retrieval uses interface call identifiers as constraints to filter the first-layer candidates at the interface level, requiring candidate components to provide at least an interface matching the activity node's required call, or to complete the corresponding call chain through existing dependent interfaces. The third layer of retrieval uses runtime environment attributes and code generation configuration attributes as filtering conditions to exclude component versions that do not match the activity node's constraint characteristics. For example, components with inconsistent runtime environment domains and lacking permitted cross-domain communication mechanisms, or components whose generated configuration templates do not support the target interface paradigm. After candidate screening, a matching degree is calculated for each candidate component. The matching degree comprehensively considers factors such as the similarity of functional tags, the consistency of interface parameter sets, the compatibility of interaction semantics, and the reusability of historical generated configurations. The specific reasons for a decrease in the matching degree are recorded for subsequent anchoring selection and rollback adjustments.

[0172] S4.4: Based on the matching degree, at least one anchorable reusable component is determined, and with the anchorable reusable component as the center, according to the message interaction order and interaction frequency defined by the UML interaction constraints, adjacent active nodes that are strongly related to the anchorable reusable component are assigned to the anchorable reusable component.

[0173] Specifically, if each activity node is independently selected with the highest matching degree, the activity node is easily scattered across multiple components, leading to an increase in the number of cross-component message edges and the dismantling of interaction order constraints. This makes the architecture structurally usable but difficult to maintain in terms of interaction consistency. The introduction of anchored reusable components allows the allocation process to gather functional activities around a small number of stable reusable points and form more cohesive component boundaries under the constraints of interaction conditions, so that reusability and interaction consistency can be taken into account simultaneously.

[0174] In this embodiment, the determination of the anchorable reusable component is not based solely on the component with the highest matching degree, but rather on a combination of coverage and interaction location. Coverage assessment determines the number of active nodes and critical path nodes that the candidate component can support, while interaction location assessment determines whether the participants corresponding to the candidate component in the interaction relationship graph are located in a concentrated interaction area or on a critical message link. After the anchored component is determined, the adjacent active nodes are snapped together around the anchored component.

[0175] The definition of adjacent active nodes is based on the predecessor / successor relationship of the control flow, and expanded to include adjacency relationships with direct message interaction or shared parameter contracts, combined with message edge relationships in interaction constraints. Strong correlation is determined by evaluating the correlation formed by the message interaction order and frequency defined by the interaction constraints. Correlation considers indicators such as message frequency, order constraint strength, number of shared data objects, and parameter overlap. When a preset threshold is met, it is determined to be strongly correlated and preferentially attached to the anchor component. Constraint verification is performed synchronously during the attachment process to ensure that attachment does not cause interface contract conflicts or runtime environment incompatibility.

[0176] S4.5: For unassigned active nodes, cluster them according to preset grouping rules to generate new component candidate groups. The grouping rules include at least one of functional similarity, data sharing degree and interaction coupling degree. Create corresponding new components according to each new component candidate group and assign the corresponding active nodes to the new components.

[0177] Specifically, unadsorbed active nodes typically possess two types of characteristics:

[0178] One category consists of newly added features for which the asset library lacks corresponding capabilities. The other category consists of features that exist but are unsuitable for reuse due to limitations in interface contracts, operating environments, or interaction constraints. Simply creating new components for each unassigned node would lead to an explosion in the number of components and interface fragmentation; blindly merging them might introduce low-cohesion component boundaries. Therefore, unassigned active nodes need to be clustered using grouping rules to ensure that the responsibilities and interaction boundaries of new components have an interpretable basis for formation, thereby providing stable units for subsequent generation and reuse.

[0179] In this embodiment, the grouping rules include at least three dimensions: functional similarity, data sharing degree, and interaction coupling degree. Functional similarity can be determined by the synonym mapping of the functional labels of the activity nodes, the consistency of the use case scenarios, or the consistency of the action semantic categories; the degree of data sharing is determined by the overlap of the input and output parameter sets of the activity nodes, the shared data object identifier, or the common access resource identifier; the interaction coupling degree is determined by the number of message edges in the interaction graph, the consistency of message types, and the strength of order constraints. The clustering process can adopt hierarchical clustering, density clustering, or threshold-based connected component partitioning, merging activity nodes that are closer in the above dimensions into the same new component candidate group. When generating a new component for each candidate group, the external call requirements of the activity nodes within the candidate group are summarized into the requirement interface of the new component, the functional outputs provided by the candidate group are summarized into the provided interface, and the interface parameter sets are deduplicated and aligned for consistency to form a generateable interface skeleton.

[0180] S4.6: Determine the framework semantic type of the new component and the anchored reusable component based on the extended component metamodel, and generate the interface connection relationship corresponding to the new component and the anchored reusable component in the initial software architecture framework model;

[0181] In this embodiment, the determination of the framework semantic type of new components and anchored reusable components follows the value rules and consistency constraints in the extended component metamodel. For anchored reusable components, the framework semantic type, runtime environment attributes, and code generation configuration attributes recorded in the component knowledge graph library are inherited first, and the newly added activity nodes introduced by the current allocation are checked for violations of consistency constraints. When the new activity causes a change in the interface paradigm, the type of the new interface is restricted by the interface type attribute constraint. If necessary, the new interface is expressed as an adaptation interface without changing the semantic type of the component itself. For new components, the semantic type is determined based on the interface call identifier and runtime constraint characteristics of its activity node set: when the activity node set mainly involves hardware access, signal reading and writing, or low-latency control behavior, the semantic type is configured as a control component and bound to the corresponding generation configuration template; when the activity node set mainly involves external service calls, service orchestration, or message interaction, the semantic type is configured as a service component and bound to the corresponding service interface generation configuration; when the activity node set needs to conform to a specific platform specification, the semantic type can be further configured as a standardized platform component category, and the necessary configuration attribute fields of the platform can be supplemented.

[0182] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for configuring and generating a software architecture framework based on UML metamodel extension technology, characterized in that, The method includes: Obtain the requirements information of the software system to be developed, and construct a UML activity diagram to represent the functional execution flow logic based on the requirements information; Based on the UML activity diagram, UML interaction constraints are generated according to preset interaction transformation rules, wherein the UML interaction constraints include at least UML timing constraints. Under the UML interaction constraints, the component metaclasses in the preset UML metamodel are extended to obtain the extended component metamodel, and the initial software architecture framework model is constructed based on the extended component metamodel. According to the UML activity diagram, the corresponding activity nodes are assigned to the target components in the initial extended component metamodel. The assignment is carried out through a middle-outward trade-off allocation strategy, which includes: searching for reusable components corresponding to the activity nodes to be assigned in the component asset library; if a reusable component is found, the activity nodes to be assigned are assigned to the reusable component and the corresponding component definition is reused; if no reusable component is found, a new component is created and the framework semantic type of the new component is determined according to the extended component metamodel. Based on the allocation results and the initial software architecture framework model, a configured software architecture framework is generated.

2. The software architecture framework configuration and generation method based on UML metamodel extension technology according to claim 1, characterized in that, The requirement information includes use case information, scenario information, functional requirement information, non-functional requirement information, and interface requirement information for hardware interaction. The requirement information is obtained by parsing requirement documents, system specifications, and user input information to generate structured requirements.

3. The software architecture framework configuration and generation method based on UML metamodel extension technology according to claim 2, characterized in that, Based on the aforementioned requirements information, a UML activity diagram is constructed to represent the functional execution flow logic, including: The use case information and scenario information in the requirement information are parsed to determine the functional boundaries and triggering conditions corresponding to each use case; Based on the functional requirements information, extract the functional behaviors under the use cases and map the functional behaviors to UML activity nodes; Based on the non-functional requirement information and the interface requirement information for hardware interaction, constraints are applied to the control flow, concurrency relationships, and conditional branches between the UML active nodes to obtain the functional execution flow logic. A UML activity diagram is generated based on the functional execution flow logic, functional boundaries, and triggering conditions.

4. The software architecture framework configuration and generation method based on UML metamodel extension technology according to claim 1, characterized in that, The step of generating UML interaction constraints according to preset interaction transformation rules includes: The UML activity graph is analyzed using a topology sorting algorithm to extract activity nodes, control flow edges, decision branches, concurrent structures, and interaction identifiers corresponding to external interfaces, thereby generating a set of activity semantic elements. Based on the set of activity semantic elements, an interaction participant set and an interaction relationship graph corresponding to the interaction participants are constructed by extracting endpoints of interaction identifiers and clustering them together. The interaction participants include at least one of software objects, software components and hardware interface entities. The partial order relationship of the interaction events is determined based on the control flow edge, and the branch interaction constraints are generated based on the decision branch. The concurrent interaction constraints are generated based on the concurrent structure to obtain the set of interaction behavior constraints. The UML interaction constraints are generated based on the set of interaction behavior constraints.

5. The software architecture framework configuration and generation method based on UML metamodel extension technology according to claim 4, characterized in that, The graphical analysis of the UML activity diagram using a topology sorting algorithm includes: The UML activity graph is converted into a control flow directed graph, and the initial node and the terminal node are set as the source and sink of the control flow directed graph, respectively. Identify the decision branch structure and concurrent structure in the directed graph of the control flow, and generate structure identifiers corresponding to the decision branch structure and concurrent structure respectively; Cycle detection is performed on the directed graph of the control flow. If a cycle is detected, the control flow edges corresponding to the cycle are iteratively expanded to obtain a directed acyclic graph that is adapted to the topological sorting constraint. A topological sort is performed on the directed acyclic graph to obtain a topological sequence of active nodes. Based on the topological sequence, the main path is extracted and the branch path is enumerated to generate a path set to represent sequential relationships, branch relationships and concurrent relationships. Based on the path set, the interaction identifiers corresponding to the external interfaces are extracted from the UML activity diagram to obtain the activity semantic element set.

6. The software architecture framework configuration and generation method based on UML metamodel extension technology according to claim 4, characterized in that, The step of constructing a set of interaction participants and an interaction relationship graph corresponding to the interaction participants by extracting endpoints of interaction identifiers and clustering them into associations includes: The interaction identifiers are extracted using named entity recognition and pattern matching algorithms to obtain a candidate set of endpoints. An endpoint similarity matrix is ​​constructed based on the endpoint candidate set, and the endpoint candidates are clustered using the DBSCAN density clustering algorithm to obtain endpoint clusters; Each endpoint cluster is identified as an interaction participant, and the interaction relationship graph is generated based on the message pointing relationship between endpoint clusters.

7. The software architecture framework configuration and generation method based on UML metamodel extension technology according to claim 1, characterized in that, The step of extending the component metaclasses in the preset UML metamodel to obtain an extended component metamodel, and constructing an initial software architecture framework model based on the extended component metamodel, includes: Define extended stereotypes and corresponding meta-attribute sets on the component meta-classes of the preset UML meta-model. The meta-attribute sets include framework semantic type attributes, interface type attributes, runtime environment attributes, and code generation configuration attributes. Construct the integrity constraints and consistency constraints of the extended stereotype, wherein the integrity constraints are used to limit the value range of the framework semantic type attribute, and the consistency constraints are used to limit the matching relationship between the interface type attribute and the runtime environment attribute; Construct an initial software architecture framework model based on the extended stereotype and the corresponding set of meta-attributes; The UML interaction constraints are mapped to the constraints of the initial software architecture framework model.

8. The software architecture framework configuration and generation method based on UML metamodel extension technology according to claim 1, characterized in that, The component asset library is a component knowledge graph library, which is built using UML component models, interface specification documents, and code generation configuration files from historical projects.

9. The software architecture framework configuration and generation method based on UML metamodel extension technology according to claim 1, characterized in that, Based on the UML activity diagram, the corresponding activity nodes are assigned to the target components in the initial extended component metamodel, including: Based on the UML activity diagram and the UML interaction constraints, extract the function labels, interface call identifiers, input and output parameter sets, and interaction relationships with adjacent activity nodes of each activity node to generate an activity feature set; Retrieve candidate reusable components that match the activity feature set from the component asset library to obtain a candidate component set, and calculate the matching degree of each candidate reusable component to the activity node; Based on the matching degree, at least one anchorable reusable component is determined, and with the anchorable reusable component as the center, according to the message interaction order and interaction frequency defined by the UML interaction constraints, adjacent active nodes that are strongly related to the anchorable reusable component are assigned to the anchorable reusable component. For unassigned active nodes, clustering is performed according to preset grouping rules to generate new component candidate groups. The grouping rules include at least one of functional similarity, data sharing degree and interaction coupling degree. New components are created according to each new component candidate group, and the corresponding active nodes are assigned to the new components. The framework semantic types of the new component and the anchored reusable component are determined based on the extended component metamodel, and the interface connection relationships corresponding to the new component and the anchored reusable component are generated in the initial software architecture framework model.

10. The software architecture framework configuration and generation method based on UML metamodel extension technology according to claim 9, characterized in that, The adjacent activity nodes refer to the predecessor and successor activity nodes that have a direct control flow connection with the activity node in the UML activity diagram. The strong correlation is determined by correlation calculation, which is based on at least two or more of the following indicators: the frequency of message interaction between the adjacent activity nodes and the activity node, the strength of message interaction order constraint, the number of shared data objects, and the overlap of interface call parameters. When the correlation is greater than or equal to a preset correlation threshold, it is determined to be a strong correlation.

Images