System architecture framework configuration and generation method based on kerML meta model

Abstract

The application relates to the technical field of model construction, in particular to a system architecture framework configuration and generation method based on a kerML meta model, and the following scheme is provided: firstly, meta model data described by kerML is subjected to semantic analysis and entity relationship abstraction to construct a computable semantic relationship graph; secondly, target elements are selected from the semantic relationship graph according to view configuration rules to generate view configuration data; then, a project hierarchy is derived according to framework configuration rules to generate framework configuration data with semantic boundaries; finally, a view semantic partial order structure is constructed based on framework nodes, view types and semantic descriptions, a minimum view set is selected, and view instances are materialized to generate a semantic complete and non-redundant system architecture framework. The application can support methodology tailoring, cross-methodology combination and semantic optimization generation of large-scale engineering modeling.

Description

Technical Field

[0001] This application relates to the field of model building technology, and in particular to a system architecture framework configuration and generation method based on the KerML metamodel. Background Technology

[0002] In complex engineering fields, system architecture often requires the use of multiple modeling methodologies for description, such as structured methodologies, behavior-driven methodologies, and industry process models. Existing modeling tools generally rely on fixed meta-model structures and preset view types. Internally, these tools typically present project hierarchies using static templates or fixed framework structures, making it difficult to flexibly combine different methodologies. The model content cannot be tailored or expanded according to project needs, resulting in a rigid project structure.

[0003] Furthermore, most existing tools' view generation methods are bound to the model file structure, graphic templates, or the tool's internal directory, making it difficult to dynamically adjust view content based on semantic changes. When the model is large or the methodology has multiple perspectives, this type of generation mode easily creates a large number of duplicate views, resulting in view redundancy and increased workload for project browsing.

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

[0005] The technical problem this application aims to solve is to address the shortcomings of existing technologies by providing a system architecture framework configuration and generation method based on the KerML metamodel. First, semantic parsing and entity relationship abstraction are performed on the KerML-described metamodel data to construct a computable semantic relationship graph. Then, target elements are selected from the semantic relationship graph according to view configuration rules to generate view configuration data. Subsequently, the project hierarchy is derived according to the framework configuration rules to generate framework configuration data with semantic boundaries. Finally, a partial order structure of view semantics is constructed based on framework nodes, view types, and semantic descriptions. The minimum set of generated views is selected, and view instances are materialized to achieve a semantically complete and non-redundant system architecture framework.

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

[0007] A method for configuring and generating a system architecture framework based on the KerML metamodel, the method comprising:

[0008] Obtain system architecture metamodel data described in KerML and requirement configurations for the methodology framework, and abstract the system architecture metamodel data into an entity-relationship data structure;

[0009] Based on preset view configuration rules, a set of target elements is selected from the entity relationship data structure, and view configuration data is generated according to the set of target elements, wherein each view type corresponds to multiple semantic data.

[0010] Based on the preset framework configuration rules, the corresponding project hierarchy in the requirement configuration is determined, and framework configuration data is generated, wherein the framework configuration data corresponds to multiple meta-models.

[0011] Based on the entity relationship data structure, view configuration data, and framework configuration data, a system architecture framework and corresponding view instances are generated.

[0012] The system architecture metamodel data includes functions, modules, activities, interfaces, performance metrics, and relationships expressed in KerML. The requirement configuration includes the target methodology type, the target project type, and the scope of metamodel elements to be covered.

[0013] The system architecture metamodel data is abstracted into an entity-relationship data structure, including:

[0014] Syntax parsing is performed on the system architecture metamodel data expressed in kerML to extract the metamodel element set and the element relation set. Each metamodel element includes a unique identifier, a type tag and an attribute set, and each element relation includes a source element identifier, a target element identifier and a relation type.

[0015] Based on the type marker, the metamodel elements in the metamodel element set are divided into semantic categories corresponding to functions, modules, activities, interfaces, and performance indicators, and a general element entity table and multiple sub-entity tables corresponding to the semantic categories are constructed, wherein the sub-entity tables are associated with the general element entity table through foreign keys;

[0016] The set of element relationships is mapped to a relation entity table. In the relation entity table, structural relationships, behavioral relationships, and constraint relationships are recorded by referencing the element identifiers in the general element entity table, thus obtaining a normalized relationship record.

[0017] Based on the normalized relation records, the general element entity table, and the sub-entity table, the entity relation data structure is obtained through multi-table association based on unique identifiers.

[0018] The entity relationship data structure obtained through multi-table association based on unique identifiers includes:

[0019] Based on the unique identifier in the general element entity table, a multi-table join is performed on the general element entity table, sub-entity table, and normalized relation records, merging the general attributes of each meta-model element with the sub-attributes of the corresponding semantic category into a unified attribute node;

[0020] Based on the relation type in the normalized relation record, the attribute nodes of the multi-table join are classified and aggregated. For each meta-model element, an outgoing edge set and an incoming edge set centered on the corresponding meta-model element are established, and an adjacency table indexed by a unique identifier is generated.

[0021] Based on the adjacency list, a semantic relationship graph is constructed, with general attribute nodes as graph nodes and normalized relationship records as graph edges. Each graph edge is labeled with its structure, behavior, and constraint relationships, resulting in an entity relationship data structure composed of meta-model element attributes and semantic relationships.

[0022] The process of selecting a target element set from the entity relationship data structure based on preset view configuration rules and generating view configuration data according to the target element set includes:

[0023] Based on the semantic selection conditions in the view configuration rules, node filtering and edge filtering are performed on the semantic relationship graph in the entity relationship data structure to obtain the target element set and the association relationship between the target elements that are adapted to the semantic selection conditions. The semantic selection conditions are determined according to the range of meta-model elements to be covered.

[0024] According to the mapping mode in the view configuration rules, the element types in the target element set are mapped and matched with the preset view semantic slots, and a corresponding element filling list is generated for each view semantic slot. The mapping mode includes type matching mode, semantic tag matching mode and relational context matching mode.

[0025] Based on the relationships between target elements, the relationships are converted into view-recognizable relational semantic units through the relationship aggregation strategy in the view configuration rules. These relational semantic units include decomposed relational units, interaction relational units, and constraint relational units.

[0026] Generate corresponding view configuration data based on the element-populated list and relational semantic units.

[0027] The step of converting the relationships between target elements into view-recognizable relational semantic units through the relationship aggregation strategy in the view configuration rules includes:

[0028] The relationships in the target element set are initially bucketed according to the relationship type, and structural relationships, behavioral relationships, and constraint relationships are assigned to structural buckets, behavioral buckets, and constraint buckets, respectively.

[0029] For the structural relationships in the structural bucket, hierarchical reduction is performed based on the hierarchical relationship between the target elements, and the multi-level structural chain is folded into the decomposition relationship unit of the parent-child structure.

[0030] For the behavioral relationships in the behavioral bucket, based on the temporal connection pattern of the behavioral relationships, the call chain, event chain, and dependency chain are identified, and interaction relationship units are generated;

[0031] For constraints in the constraint bucket, they are merged according to their scope of application, and multiple constraints acting on the same set of elements are merged into a unified constraint unit.

[0032] Based on decomposed relation units, interaction relation units, and constraint relation units, a set of relational semantic units for view configuration data is constructed.

[0033] The process, based on preset framework configuration rules, determines the corresponding project hierarchy in the requirement configuration and generates framework configuration data, including:

[0034] Based on the target methodology type in the requirement configuration, the corresponding methodology framework template is selected from the framework configuration rules, and the candidate hierarchical node set in the methodology framework template is extracted.

[0035] Based on the range of meta-model elements to be covered, perform node filtering and node expansion operations on the candidate hierarchical node set;

[0036] Based on the structural relationships in the normalized relation records, the hierarchical dependencies between metamodel elements are calculated through hierarchical relationships, and the hierarchical dependencies are mapped to the filtered and expanded set of hierarchical nodes to generate a framework hierarchical structure.

[0037] Based on the statistical characteristics of structural, behavioral, and constraint relationships, the framework hierarchy is clustered and grouped to generate framework configuration data. The framework configuration data records the hierarchical node identifiers, node semantic labels, and available view types in a tree structure.

[0038] The node filtering is used to delete hierarchical nodes that do not involve the range of the metamodel elements, and the node expansion is used to generate sub-hierarchical nodes based on the semantic category of the metamodel elements.

[0039] The generated system architecture framework and the corresponding view instances of the system architecture framework include:

[0040] The system architecture framework is constructed based on the framework configuration data, and a corresponding set of view types is configured for each node in the project hierarchy tree.

[0041] Based on the view configuration data and entity relationship data structure, under the combination of each level node and its corresponding view type, the semantic description of the candidate view is determined, wherein the semantic description includes at least the element subset identifier and relationship subset identifier selected from the entity relationship data structure.

[0042] Determine the view semantic partial order relationship based on the semantic description, and construct the view semantic partial order structure on the semantic description of all candidate views;

[0043] In the view semantic partial order structure, a minimum set of generated views that cannot be obtained by combining the semantic descriptions of other candidate views through set union and intersection operations is determined, and the candidate views in the minimum set of generated views are used as base views.

[0044] Based on the base view, a view instance is materialized under the corresponding project level node, and the view instance identifier is attached to the corresponding level node of the system architecture framework to obtain the view instance corresponding to the system architecture framework.

[0045] When a view instance corresponding to a non-base view is required, the method further includes:

[0046] Based on the semantic description of the candidate views corresponding to the non-base views, at least one candidate base view is selected from the view semantic partial order structure.

[0047] Based on the set combination rules in the view configuration data, set operations are performed on the element subsets and relation subsets corresponding to the candidate base view to generate a view instance corresponding to the non-base view.

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

[0049] This application achieves triple decoupling of metamodel semantics, view semantics, and methodological framework, freeing the modeling process from the constraints of fixed templates and tool internal structures, and enabling the free combination, tailoring, and expansion of methodologies. By abstracting the KerML metamodel into a unified entity-relationship data structure, both views and frameworks can be automatically generated based on semantics, thereby ensuring that different methodologies are collaboratively expressed on the same semantic foundation. Attached Figure Description

[0050] 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:

[0051] Figure 1 An exemplary application scenario diagram provided for an embodiment of this application;

[0052] Figure 2 This is a schematic diagram illustrating the internal workings of the modeling tool provided in the embodiments of this application.

[0053] Figure 3 This is a flowchart illustrating the system architecture framework configuration and generation method based on the KerML metamodel provided in the embodiments of this application. Detailed Implementation

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

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

[0056] In this embodiment, the system architecture framework configuration and generation method based on the KerML metamodel proposed in this application is mainly aimed at the architecture design and model management scenarios of complex products and systems, such as aerospace equipment, intelligent connected vehicles, large industrial equipment, UAV / unmanned ship systems, and enterprise-level information systems.

[0057] Understandably, such systems often involve multi-dimensional information such as functional decomposition, physical structure, interface relationships, performance constraints, and operating scenarios. Furthermore, in engineering practice, they generally require adherence to existing methodological frameworks, such as the C4 model, SysML, DoDAF, industry-specific V-models, or enterprise-customized development process methodologies. As system complexity and the number of collaborating entities increase, it becomes increasingly difficult to stably maintain a system architecture framework that conforms to enterprise methodologies while also being easily customizable and extensible, using a single modeling language or architecture tool.

[0058] Those skilled in the art will understand that in traditional practice, engineering teams typically choose a mainstream modeling tool or architecture design platform and use its built-in UML / SysML graphical language and pre-made engineering templates to build the project structure.

[0059] For example, a fixed package structure and a fixed combination of view types can be used to express the relationship between requirements, functions, logical architecture and physical architecture.

[0060] These types of tools often tightly couple metamodel elements, graphical views, and project framework structure:

[0061] Certain types of elements can only appear in certain types of diagrams, and certain types of diagrams can only be attached to specific package nodes. Once the framework structure is determined, it is difficult to refactor it as the methodology is adjusted. For scenarios that need to support multiple methodologies simultaneously (such as conforming to both industry standard frameworks and enterprise internal control processes), the only solution is to copy project templates, stack plugins, or introduce multiple tools to model separately, resulting in data fragmentation, duplicate views, rigid frameworks, and extremely high maintenance costs.

[0062] It is important to emphasize that when enterprises wish to tailor or expand upon the introduced tools and methodologies, the existing technologies often require in-depth secondary development:

[0063] One possibility is modifying the metamodel definition within the tool;

[0064] Another scenario involves rewriting the graphics plugin or project template.

[0065] This approach not only requires highly specialized developers, but also makes previously customized graphical views and frameworks prone to failure once the methodology or organizational structure changes. Methodologies iterate, organizations adjust, and project types change, but the tool's own rigid methodology and hard-coded project framework struggle to evolve in sync, resulting in unusable model assets and difficulties in aligning and comparing different projects.

[0066] This application is not merely concerned with adding a few new diagrams or defining a few new templates, but rather with proposing a semantically reorganized and generated architectural framework to address the series of technical problems caused by the high coupling between the aforementioned metamodel, view, and framework structure.

[0067] In this embodiment, kerML is used as a unified system architecture semantic foundation:

[0068] Various functions, modules, activities, interfaces, performance indicators, and their relationships are first abstracted into entity-relationship data structures independent of specific graphical views. Based on this, target elements and semantic relationships are filtered from the same semantic data according to different methodological perspectives through independent view configuration rules, and then mapped into semantic slots and relational semantic units that can be understood by different view types. At the same time, through independent framework configuration rules, the project hierarchy and the view combinations available for each node are automatically derived based solely on the methodology type, project characteristics, and metamodel coverage, without requiring the pre-locking of a specific tool's package structure or project template.

[0069] Therefore, the system architecture framework configuration and generation method in this embodiment does not rely on a fixed modeling language, a specific set of graphical views, or a predefined engineering framework as a prerequisite. Instead, it is geared towards system engineering scenarios with multiple methodologies, diverse modeling perspectives, and frequently adjusted framework structures. Through triple decoupling of the metamodel, views, and framework structure, the methodology framework can be flexibly configured, generated, and tailored on the same semantic data foundation. For large enterprises, multiple architecture frameworks for different business lines or standard systems can be generated simultaneously on a unified KerML metamodel repository. For small and medium-sized teams, simplified frameworks can be tailored from complex methodologies without modifying the underlying metamodel and tool implementation, reducing unnecessary views and artifacts.

[0070] refer to Figure 1 , Figure 1 This is an exemplary application scenario diagram provided for an embodiment of this application.

[0071] Figure 1 The diagram illustrates three methodologies, including C4 software architecture, SysML modeling, and industry V-models. The scenarios depicted represent the prevalent parallel application of multiple methodologies in current systems engineering practice.

[0072] Understandably, C4 software architecture is typically used to describe the container layering, component organization, and runtime environment relationships of a software system; SysML modeling focuses on characterizing the system's requirements, behavior, structure, and parameter constraints, among other multi-dimensional model semantics; while the industry V model is widely used for the phase division and verification-confirmation logic of the engineering development process, and its methodology emphasizes the layered development from requirements to implementation to verification.

[0073] Those skilled in the art can determine the applicable methodology based on specific business scenarios, corporate standards, or project types, and this application does not impose any limitations on this.

[0074] Figure 1 This illustrates a scenario where complex modeling needs arise when multiple methodologies are deployed simultaneously in the same modeling tool or the same engineering environment.

[0075] In such scenarios, the modeling entity often needs to switch perspectives between different methodologies. It might focus on the division of software containers and components from a C4 perspective, or analyze activity flows, internal connections, and performance constraints from a SysML perspective, or even organize project artifacts in stages according to industry V-processes. As the model content becomes increasingly rich, if modeling tools continue to organize with fixed metamodel structures, pre-defined view types, and rigid project frameworks, there is often a lack of unified semantic support between methodologies. Model components from different perspectives are difficult to share and align, and may even require repetitive modeling through independent templates, independent folder structures, or independent graphical definitions.

[0076] Based on the above challenges, the technical solution proposed in the embodiments of this application enables... Figure 1 In the application scenarios shown, the modeling tool can flexibly apply various methodological perspectives on the same semantic foundation. By dynamically configuring and combining the metamodel, view type, and project framework, it can achieve decoupling between the three, so that the generation of system architecture no longer depends on fixed templates or fixed graphical bindings. Figure 1The schematic diagram illustrates that when multiple methodologies are combined, the technical solution of this application enables the corresponding metamodel semantics, view presentation methods, and project structure organization methods to form an adjustable, replaceable, and customizable relationship within the tool, ultimately generating a system architecture adapted to the target methodology system through configuration-driven generation.

[0077] refer to Figure 2 , Figure 2 A schematic diagram illustrating the internal workings of the modeling tool provided in an embodiment of this application is shown.

[0078] like Figure 2 As shown, the modeling tool distinguishes system architecture-related data and presentation logic into multiple independent semantic layers during operation, enabling meta-model semantics, view presentation, and project framework organization to work together in a loosely coupled manner within the tool.

[0079] Figure 2 This illustrates the semantic-driven structures used by the tool during runtime, including semantic graphs, view templates, and project hierarchy trees. Semantic graphs are used to represent abstracted system entities and their relationships, reflecting the semantic distribution of the model across dimensions such as function, structure, behavior, and interface. View templates provide configurable view representation structures for different modeling methodologies, and their internal semantic slots can be filled with different types of data according to different semantic mapping rules. Project hierarchy trees are used to organize project content, representing the hierarchical division, partitioning logic, and artifact organization methods of the engineering structure under different methodologies.

[0080] Figure 2 The core modules constituting the basic capabilities of the modeling tool are further illustrated, including the metamodel, view types, and project framework. The metamodel describes the types of basic model elements supported by the tool and their semantic attributes, serving as the abstract syntactic foundation for system architecture semantics. View types define the different view categories that the modeling tool can present, such as structural views, behavioral views, or interface views. The project framework describes how the project content is organized, determining the modeling artifacts required for different stages, perspectives, and methodologies within the project.

[0081] Understandably, within the tool itself, Figure 2 The semantic graph, view templates, and project hierarchy tree on the left correspond to the metamodel, view types, and project framework on the right, respectively. However, they are not bound together using the traditional fixed mapping method of modeling tools, but rather their relationships are established in a configuration-driven manner.

[0082] Semantic graphs are instantiated based on meta-models but do not depend on the presentation of specific views;

[0083] View templates organize semantic slots according to the view type definition;

[0084] The project hierarchy tree generates an organizational structure based on the logic of the project framework, but it does not require that the model content be fixedly mapped to a certain view level.

[0085] It is important to note that Figure 2 This means that modeling tools can be configured with view presentation and framework structure on the same semantic foundation (i.e., the KerML metamodel) in ways required by different methodologies or project types, so that the modeling process no longer depends on a fixed modeling template or a fixed graphical model structure.

[0086] Next, with reference to the accompanying drawings, the system architecture framework configuration and generation method based on the KerML metamodel provided in the embodiments of this application will be further described. Figure 3 The methods shown include:

[0087] S1: Obtain system architecture metamodel data described in KerML and requirement configuration for the methodology framework, and abstract the system architecture metamodel data into an entity-relationship data structure;

[0088] In this embodiment, the model content described by KerML can originate from existing engineering artifacts, model repositories, component libraries, or real-time edited content, including semantic elements such as functions, modules, activities, interfaces, and performance metrics. The acquired semantic information is parsed and broken down into sets of elements and relationships. Through classification, normalization, and multi-table association, an entity-relationship data structure with a unified semantic structure is constructed. This unified transformation of semantic content from multiple sources into a searchable and computable entity-relationship format ensures that subsequent view selection and framework derivation unfold based on stable semantic boundaries, without relying on pre-defined understandings of graphical representations or engineering templates.

[0089] Those skilled in the art will understand that KerML is a model description language used to express model semantics, relational structures, and constraint information, capable of recording various types of model content that arise during engineering modeling in a unified semantic form. Specifically, how to obtain architectural meta-model data based on KerML's syntax, features, or expressive structure can be achieved based on the capabilities of existing modeling tools, model repositories, or semantic parsing modules. The corresponding parsing processes, text formats, or compilation methods are all known technologies, and this application does not impose further limitations on them.

[0090] Furthermore, requirement configuration can be understood as an external input description of the target methodology, project type, and semantic coverage. Its sources may include configuration options in tool interfaces, pre-defined information in project templates, structured data from project management platforms, or definitions made by engineers based on actual tasks. The method of obtaining requirement configuration can be flexibly determined; it only needs to provide basic information sufficient to indicate the target methodology framework and semantic scope. This application does not impose further limitations on this.

[0091] It should be noted that the basis of this application is:

[0092] After obtaining the KerML semantic content and requirement configuration, the focus is on how to construct a stable entity relationship data structure through semantic abstraction, and how to decouple the methodological framework, view types, and metamodel semantics on this unified semantic foundation. The specific processes, such as how the KerML files are written, how semantic refinement is done, how engineers pre-plan modules or functions, and how tools import KerML data, are all preliminary work and not within the scope of this application.

[0093] S2: Based on preset view configuration rules, select a target element set from the entity relationship data structure, and generate view configuration data according to the target element set, wherein each view type corresponds to multiple semantic data;

[0094] In this embodiment, the view configuration rules not only include the traditional static correspondence between graph types and metamodel elements, but also flexible mechanisms such as semantic selection conditions, semantic slot mapping patterns, and relationship aggregation strategies. This allows the same view type to present different semantics in different methodological contexts. For example, an activity view can present a behavioral chain or functional decomposition logic; an interface view can display both geometric ports and constraint flows. By performing semantic filtering, relationship aggregation, and slot filling on the entity relationship data structure, the view configuration data constructed in this embodiment does not depend on specific graphical symbols, but rather describes the elements and relationships required by the view in a purely semantic way, making the view representation a configurable construction unit.

[0095] S3: Based on the preset framework configuration rules, determine the corresponding project hierarchy in the requirement configuration and generate framework configuration data, wherein the framework configuration data corresponds to multiple meta-models;

[0096] In this embodiment, the framework configuration rules are not hard-coded package structure templates, but rather a set of inferable hierarchical organizational logic, including the stage structure corresponding to the methodology, the semantic categories of model components, and hierarchical dependencies derived from semantic relationships. By parsing the methodology type, project type, and coverage in the requirement configuration, an adaptive hierarchical structure can be dynamically generated. The framework configuration data is generated from semantic boundaries and relational logic, rather than relying on a set of pre-set templates. Therefore, the project organization can evolve freely with changes in methodology without requiring modification of the internal model semantics.

[0097] S4: Generate the system architecture framework and the view instance corresponding to the system architecture framework based on the entity relationship data structure, view configuration data and framework configuration data;

[0098] In this embodiment, the generation of the architecture framework is not simply a matter of stacking views into a hierarchical structure. Instead, it uses semantic alignment, view composition analysis, and instance generation strategies to select the minimum necessary view set for each level node for instantiation, and dynamically constructs non-base views as needed through semantic composition logic. By establishing a semantic partial order relationship, this embodiment can automatically identify base views that cannot be further simplified, ensuring that the number of view instances and the content presented in the framework remain at a minimum sufficiency. For non-base views, a runtime generation strategy is adopted to avoid generating a large number of redundant views in the early stages of the project.

[0099] Those skilled in the art will understand that the graphical representation of a view instance can be drawn according to the actual implementation of the tool, as long as it can display semantic content based on the view configuration data. This application does not impose any further restrictions.

[0100] Before detailing the specific technical aspects of the steps, this application's embodiments need to reiterate:

[0101] In practical architecture design, different modeling teams often need to handle multiple perspectives simultaneously within the same project cycle, such as functional decomposition, logical behavior, interface connectivity, performance constraints, and project phase division. Although this information originates from the same semantic background, it is usually scattered and stored in different graphical files, framework structures, or methodological templates in traditional modeling methods. As the model content accumulates, the semantic ontology is often implicitly split as the number of views increases, eventually leading to a view-driven semantic situation. That is, the metamodel semantics is no longer the core of modeling, but the way the semantics are presented and its boundaries are determined by the view itself.

[0102] Those skilled in the art will understand that when an engineering model begins to rely on views as the primary organizational unit, the maintenance cost of the model content increases non-linearly over time. Especially in environments with multiple methodologies, the same semantics need to match multiple perspectives, leading to increasing cross-referencing between views, redundant modeling, and structural rigidity. This forces any extension or modification of a methodology to be achieved by modifying fixed templates, expanding internal plugins, or replacing the project structure. This structure-bound semantic expression not only limits the reusability of views but also makes it difficult to add, remove, or restructure semantics without disrupting existing views once the project enters the architectural evolution phase.

[0103] Based on this, the technology proposed in this embodiment does not start from the traditional view generation process, but attempts to change the subordinate relationship between semantics, view, and frame. Specifically, this embodiment adopts a semantic-first modeling organization method, unifying the logical, structural, and behavioral information on which multiple methodologies rely into a computable entity relationship form; then, through view configuration rules independent of the metamodel ontology, a type of view can adapt to multi-semantic scenarios without changing the underlying semantics; finally, the frame configuration rules drive the generation of the project hierarchy, enabling the project content to be reorganized according to differences in methodology.

[0104] It is important to emphasize that the core of this embodiment does not lie in reconstructing the modeling language itself, nor in restricting the user's engineering workflow. Rather, it seeks a decoupling path within the traditional semantically bound view modeling approach, making semantics the sole source of engineering information, the view a configurable expression layer, and the framework a deducible organizational structure. In this way, different methodologies are no longer pieced together through hard-coded view systems or framework templates, but rather achieve flexible reuse through semantic mapping. As the project content gradually expands, the semantic boundaries remain stable, while the view and framework can adapt to changing scenarios in a lighter manner.

[0105] Next, we will further elaborate on the technical content of the entity relationship data structure in this application.

[0106] In one example, the system architecture metamodel data includes functions, modules, activities, interfaces, performance metrics, and relationships expressed in KerML, and the requirement configuration includes the target methodology type, the target project type, and the scope of metamodel elements to be covered.

[0107] In another example, the system architecture metamodel data is abstracted into an entity-relationship data structure, including:

[0108] S1.1: Perform syntax parsing on the system architecture metamodel data expressed in kerML, and extract the metamodel element set and element relation set. Each metamodel element includes a unique identifier, type tag and attribute set, and each element relation includes source element identifier, target element identifier and relation type.

[0109] Specifically, when processing architectural metamodel data expressed in KerML, the first step is to convert the textual or tree-like KerML description back into a computable data structure. KerML descriptions typically contain interwoven element declarations, relation declarations, attribute blocks, constraint statements, and namespace information. If view configuration or framework deduction is performed directly at this level, it is easy to be constrained by syntax and difficult to achieve unified querying and matching.

[0110] In this embodiment, the KerML file is sequentially scanned to identify keywords, identifiers, delimiters, and structural tags, mapping each KerML fragment to its internal syntax nodes. For syntax nodes identified as metamodel elements, the element name, namespace, type label, and attribute fields are extracted, a unique identifier is automatically generated, and this information is recorded in the metamodel element set. For syntax nodes identified as relational statements, the source identifier, target identifier, relational predicate, and associated constraints are extracted to form an element relation set. During the parsing process, duplicate or aliased references are uniformly merged to ensure that different syntaxes point to the same element identifier, preventing semantic splitting in subsequent operations. At this stage, the layout order, indentation structure, and comment information in the syntax tree no longer participate in subsequent operations; only the core fields related to the architectural semantics are retained.

[0111] S1.2: Based on the type marker, divide the metamodel elements in the metamodel element set into semantic categories corresponding to functions, modules, activities, interfaces, and performance indicators, and construct a general element entity table and multiple sub-entity tables corresponding to the semantic categories, wherein the sub-entity tables are associated with the general element entity table through foreign keys;

[0112] Specifically, simply piling all KerML elements into a single collection cannot support subsequent multidimensional queries and view mapping, because different types of elements have different engineering roles and different focuses on attribute fields. If multiple semantic types such as functions, modules, activities, interfaces, and performance metrics are stored in the same structure, it is not conducive to constraint validation, nor is it conducive to selecting target elements by role during the view configuration phase.

[0113] In this embodiment, a general element entity table is first designed for all metamodel elements. This table records public information unrelated to semantic categories, such as unique identifiers, names, source files, creation times, namespaces, and general remarks fields. Subsequently, based on type tags, elements are divided into different semantic categories such as functions, modules, activities, interfaces, and performance metrics, and a corresponding sub-entity table is created for each category. The sub-entity tables only retain attribute fields closely related to the semantic category. For example, the function sub-table records the function decomposition hierarchy and input / output interface references; the module sub-table records physical location, assembly relationships, and resource usage; the activity sub-table records predecessor / successor relationships and trigger conditions; the interface sub-table records signal direction and media type; and the performance metric sub-table records metric values, upper and lower limits, and test conditions. The general element entity table and each sub-entity table are linked via foreign keys. The primary key of each sub-table references the unique identifier in the general table, ensuring that access to any element can first be located through the general table, and then the specific sub-table can be retrieved to refine attributes as needed.

[0114] S1.3: Map the set of element relationships to a relation entity table. In the relation entity table, record structural relationships, behavioral relationships, and constraint relationships by referencing the element identifiers in the general element entity table to obtain normalized relationship records.

[0115] Specifically, relation descriptions in KerML often take various forms, ranging from explicit join statements to implicit structural, behavioral, and attribute constraints expressed through nested structures or constraints. Directly retaining the original relation descriptions hinders relation retrieval, pattern recognition, and path derivation at a unified semantic level.

[0116] In this embodiment, the element relationship set is first classified according to the relationship type. Static connections describing composition, inclusion, and dependency are categorized into structural relationships; time-related connections describing triggering, invocation, sequence, and conditional branching are categorized into behavioral relationships; and value ranges, logical constraints, and requirement bindings are categorized into constraint relationships. When constructing the relation entity table, a unified field layout is designed for each type of relationship, including relationship identifier, relationship type, source element identifier, target element identifier, directionality marker, valid range, and optional weight or priority descriptions. Different syntactic forms in the original KerML description are translated into unified relation records during the mapping process. For example, hierarchical nested structures are decomposed into parent-child structure relation records, directed edges in the behavioral graph are translated into behavioral relation records, and element pairs involved in constraint expressions are extracted into constraint relation records. Through this transformation, relation information originally scattered across various model files is uniformly collected in the relation entity table.

[0117] S1.4: Based on the normalized relation records, the general element entity table, and the sub-entity table, the entity relation data structure is obtained through multi-table association based on unique identifiers;

[0118] Specifically, after constructing the element entity table and relation entity table, the scattered table structure alone is insufficient to support subsequent semantic-based perspective selection and framework generation. It is necessary to further connect the tables at the semantic level to form an integrated entity-relationship data structure oriented towards querying and reasoning. At this stage, the general element entity table, each semantic sub-entity table, and the normalized relation records are no longer used in isolation. Instead, they are logically connected through a shared unique identifier, forming a holistic abstract model that reflects both node attributes and the relationships between nodes.

[0119] In yet another example, the entity relationship data structure obtained through multi-table association based on unique identifiers includes:

[0120] Based on the unique identifier in the general element entity table, a multi-table join is performed on the general element entity table, sub-entity table, and normalized relation records, merging the general attributes of each meta-model element with the sub-attributes of the corresponding semantic category into a unified attribute node;

[0121] Based on the relation type in the normalized relation record, the attribute nodes of the multi-table join are classified and aggregated. For each meta-model element, an outgoing edge set and an incoming edge set centered on the corresponding meta-model element are established, and an adjacency table indexed by a unique identifier is generated.

[0122] Based on the adjacency list, a semantic relationship graph is constructed, with general attribute nodes as graph nodes and normalized relationship records as graph edges. Each graph edge is labeled with its structure, behavior, and constraint relationships, resulting in an entity relationship data structure composed of meta-model element attributes and semantic relationships.

[0123] Specifically, the general element entity table provides a unique semantic anchor for all metamodel elements, and all attributes related to this element are clustered around this identifier. The functional, structural, behavioral, interface, and performance attributes recorded in the sub-entity tables essentially represent semantic expansions of the element from different perspectives. Multi-table joins using unique identifiers integrate the attributes of an element across multiple semantic dimensions into a single attribute node, allowing subsequent semantic relationship analysis to be performed from a unified node perspective, avoiding the need to handle different table structures separately due to semantic category differences. For example, during multi-table joins, element attribute objects can be created based on the unique identifier, weaving general attributes and sub-table attributes into contiguous data blocks, thus forming directly accessible composite attribute nodes in memory. These attribute nodes do not rely on the original KerML representation or graphical symbols, but rather represent a stable intermediate representation oriented towards subsequent semantic derivation.

[0124] In this embodiment, each relationship record can be associated with the attribute node constructed in the previous step based on the source element identifier and the target element identifier, thereby constructing an edge set and an ingress set for each node. Different types of relationships have different analytical requirements in terms of structure. Therefore, grouping relationships into slots according to structural relationships, behavioral relationships, and constraint relationships allows nodes to simultaneously possess multiple semantic perspectives in the adjacency list. For example, structural relationships can be merged according to hierarchical relationships and composition relationships, behavioral relationships can be organized according to trigger paths and event flow, and constraint relationships can be clustered according to scope and constraint strength. During the adjacency list construction process, this embodiment records the relationship type, directionality, additional attributes, and scope for each edge, enabling the adjacency list to not only store connection relationships but also provide condition filtering capabilities for subsequent path lookup, semantic condition filtering, and combined rule execution. The generated adjacency list uses a unique identifier as an index, allowing any node to locate and obtain its relationship set in constant time, thereby achieving efficient traversal and local inference of large-scale semantic data.

[0125] Furthermore, the semantic relationship graph uses attribute nodes as graph nodes and normalized relationship records as graph edges, while labeling each graph edge with structure, behavior, and constraint labels. To maintain the stability of the graph structure, this embodiment performs directionality confirmation, relationship classification marking, and semantic strength annotation on edges during the graph construction phase, enabling different types of edges to be treated differently during graph traversal. For example, when processing behavioral relationships, reachable paths need to be identified based on the temporal characteristics of the edges; when processing structural relationships, parent-child links need to be identified based on the hierarchical structure; and when processing constraint relationships, constraint propagation needs to be performed based on the constraint range. The introduction of the graph structure means that subsequent view generation no longer relies on table scanning, but instead obtains the target element set, relationships, and semantic structure through graph traversal algorithms. This allows view configuration rules and framework configuration rules to be executed based on the semantic network, avoiding strong coupling with the original KerML expression form.

[0126] Next, we will further elaborate on the technical content of the view configuration data in this application.

[0127] It is understood that the view configuration rules in this application are an abstract description of the perspective expression methods under different modeling methodologies. They are used to indicate what semantic content the view should present, what element matching mechanism should be used, and how to express the relationships between elements when a user selects a certain view type. The view configuration rules are not fixed, hard-coded templates, but rather a set of flexibly defined and combinable semantic constraints and mapping strategies used to select a suitable set of elements on a unified semantic relationship graph and generate instantiable view configuration data. How to construct view configuration rules from tool interfaces, methodological specifications, or external configuration files is a matter of engineering implementation and will not be elaborated upon here.

[0128] In one example, the step of selecting a target element set from the entity relationship data structure based on preset view configuration rules, and generating view configuration data based on the target element set, includes:

[0129] S2.1: Based on the semantic selection conditions in the view configuration rules, perform node filtering and edge filtering on the semantic relationship graph in the entity relationship data structure to obtain the target element set and the association relationship between the target elements that are adapted to the semantic selection conditions, wherein the semantic selection conditions are determined according to the range of meta-model elements to be covered;

[0130] Specifically, during the view configuration phase, directly selecting view content on the complete semantic relationship graph leads to problems such as an excessively large semantic scope and overly complex relationship structures. This results in any view generation requiring a global search across the entire graph, increasing computational burden and easily introducing elements irrelevant to the current perspective. Therefore, it is necessary to introduce semantic selection criteria that match the view's purpose, pre-screening elements and relationships at the semantic level, excluding nodes and edges unrelated to the current view from the candidate range from the outset. Semantic selection criteria are directly related to the range of meta-model elements to be covered. For example, when focusing on a functional perspective, functional classes and their related structural relationships should be prioritized; when focusing on a behavioral perspective, activity classes and their behavioral relationships should be prioritized, ensuring that the view generation process is confined to a reasonable semantic subspace from the beginning.

[0131] In this embodiment, the semantic selection conditions consist of several semantic constraint clauses. Each clause may include element type restrictions, semantic label restrictions, relation type restrictions, and local path features. During filtering, firstly, nodes are screened on the semantic relation graph based on element type and semantic label to generate a preliminary candidate node set. Then, using the preliminary candidate nodes as anchor points, relation type filtering is performed on the edges connected to them, retaining only structural, behavioral, or constraint relationships that satisfy the selection conditions. Based on this, the subgraph is further shrunk according to path features, for example, retaining adjacent nodes within a certain depth range or retaining sub-paths formed by specific relation patterns.

[0132] S2.2: According to the mapping mode in the view configuration rules, the element types in the target element set are mapped and matched with the preset view semantic slots, and a corresponding element filling list is generated for each view semantic slot. The mapping mode includes type matching mode, semantic tag matching mode and relational context matching mode.

[0133] Specifically, after filtering the target element set, a key issue remains: how to organize these target elements within the view structure, rather than simply listing them. Different view types often have specific requirements for the roles elements play within the view. For example, in a decomposition view, it's necessary to distinguish between parent and child nodes; in a sequence view, it's necessary to distinguish between participants and messages; and in an interface view, it's necessary to distinguish between ports and connections. If the data is filled solely based on element type, it's difficult to accurately reflect the semantic roles of elements within the view.

[0134] In this embodiment, view semantic slots are predefined by view configuration rules. Each slot has a corresponding role description, a set of allowed element types, required semantic tags, and optional contextual constraints. Mapping modes include three strategies: type matching, semantic tag matching, and relational context matching, which can be used sequentially or in combination. In type matching mode, elements are matched against the allowed type set of the slot, assigning elements that meet the type requirements to specific slots. In semantic tag matching mode, element tags are compared with slot tags, filling slots with elements having similar semantic roles. In relational context matching mode, the upstream and downstream relationships of the target element in the semantic subgraph are examined, such as whether it is at the root node position of the decomposition hierarchy, whether it is the initiating node of the call chain, or whether it connects to multiple interfaces, to determine which view role the element is more suitable for.

[0135] S2.3: Based on the relationships between target elements, the relationships are converted into view-recognizable semantic units through the relationship aggregation strategy in the view configuration rules. The semantic units include decomposed relationship units, interaction relationship units, and constraint relationship units.

[0136] Specifically, after the target element set is determined and slot mapping is completed, element role information alone is insufficient to support view rendering. It is also necessary to organize the relationships between elements into semantic units that the view can understand. Relationships in semantic relationship graphs often have multi-level links, parallel paths, or cross-references. If all the original relationships are directly projected into the view, a large number of redundant connections will be generated, which will not only affect the readability of the view but also make it difficult to reflect the key structures emphasized by the methodology.

[0137] In one example, the step of converting the relationships between target elements into view-recognizable relational semantic units through a relationship aggregation strategy in the view configuration rules includes:

[0138] The relationships in the target element set are initially bucketed according to the relationship type, and structural relationships, behavioral relationships, and constraint relationships are assigned to structural buckets, behavioral buckets, and constraint buckets, respectively.

[0139] For the structural relationships in the structural bucket, hierarchical reduction is performed based on the hierarchical relationship between the target elements, and the multi-level structural chain is folded into the decomposition relationship unit of the parent-child structure.

[0140] For the behavioral relationships in the behavioral bucket, based on the temporal connection pattern of the behavioral relationships, the call chain, event chain, and dependency chain are identified, and interaction relationship units are generated;

[0141] For constraints in the constraint bucket, they are merged according to their scope of application, and multiple constraints acting on the same set of elements are merged into a unified constraint unit.

[0142] Based on decomposed relation units, interaction relation units, and constraint relation units, a set of relational semantic units for view configuration data is constructed.

[0143] S2.4: Generate the corresponding view configuration data based on the element-filled list and relational semantic units;

[0144] In this embodiment, view configuration data is organized as structured records, with each record corresponding to a configuration description of a view instance. The records include: a view type field, indicating the view category to which the current configuration belongs; a slot list, where each slot entry records the slot name, slot role, and the set of bound element identifiers; a relational semantic unit list, where each unit entry records the unit type, participating elements, involved semantic edges, and additional attributes; and may also include meta-information such as the view's associated methodology tags, its project hierarchy node, and priority display level. When generating view configuration data, this embodiment integrates the aforementioned element-filling lists and relational semantic units one by one according to view type, packages them into a complete structure, and then stores it in a configuration data warehouse or in association with framework configuration data storage.

[0145] Next, we will further elaborate on the technical aspects of the framework configuration data in this application.

[0146] It is understood that the framework configuration data in this application is a type of structured semantic record used to describe the hierarchical structure, node types, node semantic labels, and corresponding set of available views that the project architecture should present under methodological semantics. The framework configuration data is not a fixed model template, nor is it a direct mapping of a certain engineering standard. Instead, it is a dynamic hierarchical structure extracted from the intersection of requirement configuration, semantic relationship diagram, and methodological rules, used to guide the mounting and organization of subsequent view instances in the project structure. As for how to generate specific framework configuration data templates based on different organizations' modeling habits, engineering phase division methods, or methodological specifications, this can be achieved through external configuration files, rule bases, or project initialization tools, etc., which will not be elaborated upon here.

[0147] In one example, the process of determining the corresponding project hierarchy in the requirement configuration based on preset framework configuration rules and generating framework configuration data includes:

[0148] Based on the target methodology type in the requirement configuration, the corresponding methodology framework template is selected from the framework configuration rules, and the candidate hierarchical node set in the methodology framework template is extracted.

[0149] Based on the range of metamodel elements to be covered, node filtering and node expansion operations are performed on the candidate hierarchical node set. The node filtering is used to delete hierarchical nodes that do not involve the range of metamodel elements, and the node expansion is used to generate sub-hierarchical nodes based on the semantic category of the metamodel elements.

[0150] Based on the structural relationships in the normalized relation records, the hierarchical dependencies between metamodel elements are calculated through hierarchical relationships, and the hierarchical dependencies are mapped to the filtered and expanded set of hierarchical nodes to generate a framework hierarchical structure.

[0151] Based on the statistical characteristics of structural relationships, behavioral relationships, and constraint relationships, the framework hierarchy is clustered and grouped to generate framework configuration data. The framework configuration data records the hierarchical node identifiers, node semantic labels, and available view types in a tree structure.

[0152] In real-world modeling scenarios, different methodologies often exhibit fundamental differences in how they organize project structures. For example, the V-model focuses on phased progression, C4 emphasizes hierarchical structure, while SysML tends to express engineering content through a blend of behavioral scenarios and structural models. Even when professionals are familiar with multiple methodologies, abstracting them into a unified and interpretable data structure remains challenging because these methodologies implicitly represent different engineering intentions and decomposition logics, rather than simple hierarchical distributions. This means that using only traditional static templates and meta-model matching to generate project structures can easily lead to problems such as failing to cover semantics, forcibly applying templates, or resulting in hierarchical imbalances.

[0153] It is understandable that this embodiment does not directly reuse any pre-set template of any methodology. Instead, it uses the methodology type specified by the requirements configuration as a guide, and uses the template only as a source of candidate hierarchical nodes. Then, through the dual constraints of the semantic scope of the metamodel and the normalized structural relationship, these nodes are screened, expanded and reconstructed to form a hierarchical structure that is truly suitable for the semantics of the project.

[0154] In this embodiment, the construction of the framework hierarchy begins with the candidate hierarchy node set, but does not directly adopt the hierarchical order given by the template. Instead, by analyzing the structural relationships of the meta-model elements in the normalized relation records, the hierarchical distribution, combination methods, and cross-domain dependencies of these elements in the semantic relation graph are identified, enabling candidate nodes to map to actual semantic content. For example, in structural relationships, when a certain type of element presents a tree-like decomposition structure, multiple child nodes are automatically generated at that level to carry the corresponding semantic subtree; when cross-level or cross-semantic category structural dependencies are found, bridging nodes are automatically created in the framework structure to accommodate these cross-domain relationships, avoiding semantic breaks in the framework hierarchy. This hierarchical derivation is not simply moving the semantic structure into the framework structure, but rather reorganizing the semantic structure based on the methodological structural intent, so that the framework can both reflect the methodological engineering model and retain its ability to characterize actual semantics. For example, when a component layer exists in the methodology template, but the composition relationship between modules in the actual semantics is more granular, this layer will automatically expand into multiple sub-layers, so that the semantics and methodology are naturally aligned.

[0155] Furthermore, after constructing the initial framework hierarchy, this embodiment does not immediately generate the final structure. Instead, it performs statistical analysis on structural, behavioral, and constraint relationships, clustering and grouping hierarchical nodes based on relationship density, semantic coupling, and engineering relevance. For example, if there are numerous bidirectional dependencies or dense combinations among a certain type of structural nodes, they can be clustered into subgroups at the same level to reduce the fragmentation of the framework hierarchy; if certain activity nodes form high-frequency paths in the behavioral chain, they will be automatically identified as behavioral fragments and then grouped into individual framework nodes; if certain constraint relationships span multiple semantic levels, constraint layers or horizontal semantic layers can be automatically generated for them in the framework structure to avoid redundancy of constraint information across multiple nodes.

[0156] Next, we will further elaborate on the technical content of the system architecture framework of the method in this application.

[0157] Understandably, the semantic structure of a project, the semantic structure of a view, and the methodological structure all show a significant growth trend when the project is large in scale. This is especially true in engineering-level projects, where the metamodel semantic graph often contains a large number of elements and cross-level relationships, the methodological framework may contain multiple layers of nodes, and view configuration rules can generate multiple semantic perspectives. If all theoretical combinations of framework nodes and view types are expanded one by one during the instance generation phase, it will inevitably lead to a rapid expansion of the number of views, accompanied by a large amount of semantic repetition and view redundancy, thus causing browsing burden and performance degradation in actual use.

[0158] In this embodiment, the generation of the system architecture framework is not a simple configuration-driven full expansion, but rather a comprehensive analysis of semantic differences, hierarchical structure and relational structure. View instances are filtered, merged and generated on demand, so that the final generated architecture framework maintains a controllable scale while fully covering the project semantics.

[0159] In one example, the generation of the system architecture framework and the corresponding view instance of the system architecture framework includes:

[0160] S4.1: Construct a project hierarchy tree for the system architecture framework based on the framework configuration data, and configure a corresponding set of view types for each level node in the project hierarchy tree;

[0161] Specifically, constructing a project hierarchy tree and configuring view type sets for each level node aims to establish a stable framework between the methodological and semantic structures. This ensures that subsequent view instances are no longer directly attached to the original file structure, but rather to a deducible and adjustable hierarchical organization. The project hierarchy tree reflects the decomposition of project content from a methodological perspective, rather than the package directory structure within a particular tool. Therefore, its construction requires consideration of factors such as the methodological phase division, semantic category division, and project collaboration boundaries, ensuring that each level node matches specific semantic scope and perspective requirements.

[0162] In this embodiment, the construction of the project hierarchy tree is directly based on the framework configuration data. The framework configuration data already contains information such as node identifiers, node semantic tags, and parent-child relationships. By traversing these records, a tree structure with a root node, several intermediate nodes, and leaf nodes can be reconstructed. During the construction process, a unique node identifier is assigned to each node, and its position in the tree is determined based on its semantic tags and corresponding methodological roles. Subsequently, based on the available view type fields obtained through pre-analysis in the framework configuration data, the corresponding set of view types is written into the configuration items of that node. Thus, each node not only has a semantic identity but also a set of agreed-upon view capabilities; for example, one node can host structural views and interface views, while another node can host behavioral views and performance views.

[0163] S4.2: Based on the view configuration data and entity relationship data structure, determine the semantic description of the candidate view under the combination of each level node and its corresponding view type, wherein the semantic description includes at least the element subset identifier and relationship subset identifier selected from the entity relationship data structure.

[0164] Specifically, after the project hierarchy tree and view type set are determined, a semantic description of the corresponding view needs to be provided for each combination of hierarchy nodes and view types to clarify the specific content scope that the combination refers to in the semantic relationship graph. This semantic description is not the final graphical view, but a set of element subset identifiers and relation subset identifiers extracted from the entity relationship data structure. Without this step, view instances will inevitably revert to a template-generated state, becoming disconnected from the freshness of the underlying semantics, resulting in an ambiguous mapping relationship between hierarchy nodes and views.

[0165] In this embodiment, within each hierarchical node, semantic selection conditions and semantic slot information for the corresponding view type are read from the view configuration data based on the node's semantic label, coverage, and available view types. Then, a filtering operation is performed on the semantic relationship graph represented by the entity relationship data structure. First, based on the node's semantic label, all elements in the semantic relationship graph are marked as belonging to or not belonging to the node's semantic region. For example, if a node represents the "logical architecture layer," only elements related to logical modules and logical interfaces are retained. Then, based on the view type in the view configuration data, the corresponding semantic selection conditions are overlaid onto the node's semantic region to further filter out the set of elements that meet the view requirements. After obtaining the element subset, relevant relationship records are extracted from the entity relationship data structure based on the structural, behavioral, and constraint relationships between these elements to form a relationship subset matching the element subset.

[0166] S4.3: Determine the view semantic partial order relationship based on the semantic description, and construct the view semantic partial order structure on the semantic descriptions of all candidate views;

[0167] Specifically, once each level of node and view type combination has a clear semantic description, the next key issue is how to establish a comparable semantic relationship among these candidate views to identify which views are semantically broader or narrower and whether an inclusion relationship exists. This embodiment takes a set theory perspective, treating the semantic descriptions of candidate views as ordered pairs of element subsets and relation subsets, and establishes a partial order relationship among all candidate views based on set inclusion relations:

[0168] When both the element subset and relation subset of a view are contained in the corresponding subset of another view, the former is considered semantically weaker than or contained in the latter.

[0169] In this embodiment, each candidate view is assigned a semantic description ID, which points to the corresponding element set and relation set. Then, by traversing the candidate view pairs, the inclusion relationships between the element subsets and relation subsets of any two views are compared. If the element set of view A completely contains the element set of view B, and the relation set of view A completely contains the relation set of view B, then a partial order relation of A≥B is recorded in the view semantic partial order structure. To improve efficiency, the element set and relation set can be pre-sorted or a hash index can be created to quickly determine inclusion and equality.

[0170] S4.4: In the view semantic partial order structure, determine the minimum generated view set that cannot be obtained by combining the semantic descriptions of other candidate views through set union and intersection operations, and use the candidate views in the minimum generated view set as the base view;

[0171] Specifically, after the partial order structure of view semantics is constructed, if all candidate views are still instantiated one by one, the problem of view number inflation will still occur. The partial order structure itself provides a natural compression method. By analyzing the partial order relationship, we can identify those views that can be semantically obtained by combining other views through set union or intersection operations, thus retaining only the essential set of views and treating this set of views as the minimum generating view set for subsequent instantiation.

[0172] In this embodiment, the process of determining the minimum generating view set can be understood as performing a base set search on the partial order structure. Specifically, for each view node in the partial order structure, the probability that it can be obtained by combining other views is calculated, for example, by checking:

[0173] If the set of elements of a view C is equal to the union or intersection of the set of elements of two or more views A and B, and its set of relations can also be obtained from the corresponding set of relations through union, intersection, or restricted subset operations, then view C can be marked as a composable view and does not need to be materialized as a base view. Conversely, if the set of elements and the set of relations of a view cannot be obtained from set operations of other views, then it is marked as a base view.

[0174] S4.5: Based on the base view, materialize and generate a view instance under the corresponding project level node, and attach the view instance identifier to the corresponding level node of the system architecture framework to obtain the view instance corresponding to the system architecture framework.

[0175] In yet another example, when a view instance corresponding to a non-base view is required, the method further includes:

[0176] Based on the semantic description of the candidate views corresponding to the non-base views, at least one candidate base view is selected from the view semantic partial order structure.

[0177] Based on the set combination rules in the view configuration data, set operations are performed on the element subsets and relation subsets corresponding to the candidate base view to generate a view instance corresponding to the non-base view.

[0178] 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 system architecture framework based on the KerML metamodel, characterized in that, The method includes: Obtain system architecture metamodel data described in KerML and requirement configurations for the methodology framework, and abstract the system architecture metamodel data into an entity-relationship data structure; Based on preset view configuration rules, a target element set is selected from the entity relationship data structure, and view configuration data is generated according to the target element set, wherein each view type corresponds to multiple semantic data. Based on the preset framework configuration rules, the corresponding project hierarchy in the requirement configuration is determined, and framework configuration data is generated, wherein the framework configuration data corresponds to multiple meta-models. Based on the entity relationship data structure, view configuration data, and framework configuration data, a system architecture framework and corresponding view instances are generated.

2. The system architecture framework configuration and generation method based on the KerML metamodel according to claim 1, characterized in that, The system architecture metamodel data includes functions, modules, activities, interfaces, performance metrics, and relationships expressed in KerML. The requirement configuration includes the target methodology type, the target project type, and the scope of metamodel elements to be covered.

3. The system architecture framework configuration and generation method based on the KerML metamodel according to claim 2, characterized in that, The system architecture metamodel data is abstracted into an entity-relationship data structure, including: Syntax parsing is performed on the system architecture metamodel data expressed in kerML to extract the metamodel element set and the element relation set. Each metamodel element includes a unique identifier, a type tag and an attribute set, and each element relation includes a source element identifier, a target element identifier and a relation type. Based on the type marker, the metamodel elements in the metamodel element set are divided into semantic categories corresponding to functions, modules, activities, interfaces, and performance indicators, and a general element entity table and multiple sub-entity tables corresponding to the semantic categories are constructed, wherein the sub-entity tables are associated with the general element entity table through foreign keys. The set of element relationships is mapped to a relation entity table. In the relation entity table, structural relationships, behavioral relationships, and constraint relationships are recorded by referencing the element identifiers in the general element entity table, thus obtaining a normalized relationship record. Based on the normalized relation records, the general element entity table, and the sub-entity table, the entity relation data structure is obtained through multi-table association based on unique identifiers.

4. The system architecture framework configuration and generation method based on the KerML metamodel according to claim 3, characterized in that, The entity relationship data structure obtained through multi-table association based on unique identifiers includes: Based on the unique identifier in the general element entity table, a multi-table join is performed on the general element entity table, sub-entity table, and normalized relation records, merging the general attributes of each meta-model element with the sub-attributes of the corresponding semantic category into a unified attribute node; Based on the relation type in the normalized relation record, the attribute nodes of the multi-table join are classified and aggregated. For each meta-model element, an outgoing edge set and an incoming edge set centered on the corresponding meta-model element are established, and an adjacency table indexed by a unique identifier is generated. Based on the adjacency list, a semantic relationship graph is constructed, with general attribute nodes as graph nodes and normalized relationship records as graph edges. Each graph edge is labeled with its structure, behavior, and constraint relationships, resulting in an entity relationship data structure composed of meta-model element attributes and semantic relationships.

5. The system architecture framework configuration and generation method based on the KerML metamodel according to claim 1, characterized in that, The process of selecting a target element set from the entity relationship data structure based on preset view configuration rules and generating view configuration data according to the target element set includes: Based on the semantic selection conditions in the view configuration rules, node filtering and edge filtering are performed on the semantic relationship graph in the entity relationship data structure to obtain the target element set and the association relationship between the target elements that are adapted to the semantic selection conditions. The semantic selection conditions are determined according to the range of meta-model elements to be covered. According to the mapping mode in the view configuration rules, the element types in the target element set are mapped and matched with the preset view semantic slots, and a corresponding element filling list is generated for each view semantic slot. The mapping mode includes type matching mode, semantic tag matching mode and relational context matching mode. Based on the relationships between target elements, the relationships are converted into view-recognizable relational semantic units through the relationship aggregation strategy in the view configuration rules. These relational semantic units include decomposed relational units, interaction relational units, and constraint relational units. Generate corresponding view configuration data based on the element population list and relational semantic units.

6. The system architecture framework configuration and generation method based on the KerML metamodel according to claim 5, characterized in that, The step of converting the relationships between target elements into view-recognizable relational semantic units through the relationship aggregation strategy in the view configuration rules includes: The relationships in the target element set are initially bucketed according to the relationship type, and structural relationships, behavioral relationships, and constraint relationships are assigned to structural buckets, behavioral buckets, and constraint buckets, respectively. For the structural relationships in the structural bucket, hierarchical reduction is performed based on the hierarchical relationship between the target elements, and the multi-level structural chain is folded into the decomposition relationship unit of the parent-child structure. For the behavioral relationships in the behavioral bucket, based on the temporal connection pattern of the behavioral relationships, the call chain, event chain, and dependency chain are identified, and interaction relationship units are generated; For constraints in the constraint bucket, they are merged according to their scope of application, and multiple constraints acting on the same set of elements are merged into a unified constraint unit. Based on decomposed relation units, interaction relation units, and constraint relation units, a set of relational semantic units for view configuration data is constructed.

7. The system architecture framework configuration and generation method based on the KerML metamodel according to claim 1, characterized in that, The process, based on preset framework configuration rules, determines the corresponding project hierarchy in the requirement configuration and generates framework configuration data, including: Based on the target methodology type in the requirement configuration, the corresponding methodology framework template is selected from the framework configuration rules, and the candidate hierarchical node set in the methodology framework template is extracted. Based on the range of meta-model elements to be covered, perform node filtering and node expansion operations on the candidate hierarchical node set; Based on the structural relationships in the normalized relation records, the hierarchical dependencies between metamodel elements are calculated through hierarchical relationships, and the hierarchical dependencies are mapped to the filtered and expanded set of hierarchical nodes to generate a framework hierarchical structure. Based on the statistical characteristics of structural, behavioral, and constraint relationships, the framework hierarchy is clustered and grouped to generate framework configuration data. The framework configuration data records the hierarchical node identifiers, node semantic labels, and available view types in a tree structure.

8. The system architecture framework configuration and generation method based on the KerML metamodel according to claim 7, characterized in that, The node filtering is used to delete hierarchical nodes that do not involve the range of the metamodel elements, and the node expansion is used to generate sub-hierarchical nodes based on the semantic category of the metamodel elements.

9. The system architecture framework configuration and generation method based on the KerML metamodel according to claim 1, characterized in that, The generated system architecture framework and the corresponding view instances of the system architecture framework include: The system architecture framework is constructed based on the framework configuration data, and a corresponding set of view types is configured for each node in the project hierarchy tree. Based on the view configuration data and entity relationship data structure, under the combination of each level node and its corresponding view type, the semantic description of the candidate view is determined, wherein the semantic description includes at least the element subset identifier and relationship subset identifier selected from the entity relationship data structure. Determine the view semantic partial order relationship based on the semantic description, and construct the view semantic partial order structure on the semantic description of all candidate views; In the view semantic partial order structure, a minimum set of generated views that cannot be obtained by combining the semantic descriptions of other candidate views through set union and intersection operations is determined, and the candidate views in the minimum set of generated views are used as base views. Based on the base view, a view instance is materialized under the corresponding project level node, and the view instance identifier is attached to the corresponding level node of the system architecture framework to obtain the view instance corresponding to the system architecture framework.

10. The system architecture framework configuration and generation method based on the KerML metamodel according to claim 9, characterized in that, When a view instance corresponding to a non-base view is required, the method further includes: Based on the semantic description of the candidate views corresponding to the non-base views, at least one candidate base view is selected from the view semantic partial order structure. Based on the set combination rules in the view configuration data, set operations are performed on the element subsets and relation subsets corresponding to the candidate base view to generate a view instance corresponding to the non-base view.

Images