Enterprise-level architecture modeling and layer-by-layer decomposition method based on unified meta-model

Abstract

The invention discloses an enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model, which comprises the following steps: constructing the unified meta-model covering business architecture, data architecture, application architecture, technical architecture and security architecture domains, including defining core element types and cross-domain association relationship types of each architecture domain; according to the unified meta-model, enterprise-level overall architecture modeling is carried out, and an enterprise-level architecture asset library including multi-architecture-domain standard assets and dependency relationships thereof is generated; and step-by-step architecture decomposition design is carried out on a project to be implemented based on the unified meta-model and the enterprise-level architecture asset library, and a project-level architecture blueprint aligned with the overall architecture, a refined project demand specification and a landing technology design scheme are sequentially output. Through a unified meta-model and a layer-by-layer decomposition tracing mechanism, the problem of disjunction of semantic segmentation and strategic execution in cross-domain architecture modeling is solved, and collaboration, alignment and controllability of cross-domain architecture design are achieved.

Description

Technical Field

[0001] This invention relates to the field of turbine air supply, and more specifically to an enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model. Background Technology

[0002] In enterprise digital transformation, especially in the research and development of complex systems such as aerospace and finance, enterprise architecture design and modeling are key links in guiding the implementation of business strategies and the construction of information systems. Describing the elements and relationships of various fields such as business, data, applications and technology through modeling has become an important practice to improve the standardization and visualization of R&D management.

[0003] However, existing practices based on general architecture modeling tools have significant limitations. First, different architecture domains often use their own independent model elements and description methods, lacking a set of commonly recognized meta-languages. This results in the semantics between business processes described by business personnel, data entities defined by data personnel, and system components designed by application personnel being unable to be automatically mapped and mutually recognized. Cross-domain models are essentially isolated islands that are difficult to directly present the entire logical relationship from business requirements to technical implementation.

[0004] Secondly, there is a lack of effective transmission and constraint mechanisms between the enterprise-level overall architecture and the specific project-level system architecture. The strategic blueprint depicted by the overall architecture is often reinterpreted or deviated from during the specific project initiation, requirements analysis and design stages, resulting in a distortion between the actual construction results and the top-level planning intentions. Existing methods are difficult to decompose and refine the design layer by layer based on the same set of authoritative architectural assets at each stage of the project, and it is also impossible to trace back and verify the compliance of the project design results. The continuity between strategy and execution is not well guaranteed.

[0005] Furthermore, the complex cross-domain dependencies between architectural elements are often hidden. For example, a change in a business process can affect which application functions, data entities, and technical components. These impact chains rely on manual experience and scattered documentation for sorting out, which is inefficient and prone to omissions. Due to the lack of explicit and structured storage and analysis capabilities for dependencies, it is difficult to conduct comprehensive and accurate impact analysis when making architectural changes, technology upgrades, or risk assessments, which poses potential risks to system evolution and stability.

[0006] Therefore, how to design an enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model to achieve unified architecture semantics, alignment of the design process, and controllable impact of changes is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] In view of this, the present invention provides an enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model, which aims to solve the problems of inconsistent semantics of models in different domains, missing associations, disconnect between overall planning and project implementation, and difficulty in tracing the impact of changes in traditional architecture modeling. By constructing a unified meta-model and asset library, a through-process design and verification process from enterprise strategy to project implementation is established to achieve collaboration, alignment and controllability of cross-domain architecture design.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: An enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model includes the following steps: S1. Construct a unified meta-model covering business architecture, data architecture, application architecture, technical architecture, and security architecture domains, including defining the core element types and cross-domain relationship types for each architecture domain; S2. Based on the unified meta-model, perform enterprise-level overall architecture modeling to generate an enterprise-level architecture asset library that includes standard assets of multiple architecture domains and their dependencies. S3. Based on the unified meta-model and enterprise-level architecture asset library, perform hierarchical architecture decomposition design on the project to be implemented, and sequentially produce project-level architecture blueprints, detailed project requirement specifications, and implementation technology design schemes that are aligned with the overall architecture.

[0009] Preferably, in S1, the core element types include: The business architecture domain includes business domains, business components, business processes, business objects, business rules, and business roles. The data architecture domain includes subject areas, enterprise-level logical data entities, system-level logical data entities, and system-level physical data entities. The application architecture domain includes application systems, application components, application functions, and application interfaces. Technical services, logical technical components, devices, and nodes in the technical architecture domain; Security services and security capability components in the security architecture domain.

[0010] Preferably, in S1, the cross-domain relationship types include: implementation relationship, usage relationship, association relationship, constraint relationship and deployment relationship, which are used to explicitly describe the logical connections and dependencies between elements of different architectural domains.

[0011] Preferably, S2 includes: Based on the enterprise's strategic planning and business operation model, a business architecture is constructed according to a unified meta-model, defining business domains, business components, business processes, and business objects; Taking the business architecture as input, construct the data architecture based on the unified metamodel, and define subject areas, enterprise-level logical data entities and their associations with business objects; Taking business architecture and data architecture as input, construct application architecture and technical architecture based on unified metamodel, define application systems, application components, technical services and logical technical components, and establish the usage relationship between application components and logical technical components; Integrate business, data, application, technology, and security architecture assets, and build and store the dependencies between elements based on cross-domain relationship types to generate an enterprise-level architecture asset library. Preferably, the dependencies between the elements include: The implementation relationships between business processes and application components, the association relationships between business objects and enterprise-level logical data entities, and the usage relationships between application components and the logical technology components they depend on.

[0012] Preferably, in step S3, the hierarchical architectural decomposition design of the project to be implemented includes: project initiation stage design, project requirements analysis stage design, and project detailed design stage design.

[0013] Preferably, the project initiation phase design includes: Filter business components, business processes, business objects, application components, and technical services that are relevant to the project objectives from the enterprise-level architecture asset library; Based on the unified meta-model, the business processes, system-level logical data entities, software modules and technology selections within the project scope are initially defined, and their traceability association with enterprise-level standard assets is established to generate a project-level architecture blueprint.

[0014] Preferably, the project requirements analysis phase design uses the project-level architecture blueprint as input, including: Break down business processes into user tasks and activities, and define business rules and events; The system-level logical data entities are refined into system-level logical data elements, and entity relationships are defined; The software modules are broken down into software functions, and the software services and interfaces are defined in detail. The output includes a detailed project requirements specification that includes structured business requirements, functional requirements, and non-functional requirements.

[0015] Preferably, the detailed design phase of the project takes the refined project requirements specifications as input, including: Refine the business process model based on the BPMN specification; Transform system-level logical data entities and elements into system-level physical data entities and elements to generate a physical data model; Transform software functionalities into detailed class designs and interface specifications; Determine the specific models, configurations, and deployment topology of the equipment and software, and generate a practical technical design solution.

[0016] Preferably, model consistency verification is also included: After any decomposition design phase is completed, calculate the architectural consistency score S between the current project-level architecture model and the enterprise-level architecture asset library:

[0017] in, This indicates the number of elements in the project model that match the enterprise-level standard model. This represents the total number of elements in the project model; This indicates the number of relationships in the project model that conform to enterprise-level cross-domain association rules. This represents the total number of relationships in the project model; This represents the evaluation value of the project model's compliance with enterprise-level constraint rules; These are configurable weighting coefficients; When S falls below a preset threshold, an architecture deviation alarm is generated and a correction is prompted.

[0018] As can be seen from the above technical solution, compared with the prior art, the technical solution of the present invention has the following beneficial effects: (1) This method constructs a unified meta-model covering business, data, application, technology and security domains, clearly defines the core element types and cross-domain relationship types of each domain, provides a common language foundation for multi-domain architecture design, enables business requirements, application functions, data entities and technical components to be associated and traced under the same logical framework, and promotes cross-team and cross-stage collaborative design and communication efficiency.

[0019] (2) This method establishes a layer-by-layer decomposition and alignment mechanism from enterprise-level overall architecture modeling to project-level detailed design. The enterprise-level architecture asset library serves as a unified design benchmark and constraint source. In each stage of project initiation, requirements analysis, and detailed design, it guides and constrains the architecture design of specific projects through steps such as asset screening, instantiation, refinement, and transformation. This ensures that the construction direction of specific projects is consistent with the enterprise's overall architecture blueprint and effectively reduces the risk of planning and implementation being out of sync.

[0020] (3) By standardizing and modeling the storage and management of enterprise-level architecture assets and explicitly recording various dependencies between elements, a reusable architecture asset library is formed. During project design, existing assets can be directly referenced or adapted, improving design efficiency and standardization. At the same time, based on explicit dependencies, the chain effects that may be caused by changes in specific architecture elements can be analyzed more systematically, providing a reliable basis for architecture evolution decisions and risk assessment. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0022] Figure 1 The flowchart illustrates an enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model, as provided in this embodiment of the invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] like Figure 1 As shown, this embodiment provides an enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model, including the following steps: S1. Construct a unified meta-model covering business architecture, data architecture, application architecture, technical architecture, and security architecture domains, including defining the core element types and cross-domain relationship types for each architecture domain; S2. Based on the unified meta-model, perform enterprise-level overall architecture modeling to generate an enterprise-level architecture asset library that includes standard assets of multiple architecture domains and their dependencies. S3. Based on the unified meta-model and enterprise-level architecture asset library, perform hierarchical architecture decomposition design on the project to be implemented, and sequentially produce project-level architecture blueprints, detailed project requirement specifications, and implementation technology design schemes that are aligned with the overall architecture.

[0025] This method constructs a unified meta-model covering multiple architectural domains, clearly defining the core elements and cross-domain relationships of each domain, providing a common semantic foundation and constraint framework for enterprise-level overall architecture modeling and project-level design. By establishing a layer-by-layer decomposition and traceability mechanism from the enterprise-level architecture asset library to project initiation, requirements analysis, and detailed design, it ensures the consistency between specific project implementation and the enterprise strategic blueprint. Furthermore, by leveraging explicit dependencies, it enhances the reusability of architectural assets and the ability to analyze the impact of changes, thereby achieving collaboration, alignment, and controllability in cross-domain architecture design.

[0026] The following provides a further detailed explanation of each step in the above method and their interrelationships; In this embodiment, S1, a unified meta-model is constructed covering business architecture, data architecture, application architecture, technical architecture, and security architecture domains, including defining the core element types and cross-domain relationship types for each architecture domain; The core element types include: The business architecture domain includes business domains, business components, business processes, business objects, business rules, and business roles. The data architecture domain includes subject areas, enterprise-level logical data entities, system-level logical data entities, and system-level physical data entities. The application architecture domain includes application systems, application components, application functions, and application interfaces. Technical services, logical technical components, devices, and nodes in the technical architecture domain; Security services and security capability components in the security architecture domain.

[0027] The core element types of each architectural domain are organized hierarchically in the unified metamodel and follow semantic mapping rules. For example, business components in the business architecture can be mapped to application systems in the application architecture, and enterprise-level logical data entities in the data architecture can be associated with business objects in the business architecture. In the modeling tool, these element types exist in the form of extensible metaclasses, which support users to instantiate them based on the actual enterprise. In addition, each element type comes with an attribute definition template. For example, business process elements need to include attributes such as execution frequency, participating roles, and business rules, thereby ensuring the consistency and reusability of modeling.

[0028] Furthermore, cross-domain relationship types include: implementation relationship, usage relationship, association relationship, constraint relationship, and deployment relationship, which are used to explicitly describe the logical connections and dependencies between elements of different architectural domains; Cross-domain relationship types are used to explicitly describe the logical connections between elements. For example, a business process can be connected to an application component through a relationship, indicating that the process is supported by a certain application component. A business object can be connected to an enterprise-level logical data entity through a relationship, reflecting the correspondence between business concepts and data concepts. In the tool, these relationship types can be configured as directed edges and support attribute expansion. Through the relationship network, full-link impact analysis can be achieved. For example, when a certain technical component is upgraded, it can be traced back to the affected application functions and business processes.

[0029] In this embodiment S2, based on the unified meta-model, enterprise-level overall architecture modeling is performed to generate an enterprise-level architecture asset library including standard assets of multiple architecture domains and their dependencies; including: Based on the enterprise's strategic planning and business operation model, a business architecture is constructed according to a unified meta-model, defining business domains, business components, business processes, and business objects; Taking the business architecture as input, construct the data architecture based on the unified metamodel, and define subject areas, enterprise-level logical data entities and their associations with business objects; Taking business architecture and data architecture as input, construct application architecture and technical architecture based on unified metamodel, define application systems, application components, technical services and logical technical components, and establish the usage relationship between application components and logical technical components; Integrate business, data, application, technology, and security architecture assets, and build and store the dependencies between elements based on cross-domain relationship types to generate an enterprise-level architecture asset library. The overall architecture modeling follows a layered and progressive principle: First, a business architecture is built based on the enterprise strategy, defining business domains and top-level processes; then, using the business architecture as input, a data architecture is built, identifying key data entities; next, combining the business and data architectures, application systems and technical components are designed; during this process, cross-domain relationships are established and stored in real time. For example, business processes in the business architecture are linked to application components in the application architecture through relationships, and application components are linked to logical technical components in the technical architecture through relationships; all assets and their relationships are persisted in the architecture asset repository, supporting querying and reuse.

[0030] The dependencies between elements include: The implementation relationships between business processes and application components, the association relationships between business objects and enterprise-level logical data entities, and the usage relationships between application components and the logical technology components they depend on.

[0031] Dependencies between elements include not only structural connections, but also semantic constraints and behavioral dependencies. For example, the implementation relationship between business processes and application components may include service level agreement constraints; the association between business objects and enterprise-level logical data entities may include data lineage descriptions. These dependencies are fully recorded through relationship attributes during modeling and form a directed graph structure in the architecture asset library, supporting dependency path retrieval and impact scope analysis.

[0032] In this embodiment S3, based on the unified meta-model and enterprise-level architecture asset library, the project to be implemented is designed by hierarchical architecture decomposition, and project-level architecture blueprints, detailed project requirement specifications and implementation technology design schemes that are aligned with the overall architecture are generated in sequence.

[0033] The hierarchical architectural decomposition design of the project to be implemented includes the following stages: project initiation design, project requirements analysis design, and project detailed design design.

[0034] Furthermore, the project initiation phase design includes: Filter business components, business processes, business objects, application components, and technical services that are relevant to the project objectives from the enterprise-level architecture asset library; Based on the unified meta-model, the business processes, system-level logical data entities, software modules and technology selections within the project scope are initially defined, and their traceability association with enterprise-level standard assets is established to generate a project-level architecture blueprint.

[0035] During the project initiation phase, when selecting relevant assets from the enterprise-level architecture asset library, an architecture matching formula can be used to assist in decision-making:

[0036] in, Indicates the degree of architectural matching. Indicates candidate elements for the project. Represents enterprise-level standard elements. ) is the similarity calculation function. The weight coefficients for each dimension are denoted by n, which represents the total number of dimensions. This formula is used to evaluate the quality of the screening results and ensure that the initial project design is highly consistent with the enterprise architecture.

[0037] Furthermore, the project requirements analysis phase design uses the aforementioned project-level architecture blueprint as input, including: Break down business processes into user tasks and activities, and define business rules and events; The system-level logical data entities are refined into system-level logical data elements, and entity relationships are defined; The software modules are broken down into software functions, and the software services and interfaces are defined in detail. The output includes a detailed project requirements specification that includes structured business requirements, functional requirements, and non-functional requirements.

[0038] During the requirements analysis phase, when business processes are broken down into user tasks, tasks can be decomposed based on activity complexity and execution roles, and associated with the business rule base; when data entities are broken down into data elements, enterprise data standards must be followed, and an entity relationship diagram must be established; during the function refinement process, each software function must be mapped to at least one user task, and its input, processing logic, and output must be clearly defined, while non-functional requirements are associated with corresponding technical components or security services in the form of constraints.

[0039] Furthermore, the detailed design phase of the project takes the aforementioned refined project requirements specifications as input, including: Refine the business process model based on the BPMN specification; Transform system-level logical data entities and elements into system-level physical data entities and elements to generate a physical data model; Transform software functionalities into detailed class designs and interface specifications; Determine the specific models, configurations, and deployment topology of the equipment and software, and generate a practical technical design solution.

[0040] The detailed design phase transforms the logical model into a physically executable solution. For example, the business process model is refined into an executable business process diagram according to the BPMN 2.0 specification; the logical data model is transformed into a physical database table structure and DDL scripts are generated; software functions are transformed into class diagrams and sequence diagrams, clearly defining method signatures and calling logic. The technical deployment plan needs to clearly define node configurations, network topology, and security policies, and output a deployment checklist and configuration manual.

[0041] Furthermore, the method also includes model consistency verification: After any decomposition design phase is completed, calculate the architectural consistency score S between the current project-level architecture model and the enterprise-level architecture asset library:

[0042] in, This indicates the number of elements in the project model that match the enterprise-level standard model. This represents the total number of elements in the project model; This indicates the number of relationships in the project model that conform to enterprise-level cross-domain association rules. This represents the total number of relationships in the project model; This represents the evaluation value of the project model's compliance with enterprise-level constraint rules; These are configurable weighting coefficients; When S falls below a preset threshold, an architecture deviation alarm is generated and a correction is prompted.

[0043] We continuously monitor the deviation of project design from enterprise standards using a quantified architectural consistency score S. The score S is calculated by weighting three dimensions: element standardization rate. Relationship compliance rate And the constraint compliance degree C, by configuring different weight coefficients. It can adjust the focus of verification according to different project types or stages. When the score is lower than the preset threshold, it automatically generates a deviation report to guide designers to make corrections, thereby proactively ensuring architecture alignment during the process.

[0044] The following section uses the specific application scenario of digital R&D for aerospace projects to illustrate the detailed implementation process of the enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model in this embodiment: In the R&D management of aerospace model projects, the meta-model is first configured based on the architecture modeling tool. In view of the characteristics of the aerospace field, the business components of the business architecture correspond to the model subsystems, the subject domains of the data architecture correspond to the model product data packages, the application systems of the application architecture correspond to the collaborative design platform, the logical technical components of the technical architecture correspond to the simulation computing service, and the security capability components of the security architecture correspond to the data leakage prevention module. At the same time, the cross-domain relationship is clearly defined, such as the overall model design process being linked to the 3D design software module through the implementation relationship.

[0045] Based on the digital R&D strategy of aerospace enterprises, overall architecture modeling is carried out according to the meta-model defined above. For example, at the business architecture layer, top-level business process groups such as satellite overall design and payload testing are defined; at the data architecture layer, enterprise-level logical data entities such as satellite structural data and telemetry data are defined, and their association with the business object satellite product BOM is established; at the application and technology architecture layer, standard assets such as satellite simulation systems and parallel computing clusters are defined, and the usage relationship between the simulation system and the computing cluster is established. Finally, all standardized architectural elements and their cross-domain dependencies are stored in the enterprise-level architecture asset library.

[0046] For a specific new satellite payload testing system construction project, relevant assets such as payload testing processes, test data standards, and simulation platform services are selected from the enterprise-level architecture asset library as inputs. During the project initiation phase, a project-level architecture blueprint is output, including selected business processes, preliminary system components, and technology selections. During the requirements analysis phase, the testing processes in the blueprint are refined into user tasks such as parameter settings and data acquisition, and corresponding business rules and data relationships are defined to form a structured project requirement specification. During the detailed design phase, the requirements are further transformed into BPMN flowcharts, physical database table structures, software class diagrams, and specific server models and network topologies, generating a practical technical design solution that can directly guide development and deployment.

[0047] After each decomposition design phase of the project is completed, the consistency score S between the current design model and the enterprise-level architecture asset library is calculated. For example, in the requirements analysis phase, if the data acquisition interface defined by the project does not match the enterprise standard telemetry data interface specification, the number of matching elements will decrease, resulting in a drop in the S value. When S is lower than the preset threshold, a deviation alarm is automatically generated to prompt the designers to check and correct the interface definition, ensuring that the project design is always consistent with the overall architecture strategic intent.

[0048] This embodiment uses an enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model. By constructing a unified meta-model covering business, data, application, technology, and security architecture domains, it establishes a common semantic foundation and constraint framework for cross-domain architecture design. On this basis, following a layer-by-layer decomposition and tracing mechanism from enterprise strategy to overall architecture, and then from overall architecture to specific projects, it achieves consistency and controllability of architecture design throughout the entire project lifecycle. It is particularly suitable for the R&D of complex systems such as aerospace and finance, effectively solving practical problems such as semantic fragmentation of cross-domain models, disconnect between strategy and execution, and the concealment of dependencies.

[0049] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0050] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for enterprise-level architecture modeling and layer-by-layer decomposition based on a unified meta-model, characterized in that, Includes the following steps: S1. Construct a unified meta-model covering business architecture, data architecture, application architecture, technical architecture, and security architecture domains, including defining the core element types and cross-domain relationship types for each architecture domain; S2. Based on the unified meta-model, perform enterprise-level overall architecture modeling to generate an enterprise-level architecture asset library that includes standard assets of multiple architecture domains and their dependencies. S3. Based on the unified meta-model and enterprise-level architecture asset library, perform hierarchical architecture decomposition design on the project to be implemented, and sequentially produce project-level architecture blueprints, detailed project requirement specifications, and implementation technology design schemes that are aligned with the overall architecture.

2. The enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model according to claim 1, characterized in that, In S1, the core element types include: The business architecture domain includes business domains, business components, business processes, business objects, business rules, and business roles. The data architecture domain includes subject areas, enterprise-level logical data entities, system-level logical data entities, and system-level physical data entities. The application architecture domain includes application systems, application components, application functions, and application interfaces. Technical services, logical technical components, devices, and nodes in the technical architecture domain; Security services and security capability components in the security architecture domain.

3. The enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model according to claim 1, characterized in that, In S1, the cross-domain relationship types include: implementation relationship, usage relationship, association relationship, constraint relationship and deployment relationship, which are used to explicitly describe the logical connections and dependencies between elements of different architectural domains.

4. The enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model according to claim 1, characterized in that, S2 includes: Based on the enterprise's strategic planning and business operation model, a business architecture is constructed according to a unified meta-model, defining business domains, business components, business processes, and business objects; Taking the business architecture as input, construct the data architecture based on the unified metamodel, and define subject areas, enterprise-level logical data entities and their associations with business objects; Taking business architecture and data architecture as input, construct application architecture and technical architecture based on unified metamodel, define application systems, application components, technical services and logical technical components, and establish the usage relationship between application components and logical technical components; Integrate business, data, application, technology, and security architecture assets, and build and store the dependencies between elements based on cross-domain relationship types to generate an enterprise-level architecture asset library.

5. The enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model according to claim 1, characterized in that, The dependencies between the elements include: The implementation relationships between business processes and application components, the association relationships between business objects and enterprise-level logical data entities, and the usage relationships between application components and the logical technology components they depend on.

6. The enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model according to claim 1, characterized in that, In S3, the hierarchical architectural decomposition design of the project to be implemented includes the following stages: project initiation stage design, project requirements analysis stage design, and project detailed design stage design.

7. The enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model according to claim 1, characterized in that, The project initiation phase design includes: Filter business components, business processes, business objects, application components, and technical services that are relevant to the project objectives from the enterprise-level architecture asset library; Based on the unified meta-model, the business processes, system-level logical data entities, software modules and technology selections within the project scope are initially defined, and their traceability association with enterprise-level standard assets is established to generate a project-level architecture blueprint.

8. The enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model according to claim 1, characterized in that, The project requirements analysis phase design uses the project-level architecture blueprint as input, including: Break down business processes into user tasks and activities, and define business rules and events; The system-level logical data entities are refined into system-level logical data elements, and entity relationships are defined; The software modules are broken down into software functions, and the software services and interfaces are defined in detail. The output includes a detailed project requirements specification that includes structured business requirements, functional requirements, and non-functional requirements.

9. The enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model according to claim 1, characterized in that, The detailed design phase of the project takes the refined project requirements specifications as input and includes: Refine the business process model based on the BPMN specification; Transform system-level logical data entities and elements into system-level physical data entities and elements to generate a physical data model; Transform software functionalities into detailed class designs and interface specifications; Determine the specific models, configurations, and deployment topology of the equipment and software, and generate a practical technical design solution.

10. The enterprise-level architecture modeling and layer-by-layer decomposition method based on a unified meta-model according to claim 1, characterized in that, It also includes model consistency verification: After any decomposition design phase is completed, calculate the architectural consistency score S between the current project-level architecture model and the enterprise-level architecture asset library: in, This indicates the number of elements in the project model that match the enterprise-level standard model. This represents the total number of elements in the project model; This indicates the number of relationships in the project model that conform to enterprise-level cross-domain association rules. This represents the total number of relationships in the project model; This represents the evaluation value of the project model's compliance with enterprise-level constraint rules; These are configurable weighting coefficients; When S falls below a preset threshold, an architecture deviation alarm is generated and a correction is prompted.

Images