Knowledge graph enhanced enterprise business meta-model extraction method and system

Abstract

The invention discloses a knowledge graph enhanced enterprise business meta-model extraction method and system, and belongs to the technical field of enterprise business meta-model extraction. According to the method, six core entities including data, services, functions, resources, organizations and knowledge are designed, five relationships among the six entities are defined, information of the entities and the relationships is extracted from specifications and design documents of single application programs, and a knowledge graph of a system is constructed. After the system knowledge graph is clustered, a plurality of enterprise business meta-model candidate items are obtained. The candidates represent different business functions or service components in the system, and clear boundaries and independent business capabilities exist among the different business functions or service components. And finally, based on the candidate items, a related enterprise business meta-model can be effectively extracted. By adopting the knowledge graph enhanced enterprise business meta-model extraction method and system provided by the invention, the problems of enterprise business modeling, extraction and design are solved.

Description

Technical Field

[0001] This invention relates to the field of enterprise business meta-model extraction technology, and in particular to a knowledge graph-enhanced enterprise business meta-model extraction method and system. Background Technology

[0002] Each metamodel in an enterprise business metamodel architecture focuses on a single business function and adheres to the single responsibility principle. In other words, the resulting enterprise business metamodel has its own business boundaries and lifecycle, with multiple metamodels collaborating to complete tasks. The advantages of an enterprise business metamodel include strong maintainability, scalability, automated deployment, and flexibility in technology selection. However, due to factors such as the complexity of business logic, the cost of inter-business communication, and the size of the development team, there is no unified method to determine the boundaries and scale of an enterprise business metamodel. Currently, there is a lack of a unified approach to guide the practice of extracting enterprise business metamodels.

[0003] On the other hand, in recent years, some experts have been dedicated to researching systems that implement enterprise business meta-model architecture based on demand knowledge graphs. However, due to significant design limitations, they are difficult to apply to actual engineering projects; they rely too heavily on human experience, resulting in high time costs; and they are overly reliant on the definition of interfaces or code, which many monolithic programs lack.

[0004] Therefore, it is necessary to develop and design a knowledge graph-enhanced method for extracting enterprise business meta-models. Summary of the Invention

[0005] The purpose of this invention is to provide a knowledge graph-enhanced method and system for extracting enterprise business meta-models. By designing six core entities—data, business, function, resource, organization, and knowledge—and defining five relationships between these entities, a knowledge graph is constructed. Based on the knowledge graph, an enterprise business meta-model is extracted, solving the challenges of enterprise business modeling, extraction, and design.

[0006] To achieve the above objectives, this invention provides a knowledge graph-enhanced enterprise business meta-model extraction method, comprising the following steps:

[0007] S1. Construct an enterprise business meta-model knowledge graph: Define six types of entities: data entities, module entities, function entities, resource entities, organizational entities, and knowledge entities. Extract each entity based on design documents, source code, or database tables, and construct the relationships between entities through weight calculation to form a knowledge graph.

[0008] S2. Extracting Enterprise Business Meta-Models Based on Knowledge Graphs: Using the modularity Q evaluation index, the entities in the knowledge graph are clustered into internally tightly connected business meta-model candidates through iterative optimization until the modularity reaches its maximum value.

[0009] S3. Enterprise Business Metamodel Partition Data Processing: Project and store the constructed knowledge graph, count the number, distribution and modularity of business metamodels, and generate summary data containing the business metamodel IDs to which entities belong to guide deployment and development.

[0010] The preferred method for entity extraction is as follows:

[0011] Module entity extraction: Based on the system's business composition, using the system requirements specification or system interface document as input, and leveraging the characteristics of the document directory structure, module entities are automatically identified.

[0012] Function entity extraction: Based on the system's business composition, extract functions from system interface documents or API design documents, or by analyzing control classes in the source code.

[0013] Data entity extraction: Based on system data storage and operations, extract data from the entity relationship diagram (ER diagram) or from the field design of database tables;

[0014] Resource entity extraction: Based on system hardware dependencies, resource entities include CPU, memory, hard disk and network resources, which are extracted directly from the system;

[0015] Organizational entity extraction: Based on system management needs, extraction is performed either by identifying actual departments of the enterprise or by inferring and extracting entities through the analysis module.

[0016] Knowledge entity extraction: Extract knowledge from external interface documents or configuration documents based on external dependencies of the system.

[0017] Preferably, in S1, the relationship between the entities is as follows:

[0018] Module-Function Relationship: A module entity contains a function entity, with a weight of 1;

[0019] Function-data relationship: Calculate weights based on the frequency of data access by functions, and use these weights to represent the function-data relationship;

[0020] Module-Resource Relationship: Modules are ranked and weighted according to their dependence on resources, and the weights are used to represent the module-resource relationship;

[0021] Module-Organizational Relationship: The organizational entity contains the module entity, with a weight of 1;

[0022] Knowledge-Module Relationship: Weights are calculated based on the degree of dependency of modules on knowledge. The expression for the knowledge-module relationship is the same as that for the module-resource relationship. Adaptive adjustments are made based on knowledge parameters.

[0023] Preferably, the function-data relationship expression is:

[0024]

[0025] Among them, W fd (f j ,d k ) represents the j-th function entity f j For the k-th data entity d k Function-data relationship, T(f j ,d k ) represents the j-th function entity f j Access the k-th data entity d k The frequency, Max(T(f) j ,d k )) represents all function entities f j For data entity d k The maximum number of visits, W fd The final value satisfies 0 ≤ W fd ≤1.

[0026] Preferably, the module-resource relationship expression is:

[0027]

[0028] Among them, W mr (m j ,r k ) represents the j-th module entity m j For the k-th resource entity r k Module-resource relationships, This represents the j-th module entity m under normal operating conditions of the software system. j For the k-th resource entity r k The degree of dependence; Represents the relationship between resource entity r k All associated module entities constitute a set, where nd represents the set associated with resource entity r. k The number of associated module entities, nd≤nm, where nm represents the total number of module entities; W mr The final value is between 0 and 1.

[0029] Preferably, in step S2, the specific steps for extracting the enterprise business meta-model based on the knowledge graph are as follows:

[0030] S21. Assign an independent business meta-model to each entity and calculate the initial modularity;

[0031] S22. Move entity i to the business meta-model C where the neighboring entity j is located, calculate the module degree increase value, and adjust the business meta-model affiliation of entity i only when the module degree increase value is positive, until the module degree no longer increases.

[0032] S23. Take the clustered business meta-model as a new entity, calculate the weight between the new entities. The weight between the new entities is determined by calculating the sum of the edge weights between the entities in the corresponding two business meta-models. Repeat the iteration until the number of business meta-models is stable and the modularity can no longer be increased.

[0033] Preferably, in step S21, the expression for the initial modularity is:

[0034]

[0035] Among them, A ij A represents the weight of the edge connecting entity i and entity j. When the graph is unweighted, A ij The value of k is 1; i k represents the sum of the weights of all edges connected to entity i. i =∑ j A ij ;k j k represents the sum of the weights of all edges connected to entity j. j =∑ i A ij ; m represents the sum of the weights of all edges in the graph, c i c represents the business metamodel to which entity i currently belongs. j This represents the business meta-model to which entity j currently belongs, δ(c i ,c j ) is an indicator function for determining whether entity i and entity j belong to the same business meta-model.

[0036] Preferably, in step S22, the formula for calculating the increase in modularity is:

[0037]

[0038] Where ΔQ represents the increase in modularity, This represents the sum of the weights of the edges inside the business meta-model C. For an undirected weighted graph, its value is twice the sum of the weights of all edges inside the business meta-model C. k represents the sum of the weights of the edges connected to entities in the business meta-model C. i k represents the sum of the weights of the edges connected to entity i. i,in This represents the sum of the weights of the edges from entity i to entities in the business meta-model C.

[0039] Preferably, the data processing for dividing the enterprise business metamodel includes:

[0040] S31. Project the knowledge graph into an undirected graph and store it;

[0041] S32. Save the business meta-model ID and return statistics on quantity, distribution, and modularity.

[0042] S33. Update the entity attributes and repeat the algorithm until the modular value is stable;

[0043] S34. Return the business metamodel ID of each entity to form an independent module.

[0044] A system for extracting enterprise business meta-models for the aforementioned knowledge graph enhancement method includes:

[0045] Knowledge graph construction module: used to define and extract six types of entities, build weighted relationships between entities, and generate an enterprise business meta-model knowledge graph;

[0046] The knowledge graph construction module includes:

[0047] Entity extraction unit: Extracts data entities, module entities, function entities, resource entities, organization entities, and knowledge entities from design documents, source code, and database tables, respectively;

[0048] Relationship Calculation Unit: Calculates the weights of relationships between entities based on the relationship construction method, and constructs a knowledge graph;

[0049] Meta-model extraction module: Used to extract business meta-model candidates through iterative clustering based on the modularity Q evaluation index;

[0050] The meta-model extraction module includes:

[0051] Modularity calculation unit: used to calculate the modularity Q and its increase;

[0052] Iterative optimization unit: used to perform entity attribution adjustment and graph reconstruction until the modularity is maximized;

[0053] Data processing module: used to project, statistically analyze and optimize the knowledge graph, and output the business meta-model partitioning results;

[0054] The data processing module includes:

[0055] Graph projection unit: used to project the knowledge graph into an undirected graph and store it;

[0056] Statistical analysis unit: used to calculate the number, distribution, and modular values ​​of business meta-models;

[0057] Result output unit: Used to generate the business metamodel ID to which the entity belongs, guiding deployment and development.

[0058] The advantages and positive effects of the knowledge graph-enhanced enterprise business meta-model extraction method described in this invention are as follows: The knowledge graph-enhanced enterprise business meta-model extraction method and system described in this invention constructs a knowledge graph by designing six core entities—data, business, function, resource, organization, and knowledge—and defining five relationships between these six entities. Based on the knowledge graph, the enterprise business meta-model is extracted, thus solving the problems of enterprise business modeling, extraction, and design.

[0059] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0060] Figure 1 This is a flowchart of an embodiment of the present invention;

[0061] Figure 2 This is an entity relationship diagram of the enterprise human resources management system according to an embodiment of the present invention. Detailed Implementation

[0062] In this application, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit the scope of this application.

[0063] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0064] A knowledge graph-enhanced enterprise business metamodel extraction method includes the following steps:

[0065] S1. Construct an enterprise business meta-model knowledge graph: Define six types of entities: data entities, module entities, function entities, resource entities, organizational entities, and knowledge entities. Extract each entity based on design documents, source code, or database tables, and construct the relationships between entities through weight calculation to form a knowledge graph.

[0066] The core of an enterprise management software system is its business logic. Regardless of its architecture, the system's business logic remains stable based on user needs. Business logic typically consists of domain entities, business rules, integrity constraints, and workflows. In the development of enterprise management software, business logic is primarily represented in the form of related designs (including design documents and database designs) and source code. By extracting these resources, a knowledge graph for a monolithic application can be constructed.

[0067] This invention defines six types of entities for an enterprise business meta-model knowledge graph.

[0068] (1) Data entities based on system data storage and operation

[0069] In database design, entity-relationship design and database table design primarily represent data storage and operations within a monolithic application. Therefore, based on the principles of extracting data dimensions from the enterprise business metamodel, all entities in the entity-relationship design are defined as data entities.

[0070] (2) Module entities based on system business components

[0071] Based on the principles of extracting enterprise business metamodels under the functional dimension, and according to the system business domain descriptions in the project design document of the monolithic application, module entities are defined. A module entity represents a business domain that contains multiple functions or subsystems.

[0072] (3) Function entities based on system business components

[0073] The interface provided by an enterprise management software system to users or other applications is defined as a function entity. There is a relationship of inclusion between module entities and function entities. A module entity can contain multiple function entities, but a function entity can only be assigned to one module entity at a time. Simultaneously, data entities will establish direct communication with function entities, as they are the basic unit of data manipulation. Data reading and storage also occur during function implementation.

[0074] (4) Resource entities based on system hardware dependencies

[0075] Without the support of various hardware resources, a software system cannot function properly. Different types of hardware required to support the operation of the software system are defined as resource entities. The hardware configuration of a monolithic application is determined at system deployment and cannot be changed, leading to low resource utilization. A complex issue in breaking down a monolithic application into enterprise business metamodels is how to better utilize resources. When using enterprise business metamodels, resource allocation needs to be based on the needs of each enterprise business metamodel. How many resources should be allocated to each enterprise business metamodel? Considering the resource dependencies of modules, extracting the enterprise business metamodels will help provide valuable guidance for the allocation of enterprise business metamodel resources at actual startup. For example, if a module related to goods is observed to have high memory requirements while running the monolithic application, more memory can be allocated to the goods service in the early stages of deployment.

[0076] (5) Organizational entities based on system management requirements

[0077] To facilitate enterprise management, the departments or human resources required by this system are defined as organizational entities. In practical terms, this means defining the real-world resources needed by the enterprise to support the modules providing services to users. This entity still serves the module entities.

[0078] (6) Based on the knowledge entities required by the system

[0079] This entity primarily defines the various external dependencies required by the module entity, providing support for the module to achieve normal functionality.

[0080] In one possible implementation, the following extraction method is given for the above entities.

[0081] (1) Module entity extraction

[0082] A module is a well-defined and relatively independent unit of appropriate size, formed after the modularization of a software system. Modularization is essentially the process of analyzing the system's business logic. Generally, a large program can be decomposed into modules based on business functions by adopting a top-down, progressive decomposition, and divide-and-conquer approach.

[0083] Organizations that generally follow standardized development processes prepare and create complete and standardized documentation during software development. This documentation primarily includes requirements specifications, system and software design specifications, and system interface documentation. Especially for projects with a front-end and back-end separation architecture, system interface documentation is typically generated during back-end development and usually includes basic information such as request methods, request parameters, status code definitions, and return result types to facilitate communication among developers.

[0084] The design document will indicate the modular division of a monolithic system with process specifications and detailed documentation. Therefore, the module entities can be automatically identified from the document directory structure using the system requirements specification or system interface document as input.

[0085] (2) Function entity extraction

[0086] Function entities are designed to reflect how a system provides functionality to users. Compared to modules, functions are smaller units of requirement description, and their implementation directly manipulates specific data entities. Typically, the interface documentation or API design documentation of a software project details the functions provided by the system. Therefore, function entities can be extracted directly from these documents. According to the MVC pattern, the controller maps user actions to model updates and view selection. In other words, the controller is responsible for handling business logic. Based on this characteristic, function entities can also be extracted by automatically analyzing the controller classes in the source code.

[0087] (3) Data entity extraction

[0088] To a large extent, the complexity of data entities reflects the complexity of the system. An Entity-Relationship Diagram (ER diagram) details the relationships between all entities in the system. In the absence of documentation, data entities can be extracted from the field design of database tables.

[0089] (4) Resource entity extraction

[0090] From a performance perspective, allocating specific hardware resources to relevant system modules as needed can significantly improve system performance. A common and effective method to improve software system performance in this regard is to optimize hardware configuration. It is necessary to consider allocating specific hardware resources to system modules that require these resources most. Typical key hardware elements affecting software system performance include CPU, memory, hard disk, and network resources. Therefore, hardware resources are defined as resource entities of the system.

[0091] (5) Extraction of organizational entities

[0092] Organizational entity extraction can be based on actual departments within the enterprise. This is because, in practice, the allocation of departments and human resources significantly impacts the efficiency of the enterprise management system. In the absence of sufficient information, organizational entities can be inferred and extracted by analyzing module entities.

[0093] (6) Knowledge Entity Extraction

[0094] The implementation of a module's functionality requires a significant amount of external dependency knowledge, and system calls to these dependencies also consume system performance resources. Therefore, we should start by examining the module's functional requirements for external dependencies to extract knowledge entities. Entities can be obtained by examining the application's external interface documentation or configuration documentation.

[0095] In one possible implementation, the present invention proposes a method for constructing relationships based on the above entities.

[0096] This invention is based on the concept of a highly cohesive and loosely coupled enterprise business meta-model. The closer the relationship between entities, the greater the likelihood that they belong to the same enterprise business meta-model. To convert a monolithic program into a graph structure, weights need to be assigned to each edge of the graph to represent the degree of interaction between entities. Higher edge weights indicate a stronger connection between entities, and these types of entities are more likely to belong to the same enterprise business meta-model. Based on the business logic analysis of the software system, this invention establishes the following entity relationships.

[0097] (1) Module-function relationship:

[0098] A module is the basic unit of service provided by a system. Similarly, a function is a smaller-granular unit of requirement description than a module. There is a simple relationship between module entities and function entities, so this relationship can be simply weighted with 1.

[0099] (2) Function-Data Relationship:

[0100] In software development, implementing functionality typically requires manipulating certain entities. Functions read and modify data, which forms the connection between function entities and data entities. The frequency with which functions access data is usually related to the connections between functions and data within the software system. In a shopping scenario, the search function reads the product data entity, the function that adds items to the cart modifies the cart data entity, and the function that places an order updates the order data entity. Therefore, the number of operations indicates how close the connection is between function entities and data entities. fd (f j ,d k () represents the function-data relationship. The formula is:

[0101]

[0102] Among them, W fd (f j ,d k ) represents the j-th function entity f j For the k-th data entity d k Function-data relationship, T(f j ,d k ) represents the j-th function entity f j Access the k-th data entity d k The frequency, Max(T(f) j ,d k )) represents all function entities f j For data entity d k The maximum number of visits, W fd The final value satisfies 0 ≤ W fd ≤1.

[0103] (3) Module-Resource Relationship

[0104] When modules provide business functions to users, they consume certain hardware resources. The hardware resources of the enterprise business metamodel are flexibly configurable. Considering the impact of hardware resources on the operation of related modules is crucial. Of particular concern is that hardware resources may affect the performance of services provided within the enterprise business metamodel architecture. The higher a module's utilization of a certain hardware resource, the greater its dependence on that resource. The close relationship between modules and resources should exist within the same enterprise business metamodel. In practice, relevant real-time operational data can be recorded, corresponding performance indicators calculated, and the dependence of software modules on hardware resources can be evaluated through monolithic application performance testing, thereby accurately describing the relationship between modules and resources.

[0105] Assume the module-resource relationship is W. mr (m j ,r k Given any module entity m jand resource entity r k If it is related to resource entity r k All related module entities constitute a set And W mr The size of the set is represented by the formula:

[0106]

[0107] Among them, W mr (m j ,r k ) represents the j-th module entity m j For the k-th resource entity r k Module-resource relationships, This represents the j-th module entity m under normal operating conditions of the software system. j For the k-th resource entity r k The degree of dependence; Represents the relationship between resource entity r k All associated module entities constitute a set, where nd represents the set associated with resource entity r. k The number of associated module entities, nd≤nm, where nm represents the total number of module entities; W mr The final value is between 0 and 1.

[0108] (4) Module - Organizational Relationship

[0109] A module is the basic unit of service provided by a system, and modules are also the reason for the existence of an organization. There is a simple relationship between organizational entities and module entities, where the former contains the latter; therefore, this relationship can be simply weighted with 1.

[0110] (5) Knowledge-Module Relationship

[0111] The relationship between knowledge and modules can be compared to the relationship between resources and modules, and adaptive adjustments can be made based on knowledge parameters. To obtain relationship weights, it is necessary to evaluate their dependence on knowledge.

[0112] S2. Extracting Enterprise Business Meta-Models Based on Knowledge Graphs: Using the modularity Q evaluation index, the entities in the knowledge graph are clustered into internally tightly connected business meta-model candidates through iterative optimization until the modularity reaches its maximum value.

[0113] The specific steps for extracting enterprise business meta-models based on knowledge graphs are as follows:

[0114] S21. Assign an independent business meta-model to each entity and calculate the initial modularity.

[0115] The expression for the initial modularity is:

[0116]

[0117] Among them, A ij A represents the weight of the edge connecting entity i and entity j. When the graph is unweighted, A ij The value of k is 1; i k represents the sum of the weights of all edges connected to entity i. i =∑ j A ij ;k j k represents the sum of the weights of all edges connected to entity j. j =∑ i A ij ; m represents the sum of the weights of all edges in the graph, c i c represents the business metamodel to which entity i currently belongs. j This represents the business meta-model to which entity j currently belongs, δ(c i ,c j ) is an indicator function for determining whether entity i and entity j belong to the same business meta-model.

[0118] S22. Move entity i to the business meta-model C where the neighboring entity j is located, calculate the increase in modularity, and adjust the business meta-model affiliation of entity i only when the increase in modularity is positive, until the modularity no longer increases.

[0119] Traverse the entities in the graph, assigning each entity to the business metamodel that produces the maximum increase in modularity. Evaluate the potential increase in modularity by removing entity i from its business metamodel and placing it into the business metamodel of its neighbor, entity j. Finally, place entity i into the business metamodel with the maximum increase in modularity. It's important to note that entity i's business metamodel is only adjusted if its increase in modularity is positive. Otherwise, entity i remains in its original business metamodel. Repeat this sequential processing for all entities until no further improvement is possible.

[0120] The formula for calculating the increase in modularity obtained by moving an isolated entity i into the business meta-model C is as follows:

[0121]

[0122] Where ΔQ represents the increase in modularity, This represents the sum of the weights of the links (edges) within the business meta-model C. For an undirected weighted graph, its value is twice the sum of the weights of all edges within the business meta-model C. k represents the sum of the weights of the links (edges) connected to entities in the business meta-model C. i k represents the sum of the weights of the links (edges) connected to entity i. i,inThis represents the sum of the weights of the links (edges) from entity i to entities in the business meta-model C.

[0123] S23. Take the clustered business meta-model as a new entity, calculate the weight between the new entities. The weight between the new entities is determined by calculating the sum of the edge weights between the entities in the corresponding two business meta-models. Repeat the iteration until the number of business meta-models is stable and the modularity can no longer be increased.

[0124] Reconstruct the graph structure. This step involves creating a new graph where entities are the business meta-models discovered in the first step. The weights between the new entities are determined by calculating the sum of the link weights between entities in the corresponding two business meta-models.

[0125] Iteratively execute steps S22-S23 until the number of business meta-models stabilizes and the modularity cannot be increased further (i.e., the maximum modularity is reached). In the first iteration of S22, the modularity is calculated, and each entity is assigned to a business meta-model. After the second iteration of S23, the initial entities are clustered into multiple business meta-models.

[0126] The graph structure constructed in this invention represents the interactions between different entities through six different types of entities, i.e., heterogeneous networks. At this point, the monolithic system is ultimately clustered into multiple internally tightly connected business meta-models, i.e., subgraphs, each of which can serve as a candidate enterprise business meta-model.

[0127] S3. Enterprise Business Metamodel Partition Data Processing: Project and store the constructed knowledge graph, count the number, distribution and modularity of business metamodels, and generate summary data containing the business metamodel IDs to which entities belong to guide deployment and development.

[0128] The specific data processing for enterprise business metamodel partitioning includes:

[0129] S31. Project the knowledge graph into an undirected graph and store it. The projection relationship is UNDIRECTED, which yields the best results.

[0130] S32. Save the business meta-model ID and return statistics on the number, distribution, and modularity of business meta-models.

[0131] S33. Update entity attributes and repeat the algorithm until the modular value is stable.

[0132] The execution mode extends this mode by updating the named graph with a new entity attribute containing the entity's business metamodel ID. The name of the new attribute is specified using the required configuration parameters, and the result is a single summary row. When writing back the result, the process returns only one row. The result contains meta-information, such as the number of identified business metamodels and the modularity value. This algorithm is repeated until the modularity value hardly changes anymore.

[0133] S34. Return the business metamodel ID of each entity to form an independent module.

[0134] In execution mode, the algorithm returns the business metamodel ID for each entity. This forms a series of business metamodels containing different entities, and each business metamodel can be used as an independent enterprise business metamodel module to guide deployment and development.

[0135] A system for extracting enterprise business meta-models for the aforementioned knowledge graph enhancement method includes:

[0136] Knowledge graph construction module: used to define and extract six types of entities, build weighted relationships between entities, and generate an enterprise business meta-model knowledge graph;

[0137] The knowledge graph construction module includes:

[0138] Entity extraction unit: Extracts data entities, module entities, function entities, resource entities, organization entities, and knowledge entities from design documents, source code, and database tables, respectively;

[0139] Relationship Calculation Unit: Calculates the weights of relationships between entities based on the relationship construction method, and constructs a knowledge graph;

[0140] Meta-model extraction module: Used to extract business meta-model candidates through iterative clustering based on the modularity Q evaluation index;

[0141] The meta-model extraction module includes:

[0142] Modularity calculation unit: used to calculate the modularity Q and its increase;

[0143] Iterative optimization unit: used to perform entity attribution adjustment and graph reconstruction until the modularity is maximized;

[0144] Data processing module: used to project, statistically analyze and optimize the knowledge graph, and output the business meta-model partitioning results;

[0145] The data processing module includes:

[0146] Graph projection unit: used to project the knowledge graph into an undirected graph and store it;

[0147] Statistical analysis unit: used to calculate the number, distribution, and modular values ​​of business meta-models;

[0148] Result output unit: Used to generate the business metamodel ID to which the entity belongs, guiding deployment and development.

[0149] The method described in this invention will be explained in detail below with specific examples.

[0150] This paper takes an "Enterprise Human Resources Management System" as an example to illustrate the implementation and construct a system knowledge graph. Based on the requirements of ease of operation, user-friendly interface, flexibility, practicality, and security, the enterprise human resources management system has the following functions:

[0151] 1) Module for inputting, modifying, querying, and deleting basic employee information.

[0152] 2) Department information entry, modification, query, and deletion module.

[0153] 3) Module for inputting, calculating, and querying employee salary information.

[0154] 4) Module for inputting, modifying, querying, and deleting employee attendance information.

[0155] 5) Provide information consulting, information retrieval, and information storage services for enterprise human resource management.

[0156] The entity relationship diagram of an enterprise human resources management system is as follows: Figure 2 As shown. Building a knowledge graph requires storing system entities (data, modules, functions, resources, organizations, knowledge) as nodes in Neo4j. CSV is a commonly used data carrier, so the organized entity information (CSV format) needs to be imported into the Neo4j database. First, organize the entity information using Excel, then convert it to the CSV format supported by Neo4j. Taking data.csv as an example, it stores "data node" information. After importing, data will be used as the node's label (used for classifying nodes in Neo4j). The file must contain the node's unique identifier (did) and name (dname) for easy differentiation and assignment when creating nodes.

[0157] There are two ways to import a CSV file: `load csv` and `import`. This example uses the `load csv` method. Specifically, the `LOAD CSV` statement reads the `data.csv` file, storing each row of data as a `line` variable for later reference. It checks if a `data` tag node corresponding to `did` and `dname` already exists; if so, it matches; otherwise, it creates a new node. Part of the Cypher code for importing the node information from the `data.csv` file into the Neo4j database is shown in Table 1.

[0158] Table 1 shows a portion of the Cypher code that imports the node information data.csv file into the Neo4j database.

[0159]

[0160] After executing the code described in Table 1, each row of data in data.csv will become a node labeled "data" in neo4j.

[0161] Following the data node creation process described above, create knowledge nodes, module nodes, function nodes, organization nodes, and resource nodes respectively using CSV files: knowledge, module, function, org, and resource, to create the system knowledge graph nodes for the "Enterprise Human Resources Management System".

[0162] Specifically, prepare corresponding CSV files (named knowledge.csv, module.csv, function.csv, org.csv, and resource.csv). These CSV files will have a similar format to the previous data.csv file—containing unique identifiers (such as IDs) and name attributes for each node, providing Neo4j with the raw materials for node creation. Import these five types of CSV files (knowledge, module, function, organization, and resource) into the Neo4j database sequentially using the same import logic as data.csv. Create nodes with corresponding tags in the database, gradually building a complete node system for the "Enterprise Human Resources Management System" knowledge graph.

[0163] Establish relationships between nodes by creating 5 CSV files to describe these relationships. Each file stores data for one type of relationship, including module-function relationships, function-data relationships, module-resource relationships, module-organization relationships, and knowledge-module relationships.

[0164] Taking the function-data relationship as an example, we use `LOAD CSV` to read the relationship data file and store each row of data as a variable `line` for easy reference later. We find the created function nodes in the database, matching them if the node's `fid` (function ID) and `fname` (function name) match the `line.fid` and `line.fname` in the CSV. We also find the created data nodes, matching them if the node's `did` (data ID) and `dname` (data name) match the `line.did` and `line.dname` in the CSV. If a `need` relationship already exists between the function node and the data node in the database, we match it directly; otherwise, we create a `(function)-[need]->(data)` relationship (the function needs to manipulate the data). The code for importing the function-data relationship information CSV file into Neo4j's Cypher is shown in Table 2.

[0165] Table 2 shows partial Cypher code for importing data relationship information from a CSV file into Neo4j.

[0166]

[0167] Repeat the above logic, using 5 relational CSV files to establish corresponding relationships for 5 types of nodes (knowledge, modules, functions, organizations, and resources). After all relationships are established, the knowledge graph transforms from "scattered nodes" into a "complete network".

[0168] An analysis of the "Enterprise Human Resources Management System" was conducted to verify the effectiveness of the division method and system of this invention.

[0169] Enterprise Business Metamodel Division of "Enterprise Human Resources Management System":

[0170] (1) Graphics projection and storage

[0171] In Neo4j, the Cypher command in "Tables 1 and 2" is used to project the "node + relationship" data of the knowledge graph into a graphical form and store it in a specified directory. This transforms the abstract graph data into a visual and analyzable graphical file, preparing for subsequent community segmentation. The statistical results of the knowledge graph projection are shown in Table 3.

[0172] Table 3. Statistical Results of Knowledge Graph Projection

[0173]

[0174] (2) Output the number of communities

[0175] Using the code in Table 2, count the number of communities in the knowledge graph and output the results. The Louvain algorithm is used to divide the "Enterprise Human Resources Management System" knowledge graph into four communities. These four communities are the candidate business meta-models for the enterprise, i.e., the initially defined business modules.

[0176] (3) Calculate the modularity value

[0177] Using the code in Table 2, the modularity values ​​of the community partitioning results are obtained, as shown in Table 4. The modularity value obtained the first time is only a preliminary result. By repeating the partitioning-calculation steps, the modularity value will gradually increase until it stabilizes. At this point, a "relatively optimal" community partitioning result can be obtained.

[0178] Table 4 Modularity values ​​of community division results

[0179]

[0180] (4) Call the patterned output

[0181] The community segmentation results are then output in a standardized format, resulting in the final segmentation effect shown in Table 5. This standardized presentation of the community segmentation results facilitates the evaluation of the quality of the enterprise's business meta-model segmentation.

[0182] Table 5. Community Division Results Outputted in a Patterned Model

[0183] name Community ID Attendance Record 54 bank account 54 Welfare Plan 54 Number of children 54 Date of birth 44 Joining date 54

[0184] (5) Overall process and objectives

[0185] By employing the process of "projected storage → calculating the number of communities → iterative optimization of modularity → patterned output," the knowledge graph nodes are clustered into four communities, corresponding to four candidate enterprise business meta-models. This ultimately achieves a reasonable division and evaluation of the enterprise human resources management system's business meta-models. The candidate enterprise business meta-models are shown in Table 6.

[0186] Table 6 Candidate List of Enterprise Business Metamodels

[0187]

[0188] Table 7 shows the weight table of some entities in the knowledge graph of the enterprise human resources management system.

[0189] Table 7. Research Weighting Table for Enterprise Human Resources Management System

[0190]

[0191]

[0192] This paper analyzes the business meta-model `employee_info_server` created around employee information management in an enterprise human resources management system. `employee_info_server` includes activities such as updating signatures, reading requests, reading forms, creating forms, deleting forms, and modifying forms. A cohesion matrix is ​​used to quantify the relationships between activities within the module. FC (cohesion) and SC (request processing result) indices are calculated to evaluate module cohesion, and MDC (model partitioning result index) and MCP (final quality index) are used to verify the quality of the entire business meta-model partitioning. The cohesion among all activities in the `employee_info_server` enterprise business meta-model is shown in Table 8.

[0193] Table 8 shows the cohesion among all activities in the employee_info_server enterprise business metamodel.

[0194] Update signature Read request Read Form Create a form Delete Form Modify Form Update signature 1 0.25 1 1 0.2555 0.1 Read request 1 0.25 0.25 0.704 0.0257 Read Form 1 1 0.2555 0.25 Create a form 1 0.704 0.1 Delete Form 1 0.029 Modify Form 1

[0195] (1) Cohesion (FC)

[0196] Cohesion (FC) is the degree of functional relevance of a service in executing business processes. The relationships between entities within a service are key to its cohesion. Cohesion considers the connections between entities and the interactions between activities and entities (including entity-entity and entity-activity relationships). This metric transforms the calculation of microservice cohesion into the complexity of the connections between entities within a service.

[0197] The functional modules of a service directly reflect the business functions it provides. Therefore, the cohesion of a microservice is the average cohesion of the module nodes associated with that microservice. The cohesion of the entire system can be evaluated by the average cohesion of the microservices extracted from the monolithic application.

[0198] The distance weights for relation types are shown in Table 9.

[0199] Table 9 Distance Weights for Relationship Types

[0200]

[0201] First, the cohesion between two activities (i.e., functional nodes) in the computing service.

[0202] Construct a graph containing business entities (i.e., modules and partial data nodes in the knowledge graph). Each edge with endpoints A and B has a weight in row A and column B of Table 9. The cohesion between two functional nodes i and j is called functional cohesion (FC), calculated using the following formula:

[0203]

[0204] Here, R is a set storing selected edges, that is, the set of edges that represent the shortest distance between all data nodes related to the two functional nodes. The relationship distance between the entities corresponding to edge R(i) is denoted as Weight(R(i)), which is the number of edges on the shortest path connecting the data nodes. The calculation formula is:

[0205]

[0206] Among them, e p d is the number of edges on the path between E1 and E2, p is the number of existing paths between E1 and E2, and d is the number of edges on the path between E1 and E2. i The distance is from the relation in Table 10.

[0207] The selection of the edge set R can be obtained using a greedy algorithm.

[0208] (2) The cohesion of the system (MDC) and the cohesion of each service (SC).

[0209] The formula for calculating the system's cohesion (MDC) is as follows:

[0210]

[0211] Where s represents the number of all microservices in the entire system.

[0212] SC k Let represent the cohesion of the k-th microservice, and it is calculated as follows.

[0213]

[0214] Here, r represents the number of functional nodes in the k-th microservice. FC(i,j) represents the cohesion among functional nodes. The higher the MDC value, the better the cohesion of the system.

[0215] (3) Coupling

[0216] In microservice applications, the access of functional nodes to data nodes between different services reflects the interdependence between services; that is, if a service's functionality accesses another service's data entities to meet its business needs, then these two services are considered coupled. Based on this view, the Microservice Coupling (MCP) metric is proposed, using message interactions between services to measure the degree of coupling in a microservice design. MCP can be calculated for the coupling degree of each microservice i using the following formula:

[0217]

[0218] Where, n i Rt(f) represents the number of functional nodes in the i-th microservice. j ) represents the functional node f in the i-th microservice. j The number of times data nodes from other microservices are read at the code level. Rf(f) j ) represents f j The frequency at which data nodes from other microservices are read. Wt(f) j Wf(f) represents the number of times the functional node fj in the i-th microservice writes to the data nodes of other microservices at the code level. j ) represents f j The frequency at which data nodes of other microservices are written.

[0219] To reasonably control the computational workload, in practical applications, Rf corresponds to the computational workload on functional node f during system operation. j The number of calls is determined by the business logic.

[0220] The formula for calculating the coupling degree (MCP) of the entire system is as follows:

[0221]

[0222] Here, 's' represents the number of microservices in the system. The lower the MCP value, the better the coupling of the system.

[0223] Using the above formulas, we can calculate the cohesion (FC) between activities to be 0.704, the request processing (SC) to be 0.527, the MDC to be 0.649, and the MCP to be 0.223.

[0224] Domain-driven analysis of the "Enterprise Human Resources Management System"

[0225] Based on the business requirements analysis of the "Enterprise Human Resources Management System" (hereinafter referred to as HRS), the following business use cases and domain entities of HRS are obtained:

[0226] (1) Business use cases: makeJobOffers, viewEmployees, calculateWorkHours, clockIn, recordOvertime, viewLeaveRequest, trackRecruitmentProcess, viewDepartment. The following are abbreviations: MJ, VE, CW, CI, RO, VL, TR, VD.

[0227] (2) Domain Entities: Offers, Candidate, EmployeeInfo, Time, LeaveRequest, Department, hereinafter referred to as abbreviations: O, C, EI, T, LR, D. The following table shows the correspondence between business use cases and domain entities in the HRS, as shown in Table 10.

[0228] Table 10 HRS Business Use Cases and Their Domain Entities

[0229] Use Case Name Read entity Write entity MJ O, C, D EI VE EI, D EI CW T,LR EI CI T, LR, D T RO T EI VL LR EI TR C O VD D, EI none

[0230] Based on domain-driven design, the specific details of the candidate enterprise business metamodel are shown in Table 11.

[0231] Table 11 HRS Candidate Enterprise Business Metamodel

[0232]

[0233]

[0234] The results of this partitioning were analyzed, and weight table 12 was obtained.

[0235] Table 12 Weighting Table of Enterprise Human Resources Management System After Domain-Driven Design Partitioning

[0236]

[0237]

[0238] We selected Enterprise Business Meta-Model 2 for analysis, and calculated the FC between activities to be 0.656 according to the formula.

[0239] Table 13 shows the consistency among all activities in Enterprise Business Metamodel 2.

[0240] Table 13 Consistency among all activities in Enterprise Business Metamodel 2

[0241] Service 9 Service 10 Service 11 Service 12 Service 13 Service 9 1 0.25 1 1 0.2555 Service 10 1 0.25 0.25 0.656 Service 11 1 1 0.2555 Service 12 1 0.656 Service 13 1

[0242] Therefore, the calculated SC value for request processing is 0.462. The MDC value for the enterprise business metamodel partitioning using the Domain-Driven Design (DDD) method in this case is 0.559. Finally, the calculated MCP value is 0.278.

[0243] Enterprise Business Metamodel Quality Assessment Conclusion

[0244] Table 14 Comparison of Experimental Results of Two Enterprise Business Metamodel Partitioning Methods

[0245]

[0246] For the monolithic application "Enterprise Human Resources Management System," both the method of this invention and the enterprise business metamodel partitioning method based on domain-driven design were used to calculate the MDC and MCP values ​​of the two methods. According to the comparison in Table 14, for this small monolithic application, the enterprise business metamodel partitioning method used in this invention exhibits higher cohesion and lower coupling, indicating that the enterprise business metamodel partitioning result used in this invention is superior.

[0247] Therefore, the knowledge graph-enhanced enterprise business meta-model extraction method and system described in this invention solves the problems of enterprise business modeling, extraction and design by designing six core entities: data, business, function, resource, organization and knowledge, and defining five relationships between the six entities.

[0248] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for extracting enterprise business meta-models enhanced by knowledge graphs, characterized in that, Includes the following steps: S1. Construct an enterprise business meta-model knowledge graph: Define six types of entities: data entities, module entities, function entities, resource entities, organization entities, and knowledge entities. Extract each entity based on design documents, source code, or database tables, and construct the relationships between entities through weight calculation to form a knowledge graph. S2. Extracting Enterprise Business Meta-Models Based on Knowledge Graphs: Using the modularity Q evaluation index, the entities in the knowledge graph are clustered into internally tightly connected business meta-model candidates through iterative optimization until the modularity reaches its maximum value. S3. Enterprise Business Metamodel Partition Data Processing: Project and store the constructed knowledge graph, count the number, distribution and modularity of business metamodels, and generate summary data containing the business metamodel IDs to which entities belong to guide deployment and development.

2. The method for extracting enterprise business meta-models enhanced by knowledge graphs according to claim 1, characterized in that, In S1, the method for extracting entities is as follows: Module entity extraction: Based on the system's business composition, using the system requirements specification or system interface document as input, and leveraging the characteristics of the document directory structure, module entities are automatically identified. Function entity extraction: Based on the system's business composition, extract functions from system interface documents or API design documents, or by analyzing control classes in the source code. Data entity extraction: Based on system data storage and operations, extract data from the entity relationship diagram (ER diagram) or from the field design of database tables; Resource entity extraction: Based on system hardware dependencies, resource entities include CPU, memory, hard disk and network resources, which are extracted directly from the system; Organizational entity extraction: Based on system management needs, extraction is performed either by identifying actual departments of the enterprise or by inferring and extracting entities through the analysis module. Knowledge entity extraction: Extract knowledge from external interface documents or configuration documents based on external dependencies of the system.

3. The method for extracting enterprise business meta-models enhanced by knowledge graphs according to claim 2, characterized in that, In S1, the relationships between the entities are as follows: Module-Function Relationship: A module entity contains a function entity, with a weight of 1; Function-data relationship: Calculate weights based on the frequency of data access by functions, and use these weights to represent the function-data relationship; Module-Resource Relationship: Modules are ranked and weighted according to their dependence on resources, and the weights are used to represent the module-resource relationship; Module-Organizational Relationship: The organizational entity contains the module entity, with a weight of 1; Knowledge-Module Relationship: The weight is calculated based on the degree of dependence of a module on knowledge. The expression for the knowledge-module relationship is the same as that for the module-resource relationship.

4. The method for extracting enterprise business meta-models with knowledge graph enhancement according to claim 3, characterized in that, The function-data relationship expression is as follows: Among them, W fd (f j ,d k ) represents the j-th function entity f j For the k-th data entity d k Function-data relationship, T(f j ,d k ) represents the j-th function entity f j Access the k-th data entity d k The frequency, Max(T(f) j ,d k )) represents all function entities f j For data entity d k The maximum number of visits, W fd The final value satisfies 0 ≤ W fd ≤1.

5. The method for extracting enterprise business meta-models with knowledge graph enhancement according to claim 4, characterized in that, The module-resource relationship expression is as follows: Among them, W mr (m j ,r k ) represents the j-th module entity m j For the k-th resource entity r k Module-resource relationships, This represents the j-th module entity m under normal operating conditions of the software system. j For the k-th resource entity r k The degree of dependence; Represents the relationship between resource entity r k All associated module entities constitute a set, where nd represents the set associated with resource entity r. k The number of associated module entities, nd≤nm, where nm represents the total number of module entities; W mr The final value is between 0 and 1.

6. The method for extracting enterprise business meta-models with knowledge graph enhancement according to claim 5, characterized in that, In step S2, the specific steps for extracting the enterprise business meta-model based on the knowledge graph are as follows: S21. Assign an independent business meta-model to each entity and calculate the initial modularity; S22. Move entity i to the business meta-model C where the neighboring entity j is located, calculate the module degree increase value, and adjust the business meta-model affiliation of entity i only when the module degree increase value is positive, until the module degree no longer increases. S23. Take the clustered business meta-model as a new entity, calculate the weight between the new entities. The weight between the new entities is determined by calculating the sum of the edge weights between the entities in the corresponding two business meta-models. Repeat the iteration until the number of business meta-models is stable and the modularity can no longer be increased.

7. The method for extracting enterprise business meta-models enhanced by knowledge graphs according to claim 6, characterized in that, In step S21, the expression for the initial modularity is: Among them, A ij A represents the weight of the edge connecting entity i and entity j. When the graph is unweighted, A ij The value of k is 1; i k represents the sum of the weights of all edges connected to entity i. i =∑ j A ij ;k j k represents the sum of the weights of all edges connected to entity j. j =∑ i A ij ; m represents the sum of the weights of all edges in the graph, c i c represents the business metamodel to which entity i currently belongs. j This represents the business meta-model to which entity j currently belongs, δ(c i ,c j ) is an indicator function for determining whether entity i and entity j belong to the same business meta-model.

8. The method for extracting enterprise business meta-models with knowledge graph enhancement according to claim 7, characterized in that, In step S22, the formula for calculating the increase in modularity is: Where ΔQ represents the increase in modularity, This represents the sum of the weights of the edges inside the business meta-model C. For an undirected weighted graph, its value is twice the sum of the weights of all edges inside the business meta-model C. k represents the sum of the weights of the edges connected to entities in the business meta-model C. i k represents the sum of the weights of the edges connected to entity i. i,in This represents the sum of the weights of the edges from entity i to entities in the business meta-model C.

9. The method for extracting enterprise business meta-models with knowledge graph enhancement according to claim 8, characterized in that, The specific data processing for enterprise business metamodel partitioning includes: S31. Project the knowledge graph into an undirected graph and store it; S32. Save the business meta-model ID and return statistics on quantity, distribution, and modularity. S33. Update the entity attributes and repeat the algorithm until the modular value is stable; S34. Return the business metamodel ID of each entity to form an independent module.

10. A system for extracting an enterprise business meta-model using a knowledge graph enhancement method as described in claim 9, characterized in that, include: Knowledge graph construction module: used to define and extract six types of entities, build weighted relationships between entities, and generate an enterprise business meta-model knowledge graph; The knowledge graph construction module includes: Entity extraction unit: Extracts data entities, module entities, function entities, resource entities, organization entities, and knowledge entities from design documents, source code, and database tables, respectively; Relationship Calculation Unit: Calculates the weights of relationships between entities based on the relationship construction method, and constructs a knowledge graph; Meta-model extraction module: Used to extract business meta-model candidates through iterative clustering based on the modularity Q evaluation index; The meta-model extraction module includes: Modularity calculation unit: used to calculate the modularity Q and its increase; Iterative optimization unit: used to perform entity attribution adjustment and graph reconstruction until the modularity is maximized; Data processing module: used to project, statistically analyze and optimize the knowledge graph, and output the business meta-model partitioning results; The data processing module includes: Graph projection unit: used to project the knowledge graph into an undirected graph and store it; Statistical analysis unit: used to calculate the number, distribution, and modular values ​​of business meta-models; Result output unit: Used to generate the business metamodel ID to which the entity belongs, guiding deployment and development.

Images