Intelligent software generation methods and systems tailored for enterprises

Abstract

This invention relates to the field of automatic software generation technology, specifically disclosing an intelligent software generation method and system customized for enterprises. The method includes collecting business process description text and data structure definition documents from a target enterprise; semantically annotating the business process description text; and extracting action node sequences and data flow path sets. Based on the data structure definition documents, an entity relationship graph is constructed, and action nodes are attached to corresponding entities to generate an enterprise meta-model with behavioral annotations. The enterprise meta-model is input into a pre-trained software component retrieval model to match candidate interface components and logical component sets. Combined with the data flow path set, an assembly sequence is planned, and an executable software package is output. This method can automatically parse unstructured business documents, establish the association between business behaviors and data entities, and achieve intelligent component matching and automatic combination based on model-based retrieval and sequence planning, reducing the need for manual intervention.

Description

Technical Field

[0001] This invention relates to the field of automatic software generation technology, and more specifically to intelligent software generation methods and systems customized for enterprises. Background Technology

[0002] In enterprise-customized software development scenarios, business requirements are mostly stored in the form of natural language process text and data structure documents. Existing technologies generally rely on manual reading and sorting of document content, lacking automated parsing methods for business process texts. They cannot automatically decompose business behavior elements and data flow relationships through standardized text processing methods, and the process of converting document information into machine-recognizable structured content depends on manual intervention.

[0003] Conventional software generation methods only use keyword matching or fixed template calls, which cannot build an entity association architecture based on enterprise-specific data structure documents. Business action nodes cannot be associated and bound with data entities, and business process logic is separated from the data structure system, making it difficult to form a standardized enterprise meta-model that carries complete business information.

[0004] The selection of software components relies heavily on manual experience for screening and matching, failing to utilize pre-trained models for intelligent component retrieval or to assemble and arrange components according to actual data flow rules. Industry development demands higher standards for the efficiency of enterprise-customized software generation, business adaptability, and the degree of automation throughout the entire process. Existing technologies have significant shortcomings in areas such as automatic parsing of unstructured business text, integrated business and data modeling, intelligent component retrieval, and orderly assembly, making it difficult to meet the application requirements for rapid transformation from raw business documents to customized executable software. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for generating intelligent software customized for enterprises, so as to solve the problems mentioned above.

[0006] The objective of this invention can be achieved through the following technical solutions: Enterprise-specific intelligent software generation methods include: Collect the target company's business process description text and data structure definition documents; Perform semantic role labeling on the business process description text to extract the action node sequence and data flow path set; Based on the data structure definition document, an entity relationship graph is constructed, and each action node in the action node sequence is attached to the corresponding entity in the entity relationship graph to generate an enterprise meta-model with behavioral annotations. The enterprise meta-model is input into a pre-trained software component retrieval model to match candidate interface component sets and candidate logic component sets from the component library; Based on the data flow path set, an assembly sequence plan is performed on the candidate interface component set and the candidate logic component set to obtain an executable software package.

[0007] As a further aspect of the present invention, the specific steps for performing semantic role annotation on the business process description text to extract the action node sequence and data flow path set are as follows: The business process description text is divided into multiple independent sentences by periods, and word segmentation is performed on each independent sentence to obtain a word sequence; Each word in the word sequence is mapped to a predefined semantic role label, which includes agent label, patient label, action label, time label, and location label; From the semantic role labeling results of each independent statement, the words corresponding to the action tags are extracted as the action nodes of the statement, and the words corresponding to the agent tags and patient tags are extracted as the input data source and output data target of the action nodes. Arrange the action nodes of all independent statements in the time order indicated by the time tags to form the action node sequence; The transmission relationship from the input data source of each action node to the action node and then to the output data target of the action node is recorded as a directed data path. The set of data flow paths is obtained by merging and deduplicating the directed data paths corresponding to all independent statements.

[0008] As a further aspect of the present invention, the specific steps for constructing an entity relationship graph based on the data structure definition document, attaching each action node in the action node sequence to the corresponding entity in the entity relationship graph, and generating an enterprise meta-model with behavioral annotations are as follows: Parse the data structure definition document to extract the data table name field, the field name set, and the primary key and foreign key association pairs. Define each data table name field as an entity node, define the field name set as the attribute list of the entity node, and define the primary key and foreign key association pairs as the association edges between a pair of entity nodes. For each action node in the action node sequence, extract the input data source and output data target of the action node, find the entity node that matches the input data source and output data target in the entity relationship graph, and bind the action node to the found entity node in the form of annotation; Scan the subset of action nodes in the action node sequence that are bound to the same entity node, sort each action node in the action node subset according to the time label, and generate the behavior time sequence constraint chain of the entity node. The entity relationship graph carrying the behavioral temporal constraint chain is output as the enterprise meta-model with behavioral annotations.

[0009] As a further aspect of the present invention, the specific steps for inputting the enterprise meta-model into a pre-trained software component retrieval model to match candidate interface component sets and candidate logic component sets from the component library are as follows: Traverse each entity node in the enterprise metamodel with behavioral annotations, extract the attribute list and behavioral temporal constraint chain of the entity node, and concatenate the attribute list and the behavioral temporal constraint chain into a component query feature vector. The component query feature vector is input into the pre-trained software component retrieval model, and the pre-trained software component retrieval model internally maintains a mapping index table between each component in the component library and the feature vector space; Perform a nearest neighbor search operation in the mapping index table to find the identifiers of the top few components with the smallest distance to the component's query feature vector; Based on the identified identifier, the corresponding executable component entity is extracted from the component library. Components belonging to the interface display type in the executable component entity are included in the candidate interface component set, and components belonging to the business logic processing type in the executable component entity are included in the candidate logic component set.

[0010] As a further aspect of the present invention, the specific steps for performing assembly sequence planning on the candidate interface component set and the candidate logic component set based on the data flow path set to obtain an executable software package are as follows: Extract the starting data source and ending data target of all paths from the data flow path set, mark the component type corresponding to the starting data source as the entry interface component type, and mark the component type corresponding to the ending data target as the persistent component type; Components that match the entry interface component type are selected from the candidate interface component set as entry interface component instances, and components that match the persistent component type are selected from the candidate logic component set as persistent component instances. According to the order of action nodes passed through each path in the data flow path set, component instances are selected sequentially from the candidate interface component set and the candidate logic component set. After each component instance is selected, the data input interface of the component instance is compared with the data output interface of the previously selected component instance. If the interface signatures match, a data pipeline is established between the component instances. All component instances with established data pipelines are arranged into a component execution chain according to the selection order. The data pipelines between adjacent component instances in the component execution chain are packaged into a data transmission contract. The component execution chain and the data transmission contract are jointly encapsulated into the executable software package.

[0011] As a further aspect of the present invention, after obtaining the executable software package, the method further includes an adaptation injection operation between the executable software package and the target enterprise's operating environment: Collect a set of runtime environment parameters from the target enterprise's operation and maintenance management platform. The set of runtime environment parameters includes an operating system type identifier, a set of database connection strings, and a middleware version number. Parse the data transfer contract in the executable software package, and extract the database access contract segment and the file storage contract segment from the data transfer contract; Replace the placeholder address in the database access contract segment with the master database connection string in the database connection string set, and generate an absolute file storage path that adapts to the current operating system based on the path template in the file storage contract segment and the operating system type identifier. Write the replaced database access contract segment and file storage contract segment back into the data transfer contract to generate an executable software package with environment configuration.

[0012] As a further aspect of the present invention, after generating the executable software package with environment configuration, the method further includes resolving circular dependencies between component instances: Iterate through all component instances in the component execution chain and build a dependency in-degree counter for each component instance. The initial value of the dependency in-degree counter is the number of other component instances that the component instance depends on. Push component instances with a dependency in-degree counter value of zero into the ready queue. Pop component instances from the ready queue one by one and append them to the linearized output sequence. After popping a component instance, traverse the list of successor component instances of the component instance and subtract one count unit from the dependency in-degree counter value of each successor component instance. When the dependency in-degree counter value of a successor component instance becomes zero, the successor component instance is pushed into the ready queue, and the operation of popping component instances from the ready queue is repeated until the ready queue is empty. Check whether the number of component instances in the linearized output sequence is equal to the total number of component instances in the component execution chain. If they are not equal, it is determined that there is a circular dependency. Perform a strongly connected component decomposition operation on the remaining component instances that have not been added to the linearized output sequence, compress the component instances in each strongly connected component into a composite component instance, and insert the composite component instance into the end of the linearized output sequence.

[0013] As a further aspect of the present invention, the specific steps for compressing component instances within each strongly connected component into composite component instances are as follows: Extract the data input interface set and data output interface set of all component instances within the strongly connected component, and expose the interfaces in the data input interface set that are not driven by any internal component instance output interface as external input interfaces of the composite component instance; Expose the interfaces in the set of data output interfaces that are not consumed by any internal component instance input interfaces as external output interfaces of the composite component instance; Analyze the data propagation direction between component instances within the strongly connected component, identify the starting and ending component instances of data propagation, and insert a loop count counter between the starting and ending component instances. The upper limit of the loop count counter is determined by the length of the data flow path within the strongly connected component. The strongly connected component carrying the loop count counter is deployed as an embedded execution body of the composite component instance, and the external input interface and the external output interface are bound to the embedded execution body.

[0014] As a further aspect of the present invention, after inserting the composite component instance at the end of the linearized output sequence, the method further includes performing a redundant path pruning operation on the component instance: Scan the upstream component instances bound to the data input interfaces of each component instance in the linearized output sequence, and record a list of identifiers of all its upstream component instances for each component instance; Starting from the last component instance of the linearized output sequence, traverse backwards and for each upstream component instance in the identifier list of the current component instance, check whether there are two or more different traversal paths from the upstream component instance to the current component instance. When the check result shows that there are two or more different traversal paths, retain the single path with the fewest data pipeline hops, and mark the intermediate component instances corresponding to the other paths as redundant component instances. Remove the redundant component instance from the linearized output sequence, and directly short-connect the data input interface of the removed redundant component instance to the data input interface of the downstream component instance to which its output data flows.

[0015] As a further aspect of the present invention, the present invention also includes an intelligent software generation system for enterprise customization, the system including a processor and a memory, the memory and the processor being connected, the memory being used to store programs, instructions or code, and the processor being used to execute the programs, instructions or code in the memory to implement the intelligent software generation method for enterprise customization as described above.

[0016] The beneficial effects of this invention are: Semantic role labeling is performed on the business process description text to extract the action node sequence and data flow path set from the text content. Unstructured business descriptions can be transformed into standardized and structured process elements. The business behavior logic and data transmission context in the original business documents can be retained and reused in a standardized form. Business information can be directly connected to subsequent software to generate processing flows, reducing the workload of manual organization and decomposition of business documents.

[0017] Based on the data structure definition document, an entity relationship graph is constructed, and each action node in the action node sequence is associated with an entity within the entity relationship graph, generating an enterprise meta-model with behavioral annotation attributes. A stable relationship structure is formed between business behavior elements and enterprise data entities. Business process logic and data organization architecture are integrated within a unified model framework, and business attributes and data attributes are synchronously associated and represented, fully preserving the inherent relationship logic between business and data.

[0018] The enterprise meta-model integrates with a pre-trained software component retrieval model to match and obtain candidate interface component sets and candidate logic component sets from the component library. Automated component selection is achieved through model feature mapping, and the component matching process aligns with the overall business architecture of the enterprise, moving beyond the limitations of single-keyword matching. Assembly sequence planning is performed on candidate components according to the data flow path set. The combination and arrangement of components follow the flow logic of business data, and the component arrangement order aligns with the inherent logic of business operation. The overall software architecture maintains a consistent structural characteristic with the enterprise's original business system. Attached Figure Description

[0019] The invention will now be further described with reference to the accompanying drawings.

[0020] Figure 1 This is a working state diagram of the intelligent software generation method for enterprise customization described in this invention; Figure 2 This is a flowchart illustrating the extraction of action node sequences and data flow paths from semantic role annotations. Figure 3 This is a flowchart for generating the behavioral annotation enterprise metamodel. Detailed Implementation

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

[0022] See Figure 1This invention relates to a method and system for generating intelligent software customized for enterprises, comprising: The process involves collecting business process description text and data structure definition documents from the target enterprise. Semantic role labeling is performed on the business process description text to extract action node sequences and data flow path sets. An entity relationship graph is constructed based on the data structure definition documents. Each action node in the action node sequence is attached to the corresponding entity in the entity relationship graph, generating an enterprise meta-model with behavioral annotations. This enterprise meta-model is then input into a pre-trained software component retrieval model to match candidate interface component sets and candidate logic component sets from the component library. Assembly sequence planning is performed on the candidate interface component sets and candidate logic component sets based on the data flow path set to obtain an executable software package.

[0023] In one embodiment of the present invention, when performing semantic role labeling on the business process description text to extract the action node sequence and data flow path set, refer to... Figure 2 The business process description text is divided into multiple independent statements by periods. Each independent statement is segmented to obtain a word sequence. Each word in the word sequence is mapped to a predefined semantic role label, which includes agent label, patient label, action label, time label, and location label. The words corresponding to the action labels are extracted from the semantic role labeling results of each independent statement as action nodes of the statement. The words corresponding to the agent label and patient label are extracted as the input data source and output data target of the action node. The action nodes of all independent statements are arranged in the time order indicated by the time label to form the action node sequence. The transmission relationship from the input data source of each action node to the action node and then to the output data target of the action node is recorded as a directed data path. The directed data paths corresponding to all independent statements are merged and deduplicated to obtain the data flow path set.

[0024] In practical implementation, the enterprise-customized intelligent software generation method performs semantic role labeling on the business process description text to extract the action node sequence and data flow path set. Taking an internal expense approval process as an example, the following is an example: The target enterprise's business process description text is collected. The text content is: "Finance personnel submit expense documents, department managers review expense documents, finance supervisors verify expense documents, and cashiers pay expense payments." The business process description text is divided into multiple independent statements by periods. Since the above text does not contain periods, it is divided into four independent statements according to actual semantics: the first independent statement is "Finance personnel submit expense documents," the second independent statement is "Department managers review expense documents," the third independent statement is "Finance supervisors verify expense documents," and the fourth independent statement is "Cashier pays expense payments." Each independent statement is segmented to obtain a word sequence. The segmentation results of the first independent statement are "financial personnel", "submit", and "reimbursement form". The segmentation results of the second independent statement are "department manager", "review", and "reimbursement form". The segmentation results of the third independent statement are "financial supervisor", "review", and "reimbursement form". The segmentation results of the fourth independent statement are "cashier", "payment", and "reimbursement amount".

[0025] In some embodiments, each word in the word sequence is mapped to a predefined semantic role label, which includes an agent label, a recipient label, an action label, a time label, and a location label. For the word sequence of the first independent statement, "financial personnel" is mapped to an agent label, "submit" to an action label, and "reimbursement document" to a recipient label. Since there are no words corresponding to the time and location labels in this statement, the time and location labels are mapped to null values. In the second independent statement, "department manager" is mapped to an agent label, "review" to an action label, and "reimbursement document" to a recipient label. In the third independent statement, "financial supervisor" is mapped to an agent label, "review" to an action label, and "reimbursement document" to a recipient label. In the fourth independent statement, "cashier" is mapped to an agent label, "payment" to an action label, and "reimbursement amount" to a recipient label.

[0026] Optionally, words corresponding to action tags are extracted from the semantic role labeling results of each independent statement as action nodes. The action node for the first independent statement is "Submit," for the second independent statement it is "Review," for the third independent statement it is "Verify," and for the fourth independent statement it is "Pay." Words corresponding to the agent and recipient tags are extracted as the input data source and output data target for the action nodes. For the first independent statement, the input data source for the action node "Submit" is "Finance Personnel" corresponding to the agent tag, and the output data target is "Reimbursement Documents" corresponding to the recipient tag. For the second independent statement, the input data source for the action node "Review" is "Department Manager," and the output data target is "Reimbursement Documents." For the third independent statement, the input data source for the action node "Verify" is "Finance Supervisor," and the output data target is "Reimbursement Documents." For the fourth independent statement, the input data source for the action node "Pay" is "Cashier," and the output data target is "Reimbursement Amount."

[0027] It is understood that the action nodes of all independent statements are arranged according to the time sequence indicated by the time tags. Since none of the four independent statements mentioned above have time tags, the default time sequence is the order in which each independent statement appears in the original business process description text, forming the action node sequence "Submit", "Review", "Confirm", and "Pay". The transmission relationship from the input data source of each action node to the action node and then to the output data target of the action node is recorded as a directed data path. The directed data path corresponding to the first independent statement is "Finance Personnel" pointing to "Submit" and then to "Reimbursement Documents". The directed data path corresponding to the second independent statement is "Department Manager" pointing to "Review" and then to "Reimbursement Documents". The directed data path corresponding to the third independent statement is "Finance Supervisor" pointing to "Confirm" and then to "Reimbursement Documents". The directed data path corresponding to all independent statements is merged and deduplicated. The above four directed data paths are different from each other and there are no duplicate paths. After merging, the data flow path set is obtained, which contains four directed data paths.

[0028] In one embodiment of the present invention, when constructing an entity relationship graph based on the data structure definition document, attaching each action node in the action node sequence to the corresponding entity in the entity relationship graph, and generating an enterprise meta-model with behavioral annotations, refer to... Figure 3The data structure definition document is parsed to extract the table name field, the set of field names, and the primary key and foreign key association pairs. Each table name field is defined as an entity node, the set of field names is defined as the attribute list of the entity node, and the primary key and foreign key association pairs are defined as association edges between a pair of entity nodes. For each action node in the action node sequence, the input data source and output data target of the action node are extracted. Entity nodes matching the input data source and output data target are searched in the entity relationship graph. The action nodes are bound to the found entity nodes in the form of annotations. The subset of action nodes bound to the same entity node in the action node sequence is scanned. Each action node in the subset of action nodes is sorted according to the time label to generate the behavioral temporal constraint chain of the entity nodes. The entity relationship graph carrying the behavioral temporal constraint chain is output as the enterprise meta-model with behavioral annotations.

[0029] In practical implementation, the enterprise-customized intelligent software generation method constructs an entity relationship graph based on the data structure definition document, and attaches each action node in the action node sequence to the corresponding entity in the entity relationship graph to generate an enterprise meta-model with behavioral annotations. The following example scenario of an internal expense reimbursement approval process is used for illustration; continuing from the above embodiment, the action node sequence corresponding to the business process description text of the target enterprise is "Submit", "Review", "Verify", and "Pay". The data structure definition document contains a data table named "Expense Form", a data table named "Employee", and a data table named "Approval Record".

[0030] In some embodiments, the data structure definition document is parsed to extract the table name field, the set of field names, and the primary key and foreign key association pairs. Specifically, the table definition statements are read from the data structure definition document. The first table name field is "Reimbursement Form," and the corresponding set of field names includes "Reimbursement Form Number," "Reimbursement Amount," "Reimbursement Reason," "Submitter Number," and "Approval Status." The second table name field is "Employee," and the corresponding set of field names includes "Employee Number," "Employee Name," and "Department Name." The third table name field is "Approval Record," and the corresponding set of field names includes "Record Number," "Reimbursement Form Number," "Approver Number," "Approval Action," and "Approval Time." The primary key and foreign key association pairs include "Submitter Number" in the "Reimbursement Form" table linked to "Employee Number" in the "Employee" table as a foreign key, and "Reimbursement Form Number" in the "Approval Record" table linked to "Reimbursement Form Number" in the "Reimbursement Form" table as a foreign key.

[0031] Optionally, each data table name field is defined as an entity node, the set of field names is defined as the attribute list of the entity node, and the primary key and foreign key association pairs are defined as association edges between a pair of entity nodes. Based on the above extraction results, the first entity node is named "Reimbursement Form," and its attribute list is {Reimbursement Form Number, Reimbursement Amount, Reimbursement Reason, Submitter Number, Approval Status}. The second entity node is named "Employee," and its attribute list is {Employee Number, Employee Name, Department Name}. The third entity node is named "Approval Record," and its attribute list is {Record Number, Report Number, Approval Status}. The system includes the expense report number, approver number, approval action, and approval time. A link is established between the "Expense Report" entity node and the "Employee" entity node, with the direction of the link pointing from "Expense Report" to "Employee," indicating that the "Submitter Number" in the "Expense Report" references the "Employee Number" in the "Employee." Similarly, a link is established between the "Approval Record" entity node and the "Expense Report" entity node, with the direction of the link pointing from "Approval Record" to "Expense Report," indicating that the "Expense Report Number" in the "Approval Record" references the "Expense Report Number" in the "Expense Report," thus forming an entity relationship graph.

[0032] It is understood that for each action node in the action node sequence, the input data source and output data target of the action node are extracted. An entity node matching the input data source and output data target is searched in the entity relationship graph, and the action node is bound to the found entity node in the form of an annotation. The first action node, "Submit," is extracted from the action node sequence, with the input data source being "financial personnel" and the output data target being "reimbursement form." An entity node semantically matching "reimbursement form" is searched in the entity relationship graph, and the "reimbursement form" entity node is found. The action node "Submit" is bound to the "reimbursement form" entity node in the form of an annotation. The second action node, "Approve," is extracted, with the input data source being "department manager" and the output data target being "reimbursement form." Similarly, the "Reimbursement Form" entity node is located, and the action node "Review" is bound to the "Reimbursement Form" entity node as an annotation. The third action node "Review" is retrieved, with the input data source being "Finance Supervisor" and the output data target being "Reimbursement Form". The action node "Review" is bound to the "Reimbursement Form" entity node. The fourth action node "Payment" is retrieved, with the input data source being "Cashier" and the output data target being "Reimbursement Amount". The entity node matching "Reimbursement Amount" in the entity relationship graph is searched. If no completely matching entity node is found, it is associated with the "Reimbursement Form" entity node according to the semantics of the output data target. Since "Reimbursement Amount" corresponds to the "Reimbursement Amount" attribute in "Reimbursement Form", the action node "Payment" is bound to the "Reimbursement Form" entity node.

[0033] In specific implementation, the subset of action nodes bound to the same entity node in the action node sequence is scanned, and each action node in the subset is sorted according to the time tag to generate the behavioral timing constraint chain of the entity node. The subset of action nodes bound to the "Reimbursement Form" entity node includes "Submit", "Review", "Review", and "Pay". Since no time tag was extracted for each independent statement in the aforementioned semantic role labeling operation, the order of appearance of the action nodes in the original action node sequence is used as the sorting basis: "Submit" is in the first position, "Review" is in the second position, "Review" is in the third position, and "Pay" is in the fourth position. This generates the behavioral timing constraint chain of the "Reimbursement Form" entity node. The content of the constraint chain is that the submission action must be executed before the review action, the review action must be executed before the review action, and the review action must be executed before the payment action. For the "Employee" entity node and the "Approval Record" entity node, no action nodes are bound to them, and their behavioral timing constraint chains are empty.

[0034] Optionally, the entity relationship graph carrying the behavioral temporal constraint chain is output as the enterprise meta-model with behavioral annotations. Specifically, the entity relationship graph contains three entity nodes ("expense report", "employee", and "approval record"), two association edges, and a behavioral temporal constraint chain attached to the "expense report" entity node. Each entity node, each association edge, and the behavioral temporal constraint chain bound to each entity node in the entity relationship graph are serialized into a structured document in JavaScript object representation format. This structured document is the enterprise meta-model with behavioral annotations. The enterprise meta-model contains the following mathematical relationship to express the strict order of the constraint chain: for any two action nodes bound to the same entity node... and If the time tag indicates Prior to Then a relationship exists. ,in Represents action nodes The order value in the behavior timing constraint chain, which starts from 1 and increments, ensures that subsequent components are assembled in the correct order.

[0035] In one embodiment of the present invention, when the enterprise meta-model is input into a pre-trained software component retrieval model and candidate interface component sets and candidate logic component sets are matched from the component library, each entity node in the enterprise meta-model with behavioral annotations is traversed, and the attribute list and behavioral temporal constraint chain of the entity node are extracted. The attribute list and the behavioral temporal constraint chain are concatenated into a component query feature vector. The component query feature vector is input into the pre-trained software component retrieval model. The pre-trained software component retrieval model internally maintains a mapping index table between each component in the component library and the feature vector space. A nearest neighbor search operation is performed in the mapping index table to find the identifier codes of the top few components with the smallest distance to the component query feature vector. Based on the found identifier codes, the corresponding executable component entities are extracted from the component library. Components of the executable component entities belonging to the interface display type are included in the candidate interface component set, and components of the executable component entities belonging to the business logic processing type are included in the candidate logic component set. When performing assembly sequence planning on the candidate interface component set and the candidate logic component set based on the data flow path set, the starting data source and ending data target of all paths are extracted from the data flow path set. The component type corresponding to the starting data source is marked as the entry interface component type, and the component type corresponding to the ending data target is marked as the persistent component type. Components that conform to the entry interface component type are selected from the candidate interface component set as entry interface component instances, and components that conform to the persistent component type are selected from the candidate logic component set as persistent component instances. Component instances are selected sequentially from the candidate interface component set and the candidate logic component set according to the order of action nodes traversed by each path in the data flow path set. After each component instance is selected, the data input interface of the component instance is compared with the data output interface of the previously selected component instance. If the interface signatures match, a data pipeline is established between the component instances. All component instances with established data pipelines are arranged into a component execution chain according to the selection order. The data pipelines between adjacent component instances in the component execution chain are packaged into a data transmission contract. The component execution chain and the data transmission contract are jointly encapsulated into the executable software package.

[0036] In practical implementation, the enterprise-customized intelligent software generation method inputs the enterprise metamodel into a pre-trained software component retrieval model, matches candidate interface component sets and candidate logic component sets from the component library, and performs assembly sequence planning on the candidate interface component sets and candidate logic component sets according to the data flow path set to obtain an executable software package. The following example scenario of an enterprise expense reimbursement approval process illustrates this. Using the enterprise metamodel with behavioral annotations generated in some embodiments, this enterprise metamodel contains a "reimbursement form" entity node, whose attribute list is {reimbursement form number, reimbursement amount, reimbursement reason, submitter number, approval status}, and its behavioral sequence is approximately... The chain contains sequential constraints for four action nodes: "Submit", "Review", "Confirm", and "Pay". The attribute list for the "Employee" entity node is {Employee ID, Employee Name, Department Name}. The attribute list for the "Approval Record" entity node is {Record Number, Expense Form Number, Approver Number, Approval Action, Approval Time}. The entity relationship graph contains the association edges from "Expense Form" to "Employee" and from "Approval Record" to "Expense Form". The data flow path set contains four directed data paths: "Finance Personnel → Submit → Expense Form", "Department Manager → Review → Expense Form", "Finance Supervisor → Confirm → Expense Form", and "Cashier → Pay → Expense Payment".

[0037] In some embodiments, each entity node in the enterprise metamodel with behavioral annotations is traversed, and the attribute list and behavioral temporal constraint chain of the entity node are extracted. The attribute list and the behavioral temporal constraint chain are concatenated into a component query feature vector. For the "Expense Report" entity node, the five attribute names in the attribute list and the order relationship of the four action nodes in the behavioral temporal constraint chain are extracted. The attribute name string and the action node order string are concatenated into a one-dimensional feature vector in a fixed order. The dimension of the vector is equal to the number of attribute names multiplied by the encoding length of each attribute name plus the number of action nodes multiplied by the encoding length of each action node. The value is the corresponding numerical value in the embedding representation space of each component. For the "Employee" entity node and the "Approval Record" entity node, since there is no behavioral temporal constraint chain, only the attribute list is concatenated into a component query feature vector.

[0038] In specific implementation, the component query feature vector is input into the pre-trained software component retrieval model. The pre-trained software component retrieval model internally maintains a mapping index table between each component in the component library and the feature vector space. The pre-trained software component retrieval model adopts an encoder structure based on residual networks. This model has been trained offline using a large amount of labeled component usage scenario data. The component library stores more than two thousand reusable software components. When each component is stored in the component library, the corresponding feature vector has been calculated by the encoder and stored in the mapping index table along with the component's identifier. The mapping index table adopts an index structure based on locality-sensitive hashing, which supports fast lookup of approximate nearest neighbors.

[0039] Optionally, a nearest neighbor search operation is performed in the mapping index table to find the identifiers of the top few components with the smallest distance to the component's query feature vector; Euclidean distance is used as the distance metric, and the distance calculation formula is:

[0040] in: This indicates that the component queries the feature vector. This represents the feature vector of a component in the component library. This represents the total number of dimensions of the feature vector. This indicates that the component query feature vector is at the 1st position. Values ​​in the dimension The feature vector of a component in the component library is represented in the first position. Values ​​in the dimension This represents the Euclidean distance between the two; for the component query feature vector of the "reimbursement form" entity node, perform a nearest neighbor search in the mapping index table to find the identifiers of the five components with the smallest Euclidean distance.

[0041] Understandably, based on the identified identifiers, corresponding executable component entities are extracted from the component library. Components belonging to the interface display type are categorized into the candidate interface component set, and components belonging to the business logic processing type are categorized into the candidate logic component set. Based on the five identified identifiers, five executable component entities are extracted from the component library. Two of these components are interface display type: "Expense Submission Interface Component" and "Expense List Display Component," which are categorized into the candidate interface component set. The other three components are business logic processing type: "Expense Amount Verification Logic Component," "Approval Process Driving Logic Component," and "Payment Interface Call Logic Component," which are categorized into the candidate logic component set.

[0042] In specific implementation, when performing assembly sequence planning on the candidate interface component set and the candidate logical component set based on the data flow path set, the starting data source and ending data target of all paths are extracted from the data flow path set. The component type corresponding to the starting data source is marked as the entry interface component type, and the component type corresponding to the ending data target is marked as the persistent component type. The starting data sources of the four paths in the data flow path set are "financial personnel", "department manager", "financial supervisor" and "cashier", all of which belong to personnel roles. These starting data sources require the interface components to be able to receive personnel input, so the entry interface component type is marked as "personnel input interface type". The ending data targets of the four paths are "reimbursement document", "reimbursement document", "reimbursement document" and "reimbursement amount". Among them, "reimbursement document" and "reimbursement amount" need to be written to the database for persistent storage, so the persistent component type is marked as "database write component type".

[0043] In some embodiments, components that conform to the entry interface component type are selected from the candidate interface component set as entry interface component instances, and components that conform to the persistent component type are selected from the candidate logic component set as persistent component instances. The candidate interface component set includes a "reimbursement form submission interface component" and a "reimbursement form list display component". The "reimbursement form submission interface component" can receive reimbursement form data input by financial personnel, which meets the requirements of "personnel input interface type", so the "reimbursement form submission interface component" is used as an entry interface component instance. The candidate logic component set includes a "reimbursement amount verification logic component", an "approval process driving logic component", and a "payment interface call logic component". The "payment interface call logic component" does not involve database writing, and the "reimbursement amount verification logic component" also does not involve database writing. The "approval process driving logic component" includes the function of updating the approval status to the database, which meets the requirements of "database write component type", so the "approval process driving logic component" is used as a persistent component instance.

[0044] Optionally, according to the order of action nodes traversed by each path in the data flow path set, component instances are selected sequentially from the candidate interface component set and the candidate logic component set. After each component instance is selected, the data input interface of the component instance is compared with the data output interface of the previously selected component instance. If the interface signatures match, a data pipeline is established between the component instances. The action node order in the data flow path set is "Submit", "Review", "Verify", and "Pay". First, the entry interface component instance "Reimbursement Form Submission Interface Component" is selected as the first component instance, and its data output interface signature is defined as "Reimbursement Form Data Structure". Then, the component instance corresponding to the "Review" action is selected from the candidate interface component set and the candidate logic component set. The "Approval Process Driven Logic Component" is selected as the second component instance, and the data input interface signature of this component instance is defined as "Reimbursement Form Data Structure", which matches the data output interface signature of the previous component instance, thus establishing a data pipeline between the two. Next, the component instance corresponding to the "Verify" action is selected. For component instances, since the "Approval Process Driven Logic Component" can already handle the review and verification logic, it is selected as the third component instance. Its data input interface and its own data output interface signature are consistent, establishing a self-looping data pipeline. Finally, the component instance corresponding to the "Payment" action is selected. From the candidate logic component set, the "Payment Interface Call Logic Component" is selected as the fourth component instance. The data input interface signature of this component instance is defined as "Payment Request Data Structure," while the data output interface signature of the "Approval Process Driven Logic Component" is "Approval Result Data Structure." The interface signatures of the two are inconsistent, so no data pipeline is established. At this point, a backtracking search is conducted to see if there are other component instances that can match. The "Reimbursement Amount Verification Logic Component" is selected as an intermediate bridge from the candidate logic component set. However, the data input interface signature of the "Reimbursement Amount Verification Logic Component" is "Reimbursement Document Data Structure," and the data output interface signature is "Amount Value Data Structure," which still cannot match the "Payment Request Data Structure." Therefore, the establishment of this pipeline is abandoned, and ultimately only the data pipeline between the first three component instances is established.

[0045] It can be understood that all component instances with established data pipelines are arranged into a component execution chain according to the selection order. The data pipelines between adjacent component instances in the component execution chain are packaged into a data transmission contract. The component execution chain and the data transmission contract are jointly encapsulated into the executable software package. There are three component instances with established data pipelines, arranged in the following order: "Expense Submission Interface Component", "Approval Process Driven Logic Component" (first appearance), and "Approval Process Driven Logic Component" (second appearance), arranged into a component execution chain. There are two data pipelines between adjacent component instances. The first pipeline connects the "Expense Submission Interface Component" with the first "Approval Process Driven Logic Component", and the second pipeline connects the first "Approval Process Driven Logic Component" with the second "Approval Process Driven Logic Component". These two pipelines are packaged into a data transmission contract. The data transmission contract uses Extensible Markup Language (Extreme Markup Language) to describe the source component identifier, target component identifier, and data structure definition of each pipeline. The component execution chain is stored in the form of an array in JavaScript object notation format and encapsulated together with the data transmission contract into a compressed archive file. This compressed archive file is the executable software package. Refer to Table 1, which describes the correspondence between the candidate components matched from the component library and their type affiliation in this embodiment.

[0046] Table 1: Correspondence between Candidate Components and Types ; In one embodiment of the present invention, after obtaining the executable software package, an adaptation injection operation between the software package and the target enterprise's operating environment is performed. A set of operating environment parameters is collected from the target enterprise's operation and maintenance management platform. This set includes an operating system type identifier, a database connection string set, and a middleware version number. The data transmission contract in the executable software package is parsed, and a database access contract segment and a file storage contract segment are extracted from the data transmission contract. The placeholder address in the database access contract segment is replaced according to the master database connection string in the database connection string set. An absolute file storage path adapted to the current operating system is generated based on the path template in the file storage contract segment and the operating system type identifier. The replaced database access contract segment and file storage contract segment are written back into the data transmission contract, generating an executable software package with environment configuration. After generating an executable package with environment configuration, a circular dependency resolution operation is performed between component instances. This involves traversing all component instances in the component execution chain, establishing a dependency in-degree counter for each component instance, with the initial value being the number of other component instances that the component instance depends on. Component instances with a dependency in-degree counter value of zero are pushed into a ready queue. Component instances are then sequentially popped from the ready queue and appended to the linearized output sequence. After each popped component instance, the list of successor component instances is traversed, and the dependency in-degree counter value of each successor component instance is decremented by one. For each counting unit, when the in-degree counter value of a subsequent component instance becomes zero, the subsequent component instance is pushed into the ready queue. The operation of popping component instances from the ready queue is repeated until the ready queue is empty. The number of component instances in the linearized output sequence is checked to see if it is equal to the total number of component instances in the component execution chain. If they are not equal, a circular dependency is determined. Strongly connected component decomposition is performed on the remaining component instances that have not been added to the linearized output sequence. The component instances in each strongly connected component are compressed into composite component instances, and the composite component instances are inserted into the end of the linearized output sequence.

[0047] In specific implementation, after obtaining the executable software package, the adaptation and injection operation between the software package and the target enterprise's operating environment is performed. The following description is based on the deployment scenario of an enterprise expense reimbursement approval software package. Continuing with the executable software package generated in the above embodiment, the executable software package contains the component execution chain of "Expense Reimbursement Form Submission Interface Component", "Approval Process Driving Logic Component", "Approval Process Driving Logic Component", and the data transmission contract contains the definition of two data pipelines. The first data pipeline carries a database access contract segment for reading employee information, and the second data pipeline carries a file storage contract segment for saving the upload path of approval attachments.

[0048] In some embodiments, a set of runtime environment parameters is collected from the target enterprise's operation and maintenance management platform. The set of runtime environment parameters includes an operating system type identifier, a set of database connection strings, and a middleware version number. The target enterprise's operation and maintenance management platform is a centralized configuration center based on an open system monitoring architecture. The runtime environment parameters are obtained through a Hypertext Transfer Protocol interface call. The collected operating system type identifier is "Linux". The set of database connection strings includes the master database connection string "jdbc:mysql: / / 192.168.1.100:3306 / erp_db" and the slave database connection string "jdbc:mysql: / / 192.168.1.101:3306 / erp_db". The middleware version number is "SpringBoot2.7.0".

[0049] Optionally, the data transfer contract in the executable software package is parsed, and a database access contract segment and a file storage contract segment are extracted from the data transfer contract. The data transfer contract is stored in Extensible Markup Language (XML) format. The node tree structure of the XML document is parsed, the node with the tag name "DatabaseAccessContract" is found, and the content of its child nodes is extracted as the database access contract segment. The database access contract segment contains placeholder addresses. {db.slave.url} and the database driver class name "com.mysql.jdbc.Driver"; find the node with the tag name "FileStorageContract", extract the content of its child nodes as the file storage contract segment, and the file storage contract segment contains the path template " / var / data / attachments / {month} / ” and the filename generation rule “uuid” format.

[0050] In specific implementation, the placeholder address in the database access contract segment is replaced with the master database connection string from the database connection string set; an absolute file storage path adapted to the current operating system is generated based on the path template in the file storage contract segment and the operating system type identifier; the placeholder address in the database access contract segment is then... Replace "{db.slave.url}" with the slave connection string "jdbc:mysql: / / 192.168.1.101:3306 / erp_db"; for the path template " / var / data / attachments / " in the file storage contract segment. The operating system type is identified as "Linux" and the forward slash separator in the path template is compatible with the Linux operating system, so no conversion is required. When generating the absolute path of the file, the placeholder will be dynamically replaced with the actual date value. After replacement, the absolute path will be " / var / data / attachments / 2026 / 05 / ".

[0051] It is understood that the replaced database access contract segment and file storage contract segment are written back into the data transmission contract to generate an executable software package with environment configuration; the database access contract segment after replacing the placeholder address is serialized into an Extensible Markup Language node and written back to the original database access contract segment position of the data transmission contract; the generated absolute file storage path is written into the file storage contract segment to replace the original path template; the data transmission contract written back contains the specific database connection address and the specific file storage path; the updated data transmission contract and the original component execution chain are repackaged into a compressed archive file to generate an executable software package with environment configuration.

[0052] In practical implementation, after generating the executable software package with environment configuration, the circular dependency resolution operation between component instances is performed. The component execution chain in the aforementioned executable software package with environment configuration is continued. The component execution chain contains three component instances: the first component instance "Expense Submission Interface Component", the second component instance "Approval Process Driving Logic Component", and the third component instance "Approval Process Driving Logic Component". The second and third component instances logically have a mutual calling relationship. All component instances in the component execution chain are traversed, and a dependency in-degree counter is established for each component instance. The initial value of the dependency in-degree counter is the number of other component instances that the component instance depends on. The first component instance "Expense Submission Interface Component" does not depend on any other component instances; its dependency in-degree... The dependency in-degree counter value is 0. The second component instance, "Approval Process Driven Logic Component", depends on the first component instance, and its dependency in-degree counter value is 1. The third component instance, "Approval Process Driven Logic Component", depends on the second component instance, and its dependency in-degree counter value is 1. At the same time, the second component instance asynchronously calls back a method in the third component instance, resulting in an implicit circular dependency relationship. In the actual dependency graph, the third component instance depends on the second component instance, and the second component instance also depends on the third component instance. Therefore, the dependency in-degree counter values ​​of the second and third component instances need to be calculated bidirectionally. After correction, the dependency in-degree counter value of the second component instance is 2 (depending on the first and third component instances), and the dependency in-degree counter value of the third component instance is 2 (depending on the first and second component instances).

[0053] In some embodiments, component instances with an in-degree dependency counter of zero are pushed into a ready queue, and component instances are popped from the ready queue and appended to the linearized output sequence in sequence; the first component instance has an in-degree dependency counter of 0, so the first component instance is pushed into the ready queue; the first component instance is popped from the ready queue and appended to the linearized output sequence, where the first element of the linearized output sequence is the first component instance.

[0054] Optionally, after popping each component instance, the list of successor component instances is traversed, and the dependency in-degree counter of each successor component instance is decremented by one unit. The list of successor component instances for the first component instance includes the second component instance; the dependency in-degree counter of the second component instance is decremented from 2 to 1. At this point, there are no other component instances whose dependency in-degree counters become 0, the ready queue is empty, and the linearized output sequence contains only the first component instance, not yet the second or third component instances. When a successor component instance's dependency in-degree counter becomes zero, the successor component instance is pushed into the ready queue. This process of popping component instances from the ready queue is repeated until the ready queue is empty. Since the dependency in-degree counters of the second and third component instances are both 1 (not 0), they cannot be pushed into the ready queue. After the loop is completed, the linearized output sequence contains only the first component instance.

[0055] It is understood that the process involves checking whether the number of component instances in the linearized output sequence is equal to the total number of component instances in the component execution chain. If the linearized output sequence contains one component instance and the component execution chain contains three component instances, then 1 is not equal to 3, indicating a circular dependency. For the remaining component instances not added to the linearized output sequence, a strongly connected component decomposition operation is performed. The remaining component instances are the second and third component instances. A depth-first search-based Talyan algorithm is used for strongly connected component decomposition, ensuring that the second and third component instances are mutually reachable, forming a strongly connected component. Component instances within each strongly connected component are compressed into composite component instances, which are then inserted at the end of the linearized output sequence. Finally, the second and third component instances are compressed into a single composite component instance, named "Approval Process Composite Component Instance," and inserted at the end of the linearized output sequence. The linearized output sequence is then updated to include the first component instance followed by the composite component instance. Refer to Table 2, which describes the dependency relationships of component instances and the changes in their in-degree counters in this embodiment.

[0056] Table 2: Component Instance Dependencies and In-degree Counter Changes ; In one embodiment of the present invention, when compressing component instances within each strongly connected component into composite component instances, the data input interface set and data output interface set of all component instances within the strongly connected component are extracted. Interfaces in the data input interface set that are not driven by any internal component instance output interface are exposed as external input interfaces of the composite component instance. Interfaces in the data output interface set that are not consumed by any internal component instance input interface are exposed as external output interfaces of the composite component instance. The data propagation direction between component instances within the strongly connected component is analyzed to identify the starting and ending component instances of data propagation. A loop count counter is inserted between the starting and ending component instances. The upper limit of the loop count counter is determined by the length of the data flow path within the strongly connected component. The strongly connected component carrying the loop count counter is deployed as an embedded execution body of the composite component instance. The external input interface and the external output interface are bound to the embedded execution body. After inserting the composite component instance at the end of the linearized output sequence, perform redundant path pruning on the component instance. Scan the upstream component instances bound to the data input interfaces of each component instance in the linearized output sequence, record the identifier list of all upstream component instances for each component instance, and traverse backwards starting from the last component instance in the linearized output sequence. For each upstream component instance in the identifier list of the current component instance, check whether there are two or more different traversal paths from the upstream component instance to the current component instance. When the check result is that there are two or more different traversal paths, retain the single path with the fewest data pipeline hops, mark the intermediate component instances corresponding to the remaining paths as redundant component instances, remove the redundant component instances from the linearized output sequence, and directly short-connect the data input interface of the removed redundant component instance to the data input interface of the downstream component instance to which its output data flows.

[0057] In specific implementation, the component instances within each strongly connected component are compressed into composite component instances. The following description is based on the circular dependency handling scenario in the enterprise expense reimbursement approval software package. Continuing with the strongly connected component identified in the above embodiment, the strongly connected component contains a second component instance "approval process driven logic component" and a third component instance "approval process driven logic component". The two component instances call each other to form a closed loop.

[0058] In some embodiments, the data input interface set and data output interface set of all component instances within the strongly connected component are extracted; for the second component instance "Approval Process Driven Logic Component", its data input interface includes "Approval Request Input Interface" and "Callback Trigger Input Interface", and its data output interface includes "Approval Status Output Interface" and "Callback Registration Output Interface"; for the third component instance "Approval Process Driven Logic Component", its data input interface includes "Approval Status Input Interface" and "Next Step Trigger Interface", and its data output interface includes "Approval Result Output Interface" and "Process Progress Complete Interface"; after merging and deduplicating the above four data input interfaces and four data output interfaces, the data input interface set is {Approval Request Input Interface, Callback Trigger Input Interface, Approval Status Input Interface, Next Step Trigger Interface}, and the data output interface set is {Approval Status Output Interface, Callback Registration Output Interface, Approval Result Output Interface, Process Progress Complete Interface}.

[0059] Optionally, interfaces in the data input interface set that are not driven by any internal component instance output interface are exposed as external input interfaces of the composite component instance. It is checked whether each interface in the data input interface set has a corresponding internal component instance output interface providing data driving. The approval request input interface is not driven by any internal component instance output interface, the callback trigger input interface is not driven by any internal component instance output interface, the approval status input interface is driven by the approval result output interface of the third component instance (because the output interface of the third component instance can send data to the approval status input interface of the second component instance), and the next step trigger interface is driven by the process completion interface of the second component instance. Therefore, the approval request input interface and the callback trigger input interface that are not driven by any internal component instance output interface are exposed as external input interfaces of the composite component instance.

[0060] In specific implementation, interfaces in the data output interface set that are not consumed by any internal component instance input interface are exposed as external output interfaces of the composite component instance; it is checked whether each interface in the data output interface set has a corresponding internal component instance input interface consuming its output data. The approval status output interface is consumed by the input interface of the second component instance itself (forming an internal closed loop), the callback registration output interface is not consumed by any internal component instance input interface, the approval result output interface is consumed by the approval status input interface of the second component instance, and the process completion interface is consumed by the next step trigger interface of the third component instance; therefore, the callback registration output interface that is not consumed by any internal component instance input interface is exposed as an external output interface of the composite component instance.

[0061] It is understood that by analyzing the data propagation direction between component instances within the strongly connected component, the starting and ending component instances of data propagation are identified. The data flow is traced starting from the exposed external input interface. The approval request input interface connects to the approval request input interface of the second component instance. After processing, the second component instance transmits the data to the approval status input interface of the third component instance through the approval status output interface. After processing, the third component instance returns the data to the next step trigger interface of the second component instance through the process completion interface, forming a closed loop. Data propagates repeatedly within this loop. The starting point of propagation is the moment when the second component instance receives external input, and the ending point is the moment when a certain condition within the loop is met, the third component instance generates the final approval result and transmits it outward through the approval result output interface. Therefore, the second component instance is marked as the starting component instance, and the third component instance is marked as the ending component instance.

[0062] In some embodiments, a loop count counter is inserted between the starting component instance and the ending component instance. The upper limit of the loop count counter is determined by the length of the data flow path within the strongly connected component. The data flow path within the strongly connected component passes through the second component instance and the third component instance. Each loop from the second component instance to the third component instance and back to the second component instance is counted as a complete cycle. The length of the data flow path is defined as the minimum number of component instances traversed from the input interface of one component instance to the output interface of another component instance. Here, the path length is 2 (from the second component instance to the third component instance and back to the second component instance). The formula for calculating the upper limit of the loop count counter is:

[0063] in: This indicates the upper limit of the loop count counter. This indicates the maximum number of repetitions allowed in the business process containing the strongly connected component (3, obtained from external business rules). The value 2 represents the length of the data flow path in a single loop. The calculated upper limit is 1, meaning that the loop will execute at most once. The loop count counter is inserted between the output interface of the starting component instance and the input interface of the ending component instance. The initial value is set to 0. The counter is incremented by 1 after each loop. The loop will exit when the counter reaches the upper limit of 1.

[0064] In specific implementation, the strongly connected component carrying the loop counter is deployed as an embedded execution body of the composite component instance, and the external input interface and the external output interface are bound to the embedded execution body. The second component instance, the third component instance, and the inserted loop counter are encapsulated together into an embedded execution body, which is deployed in a containerized manner and internally maintains the calling relationship and loop control logic between component instances. The approval request input interface in the external input interface is bound to the corresponding input interface of the second component instance in the embedded execution body, and the callback trigger input interface in the external input interface is bound to the callback processing entry point of the second component instance in the embedded execution body. The callback registration output interface in the external output interface is bound to the callback registration exposure endpoint of the second component instance in the embedded execution body. After the binding is completed, a composite component instance is formed, which appears to the outside as a single executable unit.

[0065] In specific implementation, after inserting the composite component instance at the end of the linearized output sequence, a redundant path pruning operation is performed on the component instance. The linearized output sequence of the above-mentioned enterprise expense reimbursement approval software package is continued to be used. This sequence includes the first component instance "Expense Submission Interface Component" and the composite component instance "Approval Process Composite Component Instance". The upstream component instances bound to the data input interface of each component instance in the linearized output sequence are scanned, and the identification code list of all upstream component instances of each component instance is recorded. The data input interface of the first component instance "Expense Submission Interface Component" is bound to external user input and has no upstream component instance. Its upstream component instance identification code list is... The table is empty; the data input interface of the composite component instance "Approval Process Composite Component Instance" is bound to two sources. One is the output interface of the first component instance, which is directly connected. The other is indirectly reached from the first component instance through an intermediate component instance via a data pipeline implicit in the sequence. In fact, there is a redundant path in the previous component execution chain. That is, before the second and third component instances are compressed, the output interface of one of the component instances is also connected to the data input interface of the composite component instance through another branch path. Therefore, the upstream component instance identifier list of the composite component instance contains the first component instance and an intermediate component instance "Intermediate Forwarding Component" that has disappeared.

[0066] Optionally, starting from the last component instance of the linearized output sequence, the process reverses and checks for two or more different traversal paths from the upstream component instance to the current component instance for each upstream component instance in the identifier list of the current component instance. Starting from the last component instance, i.e. the composite component instance, the process reverses and takes the first upstream component instance "first component instance" in the upstream component instance identifier list. The process checks for traversal paths from the first component instance to the composite component instance. There are two different paths: the first path is where the first component instance directly connects to the composite component instance through the data pipeline, and the second path is where the first component instance connects to the composite component instance through an intermediate forwarding component.

[0067] It is understandable that when the check result shows that there are two or more different traversal paths, the single path with the fewest data pipeline hops is retained, and the intermediate component instances corresponding to the other paths are marked as redundant component instances. The data pipeline hop count of the first path is 1 (passing through one data pipeline), and the data pipeline hop count of the second path is 2 (passing through the data pipeline from the first component instance to the intermediate forwarding component and the data pipeline from the intermediate forwarding component to the composite component instance). The path with the fewest hops is the first path, and the intermediate component instance "intermediate forwarding component" corresponding to the second path is marked as a redundant component instance.

[0068] In specific implementation, the redundant component instance is removed from the linearized output sequence, and the data input interface of the removed redundant component instance is directly shorted to the data input interface of the downstream component instance to which its output data flows. There is no "intermediate forwarding component" instance in the linearized output sequence (because this component instance has been implicitly removed in the compression step, but its data path remains). The short-circuiting operation is directly performed to direct the data flow that originally flowed to the data input interface of the "intermediate forwarding component" to the data input interface of its downstream component instance, i.e., the composite component instance. After the short-circuiting, the data input interface of the composite component instance only retains the direct connection from the first component instance, and the redundant data path is eliminated.

[0069] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A method for generating intelligent software customized for enterprises, characterized in that: Includes the following steps: Collect the target company's business process description text and data structure definition documents; Perform semantic role labeling on the business process description text to extract the action node sequence and data flow path set; Based on the data structure definition document, an entity relationship graph is constructed, and each action node in the action node sequence is attached to the corresponding entity in the entity relationship graph to generate an enterprise meta-model with behavioral annotations. The enterprise meta-model is input into a pre-trained software component retrieval model to match candidate interface component sets and candidate logic component sets from the component library; Based on the data flow path set, an assembly sequence plan is performed on the candidate interface component set and the candidate logic component set to obtain an executable software package.

2. The intelligent software generation method for enterprise customization according to claim 1, characterized in that, The specific steps for performing semantic role labeling on the business process description text to extract the action node sequence and data flow path set are as follows: The business process description text is divided into multiple independent sentences by periods, and word segmentation is performed on each independent sentence to obtain a word sequence; Each word in the word sequence is mapped to a predefined semantic role label, which includes agent label, patient label, action label, time label, and location label; From the semantic role labeling results of each independent statement, the words corresponding to the action tags are extracted as the action nodes of the statement, and the words corresponding to the agent tags and patient tags are extracted as the input data source and output data target of the action nodes. Arrange the action nodes of all independent statements in the time order indicated by the time tags to form the action node sequence; The transmission relationship from the input data source of each action node to the action node and then to the output data target of the action node is recorded as a directed data path. The set of data flow paths is obtained by merging and deduplicating the directed data paths corresponding to all independent statements.

3. The intelligent software generation method for enterprise customization according to claim 2, characterized in that, The specific steps for constructing an entity relationship graph based on the data structure definition document, attaching each action node in the action node sequence to the corresponding entity in the entity relationship graph, and generating an enterprise meta-model with behavioral annotations are as follows: Parse the data structure definition document to extract the data table name field, the field name set, and the primary key and foreign key association pairs. Define each data table name field as an entity node, define the field name set as the attribute list of the entity node, and define the primary key and foreign key association pairs as the association edges between a pair of entity nodes. For each action node in the action node sequence, extract the input data source and output data target of the action node, find the entity node that matches the input data source and output data target in the entity relationship graph, and bind the action node to the found entity node in the form of annotation; Scan the subset of action nodes in the action node sequence that are bound to the same entity node, sort each action node in the action node subset according to the time label, and generate the behavior time sequence constraint chain of the entity node. The entity relationship graph carrying the behavioral temporal constraint chain is output as the enterprise meta-model with behavioral annotations.

4. The intelligent software generation method for enterprise customization according to claim 3, characterized in that, The specific steps for inputting the enterprise meta-model into the pre-trained software component retrieval model to match the candidate interface component set and candidate logic component set from the component library are as follows: Traverse each entity node in the enterprise metamodel with behavioral annotations, extract the attribute list and behavioral temporal constraint chain of the entity node, and concatenate the attribute list and the behavioral temporal constraint chain into a component query feature vector. The component query feature vector is input into the pre-trained software component retrieval model, and the pre-trained software component retrieval model internally maintains a mapping index table between each component in the component library and the feature vector space; Perform a nearest neighbor search operation in the mapping index table to find the identifiers of the top few components with the smallest distance to the component's query feature vector; Based on the identified identifier, the corresponding executable component entity is extracted from the component library. Components belonging to the interface display type in the executable component entity are included in the candidate interface component set, and components belonging to the business logic processing type in the executable component entity are included in the candidate logic component set.

5. The intelligent software generation method for enterprise customization according to claim 4, characterized in that, The specific steps for performing assembly sequence planning on the candidate interface component set and the candidate logic component set based on the data flow path set to obtain the executable software package are as follows: Extract the starting data source and ending data target of all paths from the data flow path set, mark the component type corresponding to the starting data source as the entry interface component type, and mark the component type corresponding to the ending data target as the persistent component type; Components that match the entry interface component type are selected from the candidate interface component set as entry interface component instances, and components that match the persistent component type are selected from the candidate logic component set as persistent component instances. According to the order of action nodes passed through each path in the data flow path set, component instances are selected sequentially from the candidate interface component set and the candidate logic component set. After each component instance is selected, the data input interface of the component instance is compared with the data output interface of the previously selected component instance. If the interface signatures match, a data pipeline is established between the component instances. All component instances with established data pipelines are arranged into a component execution chain according to the selection order. The data pipelines between adjacent component instances in the component execution chain are packaged into a data transmission contract. The component execution chain and the data transmission contract are jointly encapsulated into the executable software package.

6. The intelligent software generation method for enterprise customization according to claim 5, characterized in that, After obtaining the executable software package, the process also includes the adaptation and injection operation between the executable software package and the target enterprise's runtime environment: Collect a set of runtime environment parameters from the target enterprise's operation and maintenance management platform. The set of runtime environment parameters includes an operating system type identifier, a set of database connection strings, and a middleware version number. Parse the data transfer contract in the executable software package, and extract the database access contract segment and the file storage contract segment from the data transfer contract; Replace the placeholder address in the database access contract segment with the master database connection string in the database connection string set, and generate an absolute file storage path that adapts to the current operating system based on the path template in the file storage contract segment and the operating system type identifier. Write the replaced database access contract segment and file storage contract segment back into the data transfer contract to generate an executable software package with environment configuration.

7. The intelligent software generation method for enterprise customization according to claim 6, characterized in that, After generating the executable package with environment configuration, the process also includes resolving circular dependencies between component instances: Iterate through all component instances in the component execution chain and build a dependency in-degree counter for each component instance. The initial value of the dependency in-degree counter is the number of other component instances that the component instance depends on. Push component instances with a dependency in-degree counter value of zero into the ready queue. Pop component instances from the ready queue one by one and append them to the linearized output sequence. After popping a component instance, traverse the list of successor component instances of the component instance and subtract one count unit from the dependency in-degree counter value of each successor component instance. When the dependency in-degree counter value of a successor component instance becomes zero, the successor component instance is pushed into the ready queue, and the operation of popping component instances from the ready queue is repeated until the ready queue is empty. Check whether the number of component instances in the linearized output sequence is equal to the total number of component instances in the component execution chain. If they are not equal, it is determined that there is a circular dependency. Perform a strongly connected component decomposition operation on the remaining component instances that have not been added to the linearized output sequence, compress the component instances in each strongly connected component into a composite component instance, and insert the composite component instance into the end of the linearized output sequence.

8. The intelligent software generation method for enterprise customization according to claim 7, characterized in that, The specific steps to compress component instances within each strongly connected component into composite component instances are as follows: Extract the data input interface set and data output interface set of all component instances within the strongly connected component, and expose the interfaces in the data input interface set that are not driven by any internal component instance output interface as external input interfaces of the composite component instance; Expose the interfaces in the set of data output interfaces that are not consumed by any internal component instance input interfaces as external output interfaces of the composite component instance; Analyze the data propagation direction between component instances within the strongly connected component, identify the starting and ending component instances of data propagation, and insert a loop count counter between the starting and ending component instances. The upper limit of the loop count counter is determined by the length of the data flow path within the strongly connected component. The strongly connected component carrying the loop count counter is deployed as an embedded execution body of the composite component instance, and the external input interface and the external output interface are bound to the embedded execution body.

9. The intelligent software generation method for enterprise customization according to claim 8, characterized in that, After inserting the composite component instance at the end of the linearized output sequence, the method further includes performing redundant path pruning on the component instance: Scan the upstream component instances bound to the data input interfaces of each component instance in the linearized output sequence, and record a list of identifiers of all its upstream component instances for each component instance; Starting from the last component instance of the linearized output sequence, traverse backwards and for each upstream component instance in the identifier list of the current component instance, check whether there are two or more different traversal paths from the upstream component instance to the current component instance. When the check result shows that there are two or more different traversal paths, retain the single path with the fewest data pipeline hops, and mark the intermediate component instances corresponding to the other paths as redundant component instances. Remove the redundant component instance from the linearized output sequence, and directly short-connect the data input interface of the removed redundant component instance to the data input interface of the downstream component instance to which its output data flows.

10. An intelligent software generation system customized for enterprises, characterized in that, The system includes a processor and a memory, the memory being connected to the processor. The memory is used to store programs, instructions, or code, and the processor is used to execute the programs, instructions, or code in the memory to implement the enterprise-customized intelligent software generation method according to any one of claims 1-9.

Images