Generative software automatic assembly method and system based on contract framework model

Abstract

The invention relates to the technical field of software assembly, and discloses a contract framework model-based generative software automatic assembly method and system, and the method comprises the steps: obtaining user demand data, and decomposing the user demand data into demand protocols based on a language model; constructing a software database based on historical software data, and generating a contract framework model; retrieving a software database through a language model based on the demand specification, and generating a software similarity candidate list; performing suitability screening on the software similarity candidate list based on an assembly engine, and generating a software similarity recommendation list; assembling the software based on the software similarity recommendation list to generate an assembly PBC; inputting the assembled PBC into a language model to determine a demand matching degree of the assembled PBC; and determining an assembly result based on the demand matching degree. According to the invention, the understanding degree of demands is improved, and the workload of manual coding is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of software assembly, and in particular, to a generative software automatic assembly method and system based on a contract framework model. Background Art

[0002] Assembly technology refers to digital assets being packaged into independent components, each of which provides independent, clear, and complete business value and is designed as a component for the assembly and reassembly of business processes and application experiences. Currently, cloud-native and microservices architectures provide viable solutions for the assemblable software assembly business architecture. In terms of assembly technology, business personnel usually manually complete the assembly, integration, and process orchestration of software modules in the assembly integration platform through low-code and zero-code tools in the way of "drag-and-drop + templates + a small amount of coding".

[0003] However, the existing assembly technology is only a concept without a clear semantic description method and structure, which makes it impossible for computers to understand, and lacks a description of assembly conditions and correctness, resulting in the inability to measure and ensure the correctness of the assembly process and results.

[0004] Therefore, it is necessary to design a generative software automatic assembly method and system based on a contract framework model to solve the problems existing in the current technology. Summary of the Invention

[0005] In view of this, the present invention proposes a generative software automatic assembly method based on a contract framework model, aiming to solve the problem of low current assembly efficiency.

[0006] On the one hand, the present invention proposes a generative software automatic assembly method based on a contract framework model, including: Obtain user requirement data, and decompose the user requirement data into requirement specifications based on a language model; Build a software database based on historical software data and generate a contract framework model; Based on the requirement specifications, retrieve the software database through a language model and generate a software similarity candidate list; Conduct an adaptability screening on the software similarity candidate list based on an assembly engine and generate a software similarity recommendation list; Assemble software based on the software similarity recommendation list to generate an assembled PBC (Packaged Business Capability); Input the assembled PBC into the language model to determine its requirement matching degree; Determine the assembly result based on the requirement matching degree.

[0007] Furthermore, the requirement specification includes: functional requirements, interface requirements, performance metrics, dependencies, business rules, non-functional requirements, and constraints.

[0008] Furthermore, when constructing a software database based on historical software data and generating a contract framework model, it includes: Incorporating the historical software data into the software database and generating a PBC framework description and a PBC assembly contract; The PBC framework description consists of a description dimension, slots, and a design hierarchical structure; The PBC assembly contract consists of preconditions, postconditions, invariants, interfaces, and dependencies; Establish an index for the PBC framework description.

[0009] Furthermore, when retrieving the software database through a language model based on the requirement specification and generating a software similarity candidate list, it includes: Perform vector transformation on the requirement specification and extract text fields; Screen the software database based on semantic similarity using the index; Further screen the software database based on the text fields using the index; Generate the software similarity candidate list based on the results of the further screening.

[0010] Furthermore, when performing an adaptability screening on the software similarity candidate list based on an assembly engine and generating a software similarity recommendation list, it includes: Screen the software similarity candidate list based on the requirement specification; The screening includes interface compatibility check, precondition and postcondition verification, dependency resolution, performance metric matching, and logical conflict detection; When the screening is unqualified, remove the unqualified screening objects from the software similarity candidate list; When all the software in the software similarity candidate list is unqualified, generate a detailed log and report an error; When the screening is qualified, retain the qualified screening objects and generate a software similarity recommendation list.

[0011] Furthermore, when assembling software based on the software similarity recommendation list to generate an assembled PBC, it includes: Select suitable software as the assembly backbone based on the similarity recommendation list and mark the software with soft risks as alternatives; Unify the communication protocols and data formats of the assembled software and determine the corresponding relationships of input and output parameters; Load the software to be assembled, initialize the running environment, and configure shared resources; Merge the configuration files and set global environment variables; When all the software to be assembled simultaneously meet the preconditions, combine the postconditions of all the software to be assembled and inherit the invariants of all the software to be assembled; Add new business rules after assembly and verify whether the contract conditions are met based on a solver; When it is verified that the contract conditions are not met, replace the alternative software and trigger an alarm; When it is verified that the contract conditions are met, generate the PBC framework description for the generated assembled PBC.

[0012] Furthermore, when assembling software based on the software similarity recommendation list and generating an assembled PBC, it also includes: Generate API gateway and middleware code based on the assembled PBC and concatenate the interface call chains of all the software to be assembled; Generate the startup logic of dependent components based on the assembled PBC and integrate configuration parameters; Perform contract consistency checks and interface specification verifications on the assembled PBC; Perform dynamic testing on the assembled PBC and generate test results; Store the assembled PBC in the software repository.

[0013] Furthermore, when inputting the assembled PBC into the language model to determine its requirement matching degree, it includes: Perform text cleaning and word segmentation on the framework description of the assembled PBC and the requirement specification; Merge the framework description of the assembled PBC and the requirement specification into a corpus and mark each document with a unique name; Obtain the word frequencies appearing in the requirement specification based on the requirement specification; Obtain the inverse document frequencies appearing in the corpus based on the corpus; Multiply the word frequencies by the inverse document frequencies to obtain the result of word frequency calculation; Determine the similarity between the requirement specification and the assembled PBC through cosine similarity; Obtain a matching degree score based on the similarity of the assembled PBC and the result of word frequency calculation.

[0014] Furthermore, when inputting the assembled PBC into the language model to determine its requirement matching degree, it also includes: Verify the interface compatibility and performance metrics of the assembled PBC and verify its dependency relationships; Determine the comprehensive score of the assembled PBC based on the matching degree score, the interface compatibility, and the performance metrics; Determine whether the assembled PBC meets the user requirement data based on the comprehensive score; When the comprehensive score meets the user requirement data, stop assembling and output the assembled PBC; When the comprehensive score does not meet the user requirement data, retrieve the software database again based on the user requirement data and reassemble.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: By the requirement decomposition ability of the language model, the problems of inaccurate requirement understanding and high communication cost in traditional development are solved. After the user describes the requirements in natural language, the model automatically extracts core elements such as functions, performance, and interfaces through context awareness and logical reasoning, and generates a standardized requirement specification document. This process not only reduces the dependence on professional requirement analysts, but also avoids development deviations caused by semantic ambiguities, ensuring a high degree of alignment between requirements and implementation. Secondly, the construction of the historical software database and the contract framework model provides systematic support for software reuse. The PBCs accumulated in the database are machine-understandable through semantic descriptions and formal contracts (such as preconditions, dependencies), while the contract framework model provides a structured expression for the assembly rules of components. By logically arranging the selected PBCs according to the requirement specification, interface glue code, dependency initialization logic, and unified configuration files can be automatically generated, while inheriting and extending the business rules and constraint conditions of member components. This "bottom-up" assembly method reduces the workload of manual coding.

[0016] On the other hand, the present application also provides a generative software automatic assembly system based on a contract framework model for applying the above-mentioned generative software automatic assembly method based on a contract framework model, including: An acquisition module configured to obtain user requirement data; A language module configured to decompose the user requirement data into a requirement specification. The language module is further configured to retrieve the software database and generate a software similarity candidate list. The language module is further configured to input the assembled PBC into the language model to determine its requirement matching degree, and determine the assembly result based on the requirement matching degree; A storage module configured to build a software database based on historical software data and generate a contract framework model; An assembly module configured to perform an adaptability screening on the software similarity candidate list and generate a software similarity recommendation list. The assembly module is further configured to assemble the software based on the software similarity recommendation list to generate an assembled PBC.

[0017] It is understandable that the above-mentioned generative software automatic assembly system based on the contract framework model has the same beneficial effects, which will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] By reading the following detailed description of the preferred embodiments, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered to be a limitation of the present invention. Moreover, throughout the drawings, the same reference numerals are used to represent the same components. In the drawings: Figure 1 is a flowchart of a generative software automatic assembly method based on a contract framework model provided by an embodiment of the present invention; Figure 2 is a flowchart of an assembly engine of a generative software automatic assembly method based on a contract framework model provided by an embodiment of the present invention; Figure 3 is a functional block diagram of a generative software automatic assembly system based on a contract framework model provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0019] Hereinafter, exemplary embodiments of the present disclosure will be described in more detail with reference to the drawings. Although the exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be fully conveyed to those skilled in the art. It should be noted that, without conflict, the embodiments in the present invention and the features in the embodiments can be combined with each other. Hereinafter, the present invention will be described in detail with reference to the drawings and in combination with the embodiments.

[0020] In some embodiments of the present application, referring to Figure 1-2 as shown, a generative software automatic assembly method based on a contract framework model includes: Obtain user requirement data, and decompose the user requirement data into requirement specifications based on a language model.

[0021] Construct a software database based on historical software data, and generate a contract framework model.

[0022] Based on the requirement specifications, retrieve the software database through a language model, and generate a software similarity candidate list.

[0023] Based on an assembly engine, perform an adaptability screening on the software similarity candidate list, and generate a software similarity recommendation list.

[0024] Assemble the software based on the software similarity recommendation list to generate an assembled PBC.

[0025] Input the assembled PBC into the language model to determine its requirement matching degree.

[0026] Determine the assembly result based on the requirement matching degree.

[0027] Specifically, decomposing the user requirement data through the language model enables the computer to understand the user requirements. The language model can be a large language model such as GPT. Put the historical software into the software database, and at the same time generate the framework description and assembly contract of the software. The framework description semantically describes multiple aspects of the PBC, enabling the language model to understand and perceive the assemblable PBC stored in the software assets. The assembly contract formally declares the assembly conditions of the PBC, enabling the assembly engine to check the rationality and correctness of the assembly. Through the constraints of the requirement specification, screen out the software that meets the requirements in the software database and generate a software similarity candidate list. Then, the assembly engine screens the candidate list, eliminates the non-conforming software, and thus generates a software similarity recommendation list. By assembling the software on the software similarity recommendation list, a new assembled PBC is obtained. Then, through the language model, compare the assembled PBC with the requirement specification to see if it meets the requirements. If it meets the requirements, the assembly ends. If it does not meet the requirements, return to the step of retrieving the software database to generate the software similarity candidate list and repeat.

[0028] It is understandable that by deeply integrating language models, automated component management, and intelligent assembly engines, a full-process automated link of "requirement understanding - component retrieval - intelligent assembly - closed-loop verification" is formed, thereby reducing the dependence of software development on manual experience while ensuring a high degree of consistency between the output quality and business goals. Language models (such as the GPT series) transform users' vague natural language requirements into precise structured requirement specifications through context awareness and logical reasoning capabilities, covering key elements such as function definitions, performance constraints, and interface specifications. This not only eliminates the ambiguity problems commonly found in traditional requirement analysis but also ensures zero deviation in the understanding of requirements between the technical team and the business team through standardized templates. The model can automatically parse out the core requirement points - function domain (cross-border payment), interface type (API), performance metrics (response time ≤ 500ms), and generate a machine-readable specification document in JSON or YAML format, laying a data foundation for subsequent component retrieval and assembly. The construction of the historical software database and the contract framework model provide systematic support for the precipitation and efficient utilization of enterprise technical assets. Each PBC (encapsulable business capability) in the database realizes multi-dimensional semantic expression through framework descriptions, including function descriptions, interface definitions, dependency relationships, performance metrics, etc., enabling the language model to deeply understand the business value and technical characteristics of components. Through multi-level similarity calculation and rule-driven screening, accurate and efficient candidate component screening is achieved. Based on the requirement specification, the language model retrieves semantically matching PBCs from the software database and generates a preliminary candidate list. For example, for the "cross-border payment" requirement, the system may match components such as "currency conversion PBC", "compliance review PBC", "multilingual support PBC", etc., and sort them according to text similarity. Subsequently, the assembly engine verifies the candidate components based on the formal rules in the contract framework, including interface parameter type compatibility (such as verifying whether the amount field is of floating-point type), protocol consistency (such as checking whether RESTful API is supported), and dependency satisfiability (such as ensuring the availability of the required user authentication service). This process replaces traditional manual code review with automated logical checks, not only improving the screening efficiency by several orders of magnitude but also discovering hidden problems (such as version conflicts), thereby generating a highly credible recommendation list. The assembly engine automatically generates interface glue code, dependency injection logic, and unified configuration files between components based on the PBCs in the recommendation list. For example, it maps the output parameters of the payment gateway to the input of the order system and configures a shared database connection pool. During this process, the engine synthesizes the assembly contracts of the member components to generate a composite contract for the new PBC. For example, it combines the preconditions (requiring both the payment channel and the risk control service to be ready) and inherits the business rules (such as the transaction amount must be positive). This "bottom-up" assembly method not only reduces the manual coding workload but also ensures the correctness of the assembly result through formal verification (such as using the Z3 solver to check the consistency of the contract logic).

[0029] In some embodiments of the present application, the requirements specification includes: functional requirements, interface requirements, performance metrics, dependencies, business rules, non-functional requirements, and constraints.

[0030] It can be understood that the interface description in the contract framework model defines the input and output parameter types, communication protocols (such as RESTful API, gRPC), and data formats (such as JSON Schema) of components. When the assembly engine filters candidate components, it will verify the interface compatibility in real time. For example, if the requirements specification requires that the amount parameter of the payment interface be of floating-point type, and the interface definition of the candidate component is of integer type, the engine will automatically exclude the component or trigger the generation of a type conversion adapter. The performance metrics are verified by combining historical test data and real-time stress testing. For example, hard constraints such as response time and throughput are embedded in the "performance description" slot of the contract framework. The assembly engine will preferentially select components that meet or exceed the requirements metrics during integration. Each PBC in the software repository explicitly declares its dependencies (such as database connection pool, third-party service API) and implicit dependencies (such as configuration file path, environment variables). The assembly engine constructs a dependency graph during integration and ensures the correctness of the loading order through topological sorting. For example, when building an e-commerce order system, the engine will initialize the user authentication service first and then load the payment gateway to avoid runtime errors caused by dependency inversion. Business rules are embedded in the "invariant" slot of the contract framework through formal logical expressions. For example, rules such as "the order amount must be greater than zero" and "inventory deduction requires atomic operations". The assembly engine will use a SAT solver (such as Z3) to check the consistency of the rules when merging components to prevent conflicts. Non-functional requirements such as security and maintainability are implemented through the "safeguard mechanism" slot of the contract framework. For example, data encryption algorithms (AES-256), logging strategies (ELK integration), and monitoring metrics (Prometheus export). The assembly engine will automatically inject this safeguard logic when generating code to ensure that the system meets enterprise-level security and operation and maintenance standards. Constraints such as technology stack limitations (such as only using the Java Spring Boot framework) or compliance requirements (such as GDPR data privacy terms) are enforced through predefined filtering rules during the candidate list generation phase. For example, exclude components that depend on Python libraries or services that do not provide data masking interfaces.

[0031] In some embodiments of the present application, when constructing a software repository based on historical software data and generating a contract framework model, it includes: Incorporate historical software data into the software repository and generate a PBC framework description and a PBC assembly contract.

[0032] The PBC framework description consists of a description dimension, slots, and a design hierarchical structure.

[0033] The PBC assembly contract consists of preconditions, postconditions, invariants, interfaces, and dependencies.

[0034] Index the PBC framework description.

[0035] It is understandable that the storage of historical software data and the generation of PBC framework descriptions can transform scattered software assets into machine - understandable semantic resources. Through a three - layer model of "description dimension - slot - hierarchical structure", the framework description standardizes the definition of attributes such as the functions, performance, interfaces, and dependencies of each PBC. For example, when describing a "Payment Gateway PBC", the function dimension may include sub - function slots such as "transaction processing" and "risk control review". The technology dimension is refined to specific parameters such as the development language (Java), communication protocol (HTTPS), and dependent services (User Authentication PBC). The hierarchical structure allows for the nesting of sub - components (such as taking the "encryption module" as the underlying component of the payment gateway). This not only makes the business value and technical characteristics of the components clear at a glance but also supports semantic retrieval and automated adaptation checks. For example, by querying in natural language "payment components that support HTTPS", candidate PBCs can be accurately located, avoiding the ambiguity of traditional keyword - based matching. The formal definition of the PBC assembly contract (including pre - conditions, post - conditions, invariants, interface specifications, and dependencies) sets clear rule boundaries for the legal combination of components, fundamentally ensuring the correctness of system integration. The pre - conditions define the environmental states required for component operation (such as database connection availability and third - party service authorization validity). The post - conditions ensure the compliance of the output after component execution (such as return value type and data integrity). The invariants constrain the constancy of business rules (such as "the order amount must be greater than zero"). For example, when assembling the "Order Processing PBC" and the "Inventory Management PBC", the assembly contract will verify whether the inventory is sufficient before order submission (pre - condition), whether the deduction operation is atomically completed (post - condition), and check that the inventory quantity is always non - negative (invariant). By replacing manual code review with automated logic checks, interface incompatibilities, dependency conflicts, or business logic errors can be intercepted in advance. The step of indexing the PBC framework description greatly improves the efficiency of component reuse and assembly through retrieval optimization. The construction of the index is based on keyword fields of semantic descriptions (such as function labels, interface protocols, and performance metrics), combined with inverted index and vector embedding technologies, supporting multi - modal queries - either quickly locating components through exact filtering (such as "protocol = HTTPS", "response time ≤ 200ms") or achieving fuzzy matching through semantic similarity calculation (such as mapping "payment processing" to "transaction settlement"). For example, when developing a cross - border payment system, when developers input requirement keywords such as "multi - currency settlement" and "compliance review", the index engine can not only return PBCs explicitly marked with these functions but also recommend semantically related components (such as "Exchange Rate Conversion PBC"). In addition, a hierarchical index structure (classified by business domain, technology stack, performance level, etc.) further accelerates the retrieval process.

[0036] In some embodiments of the present application, when retrieving a software database through a language model and generating a software similarity candidate list based on a requirements specification, it includes: Perform vector transformation on the requirements specification and extract text fields.

[0037] Filter the software database based on indexes through semantic similarity.

[0038] Further filter the software database based on indexes through text fields.

[0039] Generate a software similarity candidate list based on the results of the further filtering.

[0040] Specifically, first perform a preliminary screening on the software in the software database through semantic similarity, and then further screen the software through key text fields. Finally, a software similarity candidate list is obtained. The key text fields (such as interface protocols, input parameter types, response time thresholds) are structurally extracted to form programmable filtering conditions. For example, "HTTPS protocol" is marked as a mandatory label, providing a data basis for subsequent precise screening. The preliminary screening based on semantic similarity uses distance metrics (such as cosine similarity) in the vector space to quickly retrieve the candidate components in the software database that are most relevant to the requirements semantics. For example, when the requirements vector points to "distributed transaction management", PBCs with semantic labels such as "transaction coordination" and "distributed lock" will be preferentially matched, even if the word "distributed" is not explicitly included in their descriptions. This semantic generalization ability improves the recall rate of the retrieval, especially applicable to scenarios with diverse professional terms or fuzzy requirements descriptions. Subsequently, the further screening based on key text fields filters out candidates that are semantically similar but technically incompatible through hard rules (such as protocol consistency and parameter type matching). For example, although a certain PBC semantically matches the "payment interface", its interface protocol is HTTP instead of HTTPS specified by the requirements, or the input parameter type is integer instead of floating point type, and such components will be automatically excluded.

[0041] In some embodiments of the present application, when performing an adaptability screening on the software similarity candidate list based on an assembly engine and generating a software similarity recommendation list, it includes: Screen the software similarity candidate list based on the requirements specification.

[0042] The screening includes interface compatibility check, precondition and postcondition verification, dependency relationship resolution, performance metric matching, and logical conflict detection.

[0043] When the screening is unqualified, exclude the unqualified screening objects from the software similarity candidate list.

[0044] When all the software in the software similarity candidate list is unqualified, generate a detailed log and report an error.

[0045] When the screening is qualified, retain the qualified screening objects and generate a software similarity recommendation list.

[0046] It is understandable that the assembly engine verifies the protocol consistency, parameter type matching degree, and data format compatibility with the requirement specification by parsing the interface descriptions of candidate components (such as OpenAPI specifications, gRPC Protobuf). For example, when the requirement specifies that "the amount parameter of the payment interface is of floating-point type and the communication protocol is HTTPS", the engine will automatically eliminate components with integer parameter types or only supporting the HTTP protocol, and handle some cases that are partially compatible but require fine-tuning through dynamic adapter generation (such as type conversion middleware). For example, wrap integer parameters as floating-point types to adapt to downstream services. This flexible processing mechanism not only retains high-value candidate components but also avoids the abandonment of the overall solution due to minor mismatches. In the precondition and postcondition verification, through the combination of formal logical expressions and a rule engine (such as Drools), the verification of the component's running context and business rules is achieved. The precondition verification ensures that the system state required for component execution is ready. For example, the database connection pool is initialized, the third-party API token is valid and not expired. The postcondition, on the other hand, enforces the compliance of the output after component execution. For example, the payment status must return "success", "failure", or "processing", and the transaction log must be persistently stored. For example, when integrating the "inventory deduction PBC", the engine will verify whether its precondition "current inventory ≥ order quantity" is met before the call and check whether the postcondition "inventory quantity = original inventory - order quantity" holds after execution. If an exception (such as overselling of inventory) is detected, the transaction will be automatically rolled back and the component will be marked as "high risk". Dependency resolution ensures the satisfiability and correct loading order of all explicit and implicit dependencies (such as shared libraries, configuration files, environment variables) by constructing a component dependency graph (DAG) and applying a topological sorting algorithm. For example, when assembling an e-commerce system with a microservices architecture, the engine will first load the "user authentication PBC" and verify the availability of the Redis connection it depends on, then initialize the "shopping cart PBC" and "order processing PBC" that depend on the authentication service, while detecting circular dependencies (such as A depends on B, B depends on A) and generating warnings. The performance metric matching link quantifies and verifies whether metrics such as the response time, throughput, and resource occupancy of candidate components meet the requirement specification through the combination of historical performance data and real-time benchmark tests. Logic conflict detection identifies the incompatibility of business rules between components through the cooperation of model checking tools (such as Alloy, Z3) and a business rule engine. When the screening is unqualified, the system provides developers with actionable repair guidance through an intelligent log generation and refined error classification mechanism. For components that pass the screening, the generated recommended list is prioritized through a multi-dimensional scoring model (such as comprehensive semantic similarity, interface matching degree, performance superiority, and historical reliability), and a detailed adaptation report is attached.

[0047] In some embodiments of the present application, when assembling software based on the software similarity recommended list to generate an assembled PBC, it includes: Select the adaptable software as the assembly backbone based on the similarity recommendation list, and mark the software with soft risks as alternatives.

[0048] Unify the communication protocols and data formats of the assembled software, and determine the corresponding relationships of input and output parameters.

[0049] Load the software to be assembled, initialize the running environment, and configure shared resources at the same time.

[0050] Merge the configuration files and set global environment variables.

[0051] When all the software to be assembled simultaneously meet the preconditions, combine the postconditions of all the software to be assembled and inherit the invariants of all the software to be assembled.

[0052] Add the business rules after assembly, and verify whether the contract conditions are met based on the solver.

[0053] When the contract conditions are not met, replace the alternative software and trigger an alarm.

[0054] When the contract conditions are met, generate a PBC framework description for the generated assembled PBC.

[0055] Specifically, the unified processing of protocols and data formats fundamentally eliminates the technical friction in heterogeneous system integration. Through forced conversion or dynamic adapter generation (such as upgrading HTTP / 1.1 to HTTP / 2, XML to JSON format conversion), seamless communication between components is ensured. Through templated deployment scripts and intelligent resource allocation algorithms, the rapid construction and optimization of component operating environments are achieved. For example, when loading microservice components, Kubernetes container resources are dynamically allocated automatically according to their performance profiles (such as memory occupancy, thread count requirements), and infrastructure such as shared Redis connection pools and database session management is configured to avoid performance bottlenecks caused by resource competition. The common problem of multi-component configuration conflicts is solved through intelligent conflict detection and priority rules (such as "later loaded overrides earlier loaded"). For example, when both PBCs need to modify the same log level parameter, the configuration item of the critical service is automatically selected according to the business priority, and a difference report is generated for manual review. At the same time, the combined verification of preconditions (such as "database connection ready" ∧ "identity service token valid") during the assembly process ensures the state integrity at startup, while the logical union of postconditions (such as "payment status updated" ∧ "inventory deduction successful") defines the deterministic boundary of behavior. The inheritance and extension of invariants (such as "order amount > 0"), verified by formal methods (such as TLA+ model checking) for their invariance in the new assembled system, fundamentally prevent business rule conflicts. For example, in the financial system, it ensures the consistency of the "transaction amount verification" rule in all links such as payment, settlement, and reconciliation. The automatic embedding of new business rules and solver verification (such as Z3, Alloy) can discover deep-seated logical contradictions during the design phase. For example, when integrating the "promotion calculation PBC" and the "tax calculation PBC", if the promotion rule allows "price after full reduction is lower than the cost price" while the tax rule requires "tax-inclusive price ≥ cost price × 1.1", the solver will identify this conflict and trigger an alarm to guide developers to adjust the rules or insert compensatory logic (such as automatically adding a minimum price limit constraint). The finally generated assembled PBC framework description, through structured metadata (functional domain, interface mapping, performance metrics, dependency graph) and machine-readable contract rules, provides a complete digital twin model for subsequent maintenance, extension, and auditing.

[0056] In some embodiments of the present application, when assembling software based on the software similarity recommendation list to generate an assembled PBC, it further includes: Generating API gateway and middleware code based on the assembled PBC and concatenating the interface call chains of all the assembled software.

[0057] Generating the startup logic of dependent components based on the assembled PBC and integrating configuration parameters.

[0058] Performing contract consistency check and interface specification verification on the assembled PBC.

[0059] Perform dynamic testing on the assembled PBC and generate test results.

[0060] Store the assembled PBC in the software repository.

[0061] Specifically, the automated generation of the API gateway and middleware code has refactored the development paradigm of interface integration. By parsing and assembling the interface descriptions of PBCs (such as OpenAPI specifications, gRPC service definitions), it automatically generates gateway routing rules, load balancing strategies, and circuit breaker and fallback logics that adapt to different protocols. For example, it dynamically maps RESTful API requests to corresponding microservice endpoints, injects common middleware such as JWT authentication and request rate limiting, and the generated code strictly adheres to enterprise architecture specifications (such as layered design, log standardization), avoiding fluctuations in code quality caused by differences in developers' skills. Based on the dependency graph of the assembled PBC (such as database connections, message queues, cache services), it automatically generates Kubernetes Helm Charts or Terraform scripts to precisely orchestrate the startup order and resource quotas of components. For example, when starting a recommendation engine that requires a Redis cluster and a Kafka message bus, the engine will first deploy Redis and wait for the health check to pass, then initialize the Kafka producer, and dynamically preset the number of shards and replicas based on historical load data. The automated integration of configuration parameters ensures the coordination of configuration items (such as thread pool size, timeout threshold) of different components in the global environment through a priority merging and conflict resolution algorithm (such as namespace-based parameter isolation). For example, it automatically identifies and merges the database connection strings shared by multiple components, avoiding resource waste caused by duplicate configurations. The contract consistency check uses logic solvers (such as Z3, Alloy) to verify whether the assembled PBC satisfies the combined constraints of all preconditions, postconditions, and invariants. For example, it ensures that the "order creation PBC" will never call the "payment execution PBC" when the inventory is insufficient, thus avoiding business logic vulnerabilities. The interface specification verification ensures that the input and output parameter types, data formats, and error code definitions of the interface fully conform to enterprise standards through OpenAPI Schema comparison, gRPC Protobuf compatibility detection, and a custom rule engine (such as Rego). The engine automatically generates a test case set based on the business scenarios of the assembled PBC, including functional tests (such as covering payment success / failure branches), performance tests (such as gradient stress loading), fault tolerance tests (such as simulating the downtime of dependent services), and security tests (such as detecting SQL injection attacks). For example, when testing an e-commerce promotion system, it automatically simulates concurrent rush purchase requests, verifies the atomicity of inventory deduction and the eventual consistency of order status, and injects abnormal conditions such as network latency and node failures to ensure that the system has elastic recovery capabilities. The root cause analysis of the test results is carried out through a machine learning model. For example, it correlates performance bottlenecks with the thread pool configuration of specific components or the lack of database indexes and recommends optimization strategies (such as adjusting the connection pool size or adding composite indexes). Finally, the assetization and warehousing of the assembled PBC constructs an enterprise-level knowledge reuse library through multi-dimensional metadata annotation (function tags, performance baselines, dependency versions, test reports) and version management.The evolution history of each PBC (such as version iteration records and defect repair tracking) is fully recorded, supporting precise semantic-based retrieval and compliance auditing.

[0062] In some embodiments of the present application, when inputting the assembled PBC into the language model to determine its requirement matching degree, it includes: Perform text cleaning on the framework description and requirement specification of the assembled PBC, and perform word segmentation.

[0063] Merge the framework description and requirement specification of the assembled PBC into a corpus, and mark a unique name for each document.

[0064] Obtain the word frequency of the words appearing therein based on the requirement specification.

[0065] Obtain the inverse document frequency of the words appearing therein based on the corpus.

[0066] Multiply the word frequency by the inverse document frequency to obtain the result of word frequency calculation.

[0067] Determine the similarity between the requirement specification and the assembled PBC through cosine similarity.

[0068] Obtain the matching degree score based on the similarity of the assembled PBC and the result of word frequency calculation.

[0069] In some embodiments of the present application, when inputting the assembled PBC into the language model to determine its requirement matching degree, it further includes: Verify the interface compatibility and performance metrics of the assembled PBC, and verify its dependency relationship.

[0070] Determine the comprehensive score of the assembled PBC based on the matching degree score, interface compatibility, and performance metrics.

[0071] Determine whether the assembled PBC meets the user requirement data based on the comprehensive score.

[0072] When the comprehensive score meets the user requirement data, stop assembling and output the assembled PBC.

[0073] When the comprehensive score does not meet the user requirement data, re-retrieve the software repository based on the user requirement data and reassemble.

[0074] Specifically, by leveraging the natural language understanding and reasoning capabilities of the large model, the user's target requirements description is gradually decomposed into more specific requirement specifications, namely the PBC assembly scheme. During this process, the retrieval enhancement technology is used to refer to the PBC framework description in the software asset library. After assembling a larger PBC, the large model needs to generate a framework description for the new PBC based on the framework descriptions of the member PBCs. And the large model will compare the assembled PBC framework description with the user's target requirements description based on semantic similarity to judge the requirement matching degree of the assembled PBC and decide whether the assembly process ends. The PBC assembly engine is guided by the requirement specifications generated by the large model. First, it retrieves relevant PBCs from the software asset library, then checks the functional and performance adaptability of the assembly conditions and rules between PBCs according to the PBC assembly contract, and finally filters out the assemblable member PBCs that meet the requirement specifications and executes the assembly. And according to their assembly contracts, it specifies the assembly contract of the assembled PBC for the assembly contract, that is, the large model is used in the PBC assembly process to understand the development requirements of the user's assembled application, query relevant PBCs, deduce the assembly scheme, generate the PBC framework description structure, and judge the PBC assembly progress. First, it reads the development requirements provided by the user. (2) Through the enhanced retrieval of the PBC framework description structure in the software asset library, the large model filters out relevant PBCs. (3) Based on the large model's chain of thought ability, it deduces the requirement specifications from the initial requirement description to form the PBC assembly scheme. (4) The PBC assembly is executed by the assembly engine. (5) Summarize the framework descriptions of the member PBCs involved in the assembly. (6) The large model generates a framework description for the assembled PBC. (7) The large model analyzes and compares the assembled PBC with the requirement specifications and the original requirement description. (8) Measure the satisfaction degree of the assembled PBC against the requirements. If the requirements are not yet met, return to step (2) to continue the assembly loop. (9) If the original requirements have been met, terminate the assembly loop. The working process of the assembly engine is as follows: (1) Input the requirement specifications generated by the large model and relevant PBCs. (2) Use a logic checking tool to check the functional and performance adaptability between the PBC assembly contracts, filter out the PBCs that meet the requirement specifications and satisfy the assembly conditions. If all PBCs cannot be adapted, an error will be reported. (3) Assemble the filtered member PBCs into a larger PBC, including passing correct parameters for APIs, channels, and interfaces between PBCs, correctly setting configuration files, passing in correct global variables, obtaining and releasing shared resources, etc. Finally, generate the external API for the assembled PBC according to the requirement specifications, through the interface. (4) Synthesize the assembly contracts of the member PBCs to specify the assembly contract of the assembled PBC. (5) Package the assembly contract of the assembled PBC, the framework description of the assembled PBC generated by the large model, and the assembled PBC into a new PBC model. (6) Store the new PBC model in the software asset library for subsequent assembly processes.When determining the requirement matching degree of the assembled PBC, a semantic similarity calculation algorithm based on a pre-trained embedding model (such as BERT, SentenceBERT, etc.) is used to measure whether the framework description of the assembled PBC matches the requirements. At the same time, relevant operation fluency data such as compatibility and performance indicators are verified to obtain the comprehensive score of the assembled PBC. The comprehensive score can display the parameters of the assembled PBC, and a language model is used to judge whether it meets the user requirement data (requirement specification). When it meets, the assembly stops and outputs; when it does not meet, retrieve and assemble again.

[0075] In summary, the beneficial effects of the present invention are as follows: By the requirement decomposition ability of the language model, the problems of inaccurate requirement understanding and high communication cost in traditional development are solved. After the user describes the requirements in natural language, the model automatically extracts core elements such as functions, performance, and interfaces through context awareness and logical reasoning, and generates a standardized requirement specification document. This process not only reduces the dependence on professional requirement analysts but also avoids development deviations caused by semantic ambiguity, ensuring a high degree of alignment between requirements and implementation. Secondly, the construction of the historical software database and the contract framework model provides systematic support for software reuse. The PBCs accumulated in the database are machine-readable through semantic descriptions and formal contracts (such as preconditions, dependencies), and the contract framework model provides a structured expression for the assembly rules of components. By logically arranging the selected PBCs according to the requirement specification, interface glue code, dependency initialization logic, and unified configuration files can be automatically generated, while inheriting and extending the business rules and constraints of member components. This "bottom-up" assembly method not only reduces the workload of manual coding but also ensures the robustness of the system through formal verification.

[0076] In another preferred manner based on the above embodiments, refer to Figure 3 As shown, this embodiment provides a generative software automatic assembly system based on a contract framework model for applying the above-mentioned generative software automatic assembly method based on a contract framework model, including: An acquisition module configured to obtain user requirement data.

[0077] A language module configured to decompose the user requirement data into a requirement specification, the language module is further configured to retrieve the software database and generate a software similarity candidate list, the language module is further configured to input the assembled PBC into the language model to determine its requirement matching degree, and based on the requirement matching degree, determine the assembly result.

[0078] A storage module configured to build a software database based on historical software data and generate a contract framework model.

[0079] An assembly module, configured to perform an adaptability screening on a software similarity candidate list and generate a software similarity recommendation list. The assembly module is further configured to assemble software based on the software similarity recommendation list to generate an assembled PBC.

[0080] Specifically, a collection module is used to obtain user requirement data, decompose it into requirement specifications through a language module, retrieve a software database according to the requirement specifications, and generate a software similarity candidate list. Then, the assembly module screens the adaptability of the software similarity candidate list to obtain a screened software similarity recommendation list, and then assembles it according to the software similarity recommendation list to obtain an assembled PBC. When the assembled PBC is generated, a corresponding framework description is also generated, and the language module screens the requirement matching degree of the framework description, and then decides whether to end the assembly.

[0081] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0082] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram can be implemented by computer program instructions, and the combination of the flows and / or blocks in the flowchart and / or block diagram can also be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for realizing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0083] These computer program instructions can also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable storage medium generate a manufactured product including an instruction device, and the instruction device realizes the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0084] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operation steps are executed on the computer or other programmable apparatus to produce a computer-implemented process, thereby the instructions executed on the computer or other programmable apparatus provide steps for realizing the functions specified in one process or a plurality of processes and / or boxes. Figure 1 One process or a plurality of processes and / or boxes Figure 1 Steps for realizing the functions specified in one box or a plurality of boxes.

[0085] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those of ordinary skill in the art should understand that: modifications or equivalent replacements can still be made to the specific embodiments of the present invention. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention shall be covered by the protection scope of the claims of the present invention.

Claims

1. A generative software automatic assembly method based on a contract framework model, characterized in that: include: Acquire user demand data, and decompose the user demand data into demand specifications based on a language model; Build a software database based on historical software data and generate a contract framework model; Based on the requirement specification, searching the software database through a language model and generating a software similarity candidate list; Performing adaptability screening on the software similarity candidate list based on the assembly engine, and generating a software similarity recommendation list; Assembling the software based on the software similarity recommendation list to generate an assembled PBC; Inputting the assembled PBC into the language model to determine its requirement matching degree; Based on the requirement matching degree, an assembly result is determined.

2. The method for automatically assembling generative software based on a contract framework model according to claim 1, characterized in that: The requirement specification includes: functional requirements, interface requirements, performance indicators, dependencies, business rules, non-functional requirements and constraints.

3. The method for automatically assembling generative software based on a contract framework model according to claim 2, characterized in that: When building a software database based on historical software data and generating a contract framework model, it includes: Incorporate historical software data into the software repository and generate PBC framework descriptions and PBC assembly contracts; The PBC framework description is composed by describing dimensions, slots and designing hierarchical structures; The PBC assembly contract is composed of preconditions, postconditions, invariants, interfaces and dependencies; The PBC framework description is indexed.

4. The method for automatically assembling generative software based on a contract framework model according to claim 3, characterized in that: Based on the requirement specification, searching the software database through a language model and generating a software similarity candidate list includes: Performing vector conversion on the requirement specification and extracting text fields; Screening the software database by semantic similarity based on the index; Further screening the software library by text fields based on the index; The software similarity candidate list is generated based on the further screening results.

5. The method for automatically assembling generative software based on a contract framework model according to claim 4, characterized in that: When the software similarity candidate list is screened for suitability based on the assembly engine and a software similarity recommendation list is generated, it includes: Screening the software similarity candidate list based on the requirement specification; The screening includes interface compatibility checking, precondition and postcondition verification, dependency analysis, performance indicator matching and logic conflict detection; When the screening fails, the unqualified screening object is removed from the software similarity candidate list; When all the software in the software similarity candidate list are unqualified, a detailed log is generated and an error is reported; When the screening is qualified, the qualified screening objects are retained and a software similarity recommendation list is generated.

6. The method for automatically assembling generative software based on a contract framework model according to claim 5, characterized in that: Assembling the software based on the software similarity recommendation list to generate an assembled PBC includes: Based on the similarity recommendation list, suitable software is selected as the assembly trunk, and software with soft risks is marked as an alternative; Unify the communication protocol and data format of the assembly software, and determine the corresponding relationship between input and output parameters; Load the software to be assembled, initialize the operating environment, and configure shared resources; Merge configuration files and set global environment variables; When all software being assembled satisfies the preconditions at the same time, the postconditions of all software being assembled are combined, and the invariants of all software being assembled are inherited; Add the assembled business rules and verify whether the contract conditions are met based on the solver; When it is verified that the contract conditions are not met, the alternative software is replaced and an alarm is triggered; When it is verified that the contract conditions are satisfied, the PBC framework description is generated for the generated assembled PBC.

7. The method for automatically assembling generative software based on a contract framework model according to claim 6, characterized in that: When assembling the software based on the software similarity recommendation list and generating an assembled PBC, the following steps are also included: Generate API gateway and middleware code based on the assembled PBC, and connect the interface call chain of all assembled software in series; Generate startup logic of dependent components based on the assembled PBC and integrate configuration parameters; Performing contract consistency check and interface specification verification on the assembled PBC; Performing dynamic testing on the assembled PBC and generating test results; The assembled PBC is stored in the software library.

8. The method for automatically assembling generative software based on a contract framework model according to claim 7, characterized in that: When the assembled PBC is input into the language model to determine its requirement matching degree, it includes: Performing text cleaning and word segmentation on the framework description of the assembled PBC and the requirement specification; Combining the framework description of the assembled PBC and the requirement specification into a corpus, and marking each document with a unique name; Obtaining the frequency of words appearing therein based on the requirement specification; Obtaining the inverse document frequency of the occurrence of the corpus based on the corpus; Multiplying the word frequency by the inverse document frequency to obtain a result of word frequency calculation; Determining the similarity between the requirement specification and the assembly PBC by cosine similarity; A matching score is obtained based on the similarity of the assembled PBC and the result of the word frequency calculation.

9. The method for automatically assembling generative software based on a contract framework model according to claim 8, characterized in that: When the assembled PBC is input into the language model to determine its demand matching degree, it also includes: Verify the interface compatibility and performance indicators of the assembled PBC, and verify its dependencies; Determining a comprehensive score of the assembled PBC based on the matching score, the interface compatibility and the performance index; Determining whether the assembled PBC meets the user demand data based on the comprehensive score; When the comprehensive score meets the user demand data, stop assembling and output the assembled PBC; When the comprehensive score does not satisfy the user requirement data, the software database is re-searched and reassembled based on the user requirement data.

10. A generative software automatic assembly system based on a contract framework model, applied to the generative software automatic assembly method based on a contract framework model as claimed in any one of claims 1 to 9, characterized in that: include: A collection module, configured to obtain user demand data; A language module is configured to decompose the user demand data into demand specifications, the language module is further configured to search the software database and generate a software similarity candidate list, the language module is further configured to input the assembled PBC into the language model to determine its demand matching degree, and determine an assembly result based on the demand matching degree; A storage module, configured to build a software database based on historical software data and generate a contract framework model; The assembly module is configured to perform adaptability screening on the software similarity candidate list and generate a software similarity recommendation list. The assembly module is also configured to assemble the software based on the software similarity recommendation list to generate an assembled PBC.

Images