A generative software automatic assembly method and system based on contract framework model

Abstract

The present invention relates to the technical field of software assembly, and discloses a generative software automatic assembly method and system based on a contract framework model. The method comprises: obtaining user requirement data and decomposing the user requirement data into requirement specifications based on a language model; constructing a software database based on historical software data and generating a contract framework model; searching the software database using a language model based on the requirement specifications and generating a software similarity candidate list; performing adaptability screening on the software similarity candidate list using an assembly engine and generating a software similarity recommendation list; assembling software based on the software similarity recommendation list and generating an assembly PBC; inputting the assembly PBC into the language model to determine its requirement matching degree; and determining an assembly result based on the requirement matching degree. This application improves understanding of requirements and reduces the workload of manual coding.

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 involves packaging digital assets into independent components, each of which provides independent, clear, and complete business value. These components are designed to be assembled and reassembled into business processes and application experiences. Currently, cloud-native and microservices architectures offer viable solutions for building an assembly-based business architecture for software. Assembly technology typically involves business personnel manually assembling software modules, integrating them, and orchestrating processes using low-code or zero-code tools within an assembly and integration platform, using a "drag-and-drop" approach with templates and minimal coding.

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

[0004] Therefore, it is necessary to design a generative software automatic assembly method and system based on the contract framework model to solve the problems existing in 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 current problem of low assembly efficiency.

[0006] In one aspect, the present invention proposes a generative software automatic assembly method based on a contract framework model, comprising:

[0007] Acquire user demand data, and decompose the user demand data into demand specifications based on a language model;

[0008] Build a software database based on historical software data and generate a contract framework model;

[0009] Based on the requirement specification, searching the software database through a language model and generating a software similarity candidate list;

[0010] Performing adaptability screening on the software similarity candidate list based on the assembly engine, and generating a software similarity recommendation list;

[0011] Assemble the software based on the software similarity recommendation list to generate an assembled PBC (Packaged Business Capability);

[0012] Inputting the assembled PBC into the language model to determine its requirement matching degree;

[0013] Based on the requirement matching degree, an assembly result is determined.

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

[0015] Furthermore, when building a software database based on historical software data and generating a contract framework model, it includes:

[0016] Incorporate historical software data into the software database and generate PBC framework description and PBC assembly contract;

[0017] The PBC framework is described by describing dimensions, slots and designing hierarchical structures;

[0018] The PBC assembly contract is composed of preconditions, postconditions, invariants, interfaces and dependencies;

[0019] The PBC framework description is indexed.

[0020] Furthermore, based on the requirement specification, searching the software database through a language model and generating a software similarity candidate list includes:

[0021] Performing vector conversion on the requirement specification and extracting text fields;

[0022] screening the software database by semantic similarity based on the index;

[0023] Further screening the software database by text fields based on the index;

[0024] The software similarity candidate list is generated based on the further screening results.

[0025] Furthermore, when the software similarity candidate list is screened for suitability based on the assembly engine and a software similarity recommendation list is generated, the following steps are included:

[0026] Screening the software similarity candidate list based on the requirement specification;

[0027] The screening includes interface compatibility checking, precondition and postcondition verification, dependency analysis, performance indicator matching and logic conflict detection;

[0028] When the screening fails, the unqualified screening object is removed from the software similarity candidate list;

[0029] When all the software in the software similarity candidate list are unqualified, a detailed log is generated and an error is reported;

[0030] When the screening is qualified, the qualified screening objects are retained and a software similarity recommendation list is generated.

[0031] Furthermore, assembling the software based on the software similarity recommendation list to generate an assembled PBC includes:

[0032] Based on the similarity recommendation list, suitable software is selected as the assembly backbone, and software with soft risks is marked as an alternative;

[0033] Unify the communication protocol and data format of the assembly software, and determine the corresponding relationship between input and output parameters;

[0034] Load the software to be assembled, initialize the operating environment, and configure shared resources;

[0035] Merge configuration files and set global environment variables;

[0036] When all software being assembled meet 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;

[0037] Add assembled business rules and verify whether the contract conditions are met based on the solver;

[0038] When it is verified that the contract conditions are not met, the alternative software is replaced and an alarm is triggered;

[0039] When it is verified that the contract conditions are met, the PBC framework description is generated for the generated assembled PBC.

[0040] Furthermore, when assembling the software based on the software similarity recommendation list and generating the assembled PBC, the following steps are further included:

[0041] Generate API gateway and middleware code based on the assembled PBC, and connect the interface call chain of all assembled software in series;

[0042] Generate startup logic for dependent components based on the assembled PBC and integrate configuration parameters;

[0043] Performing contract consistency check and interface specification verification on the assembled PBC;

[0044] Performing dynamic testing on the assembled PBC and generating test results;

[0045] The assembled PBC is stored in the software library.

[0046] Furthermore, when the assembled PBC is input into the language model to determine its demand matching degree, it includes:

[0047] Perform text cleaning and word segmentation on the framework description of the assembled PBC and the requirement specification;

[0048] Merging the framework description of the PBC assembly and the requirement specification into a corpus, and labeling each document with a unique name;

[0049] Obtaining the frequency of words appearing therein based on the requirement specification;

[0050] Obtaining, based on the corpus, an inverse document frequency of occurrences thereof;

[0051] Multiplying the word frequency by the inverse document frequency to obtain a word frequency calculation result;

[0052] Determining the similarity between the requirement specification and the assembly PBC through cosine similarity;

[0053] A matching score is obtained based on the similarity of the assembled PBC and the result of the word frequency calculation.

[0054] Furthermore, when the assembled PBC is input into the language model to determine its demand matching degree, the method further includes:

[0055] Verify the interface compatibility and performance indicators of the assembled PBC and verify its dependencies;

[0056] determining a comprehensive score of the assembled PBC based on the matching score, the interface compatibility, and the performance index;

[0057] determining whether the assembled PBC satisfies the user requirement data based on the comprehensive score;

[0058] When the comprehensive score satisfies the user requirement data, assembling is stopped and the assembled PBC is output;

[0059] When the comprehensive score does not meet the user requirement data, the software database is re-searched and reassembled based on the user requirement data.

[0060] Compared to existing technologies, the present invention's beneficial effects lie in: using the requirements decomposition capabilities of language models to address the issues of inaccurate requirements understanding and high communication costs in traditional development. After users describe their requirements in natural language, the model automatically extracts core elements such as functionality, performance, and interfaces through contextual awareness and logical reasoning, generating a standardized requirements specification document. This process not only reduces reliance on professional requirements analysts but also avoids development deviations caused by semantic ambiguity, ensuring high alignment between requirements and implementation. Furthermore, the construction of a historical software database and a contract framework model provides systematic support for software reuse. The PBCs accumulated in the database are machine-understandable through semantic descriptions and formalized contracts (such as preconditions and dependencies), while the contract framework model provides a structured expression for component assembly rules. By logically arranging the selected PBCs according to the requirements specification, interface glue code, dependency initialization logic, and a unified configuration file can be automatically generated, while also inheriting and extending the business rules and constraints of member components. This "bottom-up" assembly approach reduces the workload of manual coding.

[0061] On the other hand, the present application also provides a generative software automatic assembly system based on a contract framework model, which is used to apply the above-mentioned generative software automatic assembly method based on a contract framework model, including:

[0062] A collection module is configured to obtain user demand data;

[0063] a language module configured to decompose the user requirement data into requirement specifications, the language module further configured to search the software database and generate a software similarity candidate list, the language module further configured to input the assembled PBC into the language model to determine its requirement matching degree, and determine an assembly result based on the requirement matching degree;

[0064] a storage module configured to build a software database based on historical software data and generate a contract framework model;

[0065] 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 further configured to assemble software based on the software similarity recommendation list to generate an assembled PBC.

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

[0067] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present invention. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0068] Figure 1 A flowchart of a generative software automatic assembly method based on a contract framework model provided by an embodiment of the present invention;

[0069] Figure 2 A flowchart of an assembly engine for a generative software automatic assembly method based on a contract framework model provided by an embodiment of the present invention;

[0070] Figure 3 This 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

[0071] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying 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 to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art. It should be noted that, unless there is a conflict, the embodiments of the present disclosure and the features in the embodiments can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in conjunction with the embodiments.

[0072] In some embodiments of the present application, see Figure 1-2 As shown, a generative software automatic assembly method based on a contract framework model includes:

[0073] Obtain user demand data and decompose it into demand specifications based on the language model.

[0074] Build a software database based on historical software data and generate a contract framework model.

[0075] Based on the requirement specification, the software database is searched through the language model and a software similarity candidate list is generated.

[0076] Based on the assembly engine, the software similarity candidate list is screened for suitability and a software similarity recommendation list is generated.

[0077] The software is assembled based on the software similarity recommendation list to generate an assembled PBC.

[0078] The assembled PBC is input into the language model to determine its requirement matching degree.

[0079] Determine the assembly result based on the demand matching degree.

[0080] Specifically, decomposing user requirement data through a language model enables computers to understand user requirements. The language model can be a large language model such as GPT. Historical software is placed into a software database, and a framework description and assembly contract for the software are generated simultaneously. The framework description semantically describes the various attributes 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 PBC assembly conditions, enabling the assembly engine to check the rationality and correctness of the assembly. Based on the constraints of the requirements specification, software that meets the requirements is selected from the software database and a candidate list of software similarity is generated. The assembly engine then screens the candidate list, eliminating non-compliant software to generate a software similarity recommendation list. Software on the software similarity recommendation list is assembled to obtain a new assembled PBC. The assembled PBC is then compared with the requirements specification using the language model to determine whether it meets the requirements. If so, assembly is terminated. If not, the process returns to the step of searching the software database to generate the candidate list of software similarity.

[0081] It's understandable that by deeply integrating language models, automated component management, and an intelligent assembly engine, a fully automated process—"requirements understanding - component retrieval - intelligent assembly - closed-loop verification"—is formed. This reduces software development's reliance on human experience while ensuring high-quality output consistent with business objectives. Language models (such as the GPT series) leverage contextual awareness and logical reasoning to translate vague natural language requirements into precise, structured requirements specifications encompassing key elements such as functional definitions, performance constraints, and interface specifications. This not only eliminates ambiguity common in traditional requirements analysis but also ensures consistent understanding between technical and business teams through standardized templates. The model automatically parses core requirements—functional domain (cross-border payments), interface type (API), and performance metrics (response time ≤ 500ms)—and generates machine-readable specifications in JSON or YAML format, laying the data foundation for subsequent component retrieval and assembly. The construction of a historical software database and contract framework model provides systematic support for the accumulation and efficient utilization of enterprise technology assets. Each PBC (Packaged Business Capability) in the database is expressed semantically in multiple dimensions through a framework description, including functional descriptions, interface definitions, dependencies, and performance metrics. This enables the language model to deeply understand the component's business value and technical characteristics. Multi-level similarity calculation and rule-driven screening enable accurate and efficient candidate component screening. Based on the requirements specification, the language model retrieves semantically matching PBCs from the software database to generate a preliminary candidate list. For example, for a "cross-border payment" requirement, the system might match components such as "currency conversion PBC," "compliance review PBC," and "multilingual support PBC," ranking them based on textual similarity. The assembly engine then verifies the candidate components using the formalized rules in the contract framework, performing hard constraint verification. This includes verification of interface parameter type compatibility (e.g., verifying that the amount field is a floating point type), protocol conformance (e.g., checking that RESTful APIs are supported), and dependency satisfiability (e.g., ensuring the availability of required user authentication services). This process replaces traditional manual code review with automated logic checks, not only improving screening efficiency by orders of magnitude but also uncovering hidden issues (e.g., version conflicts), resulting in a highly reliable recommendation list. Based on the recommended PBCs, the assembly engine automatically generates inter-component interface glue code, dependency injection logic, and unified configuration files. For example, it maps the payment gateway's output parameters to the order system's inputs 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 incorporates preconditions (requiring simultaneous availability of payment channels and risk control services) and inherits business rules (e.g., transaction amounts must be positive). This bottom-up assembly approach not only reduces manual coding but also ensures the correctness of the assembly results through formal verification (e.g., using the Z3 solver to check contract logic consistency).

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

[0083] It's understandable that the interface description in the contract framework model defines the component's input and output parameter types, communication protocols (such as RESTful APIs and gRPC), and data formats (such as JSON Schema). The assembly engine verifies interface compatibility in real time when screening candidate components. For example, if the requirements specification requires "the amount parameter of the payment interface to be a floating point type," and a candidate component's interface is defined as an integer, the engine will automatically exclude the component or trigger the generation of a type conversion adapter. Performance metrics are verified through a combination of historical test data and real-time stress testing. For example, hard constraints such as response time and throughput are embedded in the "Performance Specification" slot of the contract framework. During integration, the assembly engine prioritizes components that meet or exceed the required metrics. Each PBC in the software repository explicitly declares its dependencies (such as database connection pools and third-party service APIs) and implicit dependencies (such as configuration file paths and environment variables). The assembly engine constructs a dependency graph during integration and ensures the correct loading order through topological sorting. For example, when building an e-commerce order system, the engine will prioritize initializing the user authentication service before loading the payment gateway to avoid runtime errors caused by dependency inversion. Business rules are embedded in the contract framework's "invariant" slot via formalized logical expressions, such as "order amount must be greater than zero" and "inventory deductions must be atomic." When merging components, the assembly engine uses a SAT solver (such as Z3) to check rule consistency and prevent conflicts. Non-functional requirements such as security and maintainability are implemented through the contract framework's "guarantee mechanism" slot, using, for example, data encryption algorithms (AES-256), logging strategies (ELK integration), and monitoring metrics (Prometheus export). The assembly engine automatically injects this guarantee logic during code generation to ensure the system meets enterprise-level security and operational standards. Constraints such as technology stack restrictions (e.g., using only the Java Spring Boot framework) or compliance requirements (e.g., GDPR data privacy provisions) are enforced during candidate list generation through predefined filtering rules, for example, excluding components that rely on Python libraries or services that do not provide data desensitization interfaces.

[0084] In some embodiments of the present application, when building a software database based on historical software data and generating a contract framework model, the following steps are included:

[0085] Incorporate historical software data into the software repository and generate PBC framework description and PBC assembly contract.

[0086] The PBC framework is described by describing dimensions, slots and designing hierarchical structures.

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

[0088] Create an index for the PBC framework description.

[0089] It's understandable that the storage of historical software data and the generation of a PBC framework description can transform dispersed software assets into machine-understandable semantic resources. The framework description uses a three-layer model: "description dimension - slot - hierarchical structure" to standardize the functions, performance, interfaces, dependencies, and other attributes of each PBC. For example, when describing a "payment gateway PBC," the functional dimension might include sub-slots such as "transaction processing" and "risk control and review," while the technical dimension is refined to include 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 subcomponents (e.g., using an "encryption module" as the underlying component of a payment gateway). This not only clearly illustrates the business value and technical characteristics of a component, but also supports semantic search and automated compatibility checks. For example, a natural language query for "HTTPS-supported payment component" can accurately locate candidate PBCs, avoiding the ambiguity of traditional keyword-based matching. The formal definition of the PBC assembly contract (including preconditions, postconditions, invariants, interface specifications, and dependencies) establishes clear boundaries for the legal combination of components, fundamentally ensuring the correctness of system integration. Preconditions define the environmental conditions required for component operation (such as database connection availability and third-party service authorization validity), postconditions ensure the compliance of outputs after component execution (such as return value type and data integrity), and invariants constrain the constancy of business rules (such as "order amount must be greater than zero"). For example, when assembling the "Order Processing PBC" and "Inventory Management PBC," the assembly contract verifies sufficient inventory before order submission (precondition), atomically completes deduction operations (postcondition), and ensures that inventory quantities are always non-negative (invariant). Automated logic checking replaces manual code review, preemptively preventing interface incompatibilities, dependency conflicts, or business logic errors. The indexing of PBC framework descriptions significantly improves component reuse and assembly efficiency through search optimization. The index is constructed based on semantically described key fields (such as function labels, interface protocols, and performance metrics). Combined with inverted indexing and vector embedding technology, it supports multimodal queries—quickly locating components through precise filtering (e.g., "protocol = HTTPS," "response time ≤ 200ms"), as well as fuzzy matching through semantic similarity calculations (e.g., mapping "payment processing" to "transaction settlement"). For example, when developing a cross-border payment system, developers can enter the required keywords "multi-currency settlement" and "compliance review." The index engine will not only return PBCs explicitly annotated with these functions, but also recommend semantically related components (e.g., "exchange rate conversion PBC"). Furthermore, a hierarchical index structure (e.g., categorized by business domain, technology stack, and performance level) further accelerates the search process.

[0090] In some embodiments of the present application, based on the requirement specification, searching the software database through the language model and generating a software similarity candidate list include:

[0091] Perform vector conversion on the requirement specification and extract text fields.

[0092] Filter software repositories by semantic similarity based on index.

[0093] Further filter the software repository by text fields based on the index.

[0094] A software similarity candidate list is generated based on the results of further screening.

[0095] Specifically, the software library is initially screened based on semantic similarity, followed by further screening based on key text fields. This ultimately yields a candidate list of similar software. Key text fields (such as interface protocols, input parameter types, and response time thresholds) are structured and extracted to form programmable filtering criteria. For example, "HTTPS protocol" is marked as a required tag, providing a data foundation for subsequent, precise screening. This initial screening based on semantic similarity utilizes distance metrics in vector space (such as cosine similarity) to quickly retrieve candidate components from the software library that are most semantically relevant to the requirement. For example, when a requirement vector points to "distributed transaction management," PBCs with semantic tags such as "transaction coordination" and "distributed locks" are prioritized, even if their descriptions do not explicitly include the word "distributed." This semantic generalization capability improves search recall and is particularly useful in scenarios with diverse terminology or ambiguous requirement descriptions. Subsequently, further screening based on key text fields uses hard rules (such as protocol consistency and parameter type matching) to filter out semantically similar but technically incompatible candidates. For example, although a PBC semantically matches the "payment interface", its interface protocol is HTTP instead of the required HTTPS, or the input parameter type is integer instead of floating point. Such components will be automatically removed.

[0096] In some embodiments of the present application, when the software similarity candidate list is screened for suitability based on the assembly engine and a software similarity recommendation list is generated, the following steps are included:

[0097] Screen the software similarity candidate list based on the requirement specifications.

[0098] Screening includes interface compatibility checking, precondition and postcondition verification, dependency resolution, performance indicator matching, and logic conflict detection.

[0099] When the screening fails, the unqualified screening object is removed from the software similarity candidate list.

[0100] When all the software in the software similarity candidate list fails to meet the requirements, a detailed log is generated and an error is reported.

[0101] When the screening is qualified, the qualified screening objects are retained and a software similarity recommendation list is generated.

[0102] Understandably, the assembly engine parses candidate component interface descriptions (such as the OpenAPI specification and gRPCProtobuf) to verify protocol consistency, parameter type matching, and data format compatibility with the requirements specification. For example, when a requirement specifies that "the payment interface's amount parameter must be a floating point type and the communication protocol must be HTTPS," the engine automatically eliminates components with integer parameter types or that only support the HTTP protocol. It then uses dynamic adapter generation (such as type conversion middleware) to handle partially compatible cases that require fine-tuning, such as wrapping integer parameters as floating point types to accommodate downstream services. This flexible processing mechanism preserves high-value candidate components while avoiding the abandonment of the entire solution due to mismatched details. In precondition and postcondition verification, the component's operating context and business rules are verified by combining formalized logical expressions with a rule engine (such as Drools). Precondition verification ensures that the system state required for component execution is in place, such as that the database connection pool is initialized and that the third-party API token is valid and not expired. Postconditions enforce compliance of component outputs after execution. For example, the payment status must return "success," "failure," or "processing," and transaction logs must be persistently stored. For example, when integrating the "Inventory Deduction PBC," the engine verifies that its precondition, "Current Inventory ≥ Order Quantity," is met before invocation and, after execution, checks that its postcondition, "Inventory Quantity = Original Inventory - Order Quantity," holds true. If an anomaly is detected (such as oversold inventory), the transaction rollback is automatically triggered and the component is 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, and 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 prioritizes loading the "User Authentication PBC" and verifying the availability of the Redis connection it depends on. It then initializes the "Shopping Cart PBC" and "Order Processing PBC," which rely on the authentication service. It also detects circular dependencies (e.g., A depends on B, and B depends on A) and generates alerts. The performance indicator matching phase combines historical performance data with real-time benchmarks to quantitatively verify whether the candidate component's response time, throughput, resource usage, and other indicators meet the requirements specifications. Logical conflict detection uses model checking tools (such as Alloy and Z3) in collaboration with the business rule engine to identify incompatibilities in business rules between components. When the screening fails, the system provides developers with actionable remediation guidance through intelligent log generation and a refined error classification mechanism. For components that pass the screening, the generated recommendation list is prioritized using a multi-dimensional scoring model (such as comprehensive semantic similarity, interface matching, performance superiority, and historical reliability), and a detailed adaptation report is attached.

[0103] In some embodiments of the present application, when assembling software based on the software similarity recommendation list and generating an assembled PBC, the process includes:

[0104] Based on the similarity recommendation list, the adapted software is selected as the assembly backbone, and the software with soft risks is marked as an alternative.

[0105] Unify the communication protocols and data formats of the assembly software, and determine the correspondence between input and output parameters.

[0106] Load the assembled software, initialize the operating environment, and configure shared resources.

[0107] Merge configuration files and set global environment variables.

[0108] When all software being assembled meet 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.

[0109] Add the assembled business rules and verify whether the contract conditions are met based on the solver.

[0110] When the verification contract conditions are not met, the alternative software is replaced and an alarm is triggered.

[0111] When the verification contract conditions are met, a PBC framework description is generated for the generated assembled PBC.

[0112] Specifically, the unified handling of protocols and data formats fundamentally eliminates the technical friction of heterogeneous system integration. Through forced conversion or dynamic adapter generation (such as upgrading HTTP / 1.1 to HTTP / 2 and converting XML to JSON), seamless communication between components is ensured. Templated deployment scripts and intelligent resource allocation algorithms enable rapid construction and optimization of component operating environments. For example, when loading microservice components, Kubernetes container resources are automatically allocated dynamically based on their performance profiles (such as memory usage and thread requirements), and infrastructure such as shared Redis connection pools and database session management are configured to avoid performance bottlenecks caused by resource competition. Intelligent conflict detection and priority rules (such as "later-loaded overrides earlier-loaded") resolve the common problem of multi-component configuration conflicts. For example, when two PBCs both require modification of the same log level parameter, the configuration item for the critical service is automatically selected based on business priorities, and a difference report is generated for manual review. Furthermore, the joint verification of preconditions during the assembly process (e.g., "database connection ready" ∧ "identity service token valid") ensures state integrity at startup, while the logical union of postconditions (e.g., "payment status updated" ∧ "inventory deduction successful") defines deterministic boundaries for behavior. The inheritance and extension of invariants (e.g., "order amount > 0") are verified for their truthfulness in the newly assembled system through formal methods (e.g., TLA+ model checking), fundamentally eliminating business rule conflicts. For example, in financial systems, the consistency of "transaction amount verification" rules across all stages, including payment, clearing, and reconciliation, is ensured. Automated embedding of new business rules and solver verification (e.g., Z3 and Alloy) can uncover deep-seated logical contradictions during the design phase. For example, when integrating "Promotion Calculation PBC" with "Tax Calculation PBC," if the promotion rule allows "the price after a discount is lower than the cost price" while the tax rule requires "the price including tax ≥ the cost price × 1.1," the solver will identify this conflict and trigger an alert, guiding developers to adjust the rules or insert compensating logic (e.g., automatically adding a minimum price constraint). The final generated assembly PBC framework description provides a complete digital twin model for subsequent maintenance, expansion and auditing through structured metadata (functional domains, interface mapping, performance indicators, dependency graphs) and machine-readable contract rules.

[0113] In some embodiments of the present application, assembling software based on the software similarity recommendation list and generating an assembled PBC further includes:

[0114] Generate API gateway and middleware code based on the assembled PBC, and connect the interface call chain of all assembled software in series.

[0115] Generate startup logic for dependent components based on assembled PBC and integrate configuration parameters.

[0116] Perform contract consistency check and interface specification verification on assembled PBC.

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

[0118] Store the assembled PBC into the software database.

[0119] Specifically, the automated generation of API gateway and middleware code reshapes the interface integration development paradigm. By parsing the assembled PBC interface descriptions (such as OpenAPI specifications and gRPC service definitions), it automatically generates gateway routing rules, load balancing policies, and circuit breaker and degradation logic adapted to different protocols. For example, it dynamically maps RESTful API requests to corresponding microservice endpoints and injects common middleware such as JWT authentication and request rate limiting. The generated code strictly adheres to enterprise architecture standards (such as layered design and log standardization), avoiding code quality fluctuations caused by differences in developer skills. Based on the assembled PBC dependency graph (such as database connections, message queues, and cache services), it automatically generates Kubernetes Helm Charts or Terraform scripts to precisely orchestrate component startup order and resource quotas. For example, when launching a recommendation engine that requires a Redis cluster and a Kafka message bus, the engine first deploys Redis and waits for health checks to pass before initializing the Kafka producer. The number of shards and replicas is dynamically preset based on historical load data. Automated configuration parameter integration ensures global consistency across different components (e.g., thread pool size, timeout thresholds) through prioritized merging and conflict resolution algorithms (e.g., namespace-based parameter isolation). For example, shared database connection strings across multiple components are automatically identified and merged to avoid resource waste caused by duplicate configuration. Contract consistency checking utilizes logic solvers (e.g., Z3 and Alloy) to verify that the assembled PBC satisfies all preconditions, postconditions, and invariant constraints. For example, this ensures that the "Order Creation PBC" never calls the "Payment Execution PBC" when inventory is insufficient, thereby preventing business logic vulnerabilities. Interface specification verification ensures that input and output parameter types, data formats, and error code definitions fully comply with enterprise standards through OpenAPI Schema comparison, gRPC Protobuf compatibility testing, and a custom rules engine (e.g., Rego). The engine automatically generates a suite of test cases based on the business scenarios of the assembled PBC, including functional testing (e.g., payment success / failure branch coverage), performance testing (e.g., gradient stress loading), fault tolerance testing (e.g., dependent service downtime simulation), and security testing (e.g., SQL injection attack detection). For example, when testing an e-commerce promotion system, concurrent rush purchase requests are automatically simulated to verify the atomicity of inventory deductions and the eventual consistency of order status. Abnormal conditions such as network latency and node failures are also injected to ensure the system's resilience. Test results are analyzed using machine learning models to analyze root causes, such as linking performance bottlenecks to the thread pool configuration of specific components or missing database indexes, and recommending optimization strategies (such as adjusting the connection pool size or adding composite indexes). Finally, the assetized warehousing of assembled PBCs is implemented through multi-dimensional metadata annotation (function tags, performance baselines, dependency versions, test reports) and versioning management, building an enterprise-level knowledge reuse library.The evolution process of each PBC (such as version iteration records and defect repair tracking) is fully recorded, supporting semantic-based precise retrieval and compliance auditing.

[0120] In some embodiments of the present application, when the assembled PBC is input into the language model to determine its requirement matching degree, the following steps are included:

[0121] The framework description and requirement specification of the assembled PBC are cleaned and word segmented.

[0122] The framework description and requirement specification of assembling PBC are combined into a corpus, and each document is labeled with a unique name.

[0123] Get the frequency of words that appear in the requirement specification.

[0124] Get the inverse document frequency of occurrences of a word in a corpus.

[0125] The term frequency is calculated by multiplying the term frequency by the inverse document frequency.

[0126] The similarity between the requirement specification and the assembly PBC is determined by cosine similarity.

[0127] The matching score is obtained based on the results of the similarity and word frequency calculation of the assembled PBC.

[0128] In some embodiments of the present application, when the assembled PBC is input into the language model to determine its requirement matching degree, the following is further included:

[0129] Verify the interface compatibility and performance indicators of the assembled PBC, and verify its dependencies.

[0130] The comprehensive score of the assembled PBC is determined based on the matching score, interface compatibility and performance indicators.

[0131] Determine whether the assembled PBC meets the user demand data based on the comprehensive score.

[0132] When the comprehensive score meets the user's demand data, the assembly is stopped and the assembly PBC is output.

[0133] When the comprehensive score does not meet the user demand data, the software database is re-searched and reassembled based on the user demand data.

[0134] Specifically, the large model leverages its natural language understanding and reasoning capabilities to decompose the user's target requirement description into more specific requirements specifications, namely, PBC assembly plans. During this process, search-enhanced techniques are used to reference the PBC framework descriptions in the software asset library. Once a larger PBC is assembled, the large model generates a framework description for the new PBC based on the framework descriptions of the member PBCs. Furthermore, the large model compares the assembled PBC framework description with the user's target requirement description based on semantic similarity, determines the degree of fit between the assembled PBC requirements, and decides whether to terminate the assembly process. The PBC assembly engine, guided by the requirements specifications generated by the large model, first retrieves relevant PBCs from the software asset library. Then, based on the PBC assembly contract, it checks the functional and performance compatibility of the assembly conditions and rules between PBCs. Finally, it selects and assembles the member PBCs that meet the requirements specifications. Based on their assembly contracts, it generates the assembly contract for the assembled PBC pair. In other words, during the PBC assembly process, the large model is used to understand the user's assembly application development requirements, query related PBCs, derive assembly plans, generate the PBC framework description structure, and determine the PBC assembly progress. The large model first reads the user's development requirements. (2) Through enhanced retrieval of the PBC framework description structure in the software asset library, the big model selects relevant PBCs. (3) Based on the thinking chain capability of the big model, the requirements specification is derived from the initial requirements description to form a PBC assembly plan. (4) The assembly engine performs PBC assembly. (5) The PBC framework descriptions of the members involved in the assembly are summarized. (6) The big model generates a framework description for the assembled PBC. (7) The big model analyzes and compares the assembled PBC with the requirements specification and the original requirements description. (8) The satisfaction of the assembled PBC against the requirements is measured. If the requirements have not been met, return to step (2) and continue the assembly cycle. (9) If the original requirements have been met, terminate the assembly cycle. The workflow of the assembly engine is: (1) Input the requirements specification and related PBCs generated by the big model. (2) Use the logic checking tool to check the functional and performance compatibility between the PBC assembly contracts, select the PBCs that meet the requirements specification and the assembly conditions, and report an error if all PBCs cannot be adapted. (3) Assemble the selected member PBCs into a larger PBC, including passing correct parameters for APIs, channels, and interfaces between PBCs, correctly setting configuration files, passing correct global variables, acquiring and releasing shared resources, etc. Finally, generate an external API for the assembled PBC according to the requirements specification, and pass it through the interface. (4) Synthesize the assembly contracts of the member PBCs and specify the assembly contract of the assembled PBC. (5) Package the assembly contract of the assembled PBC, the assembly PBC framework description 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 use in subsequent assembly processes.When determining the degree of requirement matching for the assembled PBC, a semantic similarity calculation algorithm based on a pre-trained embedding model (such as BERT or SentenceBERT) is used to measure whether the PBC framework description matches the requirements. Furthermore, compatibility, performance metrics, and other relevant operational fluency data are verified to obtain a comprehensive score for the assembled PBC. This comprehensive score displays various parameters of the assembled PBC. A language model is then used to determine whether the user's requirement data (requirement specification) is met. If so, assembly is stopped and output is provided. If not, re-search and assembly are performed.

[0135] In summary, the beneficial effects of the present invention lie in: using the requirements decomposition capabilities of a language model to address the problems of inaccurate requirements understanding and high communication costs in traditional development. After users describe their requirements in natural language, the model automatically extracts core elements such as functionality, performance, and interfaces through contextual awareness and logical reasoning, generating a standardized requirements specification document. This process not only reduces reliance on professional requirements analysts but also avoids development deviations caused by semantic ambiguity, ensuring high alignment between requirements and implementation. Secondly, the construction of a historical software database and a contract framework model provides systematic support for software reuse. The PBCs accumulated in the database are machine-understandable through semantic descriptions and formalized contracts (such as preconditions and dependencies), while the contract framework model provides a structured expression for component assembly rules. By logically arranging the selected PBCs according to the requirements specification, interface glue code, dependency initialization logic, and a unified configuration file can be automatically generated, while also inheriting and extending the business rules and constraints of member components. This "bottom-up" assembly approach not only reduces manual coding workload but also ensures system robustness through formal verification.

[0136] In another preferred embodiment based on the above embodiment, refer to Figure 3 As shown, this embodiment provides a generative software automatic assembly system based on a contract framework model, which is used to apply the above-mentioned generative software automatic assembly method based on a contract framework model, including:

[0137] The acquisition module is configured to obtain user demand data.

[0138] The language module is configured to decompose user demand data into demand specifications. The language module is also configured to search the software database and generate a software similarity candidate list. The language module is also configured to input the assembled PBC into the language model to determine its demand matching degree, and determine the assembly result based on the demand matching degree.

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

[0140] 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 and generate an assembled PBC.

[0141] Specifically, the acquisition module is used to obtain user demand data, decompose it into demand specifications through the language module, and search the software database according to the demand specifications, and generate a software similarity candidate list. The adaptability of the software similarity candidate list is then screened through the assembly module to obtain a screened software similarity recommendation list, and then it is assembled according to the software similarity recommendation list to obtain an assembled PBC. When the assembled PBC is generated, the corresponding framework description will also be generated. The framework description will be screened for demand matching through the language module to decide whether to end the assembly.

[0142] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

[0144] These computer program instructions may also be stored in a computer-readable storage device that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable storage device produce an article of manufacture comprising an instruction device that implements the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0145] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0146] 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 it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered by the scope of protection 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; Determining an assembly result based on the requirement matching degree; The requirements specification includes: functional requirements, interface requirements, performance indicators, dependencies, business rules, non-functional requirements and constraints; When the software similarity candidate list is screened for suitability based on the assembly engine and a software similarity recommendation list is generated, the following steps are included: 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; 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 backbone, 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 meet 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 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 met, a PBC framework description is generated for the generated assembled PBC.

2. The method for automatically assembling generative software based on a contract framework model according to claim 1, 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 database and generate PBC framework description and PBC assembly contract; The PBC framework is described 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.

3. The method for automatically assembling generative software based on a contract framework model according to claim 2, 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 database by text fields based on the index; The software similarity candidate list is generated based on the further screening results.

4. The method for automatically assembling generative software based on a contract framework model according to claim 1, characterized in that: Assembling the software based on the software similarity recommendation list to generate an assembled PBC also includes: 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 for 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.

5. The method for automatically assembling generative software based on a contract framework model according to claim 4, characterized in that: When the assembled PBC is input 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; Merging the framework description of the PBC assembly and the requirement specification into a corpus, and labeling each document with a unique name; Obtaining the frequency of words appearing therein based on the requirement specification; Obtaining, based on the corpus, an inverse document frequency of occurrences thereof; Multiplying the word frequency by the inverse document frequency to obtain a word frequency calculation result; Determining the similarity between the requirement specification and the assembly PBC through cosine similarity; A matching score is obtained based on the similarity of the assembled PBC and the result of the word frequency calculation.

6. The method for automatically assembling generative software based on a contract framework model according to claim 5, characterized in that: When the assembled PBC is input into the language model to determine its demand matching degree, the method further 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 satisfies the user requirement data based on the comprehensive score; When the comprehensive score satisfies the user requirement data, assembling is stopped and the assembled PBC is output; When the comprehensive score does not meet the user requirement data, the software database is re-searched and reassembled based on the user requirement data.

7. 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 according to any one of claims 1 to 6, characterized in that: include: A collection module is configured to obtain user demand data; a language module configured to decompose the user requirement data into requirement specifications, the language module further configured to search the software database and generate a software similarity candidate list, the language module further configured to input the assembled PBC into the language model to determine its requirement matching degree, and determine an 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; 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 further configured to assemble software based on the software similarity recommendation list to generate an assembled PBC.

Images