Method and apparatus for determining formal specification

Abstract

The specification provides a formal specification determination method and device, the method comprising: obtaining a plurality of candidate formal specifications of a program unit to be verified, the candidate formal specifications comprising preconditions as input constraints and postconditions as output constraints; determining a first precondition with the weakest input constraint from the preconditions of the plurality of candidate formal specifications according to a logical implication relationship between the preconditions; determining a first postcondition with the strongest output constraint from the postconditions of the plurality of candidate formal specifications according to a logical implication relationship between the postconditions; combining the first precondition and the first postcondition into a first combined specification; calling a formal verification tool to determine whether the first combined specification is established for the program unit to be verified; if yes, determining the first combined specification as a target specification and outputting; if not, not determining the first combined specification as the target specification.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of program verification technology, and more particularly to a method and apparatus for determining formal specifications. Background Technology

[0002] Formal specifications are precise descriptions of the behavior of program units based on mathematical logic, typically consisting of preconditions and postconditions. Preconditions describe the constraints that the input parameters must satisfy before the program unit executes, while postconditions describe the constraints that the output results must satisfy after the program unit executes. Combining formal specifications with formal verification tools allows for rigorous mathematical proofs of the behavior of program units, enabling the detection of logical errors and security vulnerabilities during the compilation phase or before runtime.

[0003] With the application of large language model technology in software verification, automated formal specification generation tools based on large language models have emerged. These tools can automatically generate candidate formal specifications for a given program unit, reducing the cost of manually writing specifications. However, the specifications generated by each execution of the large language model differ. Even for the same program unit, multiple executions often produce multiple candidate formal specifications with different constraint granularities. Although these candidate specifications can all pass the initial verification by formal verification tools, their completeness of description of program behavior and the strength of constraints vary considerably. How to determine the target specification with reasonable constraints and verified validity from multiple candidate formal specifications is a technical problem that needs to be solved in the automated formal verification process.

[0004] Currently, there are several main methods for evaluating candidate formal specifications. One method is symbolic testing. Symbolic testing uses a mutation engine to modify the target program at the syntactic level, generating mutated input-output pairs. A symbolic execution engine then verifies whether the specification still holds true in the mutated program, based on the candidate specification. This method tests the robustness of the specification by constructing discrete mutants, but it is essentially still a testing method. The accuracy of the verification depends on the completeness of the mutants, which can only cover a finite subset of program behavior and cannot guarantee that the specification holds true in all input scenarios. In security-related verification scenarios, ordinary mutated input-output pairs often cannot accurately determine the correctness of the specification. Another method is benchmark comparison. Benchmark comparison relies on pre-written benchmark specifications as standard answers. A comparative analysis engine compares the candidate specification with the benchmark specification, calculating evaluation results such as completeness and robustness indices. This method requires the existence of manually written benchmark specifications beforehand, making it unsuitable when the verification task lacks benchmarks. Writing benchmark specifications requires deep involvement of domain experts, is costly, and is difficult to scale. The evaluation results are limited by the coverage of the benchmark specification and are difficult to generalize to new scenarios not covered by the benchmark.

[0005] It is evident that the aforementioned existing technical solutions either rely on a limited number of test cases and cannot guarantee completeness, or rely on experts to manually write benchmark specifications, which is costly and has limited generalization ability. Neither of them can automatically determine the target specification with reasonable constraints and verified validity from multiple candidate formal specifications based on the logical relationship of the candidate specifications themselves without the need for external references. Summary of the Invention

[0006] The embodiments in this specification aim to provide a method and apparatus for determining formal specifications. This method can automatically determine a target specification with reasonable constraints and verified validity from multiple candidate formal specifications. It eliminates the need for manually written benchmark specifications and the introduction of additional large language models as judges. The target specification can be determined solely using the logical relationships within the candidate specifications and formal verification tools. Therefore, it not only reduces reliance on expert knowledge and the human cost of the evaluation process, but also ensures the stability and reproducibility of the evaluation process by avoiding probabilistic models or heuristic scoring, thus overcoming the shortcomings of existing technologies.

[0007] According to the first aspect, a method for determining formal specifications is provided, including:

[0008] Obtain multiple candidate formal specifications for the program unit to be verified, each candidate formal specification including preconditions as input constraints and postconditions as output constraints;

[0009] Based on the logical implication relationship between the preconditions of the multiple candidate formal specifications, the first precondition with the weakest input constraint is determined from the preconditions of the multiple candidate formal specifications; based on the logical implication relationship between the postconditions of the multiple candidate formal specifications, the first postcondition with the strongest output constraint is determined from the postconditions of the multiple candidate formal specifications.

[0010] The first precondition and the first postcondition are combined into the first set of compliance agreements;

[0011] The formal verification tool is invoked to determine whether the first set of compliance agreements holds true for the program unit to be verified;

[0012] If the first set of compliance agreements is valid for the program unit to be verified, then the first set of compliance agreements is determined as the target agreement and output; if the first set of compliance agreements is not valid for the program unit to be verified, then the first set of compliance agreements is not determined as the target agreement.

[0013] In one possible implementation, if the first set of compliance agreements does not hold for the program unit to be verified, the method further includes:

[0014] Based on the set of preconditions consisting of the preconditions of the multiple candidate formal specifications and the set of postconditions consisting of the postconditions of the multiple candidate formal specifications, a first process comprising at least one round of iterative processing is performed, wherein each round of iterative processing in the at least one round of iterative processing includes:

[0015] Remove the weakest input constraint determined in the current round from the set of preconditions, or remove the strongest output constraint determined in the current round from the set of postconditions.

[0016] Based on the logical implication relationships among the remaining preconditions in the precondition set, determine the second precondition with the weakest input constraint from the remaining preconditions; based on the logical implication relationships among the remaining postconditions in the postcondition set, determine the second postcondition with the strongest output constraint from the remaining postconditions.

[0017] Combine the second precondition and the second postcondition into a second set of compliant contracts;

[0018] The formal verification tool is invoked to determine whether the second set of compliance agreements holds true for the program unit to be verified;

[0019] If true, the second set of compliance contracts is identified as the target contract and output, thus ending the first process;

[0020] If the condition is not met, the current iteration process ends.

[0021] In the first iteration of the at least one iteration process, the weakest input constraint determined in the current round is the first precondition, and the strongest output constraint determined in the current round is the first postcondition.

[0022] In one possible implementation, determining the first precondition with the weakest input constraint from the preconditions of the plurality of candidate formal reductions based on the logical implication relationships between the preconditions of the plurality of candidate formal reductions includes:

[0023] For any two of the multiple preconditions of the multiple candidate formal specifications, if the other precondition necessarily holds when one precondition is true, then it is determined that the input constraint of the one precondition implies the input constraint of the other precondition, and the input constraint of the other precondition is weaker than the input constraint of the one precondition.

[0024] From the preconditions of the plurality of candidate formal reductions, the precondition implied by all other preconditions is selected as the first precondition;

[0025] The step of determining the first postcondition with the strongest output constraint from the postconditions of the multiple candidate formal reductions based on the logical implication relationships between them includes:

[0026] For any two of the multiple postconditions of the multiple candidate formal specifications, if the other postcondition necessarily holds when one postcondition is true, then it is determined that the output constraint of the one postcondition implies the output constraint of the other postcondition, and the output constraint of the one postcondition is stronger than the output constraint of the other postcondition.

[0027] From the postconditions of the plurality of candidate formal specifications, select the postcondition that is not implied by any other postcondition as the first postcondition.

[0028] In one possible implementation, if a loop structure exists in the program unit to be verified, the invocation of the formal verification tool to determine whether the first set of compliance agreements holds for the program unit to be verified includes:

[0029] Based on the first precondition and the first postcondition, candidate loop invariants are determined;

[0030] Use formal verification tools to determine whether the first set of compliance contracts holds under the candidate cyclic invariants;

[0031] If the first set of compliant contracts holds under the candidate cyclic invariants, then the candidate cyclic invariants are taken as the target cyclic invariants, and the first set of compliant contracts and the target cyclic invariants are determined as the target reduction and output.

[0032] In one possible implementation, determining the candidate cycle invariant based on the first precondition and the first postcondition includes:

[0033] Extract the first cyclic invariant corresponding to the first precondition and the second cyclic invariant corresponding to the first postcondition from the plurality of candidate formal specifications;

[0034] The first loop invariant, the second loop invariant, and the logical AND of the first loop invariant and the second loop invariant are determined as three candidate loop invariants;

[0035] The step of calling a formal verification tool to determine whether the first set of compliance conditions holds under the candidate cyclic invariants includes:

[0036] Based on the second cyclic invariant, the logical AND of the first cyclic invariant and the second cyclic invariant, and the order of the first cyclic invariant, each candidate cyclic invariant is sequentially verified to ensure that the first set of contracts is valid. If any candidate cyclic invariant makes the first set of contracts valid, the candidate cyclic invariant is taken as the target cyclic invariant, and the verification of unverified candidate cyclic invariants is stopped.

[0037] In one possible implementation, based on the second cyclic invariant, the logical AND of the first cyclic invariant and the second cyclic invariant, and the order of the first cyclic invariant, each candidate cyclic invariant is sequentially verified to ensure that the first set of covenants is satisfied; if any candidate cyclic invariant ensures that the first set of covenants is satisfied, the candidate cyclic invariant is taken as the target cyclic invariant, and the verification of unverified candidate cyclic invariants is stopped, including:

[0038] If the first antecedent condition can derive the second cyclic invariant, and the second cyclic invariant can derive the first postcondition under the loop termination condition, then the second cyclic invariant is determined as the target cyclic invariant that makes the first set of contracts valid; otherwise,

[0039] If the first precondition can derive the logical AND of the first loop invariant and the second loop invariant, and the second loop invariant can derive the first postcondition under the loop termination condition, then the logical AND of the first loop invariant and the second loop invariant is determined as the loop invariant that makes the first set of contracts valid; otherwise,

[0040] If the first loop invariant can derive the first subsequent condition under the loop termination condition, and the first preceding condition can derive the first loop invariant, then the first loop invariant is determined as the loop invariant that makes the first set of contracts valid; otherwise,

[0041] It is determined that none of the three candidate cyclic invariants can make the first set of contracts valid.

[0042] In one possible implementation, the plurality of candidate formal specifications are all generated by an automated formal specification generation tool based on a large language model for the program unit to be verified and pass the preliminary verification by the formal verification tool.

[0043] According to the second aspect, a formal specification determination apparatus is provided, the apparatus comprising:

[0044] The specification acquisition module is used to acquire multiple candidate formal specifications of the program unit to be verified. Each candidate formal specification includes preconditions as input constraints and postconditions as output constraints.

[0045] The condition determination module is used to determine the first precondition with the weakest input constraint from the preconditions of the multiple candidate formal specifications based on the logical implication relationship between the preconditions of the multiple candidate formal specifications; and to determine the first postcondition with the strongest output constraint from the postconditions of the multiple candidate formal specifications based on the logical implication relationship between the postconditions of the multiple candidate formal specifications.

[0046] The specification combination module is used to combine the first precondition and the first postcondition into a first set of compliance contracts;

[0047] The verification module is used to call formal verification tools to determine whether the first set of compliance agreements holds true for the program unit to be verified.

[0048] The specification determination module is used to determine the first set of compliance specifications as the target specification and output it if the verification module determines that the first set of compliance specifications is valid for the program unit to be verified; if the verification module determines that the first set of compliance specifications is not valid for the program unit to be verified, the first set of compliance specifications is not determined as the target specification.

[0049] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0050] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0051] By utilizing one or more of the methods, apparatuses, computing devices, and storage media mentioned above, the weakest input constraint and the strongest output constraint can be determined by leveraging the logical implication relationships between the preconditions and postconditions of multiple candidate formal specifications. These two conditions are then combined into a first set of specifications for formal verification. Since there is no need to rely on manually written benchmark specifications or introduce additional large language models as judges, the target specification can be determined solely using the logical relationships within the candidate specifications and formal verification tools, reducing reliance on expert knowledge and the human resource costs of the evaluation process. Combining the weakest precondition with the strongest postcondition allows for the determination of the target specification with the broadest applicability and the most accurate output description within the constraints covered by the candidate specifications, improving the verification value of the determined results. The derivation process based on logical implication relationships is deterministic, not reliant on probabilistic models or heuristic scoring, ensuring the stability and reproducibility of the evaluation process. Attached Figure Description

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

[0053] Figure 1 This is a schematic diagram of a symbolic testing method for formal specifications.

[0054] Figure 2 This is a schematic diagram of a benchmark comparison method for formal specifications.

[0055] Figure 3 A flowchart illustrating a method for determining a formal specification according to an embodiment of the present invention.

[0056] Figure 4 This is a schematic diagram illustrating the logical implication relationship provided in one embodiment of the present invention.

[0057] Figure 5 This is a schematic diagram of precondition sorting provided for one embodiment of the present invention.

[0058] Figure 6 This is a schematic diagram of post-condition sorting provided in one embodiment of the present invention.

[0059] Figure 7 A flowchart of an iterative processing flow provided in one embodiment of the present invention.

[0060] Figure 8 This is a schematic diagram of the extraction of cyclic invariants according to an embodiment of the present invention.

[0061] Figure 9 This is a flowchart for verifying cyclic invariants according to an embodiment of the present invention.

[0062] Figure 10 This is a structural block diagram of a formal specification determination apparatus provided in one embodiment of the present invention. Detailed Implementation

[0063] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0064] As mentioned earlier, in the field of formal verification of software, formal specifications are the core element for mathematically describing the behavior of program units. A formal specification typically consists of preconditions and postconditions. Preconditions describe the constraints that the input parameters must satisfy before program execution, while postconditions describe the constraints that the output results must satisfy after program execution. With the development of large language model technology, automated formal specification generation tools based on large language models can automatically generate candidate formal specifications for a given program unit, reducing the cost of manually writing specifications. However, the specifications generated by large language models differ with each execution, and multiple executions of the same program unit often produce multiple candidate formal specifications with different constraint granularities. How to determine the target specification with reasonable constraints and verified validity from multiple candidate formal specifications is a technical problem that needs to be solved in the automated formal verification process.

[0065] Currently, the main methods for evaluating candidate formal specifications include the symbolic testing method and the benchmark comparison method. The basic idea of ​​the symbolic testing method is as follows: Figure 1 As shown, the target program is modified at the syntactic level by a mutation engine to generate mutated input-output pairs 101. Then, a symbolic execution engine, combined with candidate reductions 102, verifies whether the reduction still holds true in the mutated program. This method detects the robustness of the reduction by constructing discrete mutants, but it is essentially a testing method. The accuracy of the verification depends on the completeness of the mutants, which can only cover a finite subset of program behavior and cannot guarantee that the reduction holds true in all input scenarios. In security-related verification scenarios, ordinary mutated input-output pairs often cannot accurately determine the correctness of the reduction. The basic idea of ​​the benchmark comparison method is as follows... Figure 2 As shown, this method relies on a pre-written baseline specification 201 as the standard answer. A comparative analysis engine compares candidate specification 202 with the baseline specification 201, calculating evaluation results such as completeness and robustness metrics. This method requires a pre-existing manually written baseline specification, making it unsuitable when the verification task lacks a baseline. The writing of baseline specifications requires deep involvement from domain experts, is costly, and difficult to scale. Evaluation results are limited by the coverage of the baseline specification and cannot be generalized to new scenarios not covered by the baseline. If a specification holds true on all variants, it indicates that the constraint of the specification is too broad and lacks practical binding force. This method can identify overly broad specifications but cannot determine a reasonably constrained target specification from multiple candidate specifications, nor can it guide how to combine better specifications.

[0066] Another approach is the mutation test method. This method generates multiple variants by making minor semantically equivalent modifications to the target program and then tests the validity of the candidate specification across these variants. If the specification holds true in all variants, it indicates that the constraint is too broad and lacks practical binding force. This method can identify overly broad specifications, but it cannot determine a reasonably constrained target specification from multiple candidate specifications, nor can it guide how to combine better specifications. Yet another approach is the specification ranking method. This method defines multiple evaluation metrics and uses a large language model to score and rank candidate specifications. However, due to the illusion problem inherent in large language models, the accuracy and consistency of their judgments are difficult to guarantee, leading to a lack of stability and reliability in the evaluation process.

[0067] In summary, existing specification evaluation methods either rely on limited test cases, thus failing to guarantee completeness; or depend on experts manually writing benchmark specifications, which is costly and has limited generalization ability; or can only identify overly broad specifications and cannot determine the target specification; or rely on large language models for evaluation, resulting in unstable results. None of these methods can automatically determine a reasonably constrained and verified target specification from multiple candidate formal specifications based on the logical relationships within the candidate specifications themselves, without requiring external references.

[0068] To address the aforementioned technical problems, embodiments of the present invention provide a method for determining formal specifications. The detailed process of this method is described below with reference to the accompanying drawings. Figure 3 A flowchart illustrating a method for determining a formal specification according to an embodiment of the present invention. Figure 3 The method includes at least the following steps:

[0069] Step S301: Obtain multiple candidate formal specifications for the program unit to be verified. Each candidate formal specification includes a precondition as an input constraint and a postcondition as an output constraint.

[0070] Step S302: Based on the logical implication relationship between the preconditions of the multiple candidate formal specifications, determine the first precondition with the weakest input constraint from the preconditions of the multiple candidate formal specifications; based on the logical implication relationship between the postconditions of the multiple candidate formal specifications, determine the first postcondition with the strongest output constraint from the postconditions of the multiple candidate formal specifications.

[0071] Step S303: Combine the first precondition and the first postcondition into a first set of compliance agreements;

[0072] Step S304: Call the formal verification tool to determine whether the first set of compliance agreements holds true for the program unit to be verified;

[0073] Step S305: If the first set of compliance agreements is valid for the program unit to be verified, then the first set of compliance agreements is determined as the target agreement and output; if the first set of compliance agreements is not valid for the program unit to be verified, then the first set of compliance agreements is not determined as the target agreement.

[0074] First, in step S301, multiple candidate formal specifications of the program unit to be verified can be obtained. Each candidate formal specification includes a precondition as an input constraint and a postcondition as an output constraint.

[0075] In different embodiments, the program unit to be verified can be a function, a method, a procedure, or other verifiable unit in the program with independent input-output semantics. Candidate formal specifications can be generated by an automated formal specification generation tool based on a large language model, executed multiple times on the program unit to be verified. During multiple executions, due to the randomness of the large language model's generation mechanism, each execution may produce specifications with different constraint granularities. For example, for the same function calculating the square root, the precondition generated in one execution might be "the input parameter is a positive real number," while the precondition generated in another execution might be "the input parameter is a real number greater than 1." Both can pass the initial verification by the formal verification tool, but the granularity of the input constraint description differs. The obtained multiple candidate formal specifications form a candidate specification set, each containing independent preconditions and postconditions.

[0076] Next, in step S320, the first precondition with the weakest input constraint can be determined from the preconditions of the multiple candidate formal specifications based on the logical implication relationship between the preconditions of the multiple candidate formal specifications; and the first postcondition with the strongest output constraint can be determined from the postconditions of the multiple candidate formal specifications based on the logical implication relationship between the postconditions of the multiple candidate formal specifications.

[0077] Logical implication is a deductive relationship between two logical expressions. For example, if condition A is true, then condition B must be true; therefore, A implies B, denoted as A⇒B. The implication relationship means that the scope of constraints of A is encompassed by the scope of constraints of B, and the constraints of B are weaker than those of A. Regarding the antecedent condition, if the antecedent condition P1 is true, then the antecedent condition P2 must be true. In this case, the input constraints of P1 imply the input constraints of P2, and the input constraints of P2 are weaker than those of P1. For example, if the antecedent condition "the input parameter is an integer greater than 2" is true, then the antecedent condition "the input parameter is a positive integer" must be true. Therefore, "integer greater than 2" implies "positive integer," which is a weaker antecedent condition with fewer constraints on the input and a wider applicability. Regarding the consequent condition, if the consequent condition Q1 is true, then the consequent condition Q2 must be true. In this case, the output constraints of Q1 imply the output constraints of Q2, and the output constraints of Q1 are stronger than those of Q2. For example, if the condition "the return value is equal to the square root of the input and the error is less than 0.001" is true, then the condition "the return value is greater than 0" must also be true. Therefore, the output constraint of the former is stronger than that of the latter.

[0078] Figure 4 This is a schematic diagram illustrating the logical implication relationship provided in one embodiment of the present invention. For example... Figure 4 As shown, the input constraint of precondition 401 implies the input constraint of precondition 402, and the direction of the arrow indicates the implication relationship. The constraint of 402 is less and weaker. The output constraint of postcondition 403 implies the output constraint of postcondition 404, and the constraint of 403 is more and stronger.

[0079] Figure 5 This is a schematic diagram illustrating the precondition sorting provided in one embodiment of the present invention. For example... Figure 5 As shown, multiple preconditions can form a partial order structure according to implication relations. Precondition 501 implies precondition 502, and precondition 502 implies precondition 503. Precondition 503 is implied by all other preconditions, and its input constraint is the weakest, so it is determined as the first precondition. The method for determining the first precondition is as follows: for any two of the multiple preconditions of multiple candidate formal specifications, if the other precondition must be true if one of the preconditions is true, then it is determined that the input constraint of the one precondition implies the input constraint of the other precondition, and the input constraint of the other precondition is weaker than the input constraint of the one precondition; from the preconditions of multiple candidate formal specifications, the precondition implied by all other preconditions is selected as the first precondition.

[0080] Figure 6 This is a schematic diagram illustrating post-conditional sorting according to an embodiment of the present invention. Figure 6As shown, multiple postconditions can form a partial order structure according to implication relations. Postcondition 601 implies postcondition 602, and postcondition 602 implies postcondition 603. Postcondition 601 is not implied by any other postcondition, and its output constraint is the strongest, so it is determined as the first postcondition. The method for determining the first postcondition is as follows: for any two of the multiple postconditions of multiple candidate formal specifications, if the other postcondition must be true if one postcondition is true, then it is determined that the output constraint of the one postcondition implies the output constraint of the other postcondition, and the output constraint of the one postcondition is stronger than the output constraint of the other postcondition; from the postconditions of multiple candidate formal specifications, the postcondition that is not implied by any other postcondition is selected as the first postcondition.

[0081] After obtaining the first precondition and the first postcondition, in step S330, the first precondition and the first postcondition can be combined into a first set of compliant contracts.

[0082] The first precondition and the first postcondition are derived from different candidate formal reductions. The first precondition is taken from the candidate reduction with the weakest input constraints, and the first postcondition is taken from the candidate reduction with the strongest output constraints. The combination process involves using the first precondition as an input constraint and the first postcondition as an output constraint to construct a new reduction pair. This reduction pair does not require the precondition and postcondition to come from the same candidate reduction; instead, it selects the conditions with the best constraints from their respective dimensions for cross-reduction combination. This combination method makes the first set of reductions have the widest applicability on the input side and the highest descriptive accuracy on the output side, thus achieving the optimal combination within the constraint range covered by the candidate reductions.

[0083] In one embodiment, if among multiple candidate formal specifications, there exists a candidate specification whose precondition and postcondition are exactly equal to the first precondition and the first postcondition, respectively, then that candidate specification itself is the first set of compliant specifications and requires no additional construction. In another embodiment, if no candidate specification simultaneously contains the first precondition and the first postcondition, then the first precondition and the first postcondition are concatenated and combined into a new specification expression for subsequent verification.

[0084] After obtaining the first set of compliance contracts, in step S340, a formal verification tool can be invoked to determine whether the first set of compliance contracts holds true for the program unit to be verified.

[0085] Formal verification tools can verify, based on mathematical proofs, whether the behavior of a program unit under given specification constraints meets the specification requirements. In different embodiments, the formal verification tool can be one or more of Kani, Dafny, Verus, Viper, and Frama-C. Different formal verification tools can be used to perform formal verification on program units based on different programming languages ​​and verification paradigms, and this specification does not impose any limitations on this. After receiving the source code of the program unit to be verified and the first set of specifications, the formal verification tool attempts to construct a mathematical proof to confirm whether the execution result of the program unit necessarily satisfies the first postcondition when the input satisfies the first precondition. If the proof is successfully constructed, the first set of specifications holds for the program unit to be verified; if the proof fails to be constructed, the first set of specifications does not hold for the program unit to be verified.

[0086] The proof may fail because the combination of the first antecedent and the first consequent is too aggressive. The weakest antecedent implies the widest range of inputs, while the strongest consequent implies the most stringent output requirements. The combination of these two may exceed the correctness boundaries that the program unit to be verified can actually guarantee. For example, the program unit to be verified may not be able to guarantee that the output satisfies the constraints of the strongest consequent in some input scenarios, causing the verification tool to be unable to complete the proof construction.

[0087] Subsequently, in step S350, the target specification can be determined based on the verification results. Specifically, if the first set of specifications holds true for the program unit to be verified, then the first set of specifications is determined as the target specification and output. The target specification is a specification confirmed to hold true through formal verification, which can accurately describe the output behavior of the program unit to be verified under given input constraints. The holding of the first set of specifications means that even under the weakest input constraints, the strongest postcondition of the output constraints can still be satisfied, and this set of specifications has the optimal verification value within the constraint range covered by the candidate specifications. After being determined as the target specification, this specification can be output for use in the downstream formal verification process, or it can be archived as part of the program documentation.

[0088] If the first set of compliance contracts does not hold for the program unit to be verified, then the first set of compliance contracts is not determined as the target specification. The failure of the first set of compliance contracts indicates that the direct combination of the weakest antecedent and the strongest consequent exceeds the correctness boundary of the program unit to be verified, requiring other strategies to determine the target specification from the candidate specifications. In one embodiment, the target specification can be determined iteratively based on the set of antecedents (composed of the antecedents) and the set of consequents (composed of the consequents) of multiple candidate formal specifications; the specific process will be described later.

[0089] If the first set of compliance contracts does not hold for the program unit to be verified, a first processing step involving at least one round of iteration is required, based on the set of preconditions consisting of the preconditions of multiple candidate formal contracts and the set of postconditions consisting of the postconditions of multiple candidate formal contracts.

[0090] In one embodiment, each iteration of the first process may include the following steps: removing the weakest input constraint from the set of preconditions in the current round, or removing the strongest output constraint from the set of postconditions in the current round. The removal operation narrows the range of conditions that can be combined, ensuring that the combination of conditions selected in the next round differs from the previous round. In the first iteration of at least one iteration process, the weakest input constraint precondition determined in the current round is the first precondition determined in step S320, and the strongest output constraint postcondition determined in the current round is the first postcondition determined in step S320.

[0091] Based on the logical implication relationships among the remaining preconditions in the precondition set, the second precondition with the weakest input constraint is determined from the remaining preconditions; based on the logical implication relationships among the remaining postconditions in the postcondition set, the second postcondition with the strongest output constraint is determined from the remaining postconditions. The method for determining the second precondition and the second postcondition is the same as the method for determining the first precondition and the first postcondition in step S320, the only difference being that the candidate range is narrowed due to the removal operation.

[0092] The second precondition and the second postcondition are combined into a second set of compliance specifications. Formal verification tools are then used to determine whether the second set of compliance specifications holds true for the program unit to be verified. If it holds true, the second set of compliance specifications is identified as the target specification and output, ending the first processing step. If it does not hold true, the current iteration ends, and the next iteration begins.

[0093] Figure 7 A flowchart illustrating an iterative processing flow provided in one embodiment of the present invention. Figure 7 In the example shown, the overall iterative process can be as follows: After constructing the precondition set and postcondition set, remove the precondition with the weakest input constraint or the postcondition with the strongest output constraint determined in the current round from the set. Then, determine the second precondition and the second postcondition from the remaining conditions, combine them into a second set of specifications, and call the formal verification tool to determine whether it is valid. If it is valid, it is determined as the target specification and output, ending the first process. If it is not valid, determine whether the maximum number of iterations has been reached. If the maximum number of iterations has not been reached, return to the removal operation and continue to the next round of iteration. If the maximum number of iterations has been reached, randomly select one from the candidate formal specifications as the target specification output.

[0094] In the iterative processing of different embodiments, the choice between removing the weakest precondition or the strongest postcondition in each round can vary. In one embodiment, the weakest precondition and the strongest postcondition are removed alternately in each iteration. In another embodiment, each iteration compares the combinatorial reductions formed by the remaining conditions after removing the weakest precondition and the strongest postcondition, and selects the direction with a higher probability of verification success for removal. In yet another embodiment, each iteration removes both branches simultaneously, verifies the combinatorial reductions of the two branches separately, and terminates the first processing step immediately if either branch succeeds.

[0095] The maximum number of iterations is used to control the execution time of the algorithm. When the number of candidate reductions is N, the maximum number of iterations can be set to N or a preset value greater than N to ensure that the algorithm can traverse a sufficient number of condition combinations. If no valid combination reduction is found after reaching the maximum number of iterations, one is randomly selected from the candidate formal reductions as the target reduction output, which ensures that the algorithm's execution result is not worse than random selection.

[0096] When a program unit to be verified contains a loop structure, formal verification tools require loop invariants to verify whether the reduction holds. Loop invariants are assertions that remain true before and after each execution of the loop body, and are a key element in handling loop structures in formal verification. Without suitable loop invariants, formal verification tools often cannot complete the proof construction.

[0097] If a loop structure exists in the program unit to be verified, the process of calling the formal verification tool to determine whether the first set of compliance restrictions holds for the program unit to be verified includes: determining candidate loop invariants based on the first precondition and the first postcondition; calling the formal verification tool to determine whether the first set of compliance restrictions holds under the candidate loop invariants; if the first set of compliance restrictions holds under the candidate loop invariants, then the candidate loop invariants are used as the target loop invariants, and the first set of compliance restrictions and the target loop invariants are determined as the target reduction and output.

[0098] Figure 8 This is a schematic diagram illustrating the extraction of cyclic invariants according to an embodiment of the present invention. Figure 8In the example shown, the process of determining candidate loop invariants can be as follows: Extract the first loop invariant I1 corresponding to the first precondition and the second loop invariant I2 corresponding to the first postcondition from multiple candidate formal specifications. The first precondition comes from a candidate formal specification that contains the corresponding loop invariant; this loop invariant is taken as the first loop invariant I1. Similarly, the first postcondition comes from another candidate formal specification that contains the corresponding loop invariant; this loop invariant is taken as the second loop invariant I2. The first loop invariant I1, the second loop invariant I2, and the logical AND of the first loop invariant I1 and the second loop invariant I2 (I1∧I2) are used to determine three candidate loop invariants.

[0099] In one embodiment, the selection of these three candidate loop invariants can be understood using the while rule and the consequence rule in Hall logic. For example, suppose two sets of candidate reductions are (P1, Q1, I1) and (P2, Q2, I2), where P2⇒P1 and Q1⇒Q2. The goal is to find an Ibest that makes the reduction (P1, Q2, Ibest) true. According to the while rule, (P1, Q1, I1) true means... All of these hold true, where b is the loop condition, S is the loop body, wp is the weakest precondition, ⇒ represents logical implication, ∧ represents logical AND, and ¬b represents the negation of the loop condition b. Similarly, the validity of (P2, Q2, I2) implies that... All are true. The goal is to make The following conditions are true. Based on the implication rule, we can derive the following judgment conditions: If P1⇒I2 and I2∧¬b⇒Q2 are true, then Ibest=I2. Otherwise, if P1⇒I1∧I2 and I2∧¬b⇒Q2 are true, then Ibest=I1∧I2. Otherwise, if I1∧¬b⇒Q2 and P1⇒I1 are true, then Ibest=I1.

[0100] Figure 9 This is a flowchart illustrating the verification of cyclic invariants according to an embodiment of the present invention. Figure 9In the example shown, the three candidate loop invariants can be verified sequentially in the order of I2, I1∧I2, and I1. First, verify I2: If the first antecedent condition implies the second loop invariant I2, and the second loop invariant I2 implies the first postcondition under the loop termination condition, then I2 is determined as the target loop invariant that makes the first set of compliant contracts true, and the verification of unverified candidate loop invariants stops. If I2 does not meet the conditions, verify I1∧I2: If the first antecedent condition implies I1∧I2, and I2 implies the first postcondition under the loop termination condition, then I1∧I2 is determined as the target loop invariant. If I1∧I2 does not meet the conditions, verify I1: If I1 implies the first postcondition under the loop termination condition, and the first antecedent condition implies I1, then I1 is determined as the target loop invariant. If none of the three candidate loop invariants meet the conditions, it is determined that none of the three candidate loop invariants make the first set of compliant contracts true.

[0101] The choice of verification order can be based on considerations of success probability. I2 originates from the candidate specification containing the first postcondition. This candidate specification has the strongest postcondition constraint, and its cyclic invariant I2 has a high degree of matching with the strongest postcondition, making the proof most likely to be true. I1∧I2 combines information from two cyclic invariants, providing richer constraints, but with a slightly lower success probability. I1 originates from the candidate specification containing the first antecedent condition; when used alone, it provides the least constraint information and has the lowest success probability. Verifying in the order of I2, I1∧I2, and I1 allows for the discovery of valid cyclic invariants at an earlier stage, reducing unnecessary verification calculations. If any candidate cyclic invariant makes the first set of compliant specifications true, that candidate cyclic invariant is taken as the target cyclic invariant, and subsequent verification is stopped, avoiding redundant verification overhead.

[0102] Multiple candidate formal specifications can be generated for the program unit to be verified using an automated formal specification generation tool based on a large language model. This type of tool takes the source code of the program unit as input and automatically generates formal specifications describing the program's behavior using the reasoning capabilities of the large language model. Due to the randomness of the large language model's generation process, executing the generation tool multiple times on the same program unit can yield multiple candidate formal specifications with different constraint granularities. The generated candidate formal specifications need to undergo preliminary verification by a formal verification tool to ensure that each candidate specification is valid at both the syntactic and basic semantic levels. Candidate specifications that pass the preliminary verification are collected into a candidate specification set for use in subsequent screening and determination processes.

[0103] Through the above embodiments, the formal specification determination method provided by the present invention has the following advantages: First, it can automatically determine a target specification with reasonable constraints and verified validity based on the logical relationships of the candidate specifications themselves, without the need for external references. This method utilizes the logical implication relationships between the preconditions and postconditions of multiple candidate formal specifications to determine the first precondition with the weakest input constraint and the first postcondition with the strongest output constraint, and combines them into a first set of valid specifications for formal verification. Since it does not rely on manually written benchmark specifications or introduce additional large language models as judges, the determination of the target specification can be completed using only the logical relationships of the candidate specifications themselves and formal verification tools, reducing reliance on expert knowledge and the human resource cost of the evaluation process. Second, by combining the weakest precondition with the strongest postcondition, the target specification with the widest applicability and the most accurate output description can be determined within the constraint range covered by the candidate specifications, improving the verification value of the determination result. The derivation process based on logical implication relationships is deterministic, does not rely on probabilistic models or heuristic scoring, and ensures the stability and reproducibility of the evaluation process. Third, when a loop structure exists in the program unit to be verified, by extracting loop invariants from candidate specifications and verifying them in a specific order, the target loop invariant that makes the set of specifications true can be determined within a fewer number of verifications, thus improving the verification efficiency of programs containing loops. When the first set of specifications does not hold, by iteratively adjusting the combination of conditions, the target specification that holds true can be found within the constraints of the candidate specifications, ensuring the robustness of the verification process.

[0104] According to another embodiment, a formal specification determination apparatus is also provided. Figure 10 This is a structural block diagram of a formal specification determination apparatus provided in one embodiment of the present invention. As shown in FIG100, the apparatus 1000 includes:

[0105] The specification acquisition module 1001 is used to acquire multiple candidate formal specifications of the program unit to be verified. Each candidate formal specification includes a precondition as an input constraint and a postcondition as an output constraint.

[0106] The condition determination module 1002 is used to determine the first precondition with the weakest input constraint from the preconditions of the multiple candidate formal specifications based on the logical implication relationship between the preconditions of the multiple candidate formal specifications; and to determine the first postcondition with the strongest output constraint from the postconditions of the multiple candidate formal specifications based on the logical implication relationship between the postconditions of the multiple candidate formal specifications.

[0107] The specification combination module 1003 is used to combine the first precondition and the first postcondition into a first set of compliance contracts.

[0108] Verification module 1004 is used to call formal verification tools to determine whether the first set of compliance agreements holds true for the program unit to be verified;

[0109] The specification determination module 1005 is used to determine the first set of compliance specifications as the target specification and output it if the verification module determines that the first set of compliance specifications is valid for the program unit to be verified; if the verification module determines that the first set of compliance specifications is not valid for the program unit to be verified, the first set of compliance specifications is not determined as the target specification.

[0110] In another aspect, embodiments of this specification provide a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform any of the methods described above.

[0111] In another aspect, embodiments of this specification provide a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement any of the methods described above.

[0112] It should be understood that the descriptions such as "first" and "second" in this article are merely for the sake of simplicity in description and to distinguish similar concepts, and do not have any other limiting function.

[0113] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0114] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0115] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0116] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0117] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0118] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0119] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0120] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0121] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0122] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0123] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0124] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take 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.

[0125] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0126] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0127] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for determining a formal specification, comprising: Obtain multiple candidate formal specifications for the program unit to be verified, each candidate formal specification including preconditions as input constraints and postconditions as output constraints; Based on the logical implication relationship between the preconditions of the multiple candidate formal reductions, the first precondition with the weakest input constraint is determined from the preconditions of the multiple candidate formal reductions; Based on the logical implication relationship between the postconditions of the multiple candidate formal specifications, the first postcondition with the strongest output constraint is determined from the postconditions of the multiple candidate formal specifications. The first precondition and the first postcondition are combined into the first set of compliance agreements; The formal verification tool is invoked to determine whether the first set of compliance agreements holds true for the program unit to be verified; If the first set of compliance agreements is valid for the program unit to be verified, then the first set of compliance agreements is determined as the target agreement and output; if the first set of compliance agreements is not valid for the program unit to be verified, then the first set of compliance agreements is not determined as the target agreement.

2. The method of claim 1, wherein, If the first set of compliance agreements does not hold for the program unit to be verified, the method further includes: Based on the set of preconditions consisting of the preconditions of the multiple candidate formal specifications and the set of postconditions consisting of the postconditions of the multiple candidate formal specifications, a first process comprising at least one round of iterative processing is performed, wherein each round of iterative processing in the at least one round of iterative processing includes: Remove the weakest input constraint determined in the current round from the set of preconditions, or remove the strongest output constraint determined in the current round from the set of postconditions. Based on the logical implication relationships among the remaining preconditions in the precondition set, determine the second precondition with the weakest input constraint from the remaining preconditions; based on the logical implication relationships among the remaining postconditions in the postcondition set, determine the second postcondition with the strongest output constraint from the remaining postconditions. Combine the second precondition and the second postcondition into a second set of compliant contracts; The formal verification tool is invoked to determine whether the second set of compliance agreements holds true for the program unit to be verified; If true, the second set of compliance contracts is identified as the target contract and output, thus ending the first process; If the condition is not met, the current iteration process ends. In the first iteration of the at least one iteration process, the weakest input constraint determined in the current round is the first precondition, and the strongest output constraint determined in the current round is the first postcondition.

3. The method according to claim 1, wherein, The step of determining the weakest first precondition from the preconditions of the multiple candidate formal reductions based on the logical implication relationships between them includes: For any two of the multiple preconditions of the multiple candidate formal specifications, if the other precondition necessarily holds when one precondition is true, then it is determined that the input constraint of the one precondition implies the input constraint of the other precondition, and the input constraint of the other precondition is weaker than the input constraint of the one precondition. From the preconditions of the plurality of candidate formal reductions, the precondition implied by all other preconditions is selected as the first precondition; The step of determining the first postcondition with the strongest output constraint from the postconditions of the multiple candidate formal reductions based on the logical implication relationships between them includes: For any two of the multiple postconditions of the multiple candidate formal specifications, if the other postcondition necessarily holds when one postcondition is true, then it is determined that the output constraint of the one postcondition implies the output constraint of the other postcondition, and the output constraint of the one postcondition is stronger than the output constraint of the other postcondition. From the postconditions of the plurality of candidate formal specifications, select the postcondition that is not implied by any other postcondition as the first postcondition.

4. The method according to claim 1, wherein, If a loop structure exists in the program unit to be verified, then calling the formal verification tool to determine whether the first set of compliance agreements holds for the program unit to be verified includes: Based on the first precondition and the first postcondition, candidate loop invariants are determined; Use formal verification tools to determine whether the first set of compliance contracts holds under the candidate cyclic invariants; If the first set of compliant contracts holds under the candidate cyclic invariants, then the candidate cyclic invariants are taken as the target cyclic invariants, and the first set of compliant contracts and the target cyclic invariants are determined as the target reduction and output.

5. The method according to claim 4, wherein, The determination of candidate cycle invariants based on the first precondition and the first postcondition includes: Extract the first cyclic invariant corresponding to the first precondition and the second cyclic invariant corresponding to the first postcondition from the plurality of candidate formal specifications; The first loop invariant, the second loop invariant, and the logical AND of the first loop invariant and the second loop invariant are determined as three candidate loop invariants; The step of calling a formal verification tool to determine whether the first set of compliance conditions holds under the candidate cyclic invariants includes: Based on the second cyclic invariant, the logical AND of the first cyclic invariant and the second cyclic invariant, and the order of the first cyclic invariant, each candidate cyclic invariant is sequentially verified to ensure that the first set of contracts is valid. If any candidate cyclic invariant makes the first set of contracts valid, the candidate cyclic invariant is taken as the target cyclic invariant, and the verification of unverified candidate cyclic invariants is stopped.

6. The method according to claim 5, wherein, Based on the second cyclic invariant, the logical AND of the first cyclic invariant and the second cyclic invariant, and the order of the first cyclic invariant, verify in turn whether each candidate cyclic invariant makes the first set of contracts valid; If any candidate cyclic invariant makes the first set of contracts valid, then the candidate cyclic invariant is taken as the target cyclic invariant, and the verification of unverified candidate cyclic invariants is stopped, including: If the first antecedent condition can derive the second cyclic invariant, and the second cyclic invariant can derive the first postcondition under the loop termination condition, then the second cyclic invariant is determined as the target cyclic invariant that makes the first set of contracts valid; otherwise, If the first precondition can derive the logical AND of the first loop invariant and the second loop invariant, and the second loop invariant can derive the first postcondition under the loop termination condition, then the logical AND of the first loop invariant and the second loop invariant is determined as the loop invariant that makes the first set of contracts valid; otherwise, If the first loop invariant can derive the first subsequent condition under the loop termination condition, and the first preceding condition can derive the first loop invariant, then the first loop invariant is determined as the loop invariant that makes the first set of contracts valid; otherwise, It is determined that none of the three candidate cyclic invariants can make the first set of contracts valid.

7. The method according to claim 1, wherein, The multiple candidate formal specifications are generated by an automated formal specification generation tool based on a large language model for the program unit to be verified and pass the preliminary verification by the formal verification tool.

8. A formal specification determination apparatus, comprising: The specification acquisition module is used to acquire multiple candidate formal specifications of the program unit to be verified. Each candidate formal specification includes preconditions as input constraints and postconditions as output constraints. The condition determination module is used to determine the first precondition with the weakest input constraint from the preconditions of the multiple candidate formal specifications based on the logical implication relationship between the preconditions of the multiple candidate formal specifications. Based on the logical implication relationship between the postconditions of the multiple candidate formal specifications, the first postcondition with the strongest output constraint is determined from the postconditions of the multiple candidate formal specifications. The specification combination module is used to combine the first precondition and the first postcondition into a first set of compliance contracts; The verification module is used to call formal verification tools to determine whether the first set of compliance agreements holds true for the program unit to be verified. The specification determination module is used to determine the first set of compliance specifications as the target specification and output it if the verification module determines that the first set of compliance specifications is valid for the program unit to be verified; if the verification module determines that the first set of compliance specifications is not valid for the program unit to be verified, the first set of compliance specifications is not determined as the target specification.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images