A method and system for bi-directional synchronization and validation of requirements with code

Abstract

This application discloses a method and system for bidirectional synchronization and verification of requirements and code. The method includes: performing hierarchical parsing of natural language format requirement data using a pre-trained large language model; generating a requirement model based on the results of the hierarchical parsing, wherein the requirement model conforms to DSL syntax; establishing a bidirectional mapping relationship between the semantic elements of the requirement model and the nodes of the AST of the code; based on the bidirectional mapping relationship, when the requirement model changes, marking or updating the corresponding nodes according to the changed semantic elements, or when the code changes, marking or updating the corresponding semantic elements according to the changed nodes; performing a semantic consistency comparison between the requirement logic of the current requirement model and the actual logic of the current abstract syntax tree, and generating a conflict report when the core semantics of the requirement logic and the actual logic are inconsistent. This method can achieve bidirectional synchronization and consistency verification of requirements and code, improving development efficiency and development quality.

Description

Technical Field

[0001] This application relates to the field of computer software engineering technology, specifically to a method and system for bidirectional synchronization and verification of requirements and code. Background Technology

[0002] In the traditional software development lifecycle, requirements and code are two independently maintained entities. Requirements are usually described in natural language, while code is implemented in a programming language.

[0003] However, as projects iterate, requirements and code are constantly improved, making it difficult to ensure consistency between them. This not only increases communication costs and project maintenance difficulty between the requirements and code sides but also easily introduces potential software defects. Moreover, the consistency between requirements and code cannot be automatically reviewed and verified, resulting in inefficient reviews and a high risk of omissions. Summary of the Invention

[0004] In view of this, this application provides a method and system for bidirectional synchronization and verification of requirements and code, which can realize bidirectional correlation synchronization and consistency verification of requirements and code, thereby improving development efficiency and development quality.

[0005] To solve the above problems, the technical solution provided in this application is as follows:

[0006] In a first aspect of this application, a method for bidirectional synchronization and verification of requirements and code is provided, comprising:

[0007] The pre-trained large language model is used to perform hierarchical parsing of the natural language format requirement data. The hierarchical parsing includes entity layer parsing, process layer parsing, and constraint layer parsing.

[0008] A requirement model is generated based on the results of the hierarchical parsing. The results of the hierarchical parsing include the business entities, processing flow, and constraint rules of the requirement data. The requirement model conforms to the syntax of a pre-defined domain-specific language (DSL).

[0009] Establish a bidirectional mapping relationship between the semantic elements of the requirement model and the nodes of the abstract syntax tree (AST) of the code;

[0010] Based on the bidirectional mapping relationship, when the requirement model changes, the corresponding node is marked or updated according to the changed semantic element; or, when the code changes, the corresponding semantic element is marked or updated according to the changed node.

[0011] A semantic consistency comparison is performed between the requirement logic of the current requirement model and the actual logic of the current abstract syntax tree. If the core semantics of the requirement logic and the actual logic are inconsistent, a conflict report is generated. The conflict report includes conflict warnings and conflict remediation suggestions.

[0012] One possible implementation scenario where the requirement logic and the actual logic are inconsistent includes at least one of the following: there is a logical conflict between the requirement logic and the actual logic, the code does not implement the requirement, or the code exceeds the requirement.

[0013] One possible implementation also includes:

[0014] Obtain the operational information corresponding to the conflict report;

[0015] Adjust the bidirectional mapping relationship based on operational behavior information.

[0016] One possible implementation includes operational behavior information such as: manually modifying the requirement model, ignoring conflict warnings, and adopting conflict remediation suggestions;

[0017] Adjusting the bidirectional mapping relationship based on operational behavior information includes:

[0018] If the operational behavior information indicates that conflict resolution suggestions have been adopted, the positive weight in the current bidirectional mapping relationship should be strengthened; if the operational behavior information indicates that the requirement model has been manually modified or conflict warnings have been ignored, the generation strategy of the requirement model should be updated.

[0019] One possible implementation strategy for updating the demand model includes:

[0020] The RAG (Retrieval Enhancement Generative Technology) technique is used to input amendment examples as few-shot examples into a large language model, or to update the model's domain parameters when the semantic offset reaches a threshold.

[0021] The amendments include modifications to semantic elements, original semantic elements, and semantic offsets.

[0022] In a second aspect of this application, a two-way synchronization and verification system for requirements and code is provided, comprising: a model conversion module, a verification control module, a data storage module, and an application interaction module;

[0023] The model conversion module includes a requirement data parsing module and a requirement model generation module. The requirement data parsing module is used to perform hierarchical parsing of natural language format requirement data using a pre-trained large language model. The hierarchical parsing includes entity layer parsing, process layer parsing, and constraint layer parsing. The requirement model generation module is used to generate a requirement model based on the results of the hierarchical parsing. The results of the hierarchical parsing include the business entities, processing flow, and constraint rules of the requirement data. The requirement model conforms to the syntax of a pre-defined domain-specific language (DSL).

[0024] The verification control module includes a bidirectional synchronization engine, a conflict detection module, and a change propagation module. The bidirectional synchronization engine is used to establish a bidirectional mapping relationship between the semantic elements of the requirement model and the nodes of the abstract syntax tree of the code. The change propagation module is used to update or mark the corresponding nodes according to the changed semantic elements when the requirement model changes, or to update or mark the corresponding semantic elements according to the changed nodes when the code changes, based on the bidirectional mapping relationship. The conflict detection module is used to perform semantic consistency comparison between the requirement logic of the requirement model and the actual logic of the abstract syntax tree, and generate a conflict report when the requirement logic and the actual logic are inconsistent.

[0025] The data storage module is used to store at least one of the following: requirement data, requirement model, code, or mapping relationship library. The mapping relationship library is used to store bidirectional mapping relationships.

[0026] The application interaction module includes a requirement editing module, a code editing module, and a conflict report display module; the requirement editing module is used to receive modifications to requirement data or requirement models; the code editing module is used to receive modifications to code; and the conflict report display module is used to display conflict reports.

[0027] One possible implementation scenario where the requirement logic and the actual logic are inconsistent includes at least one of the following: there is a logical conflict between the requirement logic and the actual logic, the code does not implement the requirement, or the code exceeds the requirement. The conflict report includes conflict warnings and conflict remediation suggestions.

[0028] In one possible implementation, the application interaction module is also used to: receive operation behavior information corresponding to the conflict report;

[0029] The bidirectional synchronization engine is also used for:

[0030] Adjust the bidirectional mapping relationship based on operational behavior information.

[0031] One possible implementation includes operational behavior information such as: manually modifying the requirement model, ignoring conflict warnings, and adopting conflict remediation suggestions;

[0032] The bidirectional synchronization engine is specifically used for:

[0033] When the operational behavior information indicates that conflict resolution suggestions have been adopted, the positive weight in the two-way mapping relationship is strengthened; when the operational behavior information indicates that the requirement model is manually modified or conflict warnings are ignored, the generation strategy of the requirement model is updated.

[0034] One possible implementation involves a bidirectional synchronization engine used to update the generation strategy of the demand model, specifically including:

[0035] The bidirectional synchronous engine uses the retrieval-enhanced RAG technology to input amendment examples as few-shot examples into the large language model, or to update the model's domain parameters when the semantic offset reaches a threshold; the amendment examples include corrected semantic elements, original semantic elements, and semantic offsets.

[0036] The bidirectional synchronization and verification method for requirements and code provided in this application can generate a requirement model based on requirement data, realizing the transformation from informal requirements described in natural language to formal code that can be recognized and parsed by machines. This establishes a formal bridge between requirements and code, providing a foundation for bidirectional mapping between them. The method provided in this application, based on the bidirectional mapping relationship between the requirement model and code, updates the code when requirements change and updates the requirements when the code changes, thereby achieving continuous synchronization between requirements and code and maintaining consistency between requirement documents and code implementation. Furthermore, this method can verify the consistency between the requirement logic and the actual logic of the code. In cases of inconsistency between requirement logic and actual logic, it can generate a conflict report, providing early warning of potential software defects, helping maintenance personnel to fix them, and improving software quality. Attached Figure Description

[0037] Figure 1 A flowchart illustrating a method for bidirectional synchronization and verification of requirements and code, provided for an embodiment of this application;

[0038] Figure 2 A flowchart illustrating a method for establishing a bidirectional mapping relationship provided in this application embodiment;

[0039] Figure 3 A flowchart illustrating a method for bidirectional synchronization between requirements and code, provided in an embodiment of this application;

[0040] Figure 4 A flowchart illustrating a method for adjusting a bidirectional mapping relationship provided in this application embodiment;

[0041] Figure 5 A schematic diagram of a bidirectional synchronization and verification system for requirements and code provided in an embodiment of this application;

[0042] Figure 6 This is a schematic diagram of a conflict detection module provided in an embodiment of this application. Detailed Implementation

[0043] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the embodiments of this application will be further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0044] See Figure 1The figure is a flowchart of a bidirectional synchronization and verification method for requirements and code provided in an embodiment of this application.

[0045] This application provides a method for bidirectional synchronization and verification of requirements and code, including:

[0046] S1: The required data in natural language format is parsed hierarchically using a pre-trained large language model. The hierarchical parsing includes entity layer parsing, process layer parsing, and constraint layer parsing.

[0047] For example, given the requirement data as "The system needs a user login function. Users log in using a username and password. If the password is entered incorrectly more than 3 times consecutively, the account will be locked. After successful login, the session is valid for 30 minutes," a pre-trained Large Language Model (LLM) can be used to perform hierarchical parsing of the requirement data.

[0048] S2: Generate a requirement model based on the results of the hierarchical parsing. The requirement model conforms to the syntax of a preset domain-specific language (DSL).

[0049] For example, the results of layered parsing include: at the entity layer, identifying core entities such as [User], [Credentials], and [Session], and their attributes [Username, Password]; at the process layer, identifying business steps such as [Verify Credentials, Create Session, Record Failure]; and at the constraint layer, identifying key business rules [Password Error Count <= 3, Session Timeout = 30 minutes]. Based on the above parsing results, the following requirement model conforming to DSL syntax is automatically generated:

[0050] RequirementModel UserLogin {

[0051] Entity: User { username: String, password: String, failureCount:Integer}

[0052] Process: LoginFlow {

[0053] Step1: ValidateCredentials(User) -> ValidationResult

[0054] Step2: CreateSession(User) -> Session [ifValidationResult.success]

[0055] Step3: LockAccount(User) [if User.failureCount > 3]

[0056] }

[0057] Constraints: {

[0058] C1: login.failureCount <= 3

[0059] C2: session.timeout = "30m"

[0060] }

[0061] }

[0062] S3: Establish a bidirectional mapping relationship between the semantic elements of the requirement model and the nodes of the abstract syntax tree (AST) of the code.

[0063] Specifically, static analysis can be performed on the code to construct the corresponding AST; a bidirectional mapping relationship can be established between the semantic elements of the requirement model and the nodes of the code's AST.

[0064] S4: Based on the bidirectional mapping relationship, update or mark the corresponding node when the requirement data changes, or update or mark the corresponding semantic element when the code changes.

[0065] Specifically, change events can be monitored through listeners; when the requirement model changes, the corresponding AST nodes can be updated or marked according to the bidirectional mapping relationship; or, when the code changes, the corresponding semantic elements of the requirement model can be updated or marked according to the bidirectional mapping relationship.

[0066] S5: Perform semantic consistency comparison between the requirement logic of the requirement model and the actual logic of the abstract syntax tree. Generate a conflict report when the core semantics of the requirement logic and the actual logic are inconsistent. The conflict report includes conflict warnings and conflict remediation suggestions.

[0067] The bidirectional synchronization and verification method for requirements and code provided in this application can generate a requirement model based on requirement data, realizing the transformation from informal requirements described in natural language to formal code that can be recognized and parsed by machines. This establishes a formal bridge between requirements and code, providing a foundation for bidirectional mapping between them. The method provided in this application, based on the bidirectional mapping relationship between the requirement model and code, updates the code when requirements change and updates the requirements when the code changes, thereby achieving continuous synchronization between requirements and code and maintaining consistency between requirement documents and code implementation. Furthermore, this method can verify the consistency between the requirement logic and the actual logic of the code. In cases of inconsistency between requirement logic and actual logic, it can generate a conflict report, providing early warning of potential software defects, helping maintenance personnel to fix them, and improving software quality.

[0068] See Figure 2 The figure is a flowchart of a method for establishing a bidirectional mapping relationship provided in an embodiment of this application.

[0069] One possible implementation involves establishing a bidirectional mapping between the semantic elements of the requirement model and the nodes of the abstract syntax tree of the code, specifically including:

[0070] S301: Analyze the requirements model and identify its semantic elements.

[0071] S302: Analyze the code and construct the AST of the code.

[0072] S303: Establish a bidirectional mapping relationship between semantic elements and corresponding nodes in the AST.

[0073] A node is the smallest syntactic unit in the code that can be identified, processed, and analyzed independently, such as a class, method, or logic block.

[0074] For example, let's analyze the DSL requirement model and corresponding Java code AST in the above embodiments. The constraint `Constraints.C1` will be mapped to an `if` condition check within the login logic method in `AuthService.java`. For example, the bidirectional mapping relationship between semantic elements and nodes in the above embodiments is as follows:

[0075] {

[0076] "mapping_id": "map-001",

[0077] "requirement_element": "UserLogin.Constraints.C1",

[0078] "requirement_dsl": "login.failureCount <= 3",

[0079] "code_element": {

[0080] "file": "AuthService.java",

[0081] "method": "login",

[0082] "ast_path": " / method / body / if[@test='failureCount <= MAX_ATTEMPTS']"

[0083] }

[0084] }

[0085] This application does not specifically limit the execution order of steps S301 and S302. Step S301 can be executed first and then step S302, or step S302 can be executed first and then step S301.

[0086] One possible implementation further includes, after establishing the bidirectional mapping relationship:

[0087] S304: Store the bidirectional mapping relationship in the mapping knowledge base.

[0088] The method for bidirectional synchronization and verification of requirements and code provided in this application stores the bidirectional mapping relationship in a mapping knowledge base, which enables centralized management of the bidirectional mapping relationship between requirements and code, decoupling of business resources from the bidirectional mapping relationship, and facilitating automated parsing and invocation.

[0089] See Figure 3 The figure is a flowchart of a method for bidirectional synchronization between requirements and code provided in an embodiment of this application.

[0090] One possible implementation involves, based on the bidirectional mapping relationship, marking or updating the corresponding nodes according to the changed semantic elements when the requirement model changes, or marking or updating the corresponding semantic elements according to the changed nodes when the code changes. Specifically, this includes:

[0091] S401: Monitor change events in the requirements model and code.

[0092] For example, listeners can be used to monitor change events in the requirement model and code.

[0093] S402: Based on the bidirectional mapping relationship, when the requirement model changes, determine the affected nodes according to the changed semantic elements, mark the corresponding nodes and generate code AST modification suggestions, or automatically update the corresponding code AST.

[0094] Specifically, the method provided in this application embodiment performs a difference analysis on the requirement model when the requirement model changes. Based on the bidirectional mapping relationship between semantic elements and nodes, the affected nodes are located from the changed semantic elements, the corresponding nodes are marked, and code modification suggestions are generated, or the corresponding nodes are automatically updated.

[0095] This application does not specifically limit the way the requirement model is changed. For example, the requirement model can be changed directly in the requirement editor, or the requirement data can be changed and a changed requirement model can be generated based on the changed requirement data.

[0096] For example, in the above embodiment, if the product manager changes 'failureCount <= 3' to 'failureCount <= 5' in the requirements editor, the change propagator can locate the corresponding code in 'AuthService.java' via 'map-001' and automatically change the value of 'MAX_ATTEMPTS' to 5, or issue a modification suggestion to the developer.

[0097] S403: Based on the bidirectional mapping relationship, when the code changes, perform difference analysis on the code AST, determine the affected semantic elements based on the changed nodes, mark the corresponding semantic elements and generate requirement model modification suggestions, or automatically update the corresponding semantic elements.

[0098] For example, in the above embodiment, if the developer moves the logic to a new 'SecurityValidator' class during refactoring, this change can be captured by the code listener, and logical equivalence can be identified through AST analysis, automatically updating the 'code_element' path in 'map-001' without requiring manual updates to the requirements.

[0099] The bidirectional synchronization and verification method for requirements and code provided in this application can establish a bidirectional mapping relationship between the semantic elements of the requirement model and the nodes of the abstract syntax tree of the code. When the requirement model or code changes, the affected nodes or semantic elements can be marked or updated according to the bidirectional mapping relationship, thereby achieving continuous automatic synchronization between requirements and code and saving communication costs.

[0100] One possible implementation scenario where the requirement logic and the actual logic are inconsistent includes: a logical conflict between the requirement logic and the actual logic, the code failing to implement the requirement, or the code exceeding the requirement—at least one of these situations. The following description continues with reference to the above embodiments.

[0101] Specifically, a logical conflict between the requirement logic and the actual logic might be as follows: the requirement calls for "locking the account after 3 incorrect password attempts," but the code implementation calls for "locking the account after 5 incorrect password attempts." A requirement not implemented in the code might be as follows: the requirement defines "session timeout handling," but no corresponding implementation is found in the code. Code exceeding the requirement might be as follows: the requirement does not define "user role and permission check," but the code implements the "user role and permission check" function.

[0102] For example, a semantic comparison analysis engine can be used to extract the constraint 'login.failureCount<= 3' from the requirement model. Analysis of the code reveals that the hard-coded logic in 'AuthService.java' is 'if (failureCount < 5)', indicating a logical conflict between the requirement logic and the actual logic. In the event of this conflict, a warning can be generated using a conflict reporter: "Requirement [UserLogin.C1] requires the number of failures to be no more than 3, but the code implementation states no more than 4 (less than 5), indicating a logical inconsistency."

[0103] The bidirectional synchronization and verification method for requirements and code provided in this application can automatically discover hidden logical conflicts and mismatches between requirements and code, provide early warnings of potential software defects, and thus improve software quality.

[0104] One possible implementation of the bidirectional synchronization and verification method for requirements and code provided in this application embodiment further includes:

[0105] S6: Obtain the operational behavior information corresponding to the conflict report; adjust the two-way mapping relationship based on the operational behavior information.

[0106] One possible implementation, step S6 specifically includes:

[0107] S601: Obtain the operational behavior information corresponding to the conflict report.

[0108] Operational behavior information can include actions such as manually modifying the requirement model, ignoring conflict warnings, or adopting conflict remediation suggestions. For example, operational behavior information can be the actions taken by developers in response to conflict reports.

[0109] S602: If the operational behavior information is to adopt conflict resolution suggestions, strengthen the positive weights in the mapping relationship library; if the operational behavior information is to manually correct the requirement model or ignore conflict warnings, update the generation strategy of the requirement model.

[0110] Specifically, operational behavior information can be categorized using a behavior classifier. When a developer adopts a conflict resolution suggestion, it signifies their acceptance of the bidirectional mapping relationships in the current mapping database; therefore, the positive weights in the current mapping database need to be strengthened. These positive weights represent a positive correlation between semantic elements and nodes.

[0111] If developers manually modify the requirement model or ignore conflict warnings, it means that the developers do not approve of the bidirectional mapping relationship in the current mapping relationship library. Therefore, it is necessary to update the generation strategy of the requirement model to optimize the current bidirectional mapping relationship.

[0112] One possible implementation strategy for updating the demand model includes:

[0113] The Retrieval Enhancement Generation (RAG) technique uses modified examples as few-shot examples to input into a large language model, or updates the model's domain parameters when the semantic offset reaches a threshold. The modified examples include corrected semantic elements, original semantic elements, and semantic offsets.

[0114] S603: Update the mapping relationship library according to the enhanced positive weights or the updated generation strategy.

[0115] One possible implementation strategy for updating the demand model specifically includes:

[0116] The original semantic elements are compared with the modified semantic elements corresponding to the modified requirement model, and the semantic offset between the original semantic elements and the modified semantic elements is calculated. The generation strategy of the requirement model is updated based on the original semantic elements, the modified semantic elements, and the semantic offset.

[0117] For example, the original semantic elements, modified semantic elements, and semantic offsets can be stored as amendment examples in the mapping relation library. When parsing the same type of requirement corresponding to the original semantic elements, the system uses retrieval enhancement generation technology to inject the amendment example as a few-shot example into the prompt words of the large language model. When a certain type of semantic conflict (such as the difference between the word "lock" in the context of inventory and account) reaches a threshold, the domain-specific parameters of the large language model are updated to update the generation strategy of the requirement model.

[0118] See Figure 4 The figure is a flowchart of a method for adjusting a bidirectional mapping relationship provided in an embodiment of this application.

[0119] The method includes:

[0120] S701: Classify the operational behavior information corresponding to the conflict report; if the operational behavior information is to adopt the conflict remediation suggestion, execute step S702; if the operational behavior information is to manually modify the requirement model or ignore the conflict warning, execute step S703.

[0121] S702: If the operational behavior information indicates that the conflict resolution suggestion has been adopted, strengthen the positive weight in the current bidirectional mapping relationship, and then execute step S705.

[0122] Among them, positive weights represent a positive correlation between semantic elements and nodes.

[0123] S703: When the operation behavior information is manual correction of the requirement model or ignores the conflict warning, obtain the semantic offset between the corrected semantic element and the original semantic element, and store the corrected semantic element, the original semantic element and the semantic offset as amendment examples in the mapping relationship library. The amendment examples are used to optimize the multi-level semantic parsing model.

[0124] S704: When the semantic offset of a single type reaches the threshold, the amendment example is input into the multi-level semantic parsing model through the Retrieval-Augmented Generation (RAG) technique to update the configuration of the multi-level semantic parsing model.

[0125] For example, when the semantic offset of a single type reaches a threshold, the amendment example can be used as a Few-shot example to be input into the prompt words of the large language model through the Retrieval Enhancement Generation (RAG) technique. In this way, when parsing the demand data of the same type as the original semantic elements in the future, the large language model can be guided to make a judgment that meets the requirements of the amendment example, thereby realizing the update of the configuration of the large language model.

[0126] S705: Update the bidirectional mapping relationship based on the configuration of the updated multi-level semantic parsing model or the enhanced positive weights.

[0127] The bidirectional synchronization and verification method for requirements and code provided in this application can analyze the accuracy of bidirectional mapping relationships based on developer behavior information. It strengthens positive weights for high-accuracy bidirectional mapping relationships and updates the generation strategy of the requirement model for low-accuracy relationships, thereby achieving automatic optimization and updating of the mapping relationship library. This method can improve the accuracy of requirement understanding and code generation based on project-specific business domain knowledge, achieving self-optimization of bidirectional mapping relationships.

[0128] Based on the bidirectional synchronization and verification method for requirements and code provided in the above embodiments, this application also provides a bidirectional synchronization and verification system for requirements and code. The bidirectional synchronization and verification system for requirements and code provided in this application is used to implement any of the bidirectional synchronization and verification methods for requirements and code provided in the above embodiments.

[0129] See Figure 5 The figure is a schematic diagram of a bidirectional synchronization and verification system for requirements and code provided in an embodiment of this application.

[0130] The system includes a model conversion module 100, a verification control module 200, a data storage module 300, and an application interaction module 400.

[0131] The model conversion module 100 includes a requirement data parsing module 101 and a requirement model generation module 102. The requirement data parsing module 101 performs hierarchical parsing of natural language format requirement data using a pre-trained large language model. Hierarchical parsing includes entity layer parsing, process layer parsing, and constraint layer parsing. The requirement model generation module 102 generates a requirement model based on the results of the hierarchical parsing; the results include the business entities, processing flows, and constraint rules of the requirement data, and the requirement model conforms to DSL syntax.

[0132] The verification control module 200 includes a bidirectional synchronization engine 201, a conflict detection module 202, and a change propagation module 203. The bidirectional synchronization engine 201 establishes a bidirectional mapping between the semantic elements of the requirement model and the nodes of the abstract syntax tree of the code. The change propagation module 203 updates or marks the corresponding nodes according to the bidirectional mapping when the requirement model changes, or updates or marks the corresponding semantic elements according to the bidirectional mapping when the code changes. The conflict detection module 202 performs a semantic consistency comparison between the requirement logic of the requirement model and the actual logic of the abstract syntax tree, generating a conflict report when the requirement logic and the actual logic are inconsistent. The conflict report includes the conflict type and conflict remediation suggestions.

[0133] The data storage module 300 is used to store at least one of the following: requirement data, requirement model, code, or mapping relationship library. The mapping relationship library is used to store bidirectional mapping relationships.

[0134] The application interaction module 400 includes a requirement editing module 401, a code editing module 402, and a conflict report display module 403. The requirement editing module 401 is used to receive modifications to requirement data or requirement models; the code editing module 402 is used to receive modifications to code; and the conflict report display module 403 is used to display conflict reports.

[0135] The bidirectional synchronization and verification system for requirements and code provided in this application can generate a requirement model based on requirement data, realizing the transformation from informal requirements described in natural language to formal code that can be recognized and parsed by machines. This establishes a formal bridge between requirements and code, providing a foundation for bidirectional mapping between them. Based on the bidirectional mapping relationship between the requirement model and code, the system can update the code when requirements change and update the requirements when code changes, thereby achieving continuous synchronization between requirements and code and maintaining consistency between requirement documents and code implementation. Furthermore, the system can verify the consistency between the requirement logic and the actual logic of the code. In cases of inconsistency between requirement logic and actual logic, it can generate a conflict report, providing early warning of potential software defects, which helps maintenance personnel to fix them and improve software quality.

[0136] In one possible implementation, the conflict detection module 202 includes a semantic extraction module 2021, a semantic analysis and comparison module 2022, a conflict type classification module 2023, and a conflict report generation module 2024.

[0137] See Figure 6 The figure is a schematic diagram of a conflict detection module provided in an embodiment of this application.

[0138] Figure 6 In the illustrated embodiment, the semantic extraction module 2021 obtains the requirement logic from the requirement model and the actual logic of the code from the abstract syntax tree, and sends the requirement logic and actual logic to the semantic comparison and analysis module 2022. The semantic comparison and analysis module 2022 performs a comparative analysis based on the requirement logic and actual logic to determine if there is any inconsistency between them. If there is an inconsistency, the result is sent to the conflict type classification module 2023. The conflict type classification module 2023 classifies the inconsistencies between the requirement logic and actual logic and sends the conflict classification results to the conflict report generation module 2024. The conflict report generation module 2024 generates a conflict report including the conflict type and conflict remediation suggestions based on the conflict classification results.

[0139] The bidirectional synchronization and verification system for requirements and code provided in this application can automatically detect hidden logical conflicts and mismatches between requirements and code, and provide early warnings of potential software defects, thereby improving software quality.

[0140] One possible implementation scenario where the requirement logic and the actual logic are inconsistent includes at least one of the following: there is a logical conflict between the requirement logic and the actual logic, the code does not implement the requirement, or the code exceeds the requirement.

[0141] In one possible implementation, the application interaction module 400 is further configured to: obtain operation behavior information corresponding to the conflict report; the bidirectional synchronization engine 201 is further configured to: adjust the bidirectional mapping relationship according to the operation behavior information.

[0142] One possible implementation includes operational behavior information such as: manually modifying the requirement model, ignoring conflict warnings, and adopting conflict remediation suggestions;

[0143] The bidirectional synchronization engine 201 is specifically used for:

[0144] When the operational behavior information indicates that conflict resolution suggestions have been adopted, the positive weight in the two-way mapping relationship is strengthened; when the operational behavior information indicates that the requirement model is manually modified or conflict warnings are ignored, the generation strategy of the requirement model is updated.

[0145] One possible implementation involves a bidirectional synchronization engine used to update the generation strategy of the demand model, specifically including:

[0146] The bidirectional synchronous engine uses the retrieval-enhanced RAG technology to input amendment examples as few-shot examples into the large language model, or to update the model's domain parameters when the semantic offset reaches a threshold; the amendment examples include corrected semantic elements, original semantic elements, and semantic offsets.

[0147] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0148] This application also provides a readable storage medium for storing the methods provided in the above embodiments. Examples include random access memory (RAM), flash memory, read-only memory (ROM), EPROM, non-volatile read-only memory (EPROM), registers, hard disks, removable disks, or any other form of storage medium in the art.

[0149] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0150] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for bidirectional synchronization and verification of requirements and code, characterized in that, include: The pre-trained large language model is used to perform hierarchical parsing of the natural language format requirement data. The hierarchical parsing includes entity layer parsing, process layer parsing and constraint layer parsing. A requirement model is generated based on the results of the hierarchical parsing, wherein the results of the hierarchical parsing include the business entities, processing flow, and constraint rules of the requirement data. The requirement model conforms to the DSL syntax of a pre-defined domain-specific language. Establish a bidirectional mapping relationship between the semantic elements of the requirement model and the nodes of the abstract syntax tree (AST) of the code; Based on the bidirectional mapping relationship, when the requirement model changes, the corresponding node is marked or updated according to the changed semantic element; or, when the code changes, the corresponding semantic element is marked or updated according to the changed node. A semantic consistency comparison is performed between the requirement logic of the current requirement model and the actual logic of the current abstract syntax tree. If the core semantics of the requirement logic and the actual logic are inconsistent, a conflict report is generated. The conflict report includes conflict warnings and conflict remediation suggestions.

2. The method of claim 1, wherein, The inconsistencies between the requirement logic and the actual execution logic include at least one of the following: the requirement logic and the actual logic have a logical conflict; the code does not implement the requirement; or the code exceeds the requirement.

3. The method of claim 1, wherein, Also includes: Obtain the operation behavior information corresponding to the conflict report; The bidirectional mapping relationship is adjusted based on the operational behavior information.

4. The method of claim 3, wherein, The operational behavior information includes: manually modifying the requirement model, ignoring conflict warnings, and adopting conflict remediation suggestions; Adjusting the bidirectional mapping relationship based on the operational behavior information includes: If the operational behavior information is the adoption of conflict resolution suggestions, strengthen the positive weights in the current bidirectional mapping relationship; if the operational behavior information is the manual correction of the requirement model or the ignoring of conflict warnings, update the generation strategy of the requirement model.

5. The method of claim 4, wherein, The strategy for updating the generation of the requirement model includes: The RAG (Retrieval Enhancement Generative Technology) technique is used to input amendment examples as few-shot examples into a large language model, or to update the model's domain parameters when the semantic offset reaches a threshold. The amendment examples include modified semantic elements, original semantic elements, and semantic offsets.

6. A system for bi-directional synchronization and verification of requirements with code, the system comprising: include: Model conversion module, verification control module, data storage module, and application interaction module; The model conversion module includes a requirement data parsing module and a requirement model generation module. The requirement data parsing module is used to perform hierarchical parsing of the requirement data in natural language format using a pre-trained large language model. The hierarchical parsing includes entity layer parsing, process layer parsing, and constraint layer parsing. The requirement model generation module is used to generate the requirement model based on the results of the hierarchical parsing. The results of the hierarchical parsing include the business entities, processing flow, and constraint rules of the requirement data. The requirement model conforms to the syntax of a pre-defined domain-specific language (DSL). The verification control module includes a bidirectional synchronization engine, a conflict detection module, and a change propagation module. The bidirectional synchronization engine is used to establish a bidirectional mapping relationship between the semantic elements of the requirement model and the nodes of the abstract syntax tree of the code. The change propagation module is used to update or mark the corresponding node according to the changed semantic element when the requirement model changes, or to update or mark the corresponding semantic element according to the changed node when the code changes, based on the bidirectional mapping relationship. The conflict detection module is used to perform a semantic consistency comparison between the requirement logic of the requirement model and the actual logic of the abstract syntax tree, and generate a conflict report when the requirement logic and the actual logic are inconsistent. The data storage module is used to store at least one of the requirement data, the requirement model, the code, or the mapping relationship library, wherein the mapping relationship library is used to store the bidirectional mapping relationship. The application interaction module includes a requirement editing module, a code editing module, and a conflict report display module; The requirement editing module is used to receive modifications to the requirement data or the requirement model; The code editing module is used to receive modifications to the code; the conflict report display module is used to display the conflict report.

7. The system of claim 6, wherein, The inconsistencies between the requirement logic and the actual logic include at least one of the following: the requirement logic and the actual logic have a logical conflict, the code does not implement the requirement, or the code exceeds the requirement. The conflict report includes conflict warnings and conflict remediation suggestions.

8. The system of claim 6, wherein, The application interaction module is also used to: receive operation behavior information corresponding to the conflict report; The bidirectional synchronization engine is also used for: The bidirectional mapping relationship is adjusted based on the operational behavior information.

9. The system of claim 8, wherein, The operational behavior information includes: manually modifying the requirement model, ignoring conflict warnings, and adopting conflict remediation suggestions; The bidirectional synchronization engine is specifically used for: If the operational behavior information is the adoption of conflict resolution suggestions, the positive weight in the bidirectional mapping relationship is strengthened; if the operational behavior information is the manual correction of the requirement model or the ignoring of conflict warnings, the generation strategy of the requirement model is updated.

10. The system of claim 9, wherein, The bidirectional synchronization engine is used to update the generation strategy of the demand model, specifically including: The bidirectional synchronization engine uses the retrieval enhancement generation RAG technology to input the amendment examples as few-shot examples into the large language model, or updates the model's domain parameters when the semantic offset reaches a threshold; the amendment examples include corrected semantic elements, original semantic elements, and semantic offsets.

Images