Semantic verification method and device based on large model

Abstract

The invention relates to the technical field of software engineering and information processing, in particular to a semantic verification method and device based on a large model.The method comprises the steps that a source code file and a corresponding software requirement and design document are obtained, code semantic representation is generated based on grammar analysis and static program analysis, and a semantic verification result is obtained; based on text analysis and business flow chart structure identification, generating a design demand semantic representation; respectively inputting the code semantic representation and the design demand semantic representation into a pre-training language large model to generate a code implementation logic description and a design demand logic description; and performing semantic consistency verification on the two types of logic descriptions to obtain a semantic inconsistency result, determining a code position in the source code file based on the semantic inconsistency result, and outputting a scanning report. According to the invention, the automation degree and the rechecking performance of consistency checking of requirements can be improved, and the leak detection and reworking cost can be reduced.

Description

Technical Field

[0001] This invention relates to the fields of software engineering and information processing technology, and in particular to a semantic verification method and apparatus based on large models. Background Technology

[0002] With the continuous increase in software scale and collaboration complexity, deviations between requirements, design, and implementation have become major factors leading to defect spillover, rework, and delivery risks. Traditional reviews and tests struggle to cover semantic-level consistency across documents and modules, and their reliance on human experience in responding to requirement changes makes them prone to omissions and interpretation difficulties. For engineering practice, the ability to verify and compare the business intent of requirements with that of implementation, and to output actionable positioning results, has significant industry value in improving delivery quality, shortening iteration cycles, and reducing compliance audit costs. Summary of the Invention

[0003] This invention provides a semantic verification method and apparatus based on a large model, which is used to at least solve the problem of how to automatically align and verify the requirements design with the source code at the semantic level and locate inconsistent code locations.

[0004] In a first aspect, the present invention provides a semantic verification method based on a large model, comprising the following steps: Obtain source code files and corresponding software requirements and design documents; generate code semantic representations based on syntax parsing and static program analysis; and generate design requirement semantic representations based on text parsing and business process diagram structure recognition. Input the semantic representation of the code into the pre-trained language large model to generate a description of the code implementation logic, and input the semantic representation of the design requirements into the pre-trained language large model to generate a description of the design requirements logic. The semantic consistency of the code implementation logic description and the design requirement logic description is checked to obtain the semantic inconsistency result; based on the semantic inconsistency result, the code location in the source code file is determined and a scan report is output.

[0005] In one possible implementation, generating a semantic representation of code based on syntax parsing and static program analysis includes constructing an abstract syntax tree, extracting variable definition and usage relationships and function call relationships based on the abstract syntax tree, and generating a semantic representation of code based on control flow relationships and data flow relationships.

[0006] In one possible implementation, generating a semantic representation of design requirements based on text parsing and business process diagram structure recognition includes extracting requirement items, business rules, and constraints from software requirements and design documents, identifying process nodes and connection relationships in the business process diagrams in the software requirements and design documents, and structuring the requirement items, business rules, constraints, process nodes, and connection relationships into a semantic representation of design requirements.

[0007] In one possible implementation, the code semantic representation is converted into code-structured input text before being input into a pre-trained large language model. Before inputting the semantic representation of design requirements into the pre-trained language model, the semantic representation of design requirements is converted into structured input text of requirements. The structured input text of code includes descriptions of code structure and function call relationships, while the structured input text of requirements includes descriptions of requirement items and descriptions of business rule constraints.

[0008] In one possible implementation, the pre-trained language large model generates a code implementation logic description based on the code structured input text, and the pre-trained language large model generates a design requirement logic description based on the requirement structured input text. Both the code implementation logic description and the design requirement logic description include functional step descriptions, conditional branch descriptions, and data flow descriptions.

[0009] In one possible implementation, semantic consistency verification includes semantically comparing the code implementation logic description with the design requirement logic description, and generating semantically inconsistent results based on the semantic comparison. Semantic inconsistent results include logical omission results, logical contradiction results, logical redundancy results, and results where boundary conditions are not set.

[0010] In one possible implementation, the result of logical omission is determined based on the functional steps where the logical description of the design requirements exists but the logical description of the code implementation is missing; The logical contradiction is determined based on the inconsistency between the logical description of the design requirements and the logical description of the code implementation in the conditional branch description of the same functional step. The result of logical redundancy is determined based on the functional steps where the logical description of the code implementation exists but the logical description of the design requirements is missing. The result is determined by the constraint conditions required by the design requirements logic description and the missing condition branches in the code implementation logic description, even if the boundary conditions are not set.

[0011] In one possible implementation, determining the code location in the source code file based on the semantic inconsistency result includes mapping the semantic inconsistency result to a syntax node in the abstract syntax tree, determining the range of code lines in the source code file based on the syntax node, and determining the function name associated with the range of code lines based on the function call relationship.

[0012] In one possible implementation, the scan report is output in the form of a structured record, which includes code location, semantic inconsistency results, code implementation logic description, design requirement logic description, and correction suggestions. The correction suggestions are generated by the pre-trained language large model based on the semantic inconsistency results and code semantic representation, and the code business logic diagram is output in the scan report. The code business logic diagram is used to represent the call relationship and data flow relationship between functional steps.

[0013] Secondly, the present invention provides a semantic verification apparatus based on a large model for implementing a semantic verification method based on a large model, the apparatus comprising: The semantic representation module is used to obtain source code files and corresponding software requirements and design documents, generate code semantic representations based on syntax parsing and static program analysis, and generate design requirement semantic representations based on text parsing and business process diagram structure recognition. The logic generation module is used to input the semantic representation of code into the pre-trained language large model to generate a code implementation logic description, and to input the semantic representation of design requirements into the pre-trained language large model to generate a design requirement logic description. The consistency verification module is used to perform semantic consistency verification between the code implementation logic description and the design requirement logic description to obtain semantic inconsistency results. Based on the semantic inconsistency results, the code location in the source code file is determined and a scan report is output.

[0014] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows: By constructing a semantic representation of code through syntax parsing and static program analysis, a structured characterization of implementation logic is achieved; by constructing a semantic representation of design requirements through text parsing and business process diagram structure recognition, an aligned expression of requirement constraints is achieved; by generating isomorphic logical descriptions through a pre-trained language large model, cross-carrier semantic comparison is achieved; and by semantic consistency verification and abstract syntax tree mapping, traceable location of semantic inconsistencies and output of scan reports are achieved. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the execution flow of the method of the present invention; Figure 2 This is a structural block diagram of the device of the present invention. Detailed Implementation

[0016] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0017] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0018] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0019] Pre-trained large-scale language models are general-purpose language understanding and generation models trained on large-scale corpora. They can summarize and restate entities, relationships, conditions, and actions in text under given contextual constraints, and output logical steps and key constraints in a structured and readable manner. In software engineering scenarios, source code, requirement documents, and design documents express the same business intent in different ways. Traditional rule or template methods often struggle to maintain stable semantic extraction and alignment under diverse expressions. Based on the semantic modeling capabilities of pre-trained large-scale language models, semantic information from different carriers can be converted into isomorphic logical descriptions under unified output constraints, thus providing comparable objects for subsequent consistency verification and discrepancy localization. Therefore, this invention proposes a semantic verification method based on a large-scale model. The semantic representations of code and design requirements are input into the pre-trained large-scale language model to generate logical descriptions, and further semantic consistency verification and scan report output are completed.

[0020] like Figure 1 As shown, a semantic verification method based on a large model includes the following steps: Obtain source code files and corresponding software requirements and design documents; generate code semantic representations based on syntax parsing and static program analysis; and generate design requirement semantic representations based on text parsing and business process diagram structure recognition. In this embodiment, the system retrieves the source code files corresponding to the scanning task identifier from the code repository and establishes a source code file list. Lexical analysis and syntax parsing are performed on the source code files to construct an abstract syntax tree (AST). Further control flow and data flow analysis are performed to extract function call relationships, variable definition and usage relationships, and interface read / write relationships. The AST and the aforementioned relationships are then encoded according to preset fields to generate a semantic representation of the code. The system retrieves the software requirements and design documents corresponding to the source code files. Paragraph segmentation, terminology normalization, and constraint statement standardization are performed on the main text to form a set of requirement items. Graph element recognition, connection relationship parsing, and text recognition are performed on the business process diagram to construct a process node and transition relationship diagram. The set of requirement items, business rules, and transition relationship diagram are then encoded according to preset fields to generate a semantic representation of the design requirements, thus providing a unified input foundation for subsequent semantic consistency verification based on a large model.

[0021] Generating code semantic representations based on syntax parsing and static program analysis includes constructing an abstract syntax tree, extracting variable definition and usage relationships and function call relationships based on the abstract syntax tree, and generating code semantic representations based on control flow relationships and data flow relationships.

[0022] In this embodiment, the process of generating code semantic representations based on syntax parsing and static program analysis is used to convert source code files into structured semantic inputs that can be stably parsed by a pre-trained language large model. First, lexical analysis and syntax parsing are performed on the source code files to construct an abstract syntax tree (AST) according to the syntax rules of the target programming language. Nodes in the AST represent statements, expressions, declarations, and type information, and parent-child relationships between nodes represent nested syntax relationships. Then, static parsing is performed based on the AST and symbol table to identify variable declaration, assignment, and read locations, forming variable definition and usage relationships. Simultaneously, function call expression nodes are traversed, and the identifier information of the called function is parsed using namespaces and import information to form function call relationships. Further, control flow relationships are constructed based on sequential statements, branching statements, and loop statements in the AST. Control flow relationships establish control flow edges at the basic block level, and the source of control transfer conditions is recorded at branch conditions. Based on this, data flow analysis is performed on the control flow relationships based on variable definition and usage relationships to obtain reach-definition relationships and active variable relationships, characterizing the propagation and coverage of variable values ​​along different control paths. Finally, the abstract syntax tree, variable definition and usage relationships, function call relationships, control flow relationships, and data flow relationships are encoded into code semantic representations according to preset fields. The code semantic representations are organized in the form of node sets, edge sets, and attribute sets, and each type of node and edge is assigned a unique identifier and source code location information. This enables subsequent steps to achieve consistent referencing and tracing across files and functions based on the same semantic representation when generating code implementation logic descriptions and locating semantic inconsistencies, reducing the risk of context loss caused by relying solely on text fragments.

[0023] The generation of semantic representations of design requirements based on text parsing and business process diagram structure recognition includes extracting requirement items, business rules and constraints from software requirements and design documents, identifying process nodes and connection relationships in the business process diagrams in the software requirements and design documents, and structuring the requirement items, business rules, constraints, process nodes and connection relationships into semantic representations of design requirements.

[0024] In this embodiment, the process of generating semantic representations of design requirements based on text parsing and business process diagram structure recognition is used to uniformly convert the natural language descriptions and flowchart descriptions in software requirements and design documents into computable structured semantic data, providing stable input for the subsequent generation of logical descriptions of design requirements from a pre-trained language model. First, the system receives electronic files of software requirements and design documents, and performs layout parsing and paragraph segmentation on the document content, extracting heading levels, chapter numbers, and paragraph text. For terminology in the document, terminology normalization is performed according to a preset glossary, ensuring that the same business concept maintains the same name in different chapters. Subsequently, syntactic sentence segmentation and keyword trigger rule matching are performed on the paragraph text, extracting requirement items, business rules, and constraints according to a preset template. Requirement items represent functional points and their triggering conditions and processing results; business rules represent changes in business state and permission boundaries; and constraints represent input validation, data consistency, and exception handling requirements. To ensure feasibility, the system generates a unique number for each requirement item, business rule, and constraint, and records its source chapter and original text segment position.

[0025] Furthermore, the system performs structural recognition on the business process diagrams in the software requirements and design documents. When the business process diagram is in vector format, the system parses the nodes and connection objects in the graphic file, reads the node text and connection direction to generate process node and connection relationships; when the business process diagram is in image format, the system performs primitive detection and text recognition on the image, extracts start and end nodes, processing nodes, decision nodes and connection arrows, and establishes connection relationships based on the arrow direction. For decision nodes, the system splits the node text into condition expressions and branch labels, and binds the branch labels to outgoing edges, thereby forming a traceable branch structure.

[0026] Finally, the system unifies the requirement items, business rules, constraints, process nodes, and connection relationships into a unified semantic representation of design requirements. This semantic representation is organized using pre-defined fields, which at least include the number, participating objects, triggering conditions, pre-constraints, processing actions, output results, exception branches, and associated process node numbers. A correspondence between requirement items and process nodes is established. Through this process, the semantic representation of design requirements retains the semantic information of the original requirements while possessing an aligned and traceable structured form, thereby reducing the risk of missed checks during subsequent semantic consistency verification due to scattered requirement descriptions and missing flowchart information.

[0027] Input the semantic representation of the code into the pre-trained language large model to generate a description of the code implementation logic, and input the semantic representation of the design requirements into the pre-trained language large model to generate a description of the design requirements logic. In this embodiment, the pre-trained language model is used to convert the semantic representation of code and the semantic representation of design requirements into comparable logical description texts. The system first organizes the semantic representation of code into structured input text according to preset fields, which at least include function names, call relationships, variable read / write relationships, key points of control branches, and key points of exception handling. The system also organizes the semantic representation of design requirements into structured input text according to preset fields, which at least include requirement item numbers, triggering conditions, business rules, constraints, process nodes, and transition relationships. Subsequently, the system inputs the structured code input text and the structured requirement input text into the pre-trained language model, respectively, and adds uniform output constraints to the input. The output is required to adopt a fixed hierarchical structure, providing preconditions, execution actions, and postconditions sequentially according to functional steps, and marking data input, data output, and conditional branches at corresponding positions. The code implementation logic description output by the pre-trained language large model is used to characterize the actual execution path and state changes of the source code file, while the design requirement logic description output by the pre-trained language large model is used to characterize the expected execution path and state changes under the constraints of the requirement document. This provides a homogeneous comparison object for subsequent semantic consistency verification, reducing missed detections and false detections caused by inconsistent description granularity.

[0028] Before inputting the code semantic representation into a pre-trained large language model, the code semantic representation is converted into code structured input text; Before inputting the semantic representation of design requirements into the pre-trained language model, the semantic representation of design requirements is converted into structured input text of requirements. The structured input text of code includes descriptions of code structure and function call relationships, while the structured input text of requirements includes descriptions of requirement items and descriptions of business rule constraints.

[0029] In this embodiment, the process of converting code semantic representation and design requirement semantic representation into structured input text reduces the uncertainty of input to pre-trained language large models, enabling the model to generate comparable logical descriptions at a unified semantic granularity. For code semantic representation, the system converts it into structured code input text according to a preset template. The preset template includes at least file identifiers, function lists, function inputs and return values, function call relationships, key variable read / write points, control branch points, and exception handling points. The code structure description characterizes the organizational structure and key execution units of the source code file, for example, recording function names, visibility, interface inputs and outputs, and the responsibilities of main statement blocks using functions as the basic unit. The function call relationship description characterizes the call direction and conditions between functions. When generating this description, the system binds the called function in the function call relationship to the function where the call point is located and records the conditional branch information near the call point so that the differences in calls on different paths can be distinguished during subsequent logic derivation.

[0030] For the semantic representation of design requirements, the system converts it into structured input text based on another preset template. The preset template includes at least the requirement item number, requirement item title, triggering condition, input data item, processing rule, output data item, exception conditions, business process node number, and node transition relationship. Among them, the requirement item description is used to solidify the input, processing, and output relationships of the requirements in an itemized manner. The system breaks down the business actions within the same requirement item into sequentially arranged step descriptions and adds its preconditions and postconditions for each step. The business rule constraint description is used to solidify permission constraints, data consistency constraints, boundary value checks, and state machine constraints. The system standardizes the constraints into directly readable judgment statements and associates the judgment statements with the corresponding requirement item number and process node number, thereby supporting the location and traceability in subsequent consistency checks.

[0031] When generating the two types of structured input text, the system also performs consistency alignment processing to make the code structured input text and the requirement structured input text comparable at the field level. Specifically, the system sets unified field naming and output format constraints for the two types of structured input text and normalizes synonyms, so that the business object names in the design document and the identifier names in the source code file can form a corresponding mapping. Through the above transformation, the input received by the pre-trained language large model is transformed from the original semi-structured information into structured text, reducing the inference bias caused by missing context, ambiguity of expression, or inconsistent granularity. This provides a stable input foundation for the subsequent generation of code implementation logic descriptions and design requirement logic descriptions, and improves the repeatability and interpretability of semantic consistency verification.

[0032] The pre-trained language large model generates code implementation logic descriptions based on structured input text, and generates design requirement logic descriptions based on structured input text. Both the code implementation logic descriptions and the design requirement logic descriptions include functional step descriptions, conditional branch descriptions, and data flow descriptions.

[0033] In this embodiment, the pre-trained language model is used to convert the structured code input text and the structured requirement input text into a unified style of logical description, enabling subsequent semantic consistency verification to be compared at the same granularity and with the same structure. Before calling the pre-trained language model, the system configures consistent output constraint rules for both types of input. The output constraint rules at least limit the hierarchical structure, field order, and naming convention of the output to avoid the same type of information from shifting in expression across different generated results. The output constraint rules require descriptions to be expanded using functional points as basic units, and within each functional point, descriptions of functional steps, conditional branches, and data flow are given in a fixed order.

[0034] For structured input text, the pre-trained language model generates a description of the code implementation logic based on the function list, function call relationships, and key variable read / write points. Functional step descriptions characterize independently identifiable sequences of processing actions in the source code file, such as parameter validation, permission checks, business calculations, persistent writes, and return value construction. Conditional branch descriptions characterize the branch paths and triggering conditions corresponding to key control points, and associate branch paths with the involved function call relationships, allowing direct reading of the differences in call chains under different branches. Data flow descriptions characterize the flow process from input data items to output data items, and mark the assignment, transfer, and persistence positions of key variables in different steps, thus forming a traceable data processing chain.

[0035] For structured input text containing requirements, the pre-trained language model generates a logical description of the design requirements based on the descriptions of requirement items, business rule constraints, and process node transitions. Functional step descriptions characterize the sequence of business actions to be performed under requirement constraints, binding each step to the requirement item number and process node number. Conditional branch descriptions characterize the branch conditions corresponding to the decision nodes and branch labels in the business process diagram, incorporating boundary conditions and exceptional situations into the branch descriptions in conjunction with business rule constraints. Data flow descriptions characterize the relationships between input data items, intermediate processing data items, and output data items on the requirement side, presenting the source, validation requirements, and output destination of data items using fixed fields.

[0036] To ensure comparability between the two types of logical descriptions, the system performs structured validation on the output of the pre-trained language model. This validation includes at least field completeness checks and naming consistency checks. When a missing field or a field order that does not conform to output constraints is detected, the system provides supplementary prompts to the input and regenerates the corresponding logical description. Through this approach, both the code implementation logic description and the design requirement logic description structurally include functional step descriptions, conditional branch descriptions, and data flow descriptions. This allows subsequent semantic consistency checks to directly align functional steps, branch conditions, and data item flow, reducing ambiguity caused by relying solely on natural language paragraph comparisons and improving the interpretability and verifiability of the scan results.

[0037] The semantic consistency of the code implementation logic description and the design requirement logic description is checked to obtain the semantic inconsistency result; based on the semantic inconsistency result, the code location in the source code file is determined and a scan report is output.

[0038] During semantic consistency verification, the system aligns the code implementation logic description with the design requirement logic description according to functional steps. Alignment criteria include consistency constraints on functional step names, triggering conditions, processing actions, output results, and data input / output descriptions. For each aligned set of functional steps, the system performs consistency checks on the conditional branch description and data flow description, outputting semantic inconsistency results. Semantic inconsistency results include logical omissions, logical contradictions, logical redundancy, and missing boundary conditions. Logical omissions indicate functional steps where the design requirement logic description exists but the code implementation logic description is missing; logical redundancy indicates functional steps where the code implementation logic description exists but the design requirement logic description is missing; logical contradictions indicate inconsistencies in triggering conditions or branch conclusions within the same functional step; and missing boundary conditions indicate that input validation or abnormal branches required by the design requirement logic description are missing in the code implementation logic description. When determining the code location in the source code file based on semantic inconsistency results, the system utilizes the function call relationships and variable definition usage relationships recorded in the code semantic representation to locate the function scope and statement block scope corresponding to the semantic inconsistency results, and determines the code line scope based on the source code location information carried by the abstract syntax tree nodes. The scan report outputs the code location, the type of semantic inconsistency result, the corresponding code implementation logic description fragment and the design requirement logic description fragment, and provides correction suggestions to guide developers to complete branches, modify conditions, or add validation logic within the corresponding code lines.

[0039] Semantic consistency verification involves semantically comparing the code implementation logic description with the design requirement logic description, and generating semantic inconsistency results based on the semantic comparison. Semantic inconsistency results include logical omissions, logical contradictions, logical redundancy, and failure to set boundary conditions.

[0040] In this embodiment, semantic consistency verification is used to determine whether the code implementation logic description and the design requirement logic description are consistent in terms of functional steps, conditional branches, and data flow. If inconsistent, it outputs a locatable and verifiable semantic inconsistency result. Before semantic comparison, the system performs format normalization processing on the code implementation logic description and the design requirement logic description, ensuring they adopt a consistent hierarchical structure and field order, and uniformly maps synonymous terms to avoid comparison deviations caused by name differences. Subsequently, the system establishes a comparison index using functional steps as the basic comparison unit. The comparison index is established by parsing the functional step descriptions in both types of logic descriptions into a set of step entries, and matching them based on the step name, trigger condition keywords, processing action keywords, and output result keywords in the step entry set to obtain one or more sets of step alignment relationships. When multiple candidate alignment relationships exist, the system prioritizes trigger condition consistency and output result consistency as the selection rule, thus maintaining executable comparison even when the requirement granularity and implementation granularity are not completely consistent.

[0041] After aligning the steps, the system performs a semantic comparison on each group of aligned functional steps. Semantic comparison includes conditional branch comparison and data flow comparison. Conditional branch comparison determines whether the triggering conditions, branch paths, and exception branches for the same functional step are consistent in the two types of logical descriptions. The system splits the conditional branch description into a set of conditional items and a set of branch conclusions, and checks item by item whether the conditional items cover each other and whether the branch conclusions are consistent. Data flow comparison determines whether the correspondence between input data items, intermediate processing data items, and output data items is consistent in the two types of logical descriptions. The system parses the data flow description into a set of data items and a set of data item associations, and checks whether the input data items are complete, whether the output data items are consistent, and whether key data items have necessary verification and transformation descriptions.

[0042] Based on the above semantic comparison, the system generates semantic inconsistency results. Logical omission results indicate functional steps or branch paths present in the design requirement logic description but missing in the code implementation logic description. When generating logical omission results, the system records the name of the missing step and its corresponding triggering condition. Logical contradiction results indicate inconsistencies in triggering conditions, branch conclusions, or exception handling conclusions between two types of logical descriptions under the same functional step. When generating logical contradiction results, the system records the contradictory condition and the contradictory branch conclusion. Logical redundancy results indicate functional steps or branch paths present in the code implementation logic description but missing in the design requirement logic description. When generating logical redundancy results, the system records the name of the redundant step and its output result. Boundary condition not set results indicate that input validation, permission constraints, or exception branches required by the design requirement logic description are missing in the code implementation logic description. When generating boundary condition not set results, the system records the missing constraint and its object. By structuring the semantic comparison process into three stages—alignment, comparison, and result generation—semantic inconsistency results can directly correspond to specific functional steps and specific condition items, facilitating subsequent determination of code locations in source code files and generation of scan reports, thus improving the interpretability and verifiability of scan conclusions.

[0043] The result of logical omission is determined based on the functional steps for which the logical description of the design requirements exists but the logical description of the code implementation is missing. The logical contradiction is determined based on the inconsistency between the logical description of the design requirements and the logical description of the code implementation in the conditional branch description of the same functional step. The result of logical redundancy is determined based on the functional steps where the logical description of the code implementation exists but the logical description of the design requirements is missing. The result is determined by the constraint conditions required by the design requirements logic description and the missing condition branches in the code implementation logic description, even if the boundary conditions are not set.

[0044] In this embodiment, after obtaining the code implementation logic description and the design requirement logic description, the system first parses the two types of logic descriptions into a set of structured step entries. Each step entry includes at least a step name, triggering condition, processing action, output result, conditional branch list, and descriptive fragments related to data input and output. Terminology normalization is performed on the step name and business object name to eliminate matching discrepancies caused by synonymous expressions. Subsequently, the system establishes a step index using the step name and triggering condition as the primary key, and uses output result and processing action keywords as auxiliary matching conditions to form an alignment relationship between the design requirement logic description step entries and the code implementation logic description step entries. When multiple candidate alignment entries exist for the same design requirement logic description step entry, the system selects the final alignment entry based on the rule of prioritizing triggering condition consistency and then output result consistency.

[0045] In determining logical omissions, the system iterates through the set of design requirement logical description steps. If a design requirement logical description step does not have a corresponding code implementation logical description step in the alignment relationship, the design requirement logical description step is marked as a logical omission, and the name of the missing step and its triggering condition are recorded for subsequent location of the implementation to be supplemented. In determining logical redundancy, the system iterates through the set of code implementation logical description steps. If a code implementation logical description step does not have a corresponding design requirement logical description step in the alignment relationship, the code implementation logical description step is marked as a logical redundancy, and the output of the redundant steps and their call chain information are recorded for subsequent evaluation of whether the requirement specification should be deleted or supplemented.

[0046] During the process of determining logical contradictions, the system performs a conditional branch consistency check on each aligned set of steps. The system splits the conditional branch descriptions of the design requirement logic into conditional items and branch conclusions, and also splits the conditional branch descriptions of the code implementation logic in the same way. When the business objects pointed to by the conditional items are consistent, but the threshold judgments, value ranges, equality / inequality relationships, or branch conclusions are inconsistent, the system generates a logical contradiction result and records the contradictory conditional item and corresponding branch conclusion for subsequent verification of the specific judgment statements in the source code file.

[0047] In determining the result of "boundary conditions not set", the system extracts a set of constraints from the design requirement logic description. These constraints include at least input validation, permission constraints, null value handling, range validation, and exception branch requirements. Each constraint is associated with a corresponding step and branch path. The system searches the code implementation logic description for conditional branch descriptions and exception handling descriptions that are synonymous or equivalent to the constraints. When no corresponding conditional branch description is found, the system generates a "boundary conditions not set" result and records the missing constraint and its target. Through this rule-based alignment and comparison process, all four types of semantically inconsistent results point to specific step items and conditional branches, providing a verifiable basis for subsequently determining the code location in the source code file and outputting the scan report. This reduces the risk of omissions when relying solely on manual review of the requirements document and source code file for verification.

[0048] Determining the code location in the source code file based on semantic inconsistency results involves mapping the semantic inconsistency results to syntax nodes in the abstract syntax tree, determining the range of code lines in the source code file based on the syntax nodes, and determining the function names associated with the range of code lines based on function call relationships.

[0049] In this embodiment, after generating the semantic inconsistency result, the system further performs code location determination processing to pinpoint the semantic inconsistency result to the specific line range and function name in the source code file, facilitating direct review and modification by developers. To make the location process feasible, the system synchronously establishes an index set when generating the code semantic representation. The index set includes at least a mapping table from syntax nodes to source code location information, a mapping table from function syntax nodes to function names, a function call relationship index table, and a variable definition and usage relationship index table; wherein, the source code location information includes at least the file identifier, start line number, and end line number.

[0050] When mapping semantically inconsistent results to syntax nodes in the abstract syntax tree, the system selects different anchor points based on the type of the semantically inconsistent result. For logically contradictory results, the system reads the corresponding functional step name and conditional branch description fragment from the semantically inconsistent result, determines the candidate function range in the code implementation logic description based on the functional step name, and retrieves the conditional judgment statement syntax node that semantically corresponds to the conditional branch description fragment within the candidate function range, using this conditional judgment statement syntax node as the target syntax node. For results where boundary conditions are not set, the system reads the missing constraint conditions and their objects from the semantically inconsistent result, determines the set of syntax nodes for the usage positions of relevant variables in the variable definition and usage relationship index table based on the objects, and filters the statement block entry positions that match the constraint type from the syntax node set, using the syntax node corresponding to the statement block entry position as the target syntax node. For logically redundant results, the system locates the corresponding function call syntax node or business processing statement block syntax node based on the redundant functional steps in the code implementation logic description. For logical omissions, the system first determines the syntax node corresponding to the implemented functional step adjacent to the missing functional step based on the missing functional step in the design requirement logic description. Then, based on the control flow relationship, it determines the range of statement blocks that can be inserted or completed, and takes the entry syntax node of the statement block range as the target syntax node, so that the "missing position" has an operable landing point.

[0051] When determining the line range of code in a source code file based on syntax nodes, the system reads the source code location information of the target syntax node and traces upwards to the smallest statement block syntax node containing the target syntax node. The start and end line numbers of the smallest statement block syntax node are used as the line range. When the target syntax node is located inside a conditional branch structure, the line range is further extended to the corresponding conditional branch structure syntax node to cover conditional judgments and branch bodies, avoiding difficulties in verification caused by only locating a single line. When determining the function name associated with the line range based on function call relationships, the system searches upwards along the abstract syntax tree for the function definition syntax node containing the target syntax node, and reads the function name from the function definition syntax node. When the target syntax node is inside a called function and the semantic inconsistency result needs to simultaneously indicate the impact on the calling side, the system supplements the output with a set of parent function names that call the function name based on the function call relationship index table, which is used to present the call chain context in the scan report. Through the above mapping and range determination mechanism, the scan report can provide a verifiable line range and function name, reducing the cost of repeated manual retrieval and location in the source code file, and improving the interpretability and remediability of semantic inconsistency results.

[0052] The scan report is output in the form of a structured record, which includes code location, semantic inconsistency results, code implementation logic description, design requirement logic description and correction suggestions; The correction suggestions are generated by the pre-trained language large model based on the semantic inconsistency results and code semantic representation, and the code business logic diagram is output in the scan report. The code business logic diagram is used to represent the call relationship and data flow relationship between functional steps.

[0053] In this embodiment, after completing semantic consistency verification and code location determination, the system generates and outputs a scan report to centrally present and process semantic inconsistency results. The scan report is output in a structured record format, with fields including at least code location, semantic inconsistency result, code implementation logic description, design requirement logic description, and correction suggestions. Code location indicates the source code file name, function name, and line range corresponding to the semantic inconsistency result; semantic inconsistency result indicates one or more of the following: logical omission, logical contradiction, logical redundancy, or failure to set boundary conditions, and records the names of functional steps and key points of conditional branches related to the result; the code implementation logic description and design requirement logic description present comparative segments from the implementation and requirement sides respectively, enabling reviewers to complete the comparison verification without rereading all source code files and requirement documents.

[0054] To improve the manageability of scan reports, the system further generates correction suggestions. These suggestions are generated by a pre-trained language model based on semantic inconsistencies and code semantic representations. Specifically, the system uses the type of the semantic inconsistency result, the name of the associated functional step, the description of the associated conditional branch, and the code location as prompts. It also uses the abstract syntax tree fragment, variable definition and usage relationship fragment, and function call relationship fragment associated with the code location in the code semantic representation as contextual input to generate correction suggestions from the pre-trained language model. Correction suggestions include at least the target location for adjustment, the suggested supplementary or modified processing actions, and the suggested supplementary validation logic or exception branches. When the semantic inconsistency result is a logical omission, the correction suggestion indicates the functional steps to be supplemented and their triggering conditions. When the semantic inconsistency result is a logical contradiction, the correction suggestion indicates the conditional judgments and branch conclusions to be unified. When the semantic inconsistency result is a result where boundary conditions are not set, the correction suggestion indicates the input validation, permission constraints, or exception handling branches to be added. When the semantic inconsistency result is a logical redundancy, the correction suggestion indicates the implementation fragments of the requirement specification to be deleted, downgraded, or supplemented. To prevent revision suggestions from being out of touch with reality, the system performs a usability check after generating revision suggestions. The usability check includes verifying the consistency of variable names, function names and code line ranges involved in the suggestions, and if there is inconsistency, the revision suggestions are regenerated or marked as requiring manual confirmation.

[0055] The scan report also outputs a code business logic diagram, which represents the call relationships and data flow relationships between functional steps. The code business logic diagram is generated as follows: the system uses functions or functional steps as nodes, forms call edges based on function call relationships, and forms data flow edges based on variable read / write relationships. For key data items within the same functional step, the system labels the data item name and read / write direction on the data flow edges, thus presenting the call path and data flow in the same view. Through the combined output of structured records and code business logic diagrams, the scan report can simultaneously provide location information, comparison information, and handling suggestions, reducing the time cost of manual investigation and repair, and improving the feasibility of semantic consistency verification results in actual R&D processes.

[0056] like Figure 2 As shown, a semantic verification device based on a large model is used to implement a semantic verification method based on a large model. The device includes: The semantic representation module is used to acquire source code files and corresponding software requirements and design documents. It generates code semantic representations based on syntax parsing and static program analysis, and generates design requirement semantic representations based on text parsing and business process diagram structure recognition. From a hardware implementation perspective, the semantic representation module can be constructed collaboratively by a processor, memory, and input / output interfaces. The processor accesses the code repository and document storage via a network interface or local bus to read and cache source code files and software requirements and design documents. The memory stores intermediate data structures such as abstract syntax trees, symbol tables, function call relationships, control flow relationships, and data flow relationships, and provides a buffer for text parsing and business process diagram structure recognition. When acceleration is needed, a general-purpose acceleration unit can handle parallel computation of image preprocessing and text recognition to reduce the latency of business process diagram structure recognition, ultimately forming structured data of code semantic representation and design requirement semantic representation in memory.

[0057] The logic generation module is used to input the semantic representation of code into the pre-trained language large model to generate a code implementation logic description, and to input the semantic representation of design requirements into the pre-trained language large model to generate a design requirement logic description. From a hardware implementation perspective, the logic generation module can consist of a processor, memory, and large model inference computing resources. The processor organizes the semantic representation of code and the semantic representation of design requirements into structured input text and performs segmentation and encoding. It then submits the input to the large model inference end via high-speed interconnect. The large model inference end can be deployed on a local accelerator card or a remote inference server, where the acceleration unit performs matrix operations and outputs the generated results. The memory is used to store prompt information, input text, the generated code implementation logic description and the design requirement logic description, as well as the input-output mapping relationship for traceability, thereby ensuring that the generation process is repeatable and auditable.

[0058] The consistency verification module performs semantic consistency verification between the code implementation logic description and the design requirement logic description to obtain semantic inconsistency results. Based on the semantic inconsistency results, it determines the code location in the source code file and outputs a scan report. From a hardware implementation perspective, the consistency verification module consists of a processor, memory, and an output interface. The processor reads the code implementation logic description and the design requirement logic description from the memory, performs semantic alignment, conditional branch comparison, and data flow comparison to generate semantic inconsistency results, and further reads the abstract syntax tree and source code location information to locate the code line range and function name. The memory is used to store the semantic inconsistency results, location index, and a structured record of the scan report. The output interface writes the scan report to the local file system or sends it to the defect management system and continuous integration system via the network to support subsequent review, repair, and closed-loop tracking.

[0059] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.

[0060] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A semantic verification method based on a large model, characterized in that, Includes the following steps: Obtain source code files and corresponding software requirements and design documents; generate code semantic representations based on syntax parsing and static program analysis; and generate design requirement semantic representations based on text parsing and business process diagram structure recognition. The semantic representation of the code is input into the pre-trained language large model to generate a code implementation logic description, and the semantic representation of the design requirements is input into the pre-trained language large model to generate a design requirement logic description. A semantic consistency check is performed between the code implementation logic description and the design requirement logic description to obtain a semantic inconsistency result; based on the semantic inconsistency result, the code location in the source code file is determined and a scan report is output.

2. The method according to claim 1, characterized in that, Generating the code semantic representation based on syntax parsing and static program analysis includes constructing an abstract syntax tree, extracting variable definition and usage relationships and function call relationships based on the abstract syntax tree, and generating the code semantic representation based on control flow relationships and data flow relationships.

3. The method according to claim 1, characterized in that, The generation of the semantic representation of design requirements based on text parsing and business process diagram structure recognition includes extracting requirement items, business rules and constraints from the software requirements and design documents, identifying process nodes and connection relationships in the business process diagrams in the software requirements and design documents, and structuring the requirement items, business rules, constraints, process nodes and connection relationships into the semantic representation of design requirements.

4. The method according to claim 1, characterized in that, Before inputting the code semantic representation into the pre-trained language large model, the code semantic representation is converted into code structured input text; Before inputting the semantic representation of the design requirements into the pre-trained language model, the semantic representation of the design requirements is converted into a structured input text of requirements. The structured input text of code includes a description of the code structure and a description of the function call relationship. The structured input text of requirements includes a description of the requirement items and a description of the business rule constraints.

5. The method according to claim 4, characterized in that, The pre-trained language large model generates the code implementation logic description based on the code structured input text, and the pre-trained language large model generates the design requirement logic description based on the requirement structured input text. Both the code implementation logic description and the design requirement logic description include functional step description, conditional branch description, and data flow description.

6. The method according to claim 1, characterized in that, Semantic consistency verification includes semantic comparison between the code implementation logic description and the design requirement logic description, and generating semantic inconsistency results based on the semantic comparison. The semantic inconsistency results include logical omission results, logical contradiction results, logical redundancy results, and boundary condition not set results.

7. The method according to claim 6, characterized in that, The logical omission result is determined based on the functional steps that exist in the logical description of the design requirements but are missing in the logical description of the code implementation. The logical contradiction result is determined based on the inconsistency between the logical description of the design requirements and the logical description of the code implementation in the conditional branch description of the same functional step; The logical redundancy result is determined based on the functional steps where the logical description of the code implementation exists but the logical description of the design requirements is missing. The result of not setting boundary conditions is determined based on the constraints required by the design requirements logic description and the missing condition branches in the code implementation logic description.

8. The method according to claim 2, characterized in that, Determining the code location in the source code file based on the semantic inconsistency result includes mapping the semantic inconsistency result to a syntax node in the abstract syntax tree, determining the code line range in the source code file based on the syntax node, and determining the function name associated with the code line range based on the function call relationship.

9. The method according to claim 1, characterized in that, The scan report is output in the form of a structured record, which includes the code location, the semantic inconsistency results, the code implementation logic description, the design requirement logic description, and correction suggestions. The correction suggestions are generated by the pre-trained language large model based on the semantic inconsistency results and the code semantic representation, and the code business logic diagram is output in the scan report. The code business logic diagram is used to represent the call relationship and data flow relationship between functional steps.

10. A semantic verification apparatus based on a large model, used to implement the semantic verification method based on a large model as described in any one of claims 1-9, characterized in that, The device includes: The semantic representation module is used to obtain source code files and corresponding software requirements and design documents, generate code semantic representations based on syntax parsing and static program analysis, and generate design requirement semantic representations based on text parsing and business process diagram structure recognition. The logic generation module is used to input the code semantic representation into the pre-trained language large model to generate a code implementation logic description, and to input the design requirement semantic representation into the pre-trained language large model to generate a design requirement logic description. The consistency verification module is used to perform semantic consistency verification between the code implementation logic description and the design requirement logic description to obtain semantic inconsistency results, determine the code location in the source code file based on the semantic inconsistency results, and output a scan report.

Images