Program interface semantic understanding and structure reconstruction method, device and equipment and medium

Abstract

The application relates to the technical field of development assistance, and discloses a program interface semantic understanding and structure reconstruction method, device, equipment and medium, which comprises the following steps: acquiring source code, interface configuration, construction configuration information and code change records of a code program to be processed to generate an interface code object set; generating an interface semantic basis set along an interface method call path, and generating an interface logic semantic feature portrait, structured mark data and structured explanation text; diagnosing and reconstructing an interface organization structure to generate interface processing update data. The application can be applied to business scenarios such as financial technology and medical health, an interface semantic basis set is formed along an interface method call path, and based on the interface logic semantic feature portrait, marking, explanation and structure reconstruction are carried out, so that the interface explanation content and the interface organization structure can be updated with the code change, thereby reducing the probability that the interface explanation is inconsistent with the real code logic.

Description

Technical Field

[0001] This invention relates to the field of development support technology, and in particular to a method, apparatus, device and medium for semantic understanding and structural reconstruction of program interfaces. Background Technology

[0002] Current enterprise-level backend development typically employs a layered architecture consisting of a control layer, a business logic layer, and a data access layer. The control layer, as the external interface entry point, carries critical information such as interface paths, request objects, return objects, permission restrictions, exception handling, and state changes. Existing interface documentation tools primarily generate interface descriptions based on annotations, method signatures, parameter types, and return structures. This makes it difficult to understand the actual processing logic within the business logic and data access classes along the method call path, and also makes it difficult to uniformly express input conditions, calling objects, processing behaviors, return results, and exception branches as stable interface business semantics. With continuous code iteration, interface descriptions can easily deviate from the actual code logic, leading to a reliance on manual maintenance for interface classification, understanding, integration, and test building.

[0003] In the fintech business, backend interfaces typically involve scenarios such as account management, credit approval, payment clearing, transaction risk control, customer onboarding, credit limit adjustment, account reconciliation, and contract signing. These interfaces often have complex permission constraints, state transitions, exception returns, and cross-layer call logic. Existing interface documentation tools usually only display the interface path, request fields, and response fields, making it difficult to accurately reflect the corresponding financial business objects, business behaviors, triggering scenarios, execution restrictions, and impact of the results. When financial business systems are frequently adjusted, the naming, request objects, return objects, and interface descriptions of the control layer interfaces can easily become inconsistent with the actual business processing logic, thereby increasing the maintenance costs of integration testing, compliance verification, interface reuse, and automated understanding.

[0004] In the healthcare business domain, backend interfaces typically involve scenarios such as patient registration, appointment booking, examination and testing, electronic medical records, prescription circulation, medical insurance settlement, follow-up management, and health record inquiries. The business meaning of these interfaces is closely related to patient identity, treatment processes, data permissions, result feedback, and abnormal states. Existing tools struggle to identify the true semantics of medical business from the control layer interface methods and their cross-layer call relationships, and also find it difficult to update interface explanations synchronously with code changes. In collaborative development scenarios involving multiple hospital campuses, departments, and business systems, issues such as inaccurate interface business descriptions, unclear interface classification, and difficulties in understanding interface structures will continue to accumulate, affecting the efficiency of cross-system integration, test case construction, and code maintenance. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for understanding and reconstructing the semantics of a program interface, aiming to solve the technical problem that existing interface documentation tools are unable to accurately identify the business semantics of the interface based on the interface method call paths in the private backend code, resulting in inconsistencies between the interface explanation, structured marking, and interface organization structure and the actual code logic.

[0006] To achieve the above objectives, this invention provides a method for program interface semantic understanding and structural reconstruction, comprising: Obtain the source code, interface configuration, build configuration information, and code change records of the code program to be processed; identify the interface control class based on the source code, the interface configuration, and the build configuration information; extract the interface description data of the interface control class; and generate an interface code object set based on the interface description data, wherein the interface code object set includes interface methods. The interface code object set is parsed, and code tracing is performed along the call path of the interface method to generate a set of interface semantic basis. Based on the aforementioned set of interface semantic criteria, the input conditions, calling objects, processing behaviors, return results, and exception branches of the interface methods are combined and analyzed to generate an interface logical semantic feature profile. Based on the interface logical semantic feature profile, structured tag data is generated, and based on the structured tag data and the interface semantic basis set, structured explanation text corresponding to the interface method is generated. Based on the interface logical semantic feature profile, the structured tag data, and the structured explanatory text, the parsability of the interface organization structure of the interface control class is diagnosed, and a set of objects to be adjusted and an adjustment impact record are generated. Based on the set of objects to be adjusted and the adjustment impact record, the interface method and the interface control class are restructured to generate interface structure adjustment results, and interface processing update data is generated based on the interface structure adjustment results and the code change record.

[0007] Furthermore, to achieve the above objectives, the present invention provides a program interface semantic understanding and structural reconstruction apparatus, comprising: The interface code object construction module is used to obtain the source code, interface configuration, construction configuration information and code change records of the code program to be processed, identify the interface control class based on the source code, the interface configuration and the construction configuration information, extract the interface description data of the interface control class, and generate an interface code object set based on the interface description data. The interface code object set includes interface methods. The call tracing and parsing module is used to parse the set of interface code objects, trace the code along the call path of the interface methods, and generate a set of interface semantic basis. The logical semantic profile generation module is used to perform combined analysis on the input conditions, calling objects, processing behaviors, return results and abnormal branches of the interface method based on the interface semantic basis set, and generate an interface logical semantic feature profile. The tag description generation module is used to generate structured tag data based on the interface logical semantic feature profile, and to generate structured explanatory text corresponding to the interface method based on the structured tag data and the interface semantic basis set; The organizational structure diagnosis module is used to perform parsability diagnosis on the interface organizational structure of the interface control class based on the interface logical semantic feature profile, the structured tag data, and the structured explanatory text, and generate a set of objects to be adjusted and an adjustment impact record. The structure refactoring and update module is used to refactor the interface method and the interface control class based on the set of objects to be adjusted and the adjustment impact record, generate interface structure adjustment results, and generate interface processing update data based on the interface structure adjustment results and the code change record.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a program interface semantic understanding and structure reconstruction program stored in the memory and executable on the processor, wherein when the program interface semantic understanding and structure reconstruction program is executed by the processor, it implements the steps of the program interface semantic understanding and structure reconstruction method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a program interface semantic understanding and structure reconstruction program, wherein when the program interface semantic understanding and structure reconstruction program is executed by a processor, it implements the steps of the program interface semantic understanding and structure reconstruction method as described above.

[0010] Beneficial Effects: This invention relates to the field of development support technology and discloses a method, apparatus, device, and medium for program interface semantic understanding and structural reconstruction. The method includes: acquiring the source code, interface configuration, build configuration information, and code change records of the program to be processed, generating a set of interface code objects including interface methods; tracing the code along the call path of the interface methods to generate a set of interface semantic basis data; generating an interface logical semantic feature profile, structured tagging data, and structured explanatory text based on the interface semantic basis data; performing a resolvability diagnosis on the interface organization structure to generate a set of objects to be adjusted and a record of the impact of adjustments; and reconstructing the structure based on the set of objects to be adjusted and the record of the impact of adjustments, and generating interface processing update data in conjunction with the code change records. This invention can be applied to business scenarios such as fintech and healthcare. By forming an interface semantic basis set through the call path of interface methods, the interface tags and explanations have a code basis; by reconstructing the structure through the interface logical semantic feature profile, structured explanatory text, and the set of objects to be adjusted, the interface description content and interface organization structure can be updated with code changes, thereby reducing the probability of inconsistencies between the interface description and the actual code logic. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for the program interface semantic understanding and structural reconstruction method in one embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the program interface semantic understanding and structural reconstruction method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the program interface semantic understanding and structure reconstruction device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The program interface semantic understanding and structural reconstruction method provided in this embodiment of the invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The server can obtain the source code, interface configuration, build configuration information, and code change records of the program to be processed from the client, generating a set of interface code objects including interface methods; tracing the code along the call path of the interface methods to generate a set of interface semantic basis; generating an interface logical semantic feature profile, structured tag data, and structured explanatory text based on the interface semantic basis set; performing a resolvability diagnosis on the interface organization structure to generate a set of objects to be adjusted and an adjustment impact record; and performing structural reconstruction based on the set of objects to be adjusted and the adjustment impact record, combined with the code change records to generate interface processing update data. This invention can be applied to business scenarios such as fintech and healthcare. By forming an interface semantic basis set through the call path of interface methods, the interface tagging and explanation have a code basis; by reconstructing the structure through the interface logical semantic feature profile, structured explanatory text, and set of objects to be adjusted, the interface description content and interface organization structure can be updated with code changes, thereby reducing the probability of inconsistency between the interface description and the actual code logic. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the program interface semantic understanding and structural reconstruction method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the program interface semantic understanding and structural reconstruction method proposed in this invention includes the following steps: S10, obtain the source code, interface configuration, build configuration information and code change records of the code program to be processed, identify the interface control class based on the source code, the interface configuration and the build configuration information, extract the interface description data of the interface control class, and generate an interface code object set based on the interface description data, the interface code object set including interface methods; In this embodiment, the source code provides class declarations, method declarations, annotations, parameter lists, return types, and exception declarations. The interface configuration provides interface access entry points, access path configurations, request method configurations, permission configurations, and gateway path configurations. The build configuration information provides the source code directory, module divisions, and build entry file. The code change log provides the scope of changed files and code version identifiers. During implementation, the source code directory can be determined based on the build configuration information, the interface access declaration markers in the interface configuration can be used to scan the class files in the source code, and the code change log can be used to limit the parsing scope.

[0016] Interface controller classes are identified through a combination of source code, interface configuration, and build configuration information. During identification, class files are loaded in the source code directory, and class-level access declarations, method-level access declarations, request method declarations, and permission annotations are read. Class files with interface access entry points and accessible methods are identified as interface controller classes. Interface description data includes package path, interface access path, request method, method name, method parameters, request object, return object, exception declaration, and permission annotations, which can be extracted from the interface controller class through syntax parsing. A collection of interface code objects is used to store interface controller classes, interface methods, interface description data, and code version identifiers. During generation, objects can be grouped by interface controller class and created by interface method.

[0017] This can be achieved using a full scan approach. After reading the build configuration information, the source code directory and module division information are determined. The class files under the source code directory are traversed, and the interface control classes are identified based on the interface access declaration tags in the interface configuration. Then, the interface description data is extracted from the interface control classes. This approach is suitable for interface review before version release.

[0018] Alternatively, an incremental scanning approach can be used. This involves reading the scope of changed files and code version identifiers from the code change log, loading only the changed source code files. If the changed file contains interface access declaration markers, the interface description data is extracted and the interface code object collection is updated; if the changed file only contains internal implementation classes, the existing interface code object collection is retained.

[0019] In the field of healthcare business, it can perform parsing on backend services such as health record query, appointment submission and follow-up record storage, write the interface access path, request object, return object and exception declaration into the interface description data, and generate the corresponding interface code object collection record.

[0020] In the field of fintech business, backend services such as account balance inquiry, credit application submission, payment instruction processing and transaction risk handling can be parsed, and the request object, return object, exception declaration, permission annotation and interface access path can be written into the interface description data, and the corresponding interface code object collection record can be generated.

[0021] This embodiment identifies the interface control class by combining source code, interface configuration, and build configuration information, which can reduce the probability of missed or misidentified interface entry points; it collects interface access paths, request objects, return objects, exception declarations, and permission annotations by using interface description data, which can form a unified record of interface structure information scattered in the code; and it binds interface methods and code version identifiers to the interface code object set, which can reduce the probability of inconsistencies between interface descriptions and actual code content.

[0022] S20, parse the set of interface code objects, trace the code along the call path of the interface method, and generate a set of interface semantic basis; In this embodiment, the interface code object collection stores the interface control class, interface methods, interface description data, and code version identifier. When parsing the interface code object collection, the interface access path, request method, method parameters, request object, return object, exception declaration, and associated calling file can be read according to the interface method, enabling subsequent code tracing to focus on a single interface method as the parsing object. The call path of an interface method originates from the call expression in the method body, including the name of the called object, the name of the called method, and the call parameters. Code tracing can locate the called code fragments in the business processing class and data access class along the call expression and record the source code location of the called code fragments. The interface semantic basis collection stores traceable semantic basis items, which may include method name semantics, parameter field semantics, return field semantics, exception triggering location, permission restriction information, state change information, data read or write direction, source code location, and basis type. In this way, the semantic content required for the interface description can come from the internal structure and call relationships of the code, reducing misunderstandings caused by relying solely on method names or parameter names.

[0023] This can be implemented using an abstract syntax tree (AST) parsing approach. The parser reads the interface methods from the collection of interface code objects, locates the corresponding source code fragments, performs syntax parsing on the source code fragments, and extracts method declaration nodes, annotation nodes, parameter nodes, return nodes, exception nodes, and method body nodes. Then, it extracts the calling expression from the method body nodes. The name of the called object and the name of the called method in the calling expression can be used to locate the business processing class, and data access calls within the called method can further locate the data access class. The parser extracts semantic content from the interface methods and the called code fragments, binds the semantic content to the source code location, and generates a set of interface semantic bases.

[0024] Alternatively, incremental tracing can be used. The parser locates the changed interface methods based on the code version identifier and interface access path in the interface code object collection, and only re-extracts the call path for interface methods within the scope of change. If the call path has not changed, the existing source code location and reference type can be reused; if the call path has changed, the business processing class and data access class are relocated, and the corresponding semantic reference items are updated. This method is suitable for projects with a large number of interfaces and frequent code changes.

[0025] In the healthcare business domain, the interface methods corresponding to the appointment submission interface can call the appointment verification class and the appointment record data access class. The parsing program locates the verification logic and record writing position along the call path, extracts the request object, return object, exception trigger position, and status change information, and generates a set of interface semantic basis for subsequent identification of the input restrictions and return meaning of the appointment submission interface.

[0026] In the fintech business field, the interface methods corresponding to the payment instruction processing interface can call the payment verification class, account deduction class, and transaction record data access class. The parsing program locates the permission verification, account status change, and transaction record writing positions along the call path, extracts permission restriction information, status change information, and data read or write direction, and generates a set of interface semantic basis for subsequent identification of the business semantic source of the payment processing interface.

[0027] This embodiment parses the interface code object set and traces the code along the call path of the interface method. It can extract semantic basis items with source code location from the interface method, business processing class and data access class, so that the interface semantic basis set can reflect the real code content. By recording the basis type and source code location, it can reduce the situation where the interface explanation content is separated from the code implementation, thereby reducing the probability of inconsistency between the interface description and the real code logic.

[0028] S30, based on the interface semantic basis set, perform combined analysis on the input conditions, calling objects, processing behaviors, return results and abnormal branches of the interface method to generate an interface logical semantic feature profile; In this embodiment, the interface semantic basis set stores the semantic basis items corresponding to the interface method. Each semantic basis item may include the source code location, basis type, and interface method identifier. During reading, semantic basis items can be grouped according to the interface method, ensuring that the parameter field semantics, permission restriction information, calling expression, state change information, return field semantics, and exception triggering location of the same interface method are within the same analysis scope. Input conditions are formed by parameter field semantics, permission restriction information, and condition judgment information, representing the data and access requirements that must be met before the interface call. The calling object is formed by the calling expression, associated calling file, called object name, and called method name, representing the business processing object or data access object called by the interface method. Processing behavior is formed by the method name semantics, state change information, and data read or write direction, representing the actual data query, state modification, record writing, or result generation actions performed by the interface method. The return result is formed by the return field semantics, return object information, and state change information, representing the data structure and state result output by the interface method. An exception branch is formed by the exception trigger location, exception declaration, and exception return information. It represents the exception path formed when the interface method fails validation, lacks sufficient permissions, has a state conflict, or has missing data. Input conditions, calling objects, processing behaviors, return results, and exception branches are all written into the same interface method's logical semantic record, forming an interface logical semantic feature profile.

[0029] This embodiment uses interface semantic criteria to collect the input, call, behavior, return, and exception information of the same interface method, which can reduce the deviation caused by understanding the meaning of the interface based solely on the method name; by combining and analyzing to form an interface logical semantic feature profile, the business meaning of the interface can have code source and internal structure, thereby reducing the probability of inconsistency between the interface interpretation and the actual code logic.

[0030] S40, generate structured tag data based on the interface logical semantic feature profile, and generate structured explanation text corresponding to the interface method based on the structured tag data and the interface semantic basis set; In this embodiment, the interface logical semantic feature profile stores information such as business objects, business behaviors, triggering scenarios, execution restrictions, and result impacts. Structured tagging data is generated from the above content and is used to categorize interface methods into searchable, comparable, and classifiable data formats. Business objects can be converted into business domain tags, business behaviors into capability type tags, triggering scenarios into business scenario tags, execution restrictions into permission tags, result impacts and data read / write directions into data flow tags, and exception trigger locations and exception return content into exception tags. During generation, the interface logical semantic feature profile can be read according to the interface method, and various profile contents can be written into the tagging fields, while maintaining the correspondence between the tagging fields and the interface methods.

[0031] The interface semantic basis set provides code evidence for the structured explanatory text. Semantic basis items in the set can include source code location, basis type, interface method, calling object, parameter field semantics, return field semantics, exception trigger location, and permission restriction information. When generating structured explanatory text, business domain tags, business scenario tags, capability type tags, permission tags, data flow tags, and exception tags from the structured tag data are matched with the semantic basis items to form text fragments such as interface processing purpose, applicable scenarios, request preconditions, business meaning of input fields, processing restrictions, state change results, return content meaning, exception trigger conditions, and permission requirements. Each text fragment can record the corresponding source code location, allowing the text content to be traced back to the interface method and calling code.

[0032] Structured explanatory text is generated on a per-interface-method basis. The structured tagging data corresponding to the interface method determines the classification dimension of the text, while the semantic basis set determines the code basis of the text. In implementation, the binding relationship between tagging fields and semantic basis items can be established first. Then, successfully matched text fragments are written into the description body, and text fragments lacking semantic basis support are written into the pending confirmation fragment set. This avoids the interface description relying solely on the interface name for generation and reduces inconsistencies between the interface's business meaning and the code content.

[0033] This embodiment generates structured marked data by profiling interface logic semantic features. This can transform the business objects, business behaviors, triggering scenarios, execution restrictions, and result impacts of interface methods into categorizable data. By generating structured explanatory text through structured marked data and interface semantic basis set, the explanatory text can simultaneously have classification marks and code basis, thereby reducing the probability of inconsistency between the interface description content and the actual code logic.

[0034] S50, based on the interface logical semantic feature profile, the structured tag data, and the structured explanatory text, perform a parsingability diagnosis on the interface organization structure of the interface control class, and generate a set of objects to be adjusted and an adjustment impact record; In this embodiment, the interface logical semantic feature profile is used to provide a summary of the interface method's business object, business behavior, triggering scenario, execution restrictions, and result impact. Structured tagging data is used to provide business domain tags, business scenario tags, capability type tags, permission tags, data flow tags, and exception tags. Structured explanatory text is used to provide the interface processing purpose, the business meaning of input fields, the meaning of returned content, exception triggering conditions, and permission requirements. When performing a resolvability diagnosis on the interface organization structure of the interface control class, the above three types of data can be aggregated by interface control class, and the interface access path, method name, request object, return object, and package path can be read to form interface organization diagnostic data.

[0035] The resolvability diagnostic is used to determine whether interface methods in an interface controller class are easily programmatically read and categorized. During diagnosis, it can compare business behaviors and capability type markers under the same business object to identify duplicated interface methods; it can count the number of business behaviors associated with the same interface method to identify interface methods undertaking multiple independent business behaviors; it can match the action and object components in the method name with the business behavior to identify naming discrepancies; it can compare the naming of fields with the same business meaning in the request and return objects to identify differences in object expression; and it can compare the module affiliation corresponding to the package path with the business domain marker and business scenario marker to identify interface controller class aggregation discrepancies. The set of objects to be adjusted is used to store the abnormal organization objects obtained from the above diagnostics, and the adjustment impact record is used to store the scope of impact on interface access paths, request objects, return objects, exception markers, and associated calling files.

[0036] This embodiment uses interface logic semantic feature profiling, structured tagging data, and structured explanatory text to form interface organization diagnostic data. It can simultaneously use semantic induction results, classification tags, and explanatory content to identify interface organization problems. By generating duplicate interface objects, multi-behavior interface objects, naming deviation objects, object expression difference objects, and aggregation deviation objects, the set of objects to be adjusted can have a clear source. By saving the scope of the affected area in the adjustment impact record, the probability of missing interface access paths, request objects, return objects, or associated call files during subsequent structural adjustments can be reduced.

[0037] S60, based on the set of objects to be adjusted and the adjustment impact record, the interface method and the interface control class are restructured to generate interface structure adjustment results, and interface processing update data is generated based on the interface structure adjustment results and the code change record.

[0038] In this embodiment, the set of objects to be adjusted carries the interface methods and interface control classes that need to be modified, and may include duplicate interface objects, multi-behavior interface objects, naming deviation objects, object expression difference objects, and aggregation deviation objects. The adjustment impact record carries the interface access paths, request objects, return objects, exception flags, and associated calling files that will be affected by the structural reconstruction. During structural reconstruction, the objects to be modified can be determined based on the set of objects to be adjusted, and then the scope of modification can be determined based on the adjustment impact record, avoiding the omission of caller references when merging, splitting, or migrating interface methods.

[0039] The restructuring of interface methods can include merging, splitting, renaming, and unifying object representation. Interface methods corresponding to duplicate interface objects can be merged according to business behavior, request objects, and return objects. Interface methods corresponding to multi-behavior interface objects can be split into multiple interface methods according to business behavior boundaries. Interface methods corresponding to objects with naming discrepancies can have their method names adjusted based on business behavior. Request objects and return objects corresponding to objects with differing object representations can be unified based on the business meaning of input fields and the meaning of return content.

[0040] The structure of interface control classes can be restructured based on business domain and business scenario tags to adjust aggregation relationships. Interface control classes with package paths inconsistent with business affiliations can be migrated to the corresponding module directory; when interface methods are too scattered, they can be re-aggregated into the corresponding interface control classes according to business scenarios. The interface structure adjustment results are used to record merged data, split data, named expression adjustment data, interface control class aggregation and restructuring data, and compatibility mapping information. Code change records provide the scope of changed files and code version identifiers; updated interface processing data can be written to the updated interface structure adjustment results, code version identifiers, and compatibility mapping information.

[0041] This embodiment determines the objects to be modified by the set of objects to be adjusted, and determines the scope of the impact by the adjustment impact record. This allows the merging, splitting, renaming, and refactoring of interface methods and the aggregation of interface control classes to have clear objects. By recording the structural changes through the interface structure adjustment results and generating interface processing update data based on the code change record, inconsistencies between the description, caller references, and code versions after the interface structure changes can be reduced.

[0042] In one embodiment, step S10 includes: S101: Obtain the source code, interface configuration, build configuration information, and code change records of the code program to be processed; parse the build configuration information to determine the source code path and project module division information; parse the interface configuration to determine the interface access declaration marker; parse the code change records to determine the scope of changed files and code version identifier; and generate a project parsing index based on the source code path, the project module division information, the interface access declaration marker, the scope of changed files, and the code version identifier. S102, based on the source code path, project module division information and change file scope in the project parsing index, load the source code file to be parsed from the source code, and based on the interface access declaration mark in the project parsing index, filter class files containing interface access declaration marks from the source code file to be parsed to form a set of interface candidate classes; S103, class declaration parsing and method declaration parsing are performed on the class files in the interface candidate class set to identify class-level access paths and method-level access paths. Class files containing interface access declaration tags and having method-level access paths are identified as interface control classes, and methods in the interface control classes that have method-level access paths are identified as interface methods. S104, extract the package path from the interface control class, extract the request method, method name, method parameters, request object, return object, exception declaration, and permission annotation from the interface method, and generate the interface access path based on the package path, the class-level access path, and the method-level access path, and write the package path, the interface access path, the request method, the method name, the method parameters, the request object, the return object, the exception declaration, and the permission annotation into the interface description data; S105, Based on the calling expression in the method body of the interface method, identify the associated calling file that has a calling relationship with the interface method, and write the associated calling file into the interface description data; S106, Based on the code version identifier in the project parsing index, bind the interface control class, the interface method, and the interface description data to generate a set of interface code objects.

[0043] In this embodiment, the source code is used to carry class declarations, method declarations, annotations, parameter lists, return types, exception declarations, and method body content. Interface configuration is used to specify the interface access entry point, access declaration flag, request method configuration, and permission configuration. Build configuration information is used to determine the source code path, project module division information, and build entry file. Code change records are used to determine the scope of changed files and code version identifiers. When parsing the build configuration information, the source code directory field and module dependency field in the project configuration file can be read to form the source code path and project module division information; when parsing the interface configuration, the interface annotation name, routing configuration item, or access entry point configuration item can be read to form the interface access declaration flag; when parsing the code change record, the scope of changed files and code version identifier in the commit record, change list, or build record can be read. The source code path, project module division information, interface access declaration flag, scope of changed files, and code version identifier are written into the project parsing index, so that subsequent loading of class files can be constrained by the module scope, interface entry point, and version scope simultaneously.

[0044] The project parsing index is used to narrow down the scope of source code loading. The source code path is used to locate the code directory, project module division information is used to distinguish different service modules, the changed file scope is used to determine the source code files that need to be loaded, and the interface access declaration flag is used to filter class files with interface entry declarations from the source code files. When loading source code files to be parsed, the file list can be read by the source code path, then irrelevant modules can be filtered by the project module division information, and the files to be parsed can be selected by the changed file scope. When filtering class files, the class declaration area and annotation area can be read to determine whether the class file contains interface access declaration flags; class files that meet the criteria are added to the interface candidate class set.

[0045] The class files in the candidate interface class set need to undergo class declaration parsing and method declaration parsing. Class declaration parsing can read the package declaration, class name, class-level access path, and class-level permission annotations. Method declaration parsing can read the method name, method-level access path, request method, parameter list, return type, exception declaration, and method body. When a class file contains interface access declaration markers and has methods with method-level access paths, it can be identified as an interface controller class. Methods with method-level access paths in the interface controller class can be identified as interface methods. Through this process, a clear attribution relationship is established between the interface controller class and the interface methods, avoiding the need to determine the interface entry point solely based on the class name or file path.

[0046] Interface description data stores information from the interface controller class and interface methods that describes the interface structure. Package paths originate from class declarations, class-level access paths from class annotations or route configurations, method-level access paths from method annotations or route mappings, request methods from request method annotations or configuration items, method names from method declarations, method parameters from parameter lists, request objects from request body parameters or form parameters, return objects from return types or response encapsulation types, exception declarations from method declarations or exception annotations, and permission annotations from class-level or method-level permission configurations. Interface access paths can be generated by associating package paths, class-level access paths, and method-level access paths, or they can be generated from method-level access paths when class-level access paths are missing. After the above content is written into the interface description data, the entry point, request, return, exception, and permission information for the same interface method are grouped into the same record.

[0047] The associated calling file can be identified based on the calling expression in the method body of the interface method. The calling expression includes the name of the called object, the name of the called method, and the calling parameters. When parsing the method body, member variable calls, local variable calls, and injected object calls can be read, and the file where the called object is located can be determined by combining import declarations, class field declarations, and constructor parameters. Files that have a calling relationship with the interface method are written into the interface description data, so that the interface description data not only contains the interface entry structure, but also the code locations that need to be traced afterward.

[0048] When generating a collection of interface code objects, the interface controller class, interface methods, and interface description data can be bound to the same object record based on the code version identifier in the project's parsing index. Each object record can contain an interface controller class identifier, an interface method identifier, an interface access path, a request object, a return object, exception declarations, permission annotations, associated calling files, and a code version identifier. The collection of interface code objects can be grouped by interface controller class or by interface method index. Using this collection, subsequent access to interface structure and version data can be directly retrieved on a method-by-method basis.

[0049] This embodiment constructs a project parsing index, unifying source code paths, project module division information, interface access declaration markers, changed file scopes, and code version identifiers for source code file loading and interface class filtering, thereby reducing missed and misidentified interface control classes. Through class declaration parsing, method declaration parsing, and interface description data writing, package paths, interface access paths, request objects, return objects, exception declarations, and permission annotations are grouped into the same interface method record, improving the completeness of interface structure reading. By associating call file identification and binding code version identifiers, the interface code object collection can store interface entry points, object structures, call locations, and version relationships, thereby reducing the probability of subsequent inconsistencies between interface descriptions and actual code content.

[0050] In one embodiment, step S20 above includes: S201, Read the interface method from the interface code object collection, locate the source code fragment corresponding to the interface method, and form an interface method parsing object; S202, perform abstract syntax tree parsing on the interface method parsing object, extract method declaration nodes, annotation nodes, parameter nodes, return nodes, exception nodes and method body nodes, and record the source code location corresponding to each node to generate an interface method node set; S203, extract the calling expression from the method body node in the interface method node set, and generate the calling path of the interface method based on the called object name, the called method name and the calling parameters in the calling expression; S204, locate the called code fragments corresponding to the business processing class and data access class according to the call path of the interface method, identify the associated call file where the called code fragment is located, record the source code location corresponding to the called code fragment, and generate a set of traced code fragments; S205, extract method name semantics, parameter field semantics, return field semantics, condition judgment information, exception declaration, exception return information, exception triggering location and permission restriction information from the method declaration node, annotation node, parameter node, return node, exception node and method body node in the interface method node set, and extract the calling expression, called object name, called method name, return object information, state change information and data read or write direction from the tracing code fragment set to generate code semantic elements; S206, determine the basis type according to the semantic category of the code semantic element, bind the code semantic element, the source source code location, the interface method, the associated calling file and the basis type to form a semantic basis item, and summarize the semantic basis items according to the interface method to generate an interface semantic basis set.

[0051] In this embodiment, the interface code object collection stores the interface method, interface description data, interface control class identifier, and code version identifier. During parsing, the interface access path, request method, method parameters, request object, return object, exception declaration, permission annotations, and associated calling files can be read according to the interface method, and the source code segment where the interface method is located can be located based on the interface description data. The interface method parsing object consists of the interface method, source code segment, and interface description data, and is used to limit the scope of subsequent syntax parsing, preventing other methods from being mixed into the parsing scope of the current interface method.

[0052] Abstract Syntax Tree (AST) parsing is used to convert source code fragments into a readable node structure. Method declaration nodes provide the method name, return type, and exception declaration; annotation nodes provide access declarations, permission annotations, and request methods; parameter nodes provide parameter names, parameter types, and field annotations; return nodes provide the return object and return fields; exception nodes provide exception declarations, exception trigger locations, and exception return information; and method body nodes provide conditional statements, object calls, state changes, and data read / write operations. When recording the source code location corresponding to each node, the file path, class name, method name, line range, and node type can be saved, allowing subsequent semantic references to trace back to the specific code location.

[0053] The invocation expression is extracted from the method body node. Invocation expressions can include member object calls, local object calls, static method calls, and injected object calls. The called object name identifies the object to which the call target belongs, the called method name identifies the specific method within the called target, and the invocation parameters identify the fields and objects passed to downstream processing by the interface method. When generating the invocation path of the interface method based on the called object name, the called method name, and the invocation parameters, the interface method itself, the business processing class method, and the data access class method can be written into the same invocation path record according to their invocation order. For cases with multi-level invocations, the file to which the called object belongs can be parsed based on class field declarations, import declarations, and constructor parameters, and the called code segment can be located further according to the invocation depth.

[0054] Code tracing locates the called code snippets in business processing and data access classes along the call path of interface methods. The called code snippets in business processing classes provide information such as conditional statements, state changes, exception trigger locations, and permission restrictions. The called code snippets in data access classes provide information on data read or write direction, the queried object, the written object, and the returned object. When identifying the associated calling file where the called code snippet resides, the file path, class name, called method name, and source code location can be jointly written into the tracing code snippet set, ensuring that the extracted semantic content remains consistent with the source file.

[0055] The semantic elements of the code are generated jointly by the set of interface method nodes and the set of tracing code snippets. Method name semantics can be derived from the method declaration node, parameter field semantics from the parameter node, return field semantics from the return node, conditional judgment information from the method body node, exception declarations and exception return information from the exception node, exception triggering locations from conditional judgments and exception throwing statements, and permission restriction information from annotation nodes or interception configurations. The invocation expression, the name of the called object, the name of the called method, return object information, state change information, and data read / write direction can be derived from the set of tracing code snippets. Based on type, it can be generated according to semantic categories, such as parameter basis, invocation basis, return basis, exception basis, permission basis, state basis, and data direction basis.

[0056] Semantic criteria are formed by binding semantic elements of code, source code location, interface method, associated calling file, and criteria type. During binding, semantic elements of code under the same interface method can be grouped according to criteria type, while retaining the source code location and associated calling file. The interface semantic criteria set summarizes semantic criteria items according to interface method, so that the parameters, calls, returns, exceptions, permissions, status, and data direction of the same interface method are uniformly saved, and can provide a traceable data source for subsequent analysis.

[0057] This embodiment locates the source code fragments corresponding to interface methods by using a set of interface code objects, which limits the scope of syntax parsing and reduces interference from irrelevant methods. By parsing an abstract syntax tree to extract method declaration nodes, annotation nodes, parameter nodes, return nodes, exception nodes, and method body nodes, the entry point, parameters, return values, exceptions, and method body content of the interface method can be broken down into readable node data. By generating the call path of the interface method through a call expression and locating the called code fragments in the business processing class and data access class, a correspondence can be established between the interface entry point and the actual processing content. By forming semantic basis items through code semantic elements, source code location, interface method, associated calling file, and type binding, the interface semantic basis set has a clear code source, thereby reducing the probability of inconsistencies between the interface description and the actual code logic.

[0058] In one embodiment, step S30 above includes: S301, extract semantic basis items from the interface semantic basis set according to the interface method, and combine semantic basis items belonging to the same interface method into a method semantic basis subset; S302, read parameter field semantics, permission restriction information and condition judgment information from the method semantic basis subset, and generate input conditions for the interface method; S303, Read the calling expression, associated calling file, called object name and called method name from the method semantic basis subset, and generate the calling object of the interface method; S304, Read the method name semantics, state change information and data read or write direction from the method semantic basis subset, and generate the processing behavior of the interface method; S305, Read the return field semantics, return object information and state change information from the method semantic basis subset, and generate the return result of the interface method; S306, Read the exception triggering location, exception declaration and exception return information from the method semantic basis subset, and generate the exception branch of the interface method; S307. Based on the input conditions, the calling object, the processing behavior, the return result, and the exception branch, determine the business object, business behavior, triggering scenario, execution restrictions, and result impact corresponding to the interface method, and generate an interface logic semantic feature profile containing the business object, the business behavior, the triggering scenario, the execution restrictions, and the result impact.

[0059] In this embodiment, the interface semantic basis set stores semantic basis items according to the interface method. Each semantic basis item includes parameter field semantics, permission restriction information, conditional judgment information, calling expression, associated calling file, called object name, called method name, method name semantics, state change information, data read or write direction, return field semantics, return object information, exception triggering location, exception declaration, and exception return information. When extracting semantic basis items according to the interface method, the interface method identifier, interface access path, or method declaration location can be used as a collection index to write semantic basis items associated with the same interface method into the method semantic basis subset. The method semantic basis subset retains the source code location and basis type, facilitating subsequent differentiation of parameter source, call source, return source, exception source, and state source.

[0060] Input conditions are generated from parameter field semantics, permission restriction information, and conditional judgment information. Parameter field semantics identifies the data fields that the interface call needs to receive, permission restriction information identifies the permission requirements that need to be met to access the interface, and conditional judgment information identifies pre-processing checks such as field non-empty, state matching, value range, and object existence. When generating input conditions, parameter field semantics can be used as field objects, permission restriction information as access restrictions, and conditional judgment information as triggering preconditions to form input constraint records for the same interface method.

[0061] The invocation object is generated from the invocation expression, the associated invocation file, the name of the called object, and the name of the called method. The invocation expression identifies the object call initiated by the interface method, the associated invocation file locates the file containing the target object, the name of the called object identifies the class or component object being accessed, and the name of the called method identifies the actual method being accessed. When generating the invocation object, the name of the called object is matched against the associated invocation file, and the name of the called method is written into the invocation object record, thus organizing the external scope of the interface method's invocation into readable data.

[0062] The processing behavior is generated by the semantics of the method name, state change information, and data read or write direction. The semantics of the method name are used to extract the meaning of the action, the state change information is used to identify changes in data state, and the data read or write direction is used to distinguish operation types such as query, write, update, and delete. When generating the processing behavior, the action component in the semantics of the method name can be aligned with the data read or write direction, and then the state change information can be used to supplement the state changes after processing, so that the actual operation content of the interface method does not depend on a single method name.

[0063] The returned result is generated from the semantics of the returned fields, the information of the returned object, and the status change information. The semantics of the returned fields are used to identify the business meaning of the response fields, the information of the returned object is used to determine the response structure, and the status change information is used to determine the relationship between the response content and the processing result. When generating the returned result, the returned object information can be used as the response carrier, the semantics of the returned fields can be written into the meaning of the response fields, and the status change information can be written into the content affected by the result.

[0064] An exception branch is generated from the exception trigger location, exception declaration, and exception return information. The exception trigger location is used to locate the code where the exception occurred, the exception declaration is used to identify the exception type, and the exception return information is used to identify the exception response content. When generating an exception branch, the exception trigger location can be associated with conditional judgment information, and the exception declaration can be bound with the exception return information to form exception path records such as validation failure, insufficient permissions, state conflict, and missing data.

[0065] The interface logic semantic feature profile is generated jointly by input conditions, calling objects, processing behaviors, return results, and exception branches. Business objects can be extracted from parameter field semantics, return field semantics, and calling objects; business behaviors can be extracted from method name semantics, processing behaviors, and data read or write directions; triggering scenarios can be extracted from input conditions and exception branches; execution restrictions can be extracted from permission restriction information and condition judgment information; and the impact of results can be extracted from return results and state change information. The generated interface logic semantic feature profile is saved on a per-interface-method basis, ensuring that the input, call, behavior, return, and exception content of the same interface method form a unified semantic record.

[0066] This embodiment avoids mixing parameters, calls, returns, and exceptions from different interface methods by categorizing semantic criteria according to interface methods. By generating input conditions, calling objects, processing behaviors, return results, and exception branches separately, the access requirements, calling scope, operation content, response structure, and exception paths of interface methods all have clear data sources. By further forming an interface logical semantic feature profile from the above content, the deviation caused by relying solely on method names or comments to generate interface meanings can be reduced, thereby lowering the probability of inconsistencies between interface descriptions and actual code logic.

[0067] In one embodiment, step S40 above includes: S401, Read the business object, business behavior, triggering scenario, execution restriction and result impact from the interface logical semantic feature profile to form a profile tagging element set; S402, generate business domain markers, business scenario markers, capability type markers, permission markers, and data flow markers based on the profile marker element set, and read the exception trigger location, exception declaration, and exception return information from the interface semantic basis set, generate exception markers based on the exception trigger location, the exception declaration, and the exception return information, and combine the business domain markers, the business scenario markers, the capability type markers, the permission markers, the data flow markers, and the exception markers into structured marker data; S403, extract semantic basis items from the interface semantic basis set according to the interface method, and establish a tag basis binding relationship between the structured tag data and the semantic basis items based on the basis type and source code location in the semantic basis items; S404, Based on the structured marked data, generate interface processing purpose, applicable scenarios, request preconditions, business meaning of input fields, processing restrictions, state change results, meaning of returned content, exception triggering conditions, and permission requirements corresponding to the explanation candidate fragments; S405, perform basis matching on the candidate explanatory fragments based on the interface semantic basis set, write the candidate explanatory fragments that match the semantic basis items into the explanatory description body, and write the candidate explanatory fragments that do not match the semantic basis items into the fragment set to be confirmed; S406, the explanatory body, the set of fragments to be confirmed, and the marker are combined according to the binding relationship to generate the structured explanatory text corresponding to the interface method.

[0068] In this embodiment, the interface logic semantic feature profile stores business objects, business behaviors, triggering scenarios, execution restrictions, and result impacts. Business objects can originate from data objects, request objects, or return objects processed by the interface method; business behaviors can come from method name semantics and state change information; triggering scenarios can come from input conditions and exception branches; execution restrictions can come from permission restriction information and condition judgment information; and result impacts can come from return results and data read or write directions. When reading the above content, the profile fields corresponding to the same interface method can be extracted according to the interface method identifier, and the extraction results are written to the profile tag element set. The profile tag element set is used to carry the intermediate data required for subsequent tag generation, ensuring that business objects, business behaviors, triggering scenarios, execution restrictions, and result impacts maintain a corresponding relationship within the same interface method scope.

[0069] Business domain tags can be generated based on business objects to indicate the data object or business scope to which an interface method belongs. Business scenario tags can be generated based on triggering scenarios to indicate the scenario category in which the interface method is invoked. Capability type tags can be generated based on business behaviors to indicate the processing type undertaken by the interface method. Permission tags can be generated based on execution restrictions to indicate the access constraints of the interface method. Data flow tags can be generated based on the impact of results and the direction of data reading or writing to indicate the relationship of data reading, writing, updating, or returning by the interface method. Exception tags can be generated based on the exception triggering location, exception declaration, and exception return information in the interface semantic criteria set to indicate the location of exception occurrence, exception type, and exception response content. These tags are combined into structured tag data, giving the interface method searchable, categorizable, and comparable data labels.

[0070] The interface semantic basis set stores semantic basis items according to the interface method. Each semantic basis item includes a basis type and the source code location. The basis type distinguishes between parameter basis, call basis, return basis, exception basis, permission basis, and status basis. The source code location records the corresponding code file, class name, method name, and code line range. When establishing a tag basis binding relationship, each tag field in the structured tag data can be matched with a semantic basis item. Business domain tags can be bound to parameter field semantics and return field semantics; capability type tags can be bound to method name semantics and status change information; permission tags can be bound to permission restriction information; and exception tags can be bound to exception trigger location, exception declaration, and exception return information. The tag basis binding relationship records the code source of the tag fields, preventing structured tag data from becoming detached from the interface code content.

[0071] Candidate explanatory fragments are generated from structured marked data and organized according to the interface method. The interface processing purpose can be generated based on business domain and capability type markers; the applicable scenario can be generated based on business scenario markers; request preconditions can be generated based on permission markers and input conditions; the business meaning of input fields can be generated based on business objects and parameter field semantics; processing restrictions can be generated based on execution restrictions; state change results can be generated based on the impact of the results; the meaning of the returned content can be generated based on the semantics of the returned fields and the returned object information; exception triggering conditions can be generated based on exception markers; and permission requirements can be generated based on permission markers. After generation, the interface semantic basis set needs to be used for matching. Explanatory candidate fragments that match semantic basis items are written into the explanation body, while those that do not match semantic basis items are written into the set of fragments to be confirmed. The explanation body, the set of fragments to be confirmed, and the binding relationship of the marker basis together form the structured explanation text corresponding to the interface method, ensuring that the text content includes both interface classification information and retains code basis and content to be confirmed.

[0072] This embodiment extracts business objects, business behaviors, triggering scenarios, execution restrictions, and result impacts from the interface's logical semantic feature profile. This allows for the generation of business domain markers, business scenario markers, capability type markers, permission markers, and data flow markers for interface methods. By reading exception trigger locations, exception declarations, and exception return information from the interface semantic basis set, the data source for exception markers can be supplemented. By establishing a binding relationship between structured marker data and semantic basis items, the interface processing purpose, applicable scenarios, request preconditions, business meanings of input fields, meanings of return content, and exception triggering conditions can have source code locations, thereby reducing the probability of inconsistencies between structured explanatory text and actual code content.

[0073] In one embodiment, step S50 above includes: S501, according to the interface control class, aggregate the interface logical semantic feature profile, the structured tag data, the structured explanation text, the interface methods in the interface code object set, and the method name, interface access path, request object, return object, package path and associated call file in the interface description data corresponding to the interface code object set to form interface organization diagnostic data; S502, Read business objects, business behaviors, business domain tags and capability type tags from the interface organization diagnostic data, identify interface methods with the same business behaviors and consistent capability type tags under the same business object, and generate duplicate interface objects; S503, Read business behaviors from the interface organization diagnostic data, identify interface methods that correspond to multiple independent business behaviors for the same interface method, and generate a multi-behavior interface object; S504, Read the method name and business behavior from the interface organization diagnostic data, match the action component and object component in the method name with the operation type and operation object in the business behavior respectively, and generate a naming deviation object; S505, Read the business scenario marker, input field business meaning, return content meaning, request object and return object from the interface organization diagnostic data; Within the scope of interface methods corresponding to the same business scenario marker, identify interface methods with different field names corresponding to the same business meaning, and generate object expression difference objects; S506, Read the package path, business domain marker and business scenario marker from the interface organization diagnostic data, compare the module affiliation corresponding to the package path with the business affiliation corresponding to the business domain marker and the scenario affiliation corresponding to the business scenario marker, and generate an aggregated deviation object; S507, the repeated interface object, the multi-behavior interface object, the naming deviation object, the object expression difference object, and the aggregation deviation object are combined into a set of objects to be adjusted, and the scope of affected interfaces and the scope of affected calls are determined based on the interface access path, request object, return object, exception flag, and associated call file involved in the set of objects to be adjusted, and the scope of affected interfaces and the scope of affected calls are written into the adjustment impact record.

[0074] In this embodiment, the interface logical semantic feature profile stores business objects, business behaviors, triggering scenarios, execution restrictions, and result impacts. The structured tagging data stores business domain tags, business scenario tags, capability type tags, permission tags, data flow tags, and exception tags. The structured explanatory text stores the interface processing purpose, the business meaning of input fields, the meaning of returned content, exception triggering conditions, and permission requirements. The interface code object set stores interface methods, and the corresponding interface description data stores the method name, interface access path, request object, return object, package path, and associated calling file. When aggregating the above data according to the interface control class, the interface control class identifier or package path can be used as the aggregation index to write the interface methods, semantic content, tagging content, explanatory content, and interface description content under the same interface control class into the interface organization diagnostic data. The interface organization diagnostic data is used to support subsequent comparisons, storing not only information about each interface method itself but also information about other interface methods under the same interface control class, enabling duplication, deviation, and inconsistency to be identified within the same data scope.

[0075] Duplicate interface objects are identified through business objects, business behaviors, business domain markers, and capability type markers. A business object represents the data object that the interface method targets; a business behavior represents the operation performed by the interface method; a business domain marker indicates the business scope to which the interface method belongs; and a capability type marker indicates the category of capabilities provided by the interface method. During identification, interface methods with the same business behavior and consistent capability type markers under the same business object can be filtered, and then the interface access path, request object, and return object are read for verification. If multiple interface methods are identical in business object, business behavior, and capability type, these interface methods can be recorded as duplicate interface objects. Duplicate interface objects can store a list of duplicate interface methods, the corresponding interface controller class, the interface access path, and object structure information.

[0076] Multi-behavior interface objects are identified through business behaviors. If an interface method is associated with multiple independent business behaviors, it indicates that the interface method handles multiple processing units. During identification, the set of business behaviors under the same interface method in the interface organization diagnostic data can be read to determine whether there are independent data objects, independent state changes, or independent return results among the business behaviors. If an interface method contains multiple independent business behaviors such as creating objects, modifying states, and querying results, it can be recorded as a multi-behavior interface object. A multi-behavior interface object can store the interface method identifier, the set of business behaviors, the corresponding triggering scenarios, and the impact of the results.

[0077] Naming deviation objects are identified through method names and business behaviors. Method names can be broken down into action components and object components, while business behaviors can be broken down into operation types and operation objects. During matching, action components are compared with operation types, and object components are compared with operation objects. If the method name indicates a query, but the business behavior indicates a write or status change, or if the object in the method name does not match the business object, the corresponding interface method can be recorded as a naming deviation object. A naming deviation object can store the method name, business behavior, deviation location, and interface access path.

[0078] Object expression difference objects are identified through business scenario markers, the business meaning of input fields, the meaning of returned content, the request object, and the return object. Under the same business scenario marker, different interface methods may use different field names to express the same business meaning. During identification, a correspondence can be established between the field names in the request object and the return object and the business meaning of the input fields and the meaning of the returned content, and then the field names can be compared within the same business scenario. If the same business meaning corresponds to multiple field names, or the same field name corresponds to different business meanings, the corresponding interface method can be recorded as an object expression difference object. The object expression difference object can store the field name, business meaning, the request object or return object to which it belongs, and the interface method in which it belongs.

[0079] Aggregated deviation objects are identified through package path, business domain marker, and business scenario marker. The package path indicates the module location of the interface control class, the business domain marker indicates the business scope of the interface method, and the business scenario marker indicates the applicable scenario of the interface method. During comparison, the module affiliation corresponding to the package path can be read, and then compared with the business affiliation corresponding to the business domain marker and the scenario affiliation corresponding to the business scenario marker. If the interface control class is located in a module directory, but the business domain marker or business scenario marker of its internal interface method points to another business scope, the interface control class can be recorded as an aggregated deviation object. The aggregated deviation object can store the interface control class, package path, business domain marker, business scenario marker, and deviation type.

[0080] The set of objects to be adjusted consists of duplicate interface objects, multi-behavior interface objects, naming deviation objects, object expression difference objects, and aggregation deviation objects. During writing, indexes can be created according to object type, interface control class, and interface method, allowing for the retention of multiple object tags when the same interface method involves multiple issues. The adjustment impact record is determined by the interface access paths, request objects, return objects, exception flags, and associated call files involved in the set of objects to be adjusted. Interface access paths are used to determine the scope of affected interfaces, request objects and return objects are used to determine the scope of affected data structures, exception flags are used to determine the scope of exception response impact, and associated call files are used to determine the scope of affected calls. After the scope of affected interfaces and the scope of affected calls are written into the adjustment impact record, subsequent structural refactoring can be processed based on these clearly defined scopes.

[0081] This embodiment forms interface organization diagnostic data by profiling interface logic semantic features, structured tagging data, structured explanatory text, and interface description data. This allows for a unified comparison of the semantics, tagging, description, and code structure of interface methods within the same interface control class. By generating duplicate interface objects, multi-behavior interface objects, naming deviation objects, object expression difference objects, and aggregation deviation objects, the set of objects to be adjusted can have a clear source of problems and object types. By determining the scope of affected interfaces and affected calls based on interface access paths, request objects, return objects, exception flags, and associated call files, the adjustment impact record can cover the interface entry point, object structure, exception response, and call file scope, thereby reducing the probability of missing affected interface methods and associated call files during subsequent structural adjustments.

[0082] In one embodiment, step S60 above includes: S601, the set of objects to be adjusted is classified into types to obtain duplicate interface objects, multi-behavior interface objects, naming deviation objects, object expression difference objects and aggregation deviation objects, and business behaviors are read from the interface logical semantic feature profile and business behavior boundaries are determined based on the business behaviors. S602, read the business domain marker, business scenario marker and exception marker from the structured marker data, read the business meaning of the input field and the meaning of the returned content from the structured explanation text, read the interface access path, request object, return object and associated call file from the interface description data corresponding to the interface code object set, and read the affected interface range and affected call range from the adjustment impact record; S603, the duplicate interface object, the multi-behavior interface object, the naming deviation object, the object expression difference object, the aggregation deviation object, the business behavior boundary, the business domain marker, the business scenario marker, the exception marker, the business meaning of the input field, the meaning of the returned content, the interface access path, the request object, the returned object, the associated call file, the affected interface range, and the affected call range are written into the structure reconstruction processing data; S604, based on the structure reconstruction processing data, the interface methods corresponding to the duplicate interface objects are merged according to business behavior, request object and return object. Interface methods with the same business behavior, consistent request object field composition and consistent return object field composition are merged to generate interface merge data. S605, based on the structural reconstruction processing data, the interface methods corresponding to the multi-behavior interface objects are split according to the business behavior boundaries, and the interface methods before splitting, the interface methods after splitting, and the interface access paths after splitting are written into the interface splitting data. S606, based on the structure reconstruction processing data, adjust the method name of the interface method corresponding to the naming deviation object according to the business behavior, and unify the object expression of the request object and return object corresponding to the object expression difference object based on the business meaning of the input field and the meaning of the returned content, and generate naming expression adjustment data; S607, Based on the structural reconstruction processing data, the interface control class corresponding to the aggregated deviation object is reconstructed according to the business domain label and the business scenario label to generate interface control class aggregated reconstruction data; S608, based on the interface merging data, the interface splitting data, the naming expression adjustment data, the interface control class aggregation reconstruction data, and the adjustment impact record, generate an interface structure adjustment result, and when the interface access path, request object, return object, or exception flag changes, generate compatibility mapping information between the content before and after adjustment, and write the compatibility mapping information into the interface structure adjustment result; S609, read the changed file range and code version identifier from the code change record, determine the interface method to be updated based on the changed file range, update the interface semantic basis set, the interface logical semantic feature profile, the structured tag data, the structured explanation text, and the interface structure adjustment result based on the interface method to be updated, and write the updated interface structure adjustment result and code version identifier into the interface processing update data. When generating compatibility mapping information, write the compatibility mapping information into the interface processing update data.

[0083] In this embodiment, the set of objects to be adjusted is divided into duplicate interface objects, multi-behavior interface objects, naming deviation objects, object expression difference objects, and aggregation deviation objects according to object type. The type classification can be based on the problem type, interface method identifier, interface control class identifier, and diagnostic source identifier recorded in the set of objects to be adjusted. Duplicate interface objects are used to record interface methods with the same business behavior and similar object structure; multi-behavior interface objects are used to record cases where one interface method carries multiple independent business behaviors; naming deviation objects are used to record interface methods where the method name is inconsistent with the business behavior; object expression difference objects are used to record interface methods where the fields of the request object or return object are inconsistent; and aggregation deviation objects are used to record cases where the package path of the interface control class is inconsistent with the business domain marker or business scenario marker. Business behaviors are read from the interface logical semantic feature profile. The boundaries of business behaviors can be determined based on the operation object, state change location, return result, and exception branch of the business behavior, enabling the differentiation of independent processing units when splitting interface methods.

[0084] Structured tagging data provides business domain tags, business scenario tags, and exception tags. Business domain tags determine the business affiliation of the restructured interface control class; business scenario tags determine the scenario affiliation of the interface method after restructuring; and exception tags determine whether structural changes affect exception responses. Structured explanatory text provides the business meaning of input fields and the meaning of returned content, used to unify the field expressions in request and return objects. The interface description data corresponding to the interface code object collection provides the interface access path, request object, return object, and associated calling file. Adjustment impact records provide the scope of affected interfaces and the scope of affected calls. After the above content is written into the structure refactoring processing data, merging, splitting, naming adjustments, object expression unification, and interface control class aggregation refactoring can all be judged using the same data source.

[0085] Duplicate interface methods are merged based on their business behavior, request object, and return object. Identical business behavior confirms that multiple interface methods perform the same business operation; consistent request object field composition confirms that the external input structure can be received by the same interface method; and consistent return object field composition confirms that the output structure can be returned by the same interface method. During merging, interface methods with more stable access paths or smaller affected call scopes are retained, while other duplicate interface methods are recorded in the interface merging data. The interface merging data can save the retained interface methods, merged interface methods, request object field composition, return object field composition, and the scope of affected interfaces.

[0086] The interface methods corresponding to multi-behavior interface objects are split according to business behavior boundaries. These boundaries are determined by the input fields, state change locations, return results, and exception branches corresponding to different business behaviors. During splitting, a split interface method can be generated for each independent business behavior, and a split interface access path can be assigned to each method. Interface splitting data can record the interface method before splitting, the interface method after splitting, the split interface access path, the range of input fields, the range of return fields, and exception flags, facilitating subsequent generation of interface structure adjustment results.

[0087] The interface methods corresponding to the naming deviation objects have their names adjusted according to business behaviors. During adjustment, the operation type and operation object can be read from the business behavior, and the method name can be adjusted to reflect the operation type and operation object. The request and return objects corresponding to the object expression difference objects are unified based on the business meaning of the input fields and the meaning of the returned content. During unification, multiple field names corresponding to the same business meaning can be mapped to the same field name, or fields with different meanings but the same name can be split into different field names. The naming expression adjustment data can save the method name before adjustment, the method name after adjustment, the field names before adjustment, the field names after adjustment, the changed content of the request object, and the changed content of the return object.

[0088] The interface control class corresponding to the aggregated deviation object is restructured according to the aggregation relationship based on the business domain tag and the business scenario tag. The business domain tag is used to determine the business module to which the interface control class should be assigned, and the business scenario tag is used to determine the organizational position of the interface method in the interface control class. If the package path of the interface control class is inconsistent with the business domain tag, an interface control class migration record can be generated; if the same interface control class contains multiple interface methods unrelated to business scenarios, an interface method migration record can be generated. The interface control class aggregation and restructuring data can save the interface control class before adjustment, the interface control class after adjustment, the interface method migration content, the package path change content, and the affected call scope.

[0089] The interface structure adjustment results are generated from interface merging data, interface splitting data, naming expression adjustment data, interface control class aggregation and reconstruction data, and adjustment impact records. When the interface access path, request object, return object, or exception flag changes, compatibility mapping information between the content before and after the adjustment is generated. The compatibility mapping information can record the correspondence between the old and new interface access paths, the correspondence between the old and new request fields, the correspondence between the old and new return fields, and the correspondence between the old and new exception flags. The scope of changed files in the code change record is used to determine the interface method to be updated, and the code version identifier is used to mark the version to which the interface processing update data belongs. After the interface method to be updated is determined, the interface semantic basis set, interface logical semantic feature profile, structured tag data, structured explanatory text, and interface structure adjustment results are all updated around the interface method to be updated. The updated interface structure adjustment results, code version identifier, and the generated compatibility mapping information are written into the interface processing update data.

[0090] This embodiment categorizes the set of objects to be adjusted by type and writes business behavior boundaries, business domain markers, business scenario markers, exception markers, business meanings of input fields, meanings of returned content, interface access paths, request objects, return objects, associated call files, affected interface scope, and affected call scope into the structural refactoring processing data. This ensures that interface method merging, splitting, naming adjustment, object expression unification, and interface control class aggregation refactoring all have clear data sources. By generating interface structure adjustment results through interface merging data, interface splitting data, naming expression adjustment data, and interface control class aggregation refactoring data, the changes in interface structure can be recorded. By recording the correspondence between the content before and after adjustment through compatibility mapping information, and by determining the interface methods to be updated through code change records, the interface processing update data can synchronously save structural changes, version identifiers, and compatibility relationships, thereby reducing the probability of inconsistencies between interface descriptions, interface objects, and call scopes after structural refactoring.

[0091] In one embodiment, a program interface semantic understanding and structure reconstruction apparatus is provided, which corresponds one-to-one with the program interface semantic understanding and structure reconstruction method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the program interface semantic understanding and structural reconstruction device of the present invention. The program interface semantic understanding and structural reconstruction device includes: an interface code object construction module 10, a call tracing and parsing module 20, a logical semantic profile generation module 30, a tag description generation module 40, an organizational structure diagnosis module 50, and a structural reconstruction update module 60. Detailed descriptions of each functional module are as follows: The interface code object construction module 10 is used to obtain the source code, interface configuration, construction configuration information and code change records of the code program to be processed, identify the interface control class based on the source code, the interface configuration and the construction configuration information, extract the interface description data of the interface control class, and generate an interface code object set based on the interface description data. The interface code object set includes interface methods. Call tracing and parsing module 20 is used to parse the set of interface code objects, trace the code along the call path of the interface method, and generate a set of interface semantic basis. The logical semantic profile generation module 30 is used to perform combined analysis on the input conditions, calling objects, processing behaviors, return results and abnormal branches of the interface method based on the interface semantic basis set, and generate an interface logical semantic feature profile. The tag description generation module 40 is used to generate structured tag data based on the interface logical semantic feature profile, and generate structured explanation text corresponding to the interface method based on the structured tag data and the interface semantic basis set; Organizational structure diagnosis module 50 is used to perform parsability diagnosis on the interface organizational structure of the interface control class based on the interface logical semantic feature profile, the structured tag data and the structured explanatory text, and generate a set of objects to be adjusted and an adjustment impact record. The structure refactoring and updating module 60 is used to refactor the interface method and the interface control class based on the set of objects to be adjusted and the adjustment impact record, generate interface structure adjustment results, and generate interface processing update data based on the interface structure adjustment results and the code change record.

[0092] In one embodiment, the interface code object construction module 10 is specifically used for: The system obtains the source code, interface configuration, build configuration information, and code change records of the program to be processed. It parses the build configuration information to determine the source code path and project module division information, parses the interface configuration to determine the interface access declaration flag, parses the code change records to determine the scope of changed files and code version identifier, and generates a project parsing index based on the source code path, the project module division information, the interface access declaration flag, the scope of changed files, and the code version identifier. Based on the source code path, project module division information, and change file scope in the project parsing index, the source code file to be parsed is loaded from the source code, and based on the interface access declaration mark in the project parsing index, class files containing interface access declaration marks are selected from the source code file to be parsed to form a set of interface candidate classes; The class files in the candidate interface class set are parsed for class declarations and method declarations, class-level access paths and method-level access paths are identified, class files containing interface access declaration tags and having method-level access paths are identified as interface control classes, and methods in the interface control classes that have method-level access paths are identified as interface methods. The package path is extracted from the interface control class, and the request method, method name, method parameters, request object, return object, exception declaration, and permission annotation are extracted from the interface method. An interface access path is generated based on the package path, the class-level access path, and the method-level access path. The package path, the interface access path, the request method, the method name, the method parameters, the request object, the return object, the exception declaration, and the permission annotation are written into the interface description data. Based on the calling expression in the method body of the interface method, identify the associated calling file that has a calling relationship with the interface method, and write the associated calling file into the interface description data; Based on the code version identifier in the project parsing index, the interface control class, the interface method, and the interface description data are bound together to generate a collection of interface code objects.

[0093] In one embodiment, the tracing and parsing module 20 is invoked, specifically for: Read the interface methods from the set of interface code objects, locate the source code fragments corresponding to the interface methods, and form an interface method parsing object; The interface method parsing object is parsed using an abstract syntax tree, extracting method declaration nodes, annotation nodes, parameter nodes, return nodes, exception nodes, and method body nodes, and recording the source code location corresponding to each node to generate an interface method node set; Extract the calling expression from the method body node in the interface method node set, and generate the calling path of the interface method based on the called object name, called method name and calling parameters in the calling expression; Locate the called code segments corresponding to the business processing class and data access class according to the call path of the interface method, identify the associated call file where the called code segment is located, record the source code location corresponding to the called code segment, and generate a set of traced code segments; Extract method name semantics, parameter field semantics, return field semantics, condition judgment information, exception declaration, exception return information, exception triggering location and permission restriction information from the method declaration node, annotation node, parameter node, return node, exception node and method body node in the interface method node set; and extract the calling expression, called object name, called method name, returned object information, state change information and data read or write direction from the tracing code fragment set to generate code semantic elements; Based on the semantic category of the code semantic elements, the basis type is determined, and the code semantic elements, the source source code location, the interface method, the associated calling file, and the basis type are bound to form semantic basis items. The semantic basis items are then summarized according to the interface method to generate an interface semantic basis set.

[0094] In one embodiment, the logical semantic profile generation module 30 is specifically used for: Semantic basis items are extracted from the interface semantic basis set according to the interface method, and semantic basis items belonging to the same interface method are combined into a method semantic basis subset; The semantics of parameter fields, permission restriction information, and condition judgment information are read from the semantic subset of the method to generate the input conditions of the interface method; The calling expression, associated calling file, called object name, and called method name are read from the semantic subset of the method to generate the calling object of the interface method; The method name semantics, state change information, and data read or write direction are read from the subset of the method semantics to generate the processing behavior of the interface method; The return field semantics, return object information, and state change information are read from the subset of the method semantics to generate the return result of the interface method; The exception triggering location, exception declaration, and exception return information are read from the subset of the method semantic basis to generate the exception branch of the interface method; Based on the input conditions, the calling object, the processing behavior, the return result, and the exception branch, the business object, business behavior, triggering scenario, execution restrictions, and result impact corresponding to the interface method are determined, and an interface logic semantic feature profile containing the business object, the business behavior, the triggering scenario, the execution restrictions, and the result impact is generated.

[0095] In one embodiment, the labeling description generation module 40 is specifically used for: Read business objects, business behaviors, triggering scenarios, execution restrictions, and result impacts from the interface logical semantic feature profile to form a set of profile marker elements; Based on the set of profile tagging elements, business domain tags, business scenario tags, capability type tags, permission tags, and data flow tags are generated. The exception triggering location, exception declaration, and exception return information are read from the set of interface semantic basis. An exception tag is generated based on the exception triggering location, the exception declaration, and the exception return information. The business domain tags, business scenario tags, capability type tags, permission tags, data flow tags, and exception tags are combined into structured tagging data. Semantic basis items are extracted from the interface semantic basis set according to the interface method, and a tag basis binding relationship is established between the structured tag data and the semantic basis items based on the basis type and source code location in the semantic basis items. Based on the structured marked data generation interface, the following can be interpreted as candidate fragments: processing purpose, applicable scenarios, request preconditions, business meaning of input fields, processing restrictions, state change results, meaning of returned content, exception triggering conditions, and permission requirements. Based on the interface semantic basis set, the candidate explanatory fragments are matched according to the basis. The candidate explanatory fragments that match the semantic basis items are written into the explanatory description body, and the candidate explanatory fragments that do not match the semantic basis items are written into the fragment set to be confirmed. The explanatory body, the set of fragments to be confirmed, and the marker are combined according to their binding relationship to generate the structured explanatory text corresponding to the interface method.

[0096] In one embodiment, the tissue structure diagnostic module 50 is specifically used for: According to the interface control class, the interface logical semantic feature profile, the structured tag data, the structured explanatory text, the interface methods in the interface code object set, and the method name, interface access path, request object, return object, package path and associated call file in the interface description data corresponding to the interface code object set are aggregated to form interface organization diagnostic data; Read business objects, business behaviors, business domain tags, and capability type tags from the interface organization diagnostic data, identify interface methods with the same business behaviors and consistent capability type tags under the same business object, and generate duplicate interface objects. Read business behaviors from the diagnostic data of the interface organization, identify interface methods that correspond to multiple independent business behaviors for the same interface method, and generate multi-behavior interface objects; Read the method name and business behavior from the diagnostic data of the interface organization, match the action component and object component in the method name with the operation type and operation object in the business behavior respectively, and generate a naming deviation object; Read the business scenario marker, input field business meaning, return content meaning, request object and return object from the interface organization diagnostic data. Within the scope of interface methods corresponding to the same business scenario marker, identify interface methods with different field names corresponding to the same business meaning and generate object expression difference objects. The package path, business domain tag, and business scenario tag are read from the interface organization diagnostic data. The module affiliation corresponding to the package path is compared with the business affiliation corresponding to the business domain tag and the scenario affiliation corresponding to the business scenario tag, respectively, to generate an aggregated deviation object. The repeated interface object, the multi-behavior interface object, the naming deviation object, the object expression difference object, and the aggregation deviation object are combined into a set of objects to be adjusted. The scope of affected interfaces and the scope of affected calls are determined based on the interface access path, request object, return object, exception flag, and associated call file involved in the set of objects to be adjusted. The scope of affected interfaces and the scope of affected calls are written into the adjustment impact record.

[0097] In one embodiment, the structure reconstruction and update module 60 is specifically used for: The set of objects to be adjusted is classified into types such as duplicate interface objects, multi-behavior interface objects, naming deviation objects, object expression difference objects, and aggregation deviation objects. Business behaviors are read from the interface logical semantic feature profile and business behavior boundaries are determined based on the business behaviors. Read business domain tags, business scenario tags, and exception tags from the structured tag data; read the business meaning of input fields and the meaning of returned content from the structured explanatory text; read the interface access path, request object, return object, and associated call file from the interface description data corresponding to the interface code object set; and read the affected interface range and affected call range from the adjustment impact record. Write the duplicate interface object, the multi-behavior interface object, the naming deviation object, the object expression difference object, the aggregation deviation object, the business behavior boundary, the business domain marker, the business scenario marker, the exception marker, the business meaning of the input field, the meaning of the returned content, the interface access path, the request object, the returned object, the associated call file, the affected interface range, and the affected call range into the structure reconstruction processing data; Based on the structural reconstruction processing data, the interface methods corresponding to the duplicate interface objects are merged according to business behavior, request object and return object. Interface methods with the same business behavior, consistent request object field composition and consistent return object field composition are merged to generate interface merge data. Based on the structural reconstruction processing data, the interface methods corresponding to the multi-behavior interface objects are split according to the business behavior boundaries, and the interface methods before splitting, the interface methods after splitting, and the interface access paths after splitting are written into the interface splitting data. Based on the structural reconstruction processing data, the method names of the interface methods corresponding to the naming deviation objects are adjusted according to the business behavior. Based on the business meaning of the input fields and the meaning of the returned content, the object expression of the request objects and return objects corresponding to the object expression difference objects is unified, and naming expression adjustment data is generated. Based on the structural reconstruction processing data, the interface control class corresponding to the aggregated deviation object is reconstructed according to the business domain label and the business scenario label to generate interface control class aggregated reconstruction data. Based on the interface merging data, the interface splitting data, the naming expression adjustment data, the interface control class aggregation reconstruction data, and the adjustment impact record, an interface structure adjustment result is generated. When the interface access path, request object, return object, or exception flag changes, compatibility mapping information between the content before and after adjustment is generated, and the compatibility mapping information is written into the interface structure adjustment result. The scope of changed files and the code version identifier are read from the code change record. Based on the scope of changed files, the interface method to be updated is determined. Based on the interface method to be updated, the interface semantic basis set, the interface logical semantic feature profile, the structured tag data, the structured explanation text, and the interface structure adjustment result are updated. The updated interface structure adjustment result and the code version identifier are written into the interface processing update data. When generating compatibility mapping information, the compatibility mapping information is written into the interface processing update data.

[0098] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a program interface semantic understanding and structural reconstruction method on the server side.

[0099] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements client-side functions or steps of a program interface semantic understanding and structural reconstruction method.

[0100] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain the source code, interface configuration, build configuration information, and code change records of the code program to be processed; identify the interface control class based on the source code, the interface configuration, and the build configuration information; extract the interface description data of the interface control class; and generate an interface code object set based on the interface description data, wherein the interface code object set includes interface methods. The interface code object set is parsed, and code tracing is performed along the call path of the interface method to generate a set of interface semantic basis. Based on the aforementioned set of interface semantic criteria, the input conditions, calling objects, processing behaviors, return results, and exception branches of the interface methods are combined and analyzed to generate an interface logical semantic feature profile. Based on the interface logical semantic feature profile, structured tag data is generated, and based on the structured tag data and the interface semantic basis set, structured explanation text corresponding to the interface method is generated. Based on the interface logical semantic feature profile, the structured tag data, and the structured explanatory text, the parsability of the interface organization structure of the interface control class is diagnosed, and a set of objects to be adjusted and an adjustment impact record are generated. Based on the set of objects to be adjusted and the adjustment impact record, the interface method and the interface control class are restructured to generate interface structure adjustment results, and interface processing update data is generated based on the interface structure adjustment results and the code change record.

[0101] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Obtain the source code, interface configuration, build configuration information, and code change records of the code program to be processed; identify the interface control class based on the source code, the interface configuration, and the build configuration information; extract the interface description data of the interface control class; and generate an interface code object set based on the interface description data, wherein the interface code object set includes interface methods. The interface code object set is parsed, and code tracing is performed along the call path of the interface method to generate a set of interface semantic basis. Based on the aforementioned set of interface semantic criteria, the input conditions, calling objects, processing behaviors, return results, and exception branches of the interface methods are combined and analyzed to generate an interface logical semantic feature profile. Based on the interface logical semantic feature profile, structured tag data is generated, and based on the structured tag data and the interface semantic basis set, structured explanation text corresponding to the interface method is generated. Based on the interface logical semantic feature profile, the structured tag data, and the structured explanatory text, the parsability of the interface organization structure of the interface control class is diagnosed, and a set of objects to be adjusted and an adjustment impact record are generated. Based on the set of objects to be adjusted and the adjustment impact record, the interface method and the interface control class are restructured to generate interface structure adjustment results, and interface processing update data is generated based on the interface structure adjustment results and the code change record.

[0102] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0103] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0104] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0105] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0106] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for semantic understanding and structural reconstruction of a program interface, characterized in that, Includes the following steps: Obtain the source code, interface configuration, build configuration information, and code change records of the code program to be processed; identify the interface control class based on the source code, the interface configuration, and the build configuration information; extract the interface description data of the interface control class; and generate an interface code object set based on the interface description data, wherein the interface code object set includes interface methods. The interface code object set is parsed, and code tracing is performed along the call path of the interface method to generate a set of interface semantic basis. Based on the aforementioned set of interface semantic criteria, the input conditions, calling objects, processing behaviors, return results, and exception branches of the interface methods are combined and analyzed to generate an interface logical semantic feature profile. Based on the interface logical semantic feature profile, structured tag data is generated, and based on the structured tag data and the interface semantic basis set, structured explanation text corresponding to the interface method is generated. Based on the interface logical semantic feature profile, the structured tag data, and the structured explanatory text, the parsability of the interface organization structure of the interface control class is diagnosed, and a set of objects to be adjusted and an adjustment impact record are generated. Based on the set of objects to be adjusted and the adjustment impact record, the interface method and the interface control class are restructured to generate interface structure adjustment results, and interface processing update data is generated based on the interface structure adjustment results and the code change record.

2. The method for semantic understanding and structural reconstruction of program interfaces as described in claim 1, characterized in that, The code obtains the source code, interface configuration, build configuration information, and code change records of the program to be processed. Based on the source code, interface configuration, and build configuration information, it identifies the interface control class, extracts the interface description data of the interface control class, and generates a set of interface code objects based on the interface description data. The set of interface code objects includes interface methods, including: The system obtains the source code, interface configuration, build configuration information, and code change records of the program to be processed. It parses the build configuration information to determine the source code path and project module division information, parses the interface configuration to determine the interface access declaration flag, parses the code change records to determine the scope of changed files and code version identifier, and generates a project parsing index based on the source code path, the project module division information, the interface access declaration flag, the scope of changed files, and the code version identifier. Based on the source code path, project module division information, and change file scope in the project parsing index, the source code file to be parsed is loaded from the source code, and based on the interface access declaration mark in the project parsing index, class files containing interface access declaration marks are selected from the source code file to be parsed to form a set of interface candidate classes; The class files in the candidate interface class set are parsed for class declarations and method declarations, class-level access paths and method-level access paths are identified, class files containing interface access declaration tags and having method-level access paths are identified as interface control classes, and methods in the interface control classes that have method-level access paths are identified as interface methods. The package path is extracted from the interface control class, and the request method, method name, method parameters, request object, return object, exception declaration, and permission annotation are extracted from the interface method. An interface access path is generated based on the package path, the class-level access path, and the method-level access path. The package path, the interface access path, the request method, the method name, the method parameters, the request object, the return object, the exception declaration, and the permission annotation are written into the interface description data. Based on the calling expression in the method body of the interface method, identify the associated calling file that has a calling relationship with the interface method, and write the associated calling file into the interface description data; Based on the code version identifier in the project parsing index, the interface control class, the interface method, and the interface description data are bound together to generate a collection of interface code objects.

3. The method for semantic understanding and structural reconstruction of program interfaces as described in claim 1, characterized in that, The interface code object set is parsed, and code tracing is performed along the call path of the interface methods to generate a set of interface semantic basis, including: Read the interface methods from the set of interface code objects, locate the source code fragments corresponding to the interface methods, and form an interface method parsing object; The interface method parsing object is parsed using an abstract syntax tree, extracting method declaration nodes, annotation nodes, parameter nodes, return nodes, exception nodes, and method body nodes, and recording the source code location corresponding to each node to generate an interface method node set; Extract the calling expression from the method body node in the interface method node set, and generate the calling path of the interface method based on the called object name, called method name and calling parameters in the calling expression; Locate the called code segments corresponding to the business processing class and data access class according to the call path of the interface method, identify the associated call file where the called code segment is located, record the source code location corresponding to the called code segment, and generate a set of traced code segments; Extract method name semantics, parameter field semantics, return field semantics, condition judgment information, exception declaration, exception return information, exception triggering location and permission restriction information from the method declaration node, annotation node, parameter node, return node, exception node and method body node in the interface method node set; and extract the calling expression, called object name, called method name, returned object information, state change information and data read or write direction from the tracing code fragment set to generate code semantic elements; The basis type is determined based on the semantic category of the code semantic elements. The code semantic elements, the source code location, the interface method, the associated calling file, and the basis type are bound together to form semantic basis items. The semantic basis items are then summarized according to the interface method to generate an interface semantic basis set.

4. The method for semantic understanding and structural reconstruction of program interfaces as described in claim 1, characterized in that, Based on the aforementioned set of interface semantic criteria, the input conditions, calling objects, processing behaviors, return results, and exception branches of the interface method are combined and analyzed to generate an interface logical semantic feature profile, including: Semantic basis items are extracted from the interface semantic basis set according to the interface method, and semantic basis items belonging to the same interface method are combined into a method semantic basis subset; The semantics of parameter fields, permission restriction information, and condition judgment information are read from the semantic subset of the method to generate the input conditions of the interface method; The calling expression, associated calling file, called object name, and called method name are read from the semantic subset of the method to generate the calling object of the interface method; The method name semantics, state change information, and data read or write direction are read from the subset of the method semantics to generate the processing behavior of the interface method; The return field semantics, return object information, and state change information are read from the subset of the method semantics to generate the return result of the interface method; The exception triggering location, exception declaration, and exception return information are read from the subset of the method semantic basis to generate the exception branch of the interface method; Based on the input conditions, the calling object, the processing behavior, the return result, and the exception branch, the business object, business behavior, triggering scenario, execution restrictions, and result impact corresponding to the interface method are determined, and an interface logic semantic feature profile containing the business object, the business behavior, the triggering scenario, the execution restrictions, and the result impact is generated.

5. The method for semantic understanding and structural reconstruction of program interfaces as described in claim 1, characterized in that, Based on the interface logical semantic feature profile, structured marked data is generated, and based on the structured marked data and the interface semantic basis set, structured explanatory text corresponding to the interface method is generated, including: Read business objects, business behaviors, triggering scenarios, execution restrictions, and result impacts from the interface logical semantic feature profile to form a set of profile marker elements; Based on the set of profile tagging elements, business domain tags, business scenario tags, capability type tags, permission tags, and data flow tags are generated. The exception triggering location, exception declaration, and exception return information are read from the set of interface semantic basis. An exception tag is generated based on the exception triggering location, the exception declaration, and the exception return information. The business domain tags, business scenario tags, capability type tags, permission tags, data flow tags, and exception tags are combined into structured tagging data. Semantic basis items are extracted from the interface semantic basis set according to the interface method, and a tag basis binding relationship is established between the structured tag data and the semantic basis items based on the basis type and source code location in the semantic basis items. Based on the structured marked data generation interface, the following can be interpreted as candidate fragments: processing purpose, applicable scenarios, request preconditions, business meaning of input fields, processing restrictions, state change results, meaning of returned content, exception triggering conditions, and permission requirements. Based on the interface semantic basis set, the candidate explanatory fragments are matched according to the basis. The candidate explanatory fragments that match the semantic basis items are written into the explanatory description body, and the candidate explanatory fragments that do not match the semantic basis items are written into the fragment set to be confirmed. The explanatory body, the set of fragments to be confirmed, and the marker are combined according to their binding relationship to generate the structured explanatory text corresponding to the interface method.

6. The method for semantic understanding and structural reconstruction of program interfaces as described in claim 1, characterized in that, Based on the interface logical semantic feature profile, the structured tagging data, and the structured explanatory text, a resolvability diagnosis is performed on the interface organization structure of the interface control class, generating a set of objects to be adjusted and a record of the impact of adjustments, including: According to the interface control class, the interface logical semantic feature profile, the structured tag data, the structured explanatory text, the interface methods in the interface code object set, and the method name, interface access path, request object, return object, package path and associated call file in the interface description data corresponding to the interface code object set are aggregated to form interface organization diagnostic data; Read business objects, business behaviors, business domain tags, and capability type tags from the interface organization diagnostic data, identify interface methods with the same business behaviors and consistent capability type tags under the same business object, and generate duplicate interface objects. Read business behaviors from the diagnostic data of the interface organization, identify interface methods that correspond to multiple independent business behaviors for the same interface method, and generate multi-behavior interface objects; Read the method name and business behavior from the diagnostic data of the interface organization, match the action component and object component in the method name with the operation type and operation object in the business behavior respectively, and generate a naming deviation object; Read the business scenario marker, input field business meaning, return content meaning, request object and return object from the interface organization diagnostic data. Within the scope of interface methods corresponding to the same business scenario marker, identify interface methods with different field names corresponding to the same business meaning and generate object expression difference objects. The package path, business domain tag, and business scenario tag are read from the interface organization diagnostic data. The module affiliation corresponding to the package path is compared with the business affiliation corresponding to the business domain tag and the scenario affiliation corresponding to the business scenario tag, respectively, to generate an aggregated deviation object. The repeated interface object, the multi-behavior interface object, the naming deviation object, the object expression difference object, and the aggregation deviation object are combined into a set of objects to be adjusted. The scope of affected interfaces and the scope of affected calls are determined based on the interface access path, request object, return object, exception flag, and associated call file involved in the set of objects to be adjusted. The scope of affected interfaces and the scope of affected calls are written into the adjustment impact record.

7. The method for semantic understanding and structural reconstruction of program interfaces as described in claim 1, characterized in that, Based on the set of objects to be adjusted and the adjustment impact record, the interface method and the interface control class are structurally restructured to generate interface structure adjustment results. Based on the interface structure adjustment results and the code change record, interface processing update data is generated, including: The set of objects to be adjusted is classified into types such as duplicate interface objects, multi-behavior interface objects, naming deviation objects, object expression difference objects, and aggregation deviation objects. Business behaviors are read from the interface logical semantic feature profile and business behavior boundaries are determined based on the business behaviors. Read business domain tags, business scenario tags, and exception tags from the structured tag data; read the business meaning of input fields and the meaning of returned content from the structured explanatory text; read the interface access path, request object, return object, and associated call file from the interface description data corresponding to the interface code object set; and read the affected interface range and affected call range from the adjustment impact record. Write the duplicate interface object, the multi-behavior interface object, the naming deviation object, the object expression difference object, the aggregation deviation object, the business behavior boundary, the business domain marker, the business scenario marker, the exception marker, the business meaning of the input field, the meaning of the returned content, the interface access path, the request object, the returned object, the associated call file, the affected interface range, and the affected call range into the structure reconstruction processing data; Based on the structural reconstruction processing data, the interface methods corresponding to the duplicate interface objects are merged according to business behavior, request object and return object. Interface methods with the same business behavior, consistent request object field composition and consistent return object field composition are merged to generate interface merge data. Based on the structural reconstruction processing data, the interface methods corresponding to the multi-behavior interface objects are split according to the business behavior boundaries, and the interface methods before splitting, the interface methods after splitting, and the interface access paths after splitting are written into the interface splitting data. Based on the structural reconstruction processing data, the method names of the interface methods corresponding to the naming deviation objects are adjusted according to the business behavior. Based on the business meaning of the input fields and the meaning of the returned content, the object expression of the request objects and return objects corresponding to the object expression difference objects is unified, and naming expression adjustment data is generated. Based on the structural reconstruction processing data, the interface control class corresponding to the aggregated deviation object is reconstructed according to the business domain label and the business scenario label to generate interface control class aggregated reconstruction data. Based on the interface merging data, the interface splitting data, the naming expression adjustment data, the interface control class aggregation reconstruction data, and the adjustment impact record, an interface structure adjustment result is generated. When the interface access path, request object, return object, or exception flag changes, compatibility mapping information between the content before and after adjustment is generated, and the compatibility mapping information is written into the interface structure adjustment result. The scope of changed files and the code version identifier are read from the code change record. Based on the scope of changed files, the interface method to be updated is determined. Based on the interface method to be updated, the interface semantic basis set, the interface logical semantic feature profile, the structured tag data, the structured explanation text, and the interface structure adjustment result are updated. The updated interface structure adjustment result and the code version identifier are written into the interface processing update data. When generating compatibility mapping information, the compatibility mapping information is written into the interface processing update data.

8. A device for semantic understanding and structural reconstruction of a program interface, characterized in that, The program interface semantic understanding and structural reconstruction device includes: The interface code object construction module is used to obtain the source code, interface configuration, construction configuration information and code change records of the code program to be processed, identify the interface control class based on the source code, the interface configuration and the construction configuration information, extract the interface description data of the interface control class, and generate an interface code object set based on the interface description data. The interface code object set includes interface methods. The call tracing and parsing module is used to parse the set of interface code objects, trace the code along the call path of the interface methods, and generate a set of interface semantic basis. The logical semantic profile generation module is used to perform combined analysis on the input conditions, calling objects, processing behaviors, return results and abnormal branches of the interface method based on the interface semantic basis set, and generate an interface logical semantic feature profile. The tag description generation module is used to generate structured tag data based on the interface logical semantic feature profile, and to generate structured explanatory text corresponding to the interface method based on the structured tag data and the interface semantic basis set. The organizational structure diagnosis module is used to perform parsability diagnosis on the interface organizational structure of the interface control class based on the interface logical semantic feature profile, the structured tag data, and the structured explanatory text, and generate a set of objects to be adjusted and an adjustment impact record. The structure refactoring and update module is used to refactor the interface method and the interface control class based on the set of objects to be adjusted and the adjustment impact record, generate interface structure adjustment results, and generate interface processing update data based on the interface structure adjustment results and the code change record.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a program interface semantic understanding and structural reconstruction program stored in the memory and executable on the processor. When the program interface semantic understanding and structural reconstruction program is executed by the processor, it implements the steps of the program interface semantic understanding and structural reconstruction method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a program interface semantic understanding and structure reconstruction program, which, when executed by a processor, implements the steps of the program interface semantic understanding and structure reconstruction method as described in any one of claims 1-7.

Images