A method and system for automatically generating application interface documentation based on lexical analysis

Abstract

This invention provides a method and system for automatically generating application interface (API) documentation based on lexical analysis, comprising: acquiring source code to be parsed; parsing the source code using lexical analysis to obtain each component element and its corresponding tag type; determining the semantic category of each component element using bootstrap analysis based on the component elements and their corresponding tag types; and generating the corresponding API documentation based on the semantic category of each component element. This application utilizes lexical analysis, which helps reduce the reliance on high-quality specification comments in existing API documentation generation processes; and utilizes bootstrap analysis, which helps improve the practicality and readability of generated API documentation. Therefore, the method of this invention can improve the automation and accuracy of API documentation generation.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a method and system for automatically generating application programming interface (API) documentation based on lexical analysis. Background Technology

[0002] Currently, writing and maintaining Application Programming Interface (API) documentation is a crucial yet time-consuming task in software development. Traditional documentation methods typically rely on manual writing and updating, which is not only inefficient, error-prone, and unreadable, but also prone to inconsistencies between documentation and code implementation. While some tools attempt to automate this process, they often require specific comments or formatting in the source code, limiting their applicability and flexibility, potentially increasing development complexity, and having an intrusive impact on the project. Due to these limitations, developers frequently face the problem of outdated or incomplete documentation, which affects development efficiency and software quality.

[0003] Existing technologies typically employ automated code comment parsing techniques, which automatically generate API documentation by parsing specific comments in the source code. This relies on developers adding standardized comments while writing code. While this method automates documentation generation to some extent, its effectiveness and accuracy are highly dependent on the quality and completeness of the original comments. Furthermore, it is highly intrusive to existing projects, heavily reliant on the documentation generation framework, resulting in significant coupling. This automated code comment parsing technique heavily depends on the quality and completeness of comments added by developers while writing code; if comments are lacking, outdated, or inaccurate, the generated API documentation will be incomplete, erroneous, or difficult to understand. This places high demands on maintaining high-standard and consistent documentation. When the code changes, the related comments also need to be updated accordingly to ensure the accuracy of the documentation, meaning developers need to spend additional time and effort maintaining comments, increasing the overall maintenance cost of the project. This method often relies on a specific documentation generation framework, which limits its versatility and flexibility. If a project needs to switch to another framework or use multiple programming languages, maintaining and generating consistent API documentation becomes even more complex and difficult. Therefore, to generate useful documentation, developers must adhere to strict commenting standards. This not only increases the burden of learning and following these standards, but can also negatively impact code readability, especially when comments are overly verbose or complex. To make automated code comment parsing techniques effective, existing projects may require significant modifications to add or update comments. This intrusiveness can adversely affect project structure and code clarity, particularly in large or legacy projects.

[0004] In summary, existing methods for generating application interface documentation rely on developers adding standardized comments when writing code. If the comments are lacking, outdated, or inaccurate, the generated application interface documentation will be incomplete, erroneous, or difficult to understand, ultimately resulting in low documentation accuracy. Summary of the Invention

[0005] To address the problem that existing application programming interface (API) documentation generation methods rely on developers adding standardized comments during code writing, which can lead to incomplete, erroneous, or difficult-to-understand API documentation due to insufficient, outdated, or inaccurate comments, ultimately resulting in low documentation accuracy, this invention proposes an automatic API documentation generation method based on lexical analysis, comprising:

[0006] Obtain the source code to be parsed;

[0007] The source code is parsed using lexical analysis to obtain each component element in the source code and the tag type corresponding to each component element;

[0008] Based on each component element in the source code and the tag type corresponding to each component element, the semantic category to which each component element belongs is determined using a bootstrap analysis method.

[0009] Based on the semantic category to which each component belongs, an application programming interface (API) document corresponding to the source code is generated.

[0010] Optionally, the step of using lexical analysis to parse the source code to obtain each component element in the source code and the tag type corresponding to each component element includes:

[0011] The source code is parsed using lexical analysis to obtain the constituent elements of the source code;

[0012] Element identification is performed on each component element in the source code to obtain the tag type corresponding to each component element.

[0013] Optionally, the marker types include: spaces, curly braces, parentheses, identifiers, newlines, keywords, data types, and code comments.

[0014] Optionally, the step of determining the semantic category of each component element based on the component elements in the source code and the tag type corresponding to each component element, using a bootstrap analysis method, includes:

[0015] Based on each component element in the source code and the tag type corresponding to each component element, the semantic weight of each component element is obtained by using a preset regular expression and context-aware method.

[0016] Based on the semantic weights of each component element, the semantic category to which each component element belongs is obtained.

[0017] Optionally, the step of obtaining the semantic weight of each component element based on each component element in the source code and the tag type corresponding to each component element, using a preset regular expression and context-aware method, includes:

[0018] Based on each component element in the source code and the tag type corresponding to each component element, a preset regular expression is used to match each component element to obtain the basic weight of each component element.

[0019] Based on each component element in the source code and the tag type corresponding to each component element, a context-aware method is used to perform context awareness on each component element to obtain the context weight of each component element.

[0020] Based on the basic weights and context weights of each component element, the semantic weights corresponding to each component element are obtained.

[0021] Optionally, the semantic weights include: field weights, data type weights, and descriptive annotation weights.

[0022] Optionally, obtaining the semantic category to which each component element belongs based on its semantic weight includes:

[0023] When the field weight in the semantic weight of the constituent element is the highest, the semantic category to which the constituent element belongs is the field category;

[0024] When the data type weight is the highest among the semantic weights of the constituent elements, the semantic category to which the constituent element belongs is the data type category;

[0025] When the descriptive annotation has the highest semantic weight among the constituent elements, the semantic category to which the constituent element belongs is the descriptive annotation category.

[0026] Optionally, generating the application programming interface (API) document corresponding to the source code based on the semantic category to which each component element belongs includes:

[0027] Based on the semantic category to which each component belongs, determine the parameter description information of the source code;

[0028] Based on the parameter description information of the source code, generate the application programming interface (API) document corresponding to the source code.

[0029] Optionally, determining the parameter description information of the source code based on the semantic category to which each component element belongs includes:

[0030] Based on the semantic category to which each component belongs, determine whether there are any components in the source code whose semantic category is descriptive annotation.

[0031] If they exist, the constituent elements are used as parameter description information in the source code, and the constituent elements and the constituent elements in the source code whose semantic category is field are stored in a preset dictionary;

[0032] If it does not exist, based on a preset dictionary, deduce the translation information corresponding to the constituent elements of the semantic category of the field category in the source code, and use the translation information as the parameter description information of the source code.

[0033] Based on the same inventive concept, this invention also provides an automatic generation system for application programming interface (API) documentation based on lexical analysis, comprising:

[0034] The data acquisition module is used to acquire the source code to be parsed.

[0035] The code parsing module is used to parse the source code using lexical analysis methods to obtain each component element in the source code and the tag type corresponding to each component element;

[0036] The semantic analysis module is used to determine the semantic category of each component element based on the component elements in the source code and the tag type corresponding to each component element, using a bootstrap analysis method.

[0037] The document generation module is used to generate application interface documents corresponding to the source code based on the semantic category to which each component element belongs.

[0038] Optionally, the code parsing module includes:

[0039] The lexical analysis submodule is used to parse the source code using lexical analysis methods to obtain the constituent elements in the source code;

[0040] The element identification submodule is used to identify each component element in the source code and obtain the tag type corresponding to each component element.

[0041] Optionally, the tag types in the code parsing module include: spaces, curly braces, parentheses, identifiers, newlines, keywords, data types, and code comments.

[0042] Optionally, the semantic analysis module includes:

[0043] The weight-aware submodule is used to obtain the semantic weight of each component element based on each component element in the source code and the tag type corresponding to each component element, using a preset regular expression and context-aware method.

[0044] The semantic classification submodule is used to obtain the semantic category to which each component belongs based on the semantic weight of each component.

[0045] Optionally, the weight-aware submodule includes:

[0046] The regular expression matching unit is used to match each component element in the source code and the tag type corresponding to each component element using a preset regular expression to obtain the basic weight of each component element.

[0047] The context-aware unit is used to perform context awareness on each component element in the source code and the tag type corresponding to each component element, and obtain the context weight of each component element.

[0048] The semantic weight generation unit is used to obtain the semantic weight corresponding to each component element based on the basic weight of each component element and the context weight.

[0049] Optionally, the semantic weights in the semantic analysis module include: field weights, data type weights, and descriptive annotation weights.

[0050] Optionally, the semantic classification submodule includes:

[0051] The field category determination unit is used to determine the semantic category to which the constituent element belongs when the field weight in the semantic weight of the constituent element is the highest.

[0052] A data category determination unit is used to determine the semantic category to which the constituent element belongs when the data type weight is the highest among the semantic weights of the constituent elements;

[0053] The annotation category determination unit is used to determine the semantic category to which the constituent element belongs when the descriptive annotation weight is the highest among the semantic weights of the constituent elements.

[0054] Optionally, the document generation module includes:

[0055] The parameter information determination submodule is used to determine the parameter description information of the source code based on the semantic category to which each component element belongs;

[0056] The interface documentation generation submodule is used to generate application interface documentation corresponding to the source code based on the parameter description information of the source code.

[0057] Optional, the parameter information determination submodule includes:

[0058] The annotation determination unit is used to determine whether there are any components in the source code whose semantic category is descriptive annotation, based on the semantic category to which each component belongs.

[0059] The annotation parameter determination unit, if there are constituent elements in the source code whose semantic category is descriptive annotation, uses the constituent elements as parameter description information of the source code, and stores the constituent elements and constituent elements in the source code whose semantic category is field into a preset dictionary;

[0060] The annotation parameter derivation unit, if there are no constituent elements in the source code whose semantic category is descriptive annotation, derives the translation information corresponding to the constituent elements in the source code whose semantic category is field based on a preset dictionary, and uses the translation information as the parameter description information of the source code.

[0061] In another aspect, the present invention also provides an electronic device, comprising: at least one processor and a memory; the memory and the processor are connected via a bus;

[0062] The memory is used to store one or more programs;

[0063] When the one or more programs are executed by the at least one processor, the method for automatically generating application programming interface documentation based on lexical analysis as described above is implemented.

[0064] In another aspect, the present invention also provides a computer device readable storage medium having an executable program stored thereon, wherein when the executable program is executed, it implements the aforementioned method for automatically generating application programming interface documentation based on lexical analysis.

[0065] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0066] This invention provides a method and system for automatically generating application interface (API) documentation based on lexical analysis, comprising: acquiring source code to be parsed; parsing the source code using lexical analysis to obtain each component element in the source code and the tag type corresponding to each component element; determining the semantic category to which each component element belongs using a bootstrap analysis method based on the component elements in the source code and the tag type corresponding to each component element; and generating the API documentation corresponding to the source code based on the semantic category to which each component element belongs. This application uses lexical analysis to parse the tag type of the component elements in the source code, which helps reduce the reliance on high-quality normative comments in the existing API documentation generation process; using bootstrap analysis to analyze the semantic category to which each component element belongs helps improve the practicality and readability of the generated API documentation; therefore, the method of this invention helps improve the automation and accuracy of API documentation generation. Attached Figure Description

[0067] Figure 1 A flowchart illustrating an automatic generation method for application programming interface (API) documentation based on lexical analysis provided by this invention;

[0068] Figure 2 A schematic diagram illustrating the framework of an automatic generation method for application programming interface (API) documentation based on lexical analysis, provided for a specific embodiment of the present invention;

[0069] Figure 3 A schematic diagram illustrating the structural composition of an application programming interface (API) documentation automatic generation system based on lexical analysis, provided by this invention;

[0070] Figure 4 This is a schematic diagram of the structure of an electronic device provided by the present invention. Detailed Implementation

[0071] This invention proposes a method and system for automatically generating application programming interface (API) documentation based on lexical analysis. The specific embodiments of this invention will be further described in detail below with reference to the accompanying drawings.

[0072] Example 1:

[0073] This invention provides a method for automatically generating application programming interface (API) documentation based on lexical analysis, the flowchart of which is shown below. Figure 1 Shown, including:

[0074] Step 1: Obtain the source code to be parsed;

[0075] Step 2: Use lexical analysis to parse the source code, and obtain the constituent elements of the source code and the corresponding tag type of each constituent element;

[0076] Step 3: Based on the components in the source code and the tag types corresponding to each component, use the bootstrap analysis method to determine the semantic category to which each component belongs;

[0077] Step 4: Generate the application programming interface (API) document corresponding to the source code based on the semantic category of each component.

[0078] In one implementation, when obtaining the source code to be parsed in step 1 above, it is also necessary to initialize variables and prepare the necessary state management tools for the lexical analysis process. This step ensures that the analysis process starts from a clear starting point and can start from the same initial conditions whenever the analysis is performed, avoiding uncertainty and errors caused by uninitialized states. It also provides a structured way to collect and manage the constituent elements of the source code (the constituent elements can also be called tokens). This provides a structured way to collect and manage the constituent elements of the source code for the subsequent lexical analysis process, making the entire analysis process more orderly and easier to trace and debug.

[0079] In one implementation, step 2 above, which involves parsing the source code using lexical analysis to obtain the constituent elements of the source code and the corresponding tag types for each constituent element, may include:

[0080] Lexical analysis is used to parse the source code and obtain its constituent elements.

[0081] Element identification is performed on each component element in the source code to obtain the corresponding tag type for each component element.

[0082] For example, the above-mentioned tag types can include: spaces, curly braces, parentheses, identifiers, newlines, keywords, data types, and code comments.

[0083] In this implementation, lexical analysis is used to directly analyze each component of the source code, examining the source code character by character. This effectively distinguishes different components of the source code, automatically identifies the structure and semantics of the source code, and extracts key information such as function / method definitions, code comments, parameters, and return types. Based on this key information, a structured Application Programming Interface (API) document is automatically generated. The identification of each component is achieved through precisely defined rules, ensuring the accuracy and reliability of the parsing process. Furthermore, since the entire parsing process does not require adding specific comments or following specific formats in the source code, and supports multiple programming languages ​​and data types, it is beneficial to improve the automatic generation capability of documentation, reduce errors and omissions caused by inaccurate or missing standardized comments, and reduce the difficulties caused by switching to another framework or using multiple programming languages ​​in a project. Therefore, the method of this invention helps to reduce the reliance on manual standardized comments during the API documentation generation process, minimizes the intrusion on the source code, and eliminates the need for project teams to perform large-scale code comment updates, thereby reducing the cost and workload of documentation maintenance. Furthermore, by adopting a lexical analysis method, the parsed source code can be applied to multiple programming languages, without being limited by a specific programming language or documentation generation framework, providing a unified and consistent documentation generation solution for different development environments and enhancing cross-language and framework applicability.

[0084] After successful identification of constituent elements, this invention utilizes a bootstrap analysis method to determine the tag type of these constituent elements for further processing. The bootstrap analysis method is designed to allow the system to dynamically identify fields, data types, and descriptive comments by analyzing the context and specific patterns of the constituent elements. This intelligent approach significantly enhances the ability to handle complex source code structures. Specifically:

[0085] In one implementation, step 3 above, which involves determining the semantic category of each component element based on its constituent elements in the source code and the corresponding tag type, using a bootstrap analysis method, may include:

[0086] Based on the constituent elements in the source code and the tag type corresponding to each constituent element, the semantic weight of each constituent element is obtained by using a preset regular expression and context-aware method.

[0087] Based on the semantic weight of each component, the semantic category to which each component belongs is obtained.

[0088] In this implementation, the process of obtaining the semantic weight of each component element based on the component elements in the source code and the tag type corresponding to each component element, using preset regular expressions and context-aware methods, may include:

[0089] Based on each component element in the source code and the corresponding tag type, a preset regular expression is used to match each component element to obtain the basic weight of each component element.

[0090] Based on the components in the source code and the tag type corresponding to each component, a context-aware method is used to perform context awareness on each component to obtain the context weight of each component.

[0091] Based on the basic weight and context weight of each component, the semantic weight of each component is obtained. For example, the semantic weight may include: field weight, data type weight, and descriptive annotation weight.

[0092] In this implementation, the present invention uses preset regular expressions to match the constituent elements in the source code, which can accurately identify different tag types, such as identifiers, keywords, strings, and numbers. This method can effectively improve the accuracy of tag recognition. Further analysis of the constituent elements using a context-aware method can better understand their meaning in specific contexts and better handle special cases, such as ambiguity (the same identifier has different meanings in different contexts). This method not only improves the robustness of the parser when facing complex source code but also enhances parsing accuracy. By comprehensively calculating basic weights and context weights, the semantic meaning of the constituent elements can be more comprehensively evaluated. For example, the distinction between field weights, data type weights, and descriptive comment weights allows the parser to better understand the role of each element in the code. In summary, the present invention, by combining regular expressions and a context-aware method to determine the semantic category of each constituent element in the source code, can significantly improve the accuracy, robustness, and automation of parsing, thereby improving development efficiency and code quality. This technical solution has high practical value in real-world applications.

[0093] In one implementation, the process of obtaining the semantic category of each component element based on its semantic weight may include:

[0094] When the field weight in the semantic weight of a component element is the highest, the semantic category to which the component element belongs is the field category (also known as the isField category, indicating that the component element is an attribute name field);

[0095] When the data type has the highest semantic weight among the constituent elements, the semantic category to which the constituent element belongs is the data type category (also known as the isType category, indicating that the constituent element is an attribute data category field);

[0096] When the descriptive annotation has the highest semantic weight among the constituent elements, the semantic category to which the constituent element belongs is the descriptive annotation category (also known as the isDescription category, indicating that the constituent element is a code annotation);

[0097] This implementation determines the semantic category of a component by analyzing the weights of its different characteristics (such as fields, data types, and descriptive comments). This improves the accuracy of code parsing and makes the parsing results more consistent with the actual programming intent. In actual development, this is of great significance for improving software quality, maintainability, and development efficiency. Especially in actual project development, developers are often required to write detailed and standardized comments, which increases workload and distracts attention from code development and optimization. This implementation, by determining the semantic category of a component based on the highest semantic weight and automatically generating API documentation, not only reduces this burden on developers but also allows them to focus more on the development and optimization of the code itself, while ensuring timely updates and accuracy of the documentation.

[0098] In one implementation, step 4 above, which involves generating the application programming interface (API) document corresponding to the source code based on the semantic category of each component element, may include:

[0099] Based on the semantic category to which each component belongs, determine the parameter description information of the source code;

[0100] Based on the parameter description information in the source code, generate the corresponding application interface documentation.

[0101] In this implementation, the process of determining the parameter description information of the source code based on the semantic category to which each component belongs may include:

[0102] Based on the semantic category to which each component belongs, determine whether there are any components in the source code whose semantic category is descriptive annotation.

[0103] If they exist, the constituent elements are used as parameter description information in the source code, and the constituent elements and the constituent elements in the source code whose semantic category is field are stored in the preset dictionary;

[0104] If it does not exist, based on the preset dictionary, deduce the translation information corresponding to the constituent elements of the semantic category of the field category in the source code, and use the translation information as the parameter description information of the source code.

[0105] In this implementation, the API documentation automatically generated based on the collected and processed parameter description information is based on the code structure and semantics, thus exhibiting better consistency and structure. This step involves organizing the constituent elements and derived parameter description information into the specific content of the API documentation, including but not limited to parameter descriptions and sample code. Furthermore, the document formatting process ensures the readability and professionalism of the final output. By specially processing commented constituent elements, the comment content is added to a dedicated dictionary; for constituent elements without direct comments, their meaning is deduced based on the existing dictionary content. This process not only improves the completeness of the documentation but also enhances its accuracy and information content, enabling the generation of useful documentation content even in the absence of direct comments.

[0106] This invention addresses the problem that existing methods for generating application interface (API) documentation rely on developers adding standardized comments while writing code. The process of manually writing and standardizing comments is easily influenced by personal understanding and style preferences, and documentation generation typically requires developers to adhere to specific commenting conventions. This not only increases code complexity but also raises maintenance costs, leading to inconsistencies and inaccuracies, especially in large projects or those requiring frequent updates. The invention proposes a lexical analysis-based automatic API documentation generation method. This method directly analyzes the lexical elements of the source code to automatically generate API documentation. This significantly improves the automation of API documentation generation and greatly reduces invasiveness to existing code by decreasing reliance on specific comment formats. This makes maintaining and updating documentation easier and less costly, reduces human interference, and improves documentation accuracy by accurately parsing code structure and semantics through machine learning, thus reducing errors and omissions. Furthermore, different programming languages ​​and frameworks often have different commenting conventions and documentation generation tools, which poses a challenge to the documentation maintenance of multilingual projects. This invention provides a flexible documentation generation method by employing language-independent lexical analysis technology. This allows it to be used across languages ​​and frameworks, providing a unified and consistent documentation generation solution for various development environments, thus enhancing its universal applicability. This invention also aims to further improve the usability and readability of documentation through intelligent document structure and format generation. Such documentation is clearer, better structured, and easier for developers and users to understand and use.

[0107] In summary, this invention, through an automated API documentation generation process, not only improves the automation and accuracy of documentation generation, reduces project intrusion and maintenance costs, and alleviates the burden on developers to write and maintain detailed comments, allowing them to focus more on the development and optimization of the code itself, but also enhances its cross-language and framework applicability through intelligent document structure and format generation. This further reduces the burden on developers and improves the practicality and readability of the documentation, resulting in clearer, more structured, and consistent API documentation that is easier for developers and users to understand and use. Furthermore, it ensures timely updates and accuracy of the documentation.

[0108] Example 2:

[0109] A specific embodiment illustrates the method for automatically generating application programming interface (API) documentation based on lexical analysis provided by this invention, such as... Figure 2 As shown, it specifically includes:

[0110] (1) In this step, you need to input a piece of backend programming language source code;

[0111] (2) This step begins by parsing the source code of the system and initializing related variables, such as the state machine and the Token array, and defining the Token type;

[0112] (3) This step performs lexical analysis on the input source code to parse out the token type corresponding to the input code, such as space, curly brace, parenthesis, identifier, newline, keyword, data type, code comment and other types;

[0113] (4) This step will generate a Token from the parsed type and insert the Token into the Token array;

[0114] (5) In this step, the Token array generated in the previous step is subjected to bootstrapping analysis. The weights of the current Token semantics such as isField, isType, and isDescription are bootstrapping by combining regular expressions and parsing context. The semantics of the current Token are determined based on the weights.

[0115] (6) This step collects tokens whose semantic categories have been determined through bootstrapping analysis;

[0116] (7) In this step, for tokens with code comments, the parameter description text of the token is marked with code comments, and the comments and the corresponding token field are added to the dictionary for storage; for tokens without comments, the dictionary is used to translate the token field of type isField as the parameter description text of the line of source code; take the following line of source code as an example:

[0117] String body = "hello"; / / msg

[0118] In this line of source code, "String" is a component of the isType category, "body" is a component of the isField category, and " / / msg" is a component of the isDescription category. If there is a code comment in this line of source code (i.e., it contains a component of the isDescription category), this field is used directly as the parameter description text for this line of source code. If there is no code comment in this line of source code (i.e., it does not contain a component of the isDescription category), then the component of the isField category is directly translated (i.e., "body" in the example is translated as "body") as the parameter description text for this line of source code.

[0119] (8) This step will format the final obtained token array containing semantics into a fixed-format API document, such as Word format, HTML format, etc.

[0120] This specific embodiment illustrates that the present invention aims to construct a technical solution that automatically derives relevant API documentation by performing lexical analysis on existing source code and generates a user-friendly documentation format. By automatically deriving the documentation, rather than manually writing it, the efficiency of documentation creation is improved. Automatic generation based on the current code solves the problem of errors that easily occur during the writing process. This technical solution analyzes the source code without requiring any modification to the current code; therefore, it does not require adding specific comments or formatting to the code, has no intrusive impact on the project, and does not increase development complexity.

[0121] Example 3:

[0122] Based on the same inventive concept, this invention also provides an automatic generation system for application programming interface (API) documents based on lexical analysis, the structural composition of which is shown in the schematic diagram below. Figure 3 Shown, including:

[0123] The data acquisition module is used to acquire the source code to be parsed.

[0124] The code parsing module is used to parse the source code using lexical analysis methods to obtain the constituent elements of the source code and the corresponding tag type of each constituent element;

[0125] The semantic analysis module is used to determine the semantic category of each component element based on the components in the source code and the tag type corresponding to each component element, using a bootstrap analysis method.

[0126] The documentation generation module is used to generate application interface documentation corresponding to the source code based on the semantic category to which each component belongs.

[0127] In one possible implementation, the code parsing module described above may include:

[0128] The lexical analysis submodule is used to parse the source code using lexical analysis methods to obtain the constituent elements of the source code;

[0129] The element recognition submodule is used to identify each component element in the source code and obtain the corresponding tag type for each component element.

[0130] Optionally, the tag types in the code parsing module include: spaces, curly braces, parentheses, identifiers, newlines, keywords, data types, and code comments.

[0131] In one possible implementation, the semantic analysis module described above may include:

[0132] The weight-aware submodule is used to obtain the semantic weight of each component element based on the component elements in the source code and the tag type corresponding to each component element, using preset regular expressions and context-aware methods.

[0133] The semantic classification submodule is used to determine the semantic category of each component element based on its semantic weight.

[0134] In one possible implementation, the aforementioned weight-aware submodule may include:

[0135] The regular expression matching unit is used to match each component element in the source code and the corresponding tag type of each component element using a preset regular expression to obtain the basic weight of each component element.

[0136] The context-aware unit is used to perform context awareness on each component element in the source code and the corresponding tag type of each component element, and obtain the context weight of each component element.

[0137] The semantic weight generation unit is used to obtain the semantic weight of each component element based on the basic weight and context weight of each component element.

[0138] In this implementation, the semantic weights in the semantic analysis module mentioned above may include: field weights, data type weights, and descriptive annotation weights.

[0139] In one possible implementation, the semantic classification submodule described above may include:

[0140] The field category determination unit is used when the field with the highest semantic weight among the constituent elements is identified as the field category.

[0141] The data category determination unit is used when the data type weight is the highest among the semantic weights of the constituent elements, and the semantic category to which the constituent element belongs is the data type category.

[0142] The annotation category determination unit is used when the descriptive annotation has the highest semantic weight among the constituent elements, and the semantic category to which the constituent element belongs is the descriptive annotation category.

[0143] In one possible implementation, the document generation module described above may include:

[0144] The parameter information determination submodule is used to determine the parameter description information of the source code based on the semantic category to which each component belongs;

[0145] The Interface Documentation Generation Submodule is used to generate application interface documentation corresponding to the source code based on the parameter description information in the source code.

[0146] In this implementation, the parameter information determination submodule mentioned above may include:

[0147] The annotation judgment unit is used to determine whether there are any components in the source code whose semantic category is descriptive annotation, based on the semantic category to which each component belongs.

[0148] The annotation parameter determination unit, if there are constituent elements in the source code whose semantic category is descriptive annotation, uses the constituent elements as parameter description information in the source code, and stores the constituent elements and constituent elements in the source code whose semantic category is field into a preset dictionary;

[0149] The annotation parameter derivation unit, if there are no constituent elements in the source code whose semantic category is descriptive annotation, derives the translation information corresponding to the constituent elements in the source code whose semantic category is field based on a preset dictionary, and uses the translation information as the parameter description information of the source code.

[0150] Example 4:

[0151] like Figure 4 As shown, the present invention also provides an electronic device, which may be a computer device, a microcontroller device, a smart mobile device, etc. The electronic device in this embodiment may include a processor, a memory, a transceiver component, etc. The memory, processor, and transceiver component are connected via a bus; the memory can be used to store executable programs, and an exemplary executable program may include instructions; the processor is used to execute the instructions stored in the memory. The memory can also be used to store data, which can be accessed and / or modified when instructions are executed.

[0152] The processor may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, and it is suitable for implementing one or more instructions. Specifically, it is suitable for loading and executing one or more instructions in the storage medium to implement the corresponding method flow or corresponding function, so as to implement the steps of the lexical analysis-based application interface document automatic generation method in the above embodiments.

[0153] Example 4:

[0154] Based on the same inventive concept, this invention also provides a readable storage medium, specifically an electronic device readable storage medium (Memory). This readable storage medium is a memory device within an electronic device used to store programs and data. It is understood that the storage medium here can include both built-in storage media within the electronic device and extended storage media supported by the electronic device. The storage medium provides storage space, which stores the terminal's operating system. Furthermore, this storage space also stores one or more instructions suitable for loading and execution by a processor. These instructions can be one or more executable programs (including program code). It should be noted that the storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device. Loading and executing one or more instructions stored in the storage medium by the processor can implement the steps of the lexical analysis-based automatic application programming interface (API) documentation generation method described in the above embodiments.

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

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

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

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

[0159] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit its scope of protection. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that after reading the present invention, they can still make various changes, modifications or equivalent substitutions to the specific implementation methods of the application, but these changes, modifications or equivalent substitutions are all within the scope of protection of the claims pending approval.

Claims

1. A method for automatically generating application programming interface (API) documentation based on lexical analysis, characterized in that, include: Obtain the source code to be parsed; The source code is parsed using lexical analysis to obtain each component element in the source code and the tag type corresponding to each component element; Based on each component element in the source code and the tag type corresponding to each component element, a preset regular expression is used to match each component element to obtain the basic weight of each component element. Based on each component element in the source code and the tag type corresponding to each component element, a context-aware method is used to perform context awareness on each component element to obtain the context weight of each component element. Based on the basic weights and context weights of each component element, the semantic weights corresponding to each component element are obtained; wherein, the semantic weights include: field weights, data type weights, and descriptive annotation weights; When the field weight in the semantic weight of the constituent element is the highest, the semantic category to which the constituent element belongs is the field category; When the data type weight is the highest among the semantic weights of the constituent elements, the semantic category to which the constituent element belongs is the data type category; When the descriptive annotation weight is the highest among the semantic weights of the constituent elements, the semantic category to which the constituent element belongs is the descriptive annotation category; Based on the semantic category to which each component belongs, determine the parameter description information of the source code; Based on the parameter description information of the source code, generate the application programming interface (API) document corresponding to the source code.

2. The method as described in claim 1, characterized in that, The step involves using lexical analysis to parse the source code, obtaining each component element and its corresponding tag type, including: The source code is parsed using lexical analysis to obtain the constituent elements of the source code; Element identification is performed on each component element in the source code to obtain the tag type corresponding to each component element.

3. The method as described in claim 1 or 2, characterized in that, The tag types include: spaces, curly braces, parentheses, identifiers, newlines, keywords, data types, and code comments.

4. The method as described in claim 1, characterized in that, The step of determining the parameter description information of the source code based on the semantic category to which each component element belongs includes: Based on the semantic category to which each component belongs, determine whether there are any components in the source code whose semantic category is descriptive annotation. If they exist, the constituent elements are used as parameter description information in the source code, and the constituent elements and the constituent elements in the source code whose semantic category is field are stored in a preset dictionary; If it does not exist, based on a preset dictionary, deduce the translation information corresponding to the constituent elements of the semantic category of the field category in the source code, and use the translation information as the parameter description information of the source code.

5. A system for automatically generating application programming interface (API) documentation based on lexical analysis, characterized in that, include: The data acquisition module is used to acquire the source code to be parsed. The code parsing module is used to parse the source code using lexical analysis methods to obtain each component element in the source code and the tag type corresponding to each component element; The semantic analysis module is used to determine the semantic category of each component element based on the component elements in the source code and the tag type corresponding to each component element, using a bootstrap analysis method. The document generation module is used to generate the application interface document corresponding to the source code based on the semantic category to which each component element belongs; The semantic analysis module includes: The weight-aware submodule is used to obtain the semantic weight of each component element based on each component element in the source code and the tag type corresponding to each component element, using a preset regular expression and context-aware method. The semantic classification submodule is used to obtain the semantic category to which each component element belongs based on the semantic weight of each component element; The weight-aware submodule includes: The regular expression matching unit is used to match each component element in the source code and the tag type corresponding to each component element using a preset regular expression to obtain the basic weight of each component element. The context-aware unit is used to perform context awareness on each component element in the source code and the tag type corresponding to each component element, and obtain the context weight of each component element. The semantic weight generation unit is used to obtain the semantic weight corresponding to each component element based on the basic weight of each component element and the context weight; wherein, the semantic weight includes: field weight, data type weight and descriptive annotation weight; The semantic classification submodule includes: The field category determination unit is used to determine the semantic category to which the constituent element belongs when the field weight in the semantic weight of the constituent element is the highest. A data category determination unit is used to determine the semantic category to which the constituent element belongs when the data type weight is the highest among the semantic weights of the constituent elements; The annotation category determination unit is used to determine the semantic category to which the constituent element belongs when the descriptive annotation weight is the highest among the semantic weights of the constituent elements. The document generation module includes: The parameter information determination submodule is used to determine the parameter description information of the source code based on the semantic category to which each component element belongs; The interface documentation generation submodule is used to generate application interface documentation corresponding to the source code based on the parameter description information of the source code.

6. The system as described in claim 5, characterized in that, The code parsing module includes: The lexical analysis submodule is used to parse the source code using lexical analysis methods to obtain the constituent elements in the source code; The element identification submodule is used to identify each component element in the source code and obtain the tag type corresponding to each component element.

7. An electronic device, characterized in that, include: At least one processor and memory; The memory and processor are connected via a bus; The memory is used to store one or more programs; When the one or more programs are executed by the at least one processor, a method for automatically generating application interface documentation based on lexical analysis as described in any one of claims 1 to 4 is implemented.

8. A computing device readable storage medium, characterized in that, It contains an executable program, which, when executed, implements a method for automatically generating application interface documentation based on lexical analysis as described in any one of claims 1 to 4.

Images