Component description file generation method and apparatus

Abstract

This application discloses a method and apparatus for generating component description files. The method includes: obtaining component source code and performing multi-level structural parsing on the component source code to generate an abstract syntax tree (AST); parsing the AST to generate an enhanced abstract syntax tree (ESL); obtaining a domain terminology knowledge graph of the target business; mapping multiple business nodes included in the ESL to multiple business parameters based on the ESL and the domain terminology knowledge graph; converting business event data included in the ESL into business event description information corresponding to the multiple business parameters; and generating a component description file corresponding to the component source code based on the multiple business parameters and the business event description information. This method can achieve code parsing and semantic enhancement of component source code, generating a component description file corresponding to the component source code in the target business scenario.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method and apparatus for generating component description files. Background Technology

[0002] With the continuous development of internet technology, the number of components involved in the development process is also increasing. After developers complete the writing of a component, they need to write corresponding semantic documentation to facilitate the use of the component by other users. Existing technical solutions typically employ manual annotation or automated documentation generation tools based on static analysis to write the documentation for each component.

[0003] However, current semantic documentation generation for components faces significant bottlenecks: traditional manual coding methods not only consume substantial development resources but also suffer from high error rates and severe delays in documentation updates. Meanwhile, automated documentation generation tools based on static analysis cannot understand the dynamic semantic relationships within the code, resulting in documentation that often lacks crucial contextual information, exhibits high error rates, and has low applicability. Summary of the Invention

[0004] This application discloses a method and apparatus for generating component description files, which can perform code parsing and semantic enhancement on component source code, generate component description files corresponding to component source code in target business scenarios, realize the conversion from component source code to natural text language, and generate component description files with high accuracy and high applicability.

[0005] Firstly, this application provides a method for generating a component description file, comprising: obtaining component source code, and performing multi-level structural parsing on the application programming interface (API) syntax structure included in the component source code to generate an abstract syntax tree corresponding to the component source code, wherein the abstract syntax tree includes multiple business nodes associated with a target business; parsing the abstract syntax tree to obtain instruction constraint data of a first business node and data flow dependency data of a second business node, and annotating the instruction constraint data for the first business node and the data flow dependency data for the second business node in the abstract syntax tree to generate an enhanced abstract syntax tree, wherein the first business node is a business node with instruction constraints among the multiple business nodes, and the second business node is one of the multiple business nodes. The document describes a process involving business nodes with data flow dependencies. The enhanced abstract syntax tree (EST) includes multiple business nodes and business event data, including instruction constraint data and data flow dependency data. It then acquires a domain terminology knowledge graph for the target business, which includes mappings between nodes and business parameters, as well as mappings between business event data and business event descriptions. Based on the EST and the domain terminology knowledge graph, the document maps the multiple business nodes in the EST to multiple business parameters, converts the business event data in the EST into business event descriptions corresponding to the multiple business parameters, and generates a component description file corresponding to the component source code based on the multiple business parameters and the business event descriptions. In this application, component source code can be obtained, and multi-level structural parsing can be performed on the component source code to generate an abstract syntax tree (AST) corresponding to the component source code. Then, data parsing is performed on the AST to obtain instruction constraint data and data flow dependency data. Based on the instruction constraint data and data flow dependency data, business event data annotation can be performed on multiple business nodes in the AST to generate an enhanced AST. Furthermore, based on the domain terminology knowledge graph of the target business and the enhanced AST, the multiple business nodes included in the enhanced AST can be mapped to multiple business parameters, and the business event data can be converted into business event description information corresponding to the business parameters. Finally, a component description file corresponding to the component source code can be generated based on the multiple business parameters and the business event description information. Using the method provided in this application, the component source code can be converted into target business-related business parameters and business event description information through code parsing and semantic enhancement, achieving the conversion from component source code to natural text language. The generated component description file has high accuracy and high applicability.

[0006] In one possible implementation, the above-mentioned multi-level structural parsing of the application programming interface (API) syntax structure included in the component source code to generate the abstract syntax tree corresponding to the component source code includes: performing multi-level structural parsing of the various API syntaxes used in the component source code using a multi-mode parser, and uniformly mapping the parsed various API syntax structures into multiple syntax nodes in an intermediate representation form to generate the abstract syntax tree corresponding to the component source code; wherein the abstract syntax tree contains the multiple syntax nodes, the multiple syntax nodes include the multiple business nodes, and the multiple API syntaxes include Options API syntax or Composition API syntax. In this application, a multi-mode parser can perform multi-level structural parsing of various application programming interface (API) syntaxes used in component source code. This overcomes the limitations of traditional single-mode parsers and supports code parsing of component source code with mixed API syntax structures. It also overcomes the single-syntax limitation, supports heterogeneous source code analysis, and can uniformly map the parsed API syntax structures into multiple syntax nodes in intermediate representation (IR) form to generate an abstract syntax tree corresponding to the component source code. This achieves semantic alignment of different syntaxes at the abstract syntax tree level, providing a unified processing foundation for subsequent code analysis and semantic transformation, and demonstrating high applicability. Furthermore, the generated abstract syntax tree integrates multiple syntaxes, more comprehensively reflecting the actual behavior of the component and supporting subsequent code analysis of instruction constraints and data flow dependencies.

[0007] In one possible implementation, the above-mentioned data parsing of the abstract syntax tree to obtain instruction constraint data of the first business node and data flow dependency data of the second business node includes: identifying instruction constraints on the plurality of syntax nodes in the abstract syntax tree to obtain instruction constraint data of the first business node in the component source code, wherein the first business node is a syntax node with instruction constraints among the plurality of syntax nodes, and the instruction constraints include at least one of conditional rendering instruction constraints, list rendering instruction constraints, show or hide instruction constraints, or binding instruction constraints; parsing the abstract syntax tree based on the symbol table, recording the variables referenced by the plurality of syntax nodes in the abstract syntax tree, and obtaining data flow dependency data of the plurality of syntax nodes to obtain data flow dependency data of the second business node, wherein the second business node is a syntax node with data flow dependencies among the plurality of syntax nodes. In this application, instruction constraints in an abstract syntax tree can be identified to obtain instruction constraint data. Furthermore, variables referenced by multiple syntax nodes can be recorded based on a symbol table to obtain data flow dependency data. This provides a data foundation for subsequent annotation of business nodes. Instruction constraints on syntax nodes in the abstract syntax tree can be extracted as instruction constraint data, and variables across nodes in the abstract syntax tree can be recorded as data flow dependency data. This improves the correctness of both instruction constraint data and data flow dependency data, enabling the subsequently generated enhanced abstract syntax tree to contain both instruction constraint data and data flow dependency data. This provides a more comprehensive semantic analysis data foundation with high accuracy and applicability.

[0008] In one possible implementation, the above-mentioned parsing of the abstract syntax tree based on a symbol table and recording the variables referenced by the multiple syntax nodes in the abstract syntax tree includes: recording the definition information and transitive relationships of each variable referenced by the multiple syntax nodes in the abstract syntax tree through a symbol table; and generating a data flow dependency graph based on the definition information and transitive relationships of each variable to record the variables referenced by the multiple syntax nodes in the abstract syntax tree. In this application, the definition information and transitive relationships of each variable referenced by multiple syntax nodes in the abstract syntax tree can be recorded through a symbol table, thereby generating a data flow dependency graph. The data flow dependency graph has globality, provides a more comprehensive semantic analysis data foundation, and has high accuracy and applicability.

[0009] In one possible implementation, before generating the data flow dependency graph based on the definition information and transitive relationships of the aforementioned variables, the method further includes: when any of the aforementioned variables has multiple definitions in the various API syntaxes, a timestamp-based priority strategy retains the definition information declared in the definition most recently defined at the current time, as the definition information of any of the aforementioned variables. In this application, when any variable has multiple definitions in various API syntaxes, a timestamp-based priority strategy can be used to retain the definition information declared in the definition most recently defined at the current time as the definition information of that variable. This ensures that the definition information of the variable most recently defined at any time is used, thereby avoiding ambiguity and conflicts that may be caused by multiple versions and multiple sources of definitions. This allows the generated component description file to accurately and consistently reflect the currently valid definition information of the variable, thereby avoiding mapping errors caused by historical or duplicate definitions and improving the accuracy and reliability of the component description file.

[0010] In one possible implementation, generating the component description file corresponding to the component source code based on the multiple business parameters and the business event description information includes: obtaining the language type corresponding to the target business based on a federated learning multilingual adapter; transforming the multiple business parameters and the business event description information into textual language types based on the language type corresponding to the target business; and generating the component description file corresponding to the component source code based on the transformed multiple business parameters and the business event description information. In this application, the language type corresponding to the target business can be obtained based on a federated learning multilingual adapter, and then the multiple business parameters and the business event description information can be transformed into textual language types based on the language type corresponding to the target business to generate the component description file. This allows for language adaptability of the component description file, making the generated component code documentation applicable to target businesses in multiple language environments, thus exhibiting high applicability.

[0011] In one possible implementation, the method further includes: when a change in the syntax structure of the component source code is detected, locating the business node affected by the syntax structure change, changing the business parameters corresponding to the business node affected by the syntax structure change in the component description file, and highlighting text related to the updated business parameters in the component description file; or when a change in a variable is detected in the component source code, locating the business event data affected by the variable change based on the data flow dependency relationship, changing the business event description information corresponding to the business event data affected by the variable change in the component description file, and highlighting text related to the updated business event description information in the component description file. In this application, when a change in the syntax structure of the component source code is detected, the business node affected by the syntax structure change can be located, the business parameters corresponding to the business node affected by the syntax structure change in the component description file can be changed, and text related to the updated business parameters can be highlighted in the component description file. When a variable change is detected in the component source code, the business event data affected by the variable change can be located based on data flow dependencies. The corresponding business event description information in the component description file affected by the variable change is then updated, and text related to the updated business event description information is highlighted in the component description file. It is understood that using this application ensures strict synchronization between the component description file and the latest state of the source code, improves the readability and intuitiveness of change points, and enhances the accuracy, timeliness, and readability of code maintenance and documentation updates.

[0012] In one possible implementation, the method further includes: obtaining the effective conditions of the target instruction constraints based on reactive logic for the interface, as conditions indicating the usability of the component description file; wherein the target instruction constraints include at least one of conditional rendering instruction constraints, list rendering instruction constraints, show or hide instruction constraints, or binding instruction constraints. In this application, the effective conditions of instruction constraints can be obtained based on various instruction constraints of the interface using reactive logic, as conditions for the usability of the component description file. This allows the component description file to automatically reflect and synchronize the actual interaction logic and constraint state of the interface, thereby improving the accuracy and real-time performance of the component description in terms of interface control and behavior description.

[0013] Secondly, this application provides a component description file generation apparatus, which includes a module or unit for performing the component description file generation method provided in the first aspect or any possible implementation thereof.

[0014] For example, the component description file generation apparatus described above includes: The source code parsing module is used to obtain the component source code and perform multi-level structural parsing on the application programming interface (API) syntax structure included in the component source code to generate the abstract syntax tree corresponding to the component source code. The abstract syntax tree includes multiple business nodes associated with the target business. The aforementioned source code parsing module is also used to parse the aforementioned abstract syntax tree to obtain the instruction constraint data of the first business node and the data flow dependency data of the second business node, and to annotate the aforementioned instruction constraint data for the first business node and the aforementioned data flow dependency data for the second business node in the aforementioned abstract syntax tree to generate an enhanced abstract syntax tree. The aforementioned first business node is a business node with instruction constraints among the aforementioned multiple business nodes, and the aforementioned second business node is a business node with data flow dependency among the aforementioned multiple business nodes. The aforementioned enhanced abstract syntax tree includes the aforementioned multiple business nodes and business event data, and the aforementioned business event data includes the aforementioned instruction constraint data and the aforementioned data flow dependency data. The semantic module is used to obtain the domain terminology knowledge graph of the target business, which includes the mapping relationship between nodes and business parameters, as well as the mapping relationship between business event data and business event description information. The semanticization module is further configured to map the multiple business nodes included in the enhanced abstract syntax tree to multiple business parameters based on the enhanced abstract syntax tree and the domain terminology knowledge graph, convert the business event data included in the enhanced abstract syntax tree into business event description information corresponding to the multiple business parameters, and generate a component description file corresponding to the component source code based on the multiple business parameters and the business event description information.

[0015] Thirdly, this application provides a computer device, which includes a processor and a memory; the memory and the processor are connected, wherein the memory is used to store program code, and the processor is used to call the program code to execute the steps of the component description file generation method provided in the first aspect or any possible embodiment of the first aspect.

[0016] Fourthly, this application provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and to execute the steps of the component description file generation method provided in the first aspect or any possible implementation thereof.

[0017] The technical effects of the second, third, and fourth aspects can be referred to the technical effects of the first aspect and any possible implementation thereof, and will not be repeated here. Attached Figure Description

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

[0019] Figure 1 A schematic diagram of the system architecture for the component description file generation method provided in the embodiments of this application; Figure 2 This is a schematic diagram illustrating an application scenario of the component description file generation method provided in the embodiments of this application; Figure 3 A flowchart illustrating the component description file generation method provided in this application embodiment; Figure 4 A schematic diagram of the component description file generation apparatus provided in the embodiments of this application; Figure 5 A schematic diagram of the structure of a computer device provided in an embodiment of this application.

[0020] Explanation of reference numerals in the attached figures: 10-Server; 20-Computer equipment; 201 - Processor; 202 - Communication bus; 203 - User interface; 204 - Network interface; 205 - Memory; 40 - Component description file generation device; 401 - Source code parsing module; 402 - Semantic code generation module; 403 - Change detection module; 404 - Condition detection module. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0022] With the evolution of internet technology, the number of components involved in modern software development is increasing daily. After completing the writing of a component, developers typically need to generate semantic documentation to support team collaboration and component reuse. Currently, the mainstream approach to generating such documentation still relies on manual writing or the use of automated documentation generation tools based on static code analysis.

[0023] However, existing methods face significant limitations in practical applications: manual documentation not only consumes a large amount of development manpower but is also prone to introducing errors and is difficult to update in a timely manner with code iterations; while automated tools based on static analysis, due to their inability to capture the dynamic semantics and contextual relationships of code at runtime, often generate documentation that lacks key logical information, has low accuracy and poor applicability, and is difficult to meet the documentation needs of complex systems.

[0024] This application provides a method and apparatus for generating component description files. The method obtains component source code, performs multi-level structural parsing to generate an abstract syntax tree (AST) corresponding to the component source code, and then parses the AST to obtain instruction constraint data and data flow dependency data. Based on the instruction constraint data and data flow dependency data, multiple business nodes in the AST are labeled with business event data to generate an enhanced AST. Further, based on the domain terminology knowledge graph of the target business and the enhanced AST, the multiple business nodes included in the enhanced AST are mapped to multiple business parameters, and the business event data is converted into business event description information corresponding to the business parameters. Based on these multiple business parameters and business event description information, a component description file corresponding to the component source code can be generated. The method provided in this application can convert component source code into target business-related business parameters and business event description information through code parsing and semantic enhancement, achieving the conversion from component source code to natural text language. The generated component description file has high accuracy and high applicability.

[0025] Please see Figure 1 , Figure 1 This is a schematic diagram of the system architecture for the component description file generation method provided in this application embodiment. The component description file generation method provided in this application embodiment can be applied to, for example... Figure 1The system architecture shown may include connected servers 10 and computer devices 20. Server 10 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms. Computer device 20 may be a PDA, smartphone, laptop, desktop computer, tablet, mobile internet device (MID), wearable device (e.g., smartwatch, smart bracelet), smart computer, or other smart terminal, but is not limited to these. Computer device 20 may include an operating system, hardware, and application software. The hardware may include, but is not limited to, a central processing unit (CPU), memory (e.g., RAM, hard disk), and peripherals, providing core capabilities for computing, storage, and input / output. An operating system can serve as the management and abstraction layer for hardware. Through its kernel and drivers, it can schedule CPU resources, manage memory space, and control peripheral operations. It also encapsulates complex hardware details into unified system calls and service interfaces, thereby providing a stable, efficient, and secure operating environment for upper-layer application software. Application software, built on the operating system, can utilize hardware resources through the interfaces provided by the operating system. For example, it can read component source code stored in memory to provide users with usable services. In this embodiment, the application software may include, but is not limited to, component description file generation software. The computer device 20 can run this component description file generation software to execute the component description file generation method provided in this embodiment.

[0026] The server 10 and the computer device 20 can establish a communication connection. The communication connection method is not limited; it can be established directly or indirectly via wired communication or wireless communication, etc., depending on the actual application scenario, and is not restricted here.

[0027] The method provided in the embodiments of this application can be derived from, for example... Figure 1 The execution can be performed by server 10, computer device 20, or both server 10 and computer device 20. The specific execution method can be determined according to the actual application scenario, and no restrictions are imposed here.

[0028] It should be understood that, such as Figure 1The computer device 20 shown can be equipped with an application client (not shown in the figure) for component description file generation software. When this application client runs on the computer device 20, it can interact with the aforementioned... Figure 1 The servers 10 shown interact with each other, allowing server 10 to obtain business data from computer device 20 through interfaces and other paths. This business data can include, but is not limited to, component source code input by the user, component source code stored in hardware memory, or target component description files generated by component description file generation software, which are invoked during the user's use of the application client. This business data can be shared with server 10 or shared through server 10 with other business devices (not shown in the figure) connected to server 10, depending on the actual application scenario. The application client can be an application program, a webpage, or a website, depending on the actual application scenario. The application client can be a standalone client or an embedded sub-client integrated into a client (e.g., an instant messaging client, a social networking client, etc.), depending on the actual application scenario. Users can send business data to server 10 through this application client. This business data can be used to request server 10 to start relevant business processes and return relevant process data to the application client. For example, server 10 can obtain the component source code uploaded by the user from the application client in computer device 20, process the component source code to generate the corresponding component description file, and then transmit the component description file as business data to computer device 20. The specific implementation can be determined according to the actual application scenario and is not limited here. Here, server 10, as the server for the application client, can be a collection of multiple servers, including the backend server and data processing server corresponding to the application client. Alternatively, computer device 20 can also obtain a piece of component source code from server 10. This component source code can be code stored on server 10 or code shared by other business devices (not shown in the figure) connected to server 10. Computer device 20 can call component description file generation software to process the above component source code to generate the corresponding component description file, and then transmit the component description file as business data to server 10. The specific implementation can be determined according to the actual application scenario and is not limited here.

[0029] For ease of subsequent understanding and explanation, in the embodiments of this application, the following will be used as... Figure 1 The computer device 20 shown serves as the execution entity of the component description file generation method (which can be simply referred to as the resource scheduling method or method for ease of description) provided in the embodiments of this application, in conjunction with... Figure 2 The application scenarios of the component description file generation method provided in the embodiments of this application are illustrated with examples.

[0030] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating an application scenario of the component description file generation method provided in this application embodiment. For example... Figure 2 As shown, computer device 20 can provide a webpage or client, etc., to obtain the source code of components input or uploaded by the user. Assume the user is... Figure 2 In the user interface 1 shown, the user enters / pastes the component source code in the text box (e.g., enters the code `props: { size: { type: String, default: 'medium', validator: (val) =>['small', 'medium', 'large'].includes(val)}}`), and clicks the "Generate" button. After detecting that the "Generate" button in user interface 1 has been clicked, the computer device can generate a component description file from the currently entered / pasted component source code. The computer device can perform code parsing, data extraction, semantic conversion, etc., on the component source code in the background; details can be found in subsequent embodiments and will not be elaborated here. After the component description file is generated, the computer device can provide or refresh the user interface (e.g., user interface 2) to display the text content of the component description file and provide an "Export" button for the user to export the component description file. Figure 2 As shown, user interface 2 can display the text content of the corresponding component source code from the component description file (such as | Parameter | Type | Required | Default Value | Description | | size | string | No | medium | Button size (small / medium / large) |) and provide an "Export" button. When the computer device detects a click on the "Export" button, it can output documents in formats such as Markdown / JSON, without any restrictions.

[0031] It is understood that in the specific implementation of this application, data related to object information is involved. When the embodiments of this application are applied to specific products or technologies, permission or consent from the object is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0032] The following will combine Figure 3 and Figure 4 The method and apparatus for generating component description files provided in the embodiments of this application will be described in detail.

[0033] See Figure 3 , Figure 3This is a flowchart illustrating the component description file generation method provided in this application embodiment. For ease of understanding and explanation, this application embodiment will describe the process using a computer device as the execution subject. This computer device can be any device or server, such as one equipped with component description file generation software. Figure 1 The computer device 20 shown can be the execution entity of the component description file generation method provided in the embodiments of this application. The component description file generation method may include at least the following steps S301 to S304: S301, Obtain the component source code, and perform multi-level structure parsing on the application programming interface (API) syntax structure included in the component source code to generate an abstract syntax tree corresponding to the component source code. The abstract syntax tree includes multiple business nodes associated with the target business.

[0034] In some feasible implementations, the computer device can obtain the component source code; here, the computer device can obtain it from local storage space (e.g., Figure 1 The component source code can be read from the storage in the computer device (or downloaded from a server connected to the computer device), depending on the specific application scenario. It is understood that the component source code can support multiple syntaxes, such as Options API and Composition API, again depending on the application scenario. The computer device can perform multi-level structural parsing of the application programming interface (API) syntax structure included in the component source code to generate the corresponding abstract syntax tree. Here, the computer device can perform lexical analysis on the code text in the component source code, converting the character sequence into a token stream with specific types, such as recognizing Vue-specific keywords and syntax units like `export default`, `data`, `setup`, and `ref`. Furthermore, the computer device can perform syntax analysis, generating a nested tree structure—the abstract syntax tree—based on the syntax rules of Vue components and JavaScript / TypeScript syntax rules, again depending on the application scenario. It is understood that the aforementioned abstract syntax book includes at least multiple business nodes associated with the target business. These business nodes can be mapped to business parameters associated with the target business in subsequent processing. For details, please refer to the following embodiments; further elaboration is not provided here. It is understood that the aforementioned target business may include, but is not limited to, e-commerce, healthcare, and manufacturing, etc., and can be determined based on the actual application scenario; no restrictions are imposed here.

[0035] In some feasible implementations, computer devices can use a multi-mode parser to perform multi-level structural parsing of the various API syntaxes used in the component source code, mapping the parsed API syntax structures into multiple syntax nodes in an intermediate representation to generate an abstract syntax tree corresponding to the component source code. This abstract syntax tree contains the aforementioned multiple syntax nodes, which include the aforementioned multiple business nodes. The various API syntaxes include Options API syntax or Composition API syntax. Here, Options API syntax can organize component code using an object containing multiple options, such as data, methods, computed properties, and lifecycle hooks. This syntax structure can distribute code for the same function across different options. Composition API syntax allows developers to write component logic in a functional way, combining reactive states, computed properties, and methods through setup functions. This syntax structure allows code for related functions to be grouped together. It should be understood that Options API syntax and Composition API syntax can be used individually or in combination in the component source code. Besides Options API syntax and Composition API syntax, other API syntax structures may exist in the component source code, which can be determined according to the actual application scenario and are not limited here. For ease of description, the following explanation will use only the Options API and Composition API syntax in the component source code as examples. Computer devices can employ multi-mode parsers to perform multi-level structural parsing of the various APIs used in the component source code. Specifically, for the Options API, it can parse elements including, but not limited to, data functions, method objects, and computed objects, into multiple syntax nodes in the abstract syntax tree. For the Composition API, it can identify the logic within the setup function body, including but not limited to parsing composed function calls such as ref, reactive, computed, and lifecycle hooks. The specific details can be determined based on the actual application scenario and are not limited here.Here, the multi-mode parser introduced by the computer device can integrate a basic JavaScript / TypeScript parser, such as Babel Parser or TypeScript compiler, and also needs to integrate a parsing module based on object property traversal for the Options API, a reactive variable tracker for the Composition API, and a central coordinator or intermediate representation generator, etc., to achieve multi-level structural parsing of the API syntax used in the component source code, and to uniformly map the various API syntax structures obtained from the parsing to multiple syntax nodes under the intermediate representation (IR). For example, the computer device can introduce a parsing module based on object property traversal for the Options API to establish parameter mapping tables for key functions such as setup() and data(), and introduce a reactive variable tracker for the Composition API to dynamically capture the declared dependencies through proxy interception technology to achieve dynamic binding of declarations such as ref and reactive. The specific multi-mode parser can be determined according to the actual application scenario, and no restrictions are imposed here. Optionally, a unified interface conversion layer can be developed in the computer device to convert the syntactic elements of the two APIs into an intermediate representation. This intermediate representation may include, but is not limited to, component configuration metadata, reactive variable relationship matrices, and lifecycle hook mapping tables, mapping multiple API syntactic structures to multiple syntactic nodes under the intermediate representation. The specific implementation can be determined based on the actual application scenario and is not limited here. In this embodiment, a multi-mode parser can perform multi-level structural parsing of multiple application programming interface (API) syntaxes used in the component source code. This overcomes the limitations of traditional single-mode parsers, supports code parsing of component source code with mixed API syntactic structures, breaks through the single-syntactic limitation, supports heterogeneous source code analysis, and can uniformly map the parsed multiple API syntactic structures to multiple syntactic nodes under the intermediate representation (IR) form to generate an abstract syntax tree corresponding to the component source code. This achieves semantic alignment of different syntaxes at the abstract syntax tree level, providing a unified processing foundation for subsequent code analysis and semantic conversion, and has high applicability. Meanwhile, the generated abstract syntax tree integrates multiple syntaxes, which can more comprehensively reflect the actual behavior of components and support subsequent code analysis of instruction constraints and data flow dependencies.

[0036] S302, perform data parsing on the above abstract syntax tree to obtain the instruction constraint data of the first business node and the data flow dependency data of the second business node, and annotate the instruction constraint data for the first business node and the data flow dependency data for the second business node in the above abstract syntax tree to generate an enhanced abstract syntax tree. The first business node is a business node with instruction constraints among the multiple business nodes, and the second business node is a business node with data flow dependencies among the multiple business nodes. The enhanced abstract syntax tree includes the multiple business nodes and business event data, and the business event data includes the instruction constraint data and the data flow dependency data.

[0037] In some feasible implementations, a computer device can perform data parsing based on the aforementioned abstract syntax tree to obtain instruction constraint data of the first business node and data flow dependency data of the second business node. The device then annotates the instruction constraint data for the first business node and the data flow dependency data for the second business node within the abstract syntax tree, thereby generating an enhanced abstract syntax tree. Here, the first business node is a business node with instruction constraints among the multiple business nodes in the abstract syntax tree, and the second business node is a business node with data flow dependencies among the multiple business nodes in the abstract syntax tree. The enhanced abstract syntax tree includes the aforementioned multiple business nodes and business event data, which may include, but is not limited to, the aforementioned instruction constraint data and data flow dependency data. Here, the computer device can employ an abstract syntax tree parser equipped with abstract syntax tree parsing technology, data flow tracing technology, and path sensitivity analysis algorithms to implement the above process. For example, the computer device can use abstract syntax tree parsing technology to identify the definition locations of parameters referenced by syntax nodes (such as order status, user configuration permissions, etc.) and corresponding output events (such as payment success callbacks). The relevant data flow information of these output events can be annotated on the relevant syntax nodes as data flow dependency data. The abstract syntax tree parser can also integrate symbolic execution engines, constraint solvers, etc., which can be determined according to the actual application scenario and are not limited here. For example, the computer device can use a constraint solver to record the value changes of parameters referenced by each syntax node on each path, thereby completely reconstructing the type constraints, scope, and change trajectory within the parameter's lifecycle, and thus obtaining data flow dependency data for multiple syntax nodes. As another example, the computer device can use an instruction influence tracing module to identify the constraints of conditional rendering instructions (such as v-if) on parameter visibility.

[0038] In some feasible implementations, the computer device can identify instruction constraints on the plurality of syntax nodes in the abstract syntax tree to obtain instruction constraint data of the first business node in the component source code. The first business node is a syntax node with instruction constraints among the plurality of syntax nodes. These instruction constraints include at least one of conditional rendering instruction constraints, list rendering instruction constraints, show or hide instruction constraints, or binding instruction constraints. It is understood that the computer device can traverse all syntax nodes in the abstract syntax tree. Here, syntax nodes may include, but are not limited to, element nodes, text nodes, instruction nodes, attribute nodes, etc. Each syntax node includes, but is not limited to, its type, position, attributes, child nodes, instruction constraints, etc. The computer device can perform instruction constraint detection on each syntax node in the abstract syntax tree. For example, it can use a detector to check the attributes of each node and identify instruction constraints. Here, directive constraints include, but are not limited to, conditional rendering directive constraints, list rendering directive constraints, show or hide directive constraints, or binding directive constraints. Conditional rendering directives may include, but are not limited to, directives such as `v-if`, `v-else-if`, `v-else`, and `ng-if`. List rendering directive constraints may include, but are not limited to, directives such as `v-for` and `ng-for`. Show or hide directive constraints may include, but are not limited to, directives such as `v-show`. Binding directive constraints may include, but are not limited to, attribute binding (such as the ":" prefix or `v-bind:`), event binding (such as the "@" prefix or `v-on:`), and text interpolation (such as "{{}}"). The specific details can be determined based on the actual application scenario and are not limited here. After detecting the directive constraints in each syntax node, the computer device can classify and record each detected directive constraint to obtain directive constraint data. Here, directive constraint data may include, but is not limited to, directive type, expression content, and scope. The specific details can be determined based on the actual application scenario and are not limited here. The computer device can parse the abstract syntax tree (AST) based on the symbol table, record the variables referenced by the multiple syntax nodes in the AST, and obtain the data flow dependency data of the multiple syntax nodes to obtain the data flow dependency data of the second business node. The second business node is a syntax node that has data flow dependencies with the multiple syntax nodes. Here, the computer device can construct a symbol table to record and manage the variables referenced by the multiple syntax nodes. The symbol table includes, but is not limited to, the unique identifier of the variable, the variable type (such as props, data, computed, ref, etc.), the initial value or expression of the variable at the time of declaration, and the set of dependencies. The specific details can be determined according to the actual application scenario and are not limited here.In this embodiment, instruction constraints in the abstract syntax tree can be identified to obtain instruction constraint data. Furthermore, variables referenced by multiple syntax nodes can be recorded based on a symbol table to obtain data flow dependency data. This provides a data foundation for subsequent annotation of business nodes. Instruction constraints on syntax nodes in the abstract syntax tree can be extracted as instruction constraint data, and variables across nodes in the abstract syntax tree can be recorded as data flow dependency data. This improves the correctness of both instruction constraint data and data flow dependency data, enabling the subsequently generated enhanced abstract syntax tree to contain both instruction constraint data and data flow dependency data. This provides a more comprehensive semantic analysis data foundation with high correctness and applicability.

[0039] In some feasible implementations, a computer device can record the definition information and transitive relationships of each variable referenced by the multiple syntax nodes in the abstract syntax tree using a symbol table. Based on this definition information and transitive relationships, a data flow dependency graph can be generated to record the variables referenced by the multiple syntax nodes in the abstract syntax tree. It is understood that the computer device can traverse all syntax nodes in the abstract syntax tree and record the variable declarations (such as identifiers defined in props, data, and computed) referenced by each syntax node in the symbol table. The symbol table includes, but is not limited to, the variable's unique identifier, variable type, initial value or expression at the time of declaration, and a set of dependencies. Here, the set of dependencies may include, but is not limited to, the initial definition point of each variable, one or more usage points, and the transitive relationships between the usage point and the definition point. It is understood that the unique identifier, variable type, initial value or expression at the time of declaration, etc., of the aforementioned variables can be considered as the variable's definition information. The computer device can then generate a data flow dependency graph based on the definition information and transitive relationships of each variable. It is understood that any data flow dependency chain in the data flow dependency graph can be used to represent the complete transitive path of a variable from its source definition to its final use. For example, a data flow dependency graph can contain any data flow dependency chain that begins with the initial definition node of a variable (such as its declaration in `data` or `props`), passes through all intermediate nodes that perform calculations, transformations, or propagations on that variable (such as computed properties, method processing, or expression transformations in templates), and finally reaches one or more syntax nodes that consume the variable's value (such as directive conditional `v-if` or attribute binding `:value`). In this embodiment, a symbol table can be used to record the definition information and propagation relationships of each variable referenced by multiple syntax nodes in the abstract syntax tree, thereby generating a data flow dependency graph. This data flow dependency graph is global, providing a more comprehensive semantic analysis data foundation, and has high accuracy and applicability.

[0040] In some feasible implementations, when any of the aforementioned variables are defined multiple times in the various API syntaxes, the computer device can retain the definition information declared at the most recent definition time based on a timestamp priority strategy, using this as the definition information for any of the aforementioned variables. It can be understood that when the computer device detects that the same variable is defined multiple times through different APIs within the component's lifecycle, the computer device can assign a logical "timestamp" to each definition operation. Here, the timestamp can be used to characterize the logical order of definitions in code execution or source code structure priority. For example, if a variable is first defined through `data` and then redefined through the `setup` function, the computer device can assign a logical timestamp to each definition operation. Based on the two logical timestamps, it can be determined that the data returned by `setup` takes precedence over the `data` definition; that is, the data returned by `setup` can overwrite the `data` definition. It can also be understood that during the construction of the symbol table and the parsing of the data stream, the computer device can actively apply the definition information declared at the most recent definition time. The definition information of the variable entry in the symbol table (including its value, type, associated reactive logic, etc.) will be updated to this latest version. Correspondingly, all subsequent syntax nodes' references to this variable and dependency analysis can establish data flow dependency chains based on the final retained definition information. In this embodiment, when any variable has multiple definitions in various API syntaxes, a timestamp priority strategy can be used to select the definition information declared in the definition most recently defined at the current time. This ensures that the definition information of the variable most recently defined at any time is used, thereby avoiding ambiguity and conflicts that may be caused by multiple versions and multiple sources of definitions. This allows the generated component description file to accurately and consistently reflect the currently valid definition information of the variable, thus avoiding mapping errors caused by historical or duplicate definitions and improving the accuracy and reliability of the component description file.

[0041] S303, Obtain the domain terminology knowledge graph of the target business, which includes the mapping relationship between nodes and business parameters, as well as the mapping relationship between business event data and business event description information.

[0042] In some feasible implementations, the computer device can acquire a domain terminology knowledge graph of the target business. This knowledge graph can include mapping relationships between nodes and business parameters, as well as mapping relationships between business event data and business event description information. Here, the domain terminology knowledge graph of the target business can be collaboratively constructed by experts, knowledge engineers, and technical teams within the target domain. The computer device can read the domain terminology knowledge graph of the target business from local storage or download it from a server connected to it, depending on the actual application scenario. For example, when the target business is an e-commerce scenario, the code symbol "discountRate" corresponding to a node can be mapped to the business term "member discount rate." As another example, when the target business is a medical system, the computer device can map "diagCode: string[]" to "diagnostic code list: ICD-10 standard code, multiple selection." It is understood that business event data can include, but is limited to, instruction constraint data and data flow dependency data, and business event description information can be user-understandable descriptive information. For example, the instruction constraint "{ type: 'TEXT_INTERPOLATION', dependsOn: 'patientAge'}" can be mapped to the business event description information "Dynamically display the value of 'patient age' here." It can be understood that this mapping enables the connection between static code and dynamic business logic and rules.

[0043] S304, based on the aforementioned enhanced abstract syntax tree and the aforementioned domain terminology knowledge graph, the aforementioned multiple business nodes included in the aforementioned enhanced abstract syntax tree are mapped to multiple business parameters, the aforementioned business event data included in the aforementioned enhanced abstract syntax tree are converted into business event description information corresponding to the aforementioned multiple business parameters, and a component description file corresponding to the aforementioned component source code is generated based on the aforementioned multiple business parameters and the aforementioned business event description information.

[0044] In some feasible implementations, the computer device can, based on the Enhanced Abstract Syntax Tree (EAST) and a domain terminology knowledge graph, map multiple business nodes included in the EAST to multiple business parameters, convert business event data included in the EAST into business event description information corresponding to multiple business parameters, and generate a component description file corresponding to the component source code based on the aforementioned multiple business parameters and the aforementioned business event description information. For ease of understanding, for example, assuming the target business is a medical system, the computer device can obtain the EAST corresponding to the component source code and the domain terminology knowledge graph of the target business. By traversing each business node in the EAST, it maps each node to a specific business parameter according to the domain knowledge graph. For example, it maps “{{ patientAge}}” to “patient age: numeric, unit: years”, and “diagCode: string[]” to “diagnosis code list: ICD-10 standard code, multiple selection”. The computer device can obtain business event data in the EAST and convert it into business event description information corresponding to the business parameters. For example, the technical constraint `v-if="isDoctor"` can be transformed into a business rule description stating that "this function is only visible to the doctor role." Ultimately, the computer device can synthesize all mapped business parameters and their corresponding business event descriptions to generate a component description file. This file can record the component's business functions, data rules, interaction logic, and constraints using natural text language. Optionally, the component description file generated by the computer device can be in formats including, but not limited to, Markdown documents, YAML files, framework-specific document blocks, JSON files, TypeScript Interface, and JSDoc comment extracts. The specific format can be determined based on the actual application scenario and is not limited here. Markdown documents, YAML files, and framework-specific document blocks are directly human-readable document formats, while JSON files, TypeScript Interface, and JSDoc comment extracts are structured document formats; all of these document formats are readable.

[0045] In some feasible implementations, the computer device can obtain the language type corresponding to the target business based on a multilingual adapter using federated learning. Then, it can transform the multiple business parameters and the business event description information into textual language types based on the language type of the target business, and generate a component description file corresponding to the component source code based on the transformed multiple business parameters and the business event description information. It is understood that the computer device can accurately identify the language type (such as Chinese, English, Korean, etc.) corresponding to the target business based on the multilingual adapter using federated learning. Once the computer device obtains the business parameters (such as "patient age: numerical, unit: years") and business event description information (such as "this function is only visible to the doctor role") mapped by the enhanced abstract syntax tree, it can identify the target language type based on the multilingual adapter and call the corresponding language's domain terminology knowledge graph and translation model to perform semantically preserved language conversion on all text content. It is understood that this language conversion can be adapted by combining the business habits, legal terminology, and cultural context of the target language region; the specifics can be determined according to the actual application scenario and are not limited here. In this embodiment, a multilingual adapter based on federated learning can be used to obtain the language type corresponding to the target business. Then, based on the language type corresponding to the target business, the text language type of the above-mentioned multiple business parameters and the above-mentioned business event description information can be transformed to generate a component description file corresponding to the component source code. This can realize the language adaptability of the component description file, and make the generated component code document applicable to the target business in multiple language environments, with high applicability.

[0046] In some feasible implementations, when a change in the syntax structure of the aforementioned component source code is detected, the computer device can locate the business nodes affected by the syntax structure change, modify the business parameters corresponding to the affected business nodes in the component description file, and highlight the text related to the updated business parameters in the component description file. When a change in a variable is detected in the aforementioned component source code, the computer device can locate the business event data affected by the variable change based on the aforementioned data flow dependency relationship, modify the business event description information corresponding to the affected business event data in the component description file, and highlight the text related to the updated business event description information in the component description file. It is understood that when a syntax structure change occurs, the computer device can locate the business nodes affected by the syntax structure change. For example, the computer device can locate the business nodes affected by the syntax structure change by comparing the abstract syntax tree before and after the change. The specific location can be determined according to the actual application scenario and is not limited here. Furthermore, when a change in a variable is detected in the component source code, the computer device can track the propagation effect of the change through the established data flow dependency graph to locate the business event data affected by the variable change. After locating the changed business nodes or business event data, the computer device can correspondingly change the text related to the business parameters or business event description information in the component description file and highlight it. This highlighting includes, but is not limited to, font size highlighting, font color highlighting, underlining, etc., and can be determined according to the actual application scenario, without limitation. In this embodiment, when a change in the syntax structure of the component source code is detected, the business nodes affected by the syntax structure change can be located, the business parameters corresponding to the affected business nodes in the component description file can be changed, and the text related to the updated business parameters can be highlighted in the component description file. Similarly, when a change in a variable in the component source code is detected, the business event data affected by the variable change can be located based on data flow dependencies, the business event description information corresponding to the affected business event data in the component description file can be changed, and the text related to the updated business event description information can be highlighted in the component description file. It is understood that using this application can ensure strict synchronization between the component description file and the latest state of the source code, improve the readability and intuitiveness of the change points, and enhance the accuracy, timeliness, and readability of code maintenance and document updates.

[0047] In some feasible implementations, the computer device can obtain the effective conditions of the target instruction constraints on the interface based on the reactive logic, and use these conditions to indicate the usability of the component description file. The target instruction constraints include at least one of conditional rendering instruction constraints, list rendering instruction constraints, show or hide instruction constraints, or binding instruction constraints. Here, the interface can be a business capability channel exposed by a business node that can be perceived or interacted with externally (parent component, user, system). Typically, a business node can define one or more interfaces. The target instruction constraints of the reactive logic on the interface can usually be the behavioral semantics of the interface defined by the business node, which can be used to characterize the interface's operation under certain specific conditions. The specific implementation can be determined according to the actual application scenario and is not limited here. For example, the computer device can identify the dynamic constraints (i.e., target instruction constraints) of reactive logic such as watch and computed on the interface through data flow analysis, and obtain the effective conditions of the target instruction constraints through dynamic scope analysis, which can be used as conditions for the usability of the generated component description file. It is understood that the conditions for the usability of the component description file can be stored in the file attributes of the component description file or recorded in text form within the component description file, depending on the actual application scenario and is not limited here. In this embodiment, the effective conditions of instruction constraint information can be obtained based on the various instruction constraints of the interface using reactive logic, which can be used as the conditions for the availability of the component description file. This allows the component description file to automatically reflect and synchronize the actual interaction logic and constraint state of the interface, thereby improving the accuracy and real-time performance of the component description in terms of interface control and behavior description.

[0048] In summary, the component description file generation method provided in this application can obtain component source code, perform multi-level structural parsing on the component source code to generate an abstract syntax tree (AST) corresponding to the component source code, and then perform data parsing on the AST to obtain instruction constraint data and data flow dependency data. Based on the instruction constraint data and data flow dependency data, business event data can be labeled on multiple business nodes in the AST to generate an enhanced AST. Furthermore, based on the domain terminology knowledge graph of the target business and the enhanced AST, the multiple business nodes included in the enhanced AST can be mapped to multiple business parameters, and the business event data can be converted into business event description information corresponding to the business parameters. Based on the multiple business parameters and the business event description information, a component description file corresponding to the component source code can be generated. The method provided in this application can convert component source code into target business-related business parameters and business event description information through code parsing and semantic enhancement, achieving the conversion from component source code to natural text language. The generated component description file has high accuracy and high applicability. Therefore, the component description file generation method provided in this application embodiment can improve user experience and enhance the market competitiveness of products, providing a component description file generation solution with high accuracy and readability for various enterprises.

[0049] Based on the above description of the component description file generation method, this application also discloses a component description file generation apparatus. This apparatus can be applied to the component description file generation method provided in the foregoing embodiments to execute the steps in the component description file generation method. That is, the component description file generation apparatus can be the one described above. Figure 3 The execution body in the component description file generation method of the illustrated embodiment. See also... Figure 4 , Figure 4 This is a schematic diagram of the component description file generation apparatus provided in an embodiment of this application. Figure 4 As shown in this embodiment, the component description file generation device 40 can operate the following modules: The source code parsing module 401 is used to obtain the component source code and perform multi-level structural parsing on the application programming interface (API) syntax structure included in the component source code to generate an abstract syntax tree corresponding to the component source code. The abstract syntax tree includes multiple business nodes associated with the target business. The aforementioned source code parsing module 401 is further configured to perform data parsing on the aforementioned abstract syntax tree to obtain instruction constraint data of the first business node and data flow dependency data of the second business node, and to annotate the instruction constraint data for the first business node and the data flow dependency data for the second business node in the aforementioned abstract syntax tree to generate an enhanced abstract syntax tree. The first business node is a business node with instruction constraints among the aforementioned multiple business nodes, and the second business node is a business node with data flow dependency among the aforementioned multiple business nodes. The enhanced abstract syntax tree includes the aforementioned multiple business nodes and business event data, and the business event data includes the instruction constraint data and the data flow dependency data. Semanticization module 402 is used to obtain the domain terminology knowledge graph of the target business, which includes the mapping relationship between nodes and business parameters, as well as the mapping relationship between business event data and business event description information. The semanticization module 402 is further configured to, based on the enhanced abstract syntax tree and the domain terminology knowledge graph, map the multiple business nodes included in the enhanced abstract syntax tree to multiple business parameters, convert the business event data included in the enhanced abstract syntax tree into business event description information corresponding to the multiple business parameters, and generate a component description file corresponding to the component source code based on the multiple business parameters and the business event description information.

[0050] In some feasible implementations, the aforementioned source code parsing module 401 is used for: The multi-mode parser performs multi-level structural parsing on the various API syntaxes used in the source code of the above components, and maps the parsed API syntax structures into multiple syntax nodes in an intermediate representation to generate an abstract syntax tree corresponding to the source code of the above components. The abstract syntax tree contains the above multiple syntax nodes, which include the above multiple business nodes. The above multiple API syntaxes include Options API syntax or Composition API syntax.

[0051] In some feasible implementations, the aforementioned source code parsing module 401 is used for: Identify the instruction constraints on the multiple syntax nodes in the abstract syntax tree to obtain the instruction constraint data of the first business node in the component source code. The first business node is a syntax node with instruction constraints among the multiple syntax nodes. The instruction constraints include at least one of conditional rendering instruction constraints, list rendering instruction constraints, show or hide instruction constraints, or binding instruction constraints. The abstract syntax tree is parsed based on the symbol table. The variables referenced by the multiple syntax nodes in the abstract syntax tree are recorded, and the data flow dependency data of the multiple syntax nodes is obtained to obtain the data flow dependency data of the second business node. The second business node is a syntax node that has a data flow dependency relationship with the multiple syntax nodes.

[0052] In some feasible implementations, the aforementioned source code parsing module 401 is used for: The symbol table records the definition information and transit relationships of each variable referenced by the multiple syntax nodes in the above abstract syntax tree. Based on the definition information and transit relationships of the above variables, a data flow dependency graph is generated to record the variables referenced by the above multiple syntax nodes in the above abstract syntax tree.

[0053] In some feasible implementations, the aforementioned source code parsing module 401 is used for: When any of the above variables are defined multiple times in the various API syntaxes, the timestamp-based priority strategy retains the definition information declared at the time most recently defined, and uses it as the definition information for any of the above variables.

[0054] In some feasible implementations, the semanticization module 402 described above is used for: A multilingual adapter based on federated learning is used to obtain the language type corresponding to the above target business. Based on the language type corresponding to the target business, the above-mentioned multiple business parameters and business event description information are transformed into text language types, and the component description file corresponding to the above-mentioned component source code is generated based on the transformed multiple business parameters and business event description information.

[0055] In some feasible implementations, the component description document generation apparatus 40 further includes a change detection module 403, used for: When a syntax change is detected in the source code of the aforementioned components, the business nodes affected by the syntax change are located, the business parameters corresponding to the affected business nodes in the component description file are changed, and the text related to the updated business parameters is highlighted in the component description file; or When a change in a variable in the source code of the aforementioned component is detected, the business event data affected by the variable change is located based on the aforementioned data flow dependency relationship. The business event description information corresponding to the business event data affected by the variable change in the aforementioned component description file is changed, and the text related to the updated business event description information is highlighted in the aforementioned component description file.

[0056] In some feasible implementations, the component description file generation apparatus 40 further includes a condition detection module 404, used for: Based on the reactive logic, the target instruction constraints of the interface are obtained to determine the effective conditions of the target instruction constraints, which serve as conditions indicating the availability of the component description file. The aforementioned target instruction constraints include at least one of the following: conditional rendering instruction constraints, list rendering instruction constraints, show or hide instruction constraints, or binding instruction constraints.

[0057] In the embodiments of this application, the above Figure 4 The modules in the illustrated device can be individually or entirely combined into one or more other modules, or some of the modules can be further divided into multiple functionally smaller modules. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can be implemented by multiple modules, or the function of multiple modules can be implemented by one module. In other feasible implementations of this application, the above device may also include other modules. In practical applications, these functions can also be implemented with the assistance of other modules, and can be implemented collaboratively by multiple modules, without limitation.

[0058] In some feasible implementations, the above Figure 3 The implementation methods provided for each step in the component description file generation method shown can be derived from... Figure 4 The various modules of the illustrated device are executed. For example, the above... Figure 3 In the component description file generation method shown, steps S301 and S302 can be generated by... Figure 4 The source code parsing module 401 in the device shown executes steps S303 and S304, which can be performed by... Figure 4 The semantic markup module 402 in the illustrated device is executed. The implementation method of this module can be found in the implementation methods provided in the various steps of the above embodiments, and will not be repeated here.

[0059] In summary, the component description file generation apparatus provided in this application embodiment comprises at least a source code parsing module and a semantic markup module, and may further include functional modules such as a change detection module and a condition detection module. It can acquire component source code, perform multi-level structural parsing of the component source code to generate an abstract syntax tree (AST) corresponding to the component source code, and then perform data parsing on the AST to obtain instruction constraint data and data flow dependency data. Based on the instruction constraint data and data flow dependency data, it can annotate multiple business nodes in the AST with business event data to generate an enhanced AST. Furthermore, based on the domain terminology knowledge graph of the target business and the enhanced AST, it can map the multiple business nodes included in the enhanced AST to multiple business parameters, convert the business event data into business event description information corresponding to the business parameters, and then generate a component description file corresponding to the component source code based on the multiple business parameters and the business event description information. The method provided in this application embodiment can convert component source code into business parameters and business event descriptions related to the target business through code parsing and semantic enhancement, thereby achieving the conversion from component source code to natural text language. The generated component description file has high accuracy and high applicability. Therefore, the component description file generation method provided in this application embodiment can improve user experience and enhance product market competitiveness, providing various enterprises with a highly accurate and readable component description file generation solution.

[0060] See Figure 5 , Figure 5 A schematic diagram of the structure of a computer device provided in an embodiment of this application. For example... Figure 5 As shown, the computer device 20 can be used for the above-mentioned Figures 1 to 3 The computer device in the corresponding embodiment. The computer device 20 may include: a processor 201, a network interface 204, and a memory 205. Furthermore, the computer device 20 may also include: a user interface 203, and at least one communication bus 202. The communication bus 202 is used to enable communication between these components. The user interface 203 may include a display screen and a keyboard; optionally, the user interface 203 may also include a standard wired interface or a wireless interface. The network interface 204 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 205 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. The memory 205 may also optionally be at least one storage device located remotely from the aforementioned processor 201. Figure 5As shown, the memory 205, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0061] The network interface 204 in the computer device 20 can also be connected to the aforementioned Figure 1 The service device 200c in the corresponding embodiment is connected to the network, and the optional user interface 203 may further include a display screen and a keyboard. Figure 5 In the computer device 20 shown, the network interface 204 provides network communication functionality; the user interface 203 is mainly used to provide an input interface for the user, such as allowing the user to input component source code via a keyboard; and the processor 201 can be used to call the device control application stored in the memory 205 to implement the aforementioned... Figure 3 The method for generating component description files in the corresponding embodiments.

[0062] It should be understood that the computer device 20 described in the embodiments of this application can perform the foregoing... Figure 3 The description of the component description file generation method in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0063] Optionally, the processor 201 mentioned above can be one or more.

[0064] Optionally, the aforementioned memory 205 can be one or more.

[0065] Optionally, the memory 205 and the processor 201 can be integrated together or set separately.

[0066] Furthermore, embodiments of this application also provide a computer-readable storage medium storing computer instructions, which, when executed on a computer, cause the methods in the various method embodiments of this application to be performed.

[0067] This application also provides a computer program product, which includes computer program code or instructions, such that when the computer program code or instructions are run on a computer, the methods in the various method embodiments of this application are executed.

[0068] Furthermore, this application also provides a chip including a processor. A memory for storing a computer program is provided independently of the chip, and the processor is used to execute the computer program stored in the memory, so that the methods in the various method embodiments of this application are performed.

[0069] Furthermore, the chip may also include a communication interface. This communication interface can be an input / output interface or an interface circuit, etc. Furthermore, the chip may also include a memory.

[0070] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with the ability to process signals. In implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a central processing unit (CPU), or 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, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware encoding processor, or implemented by a combination of hardware and software modules in the encoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0071] The memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), and synchronous link dynamic memory (SLDRAM).

[0072] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory can be integrated into the processor.

[0073] It should also be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0074] The term "comprising," and any variations thereof, in the specification, claims, and drawings of this application are intended to cover a non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or modules is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other steps or modules inherent to such processes, methods, apparatus, products, or devices.

[0075] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0076] The methods and related apparatuses provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0077] The above embodiments further illustrate the purpose, technical solution, and advantages of the present invention. It should be understood that the above are merely embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for generating a component description file, characterized in that, include: Obtain the component source code and perform multi-level structural parsing on the application programming interface (API) syntax structure included in the component source code to generate an abstract syntax tree corresponding to the component source code. The abstract syntax tree includes multiple business nodes associated with the target business. The abstract syntax tree is parsed to obtain instruction constraint data of the first business node and data flow dependency data of the second business node. The instruction constraint data is annotated for the first business node in the abstract syntax tree, and the data flow dependency data is annotated for the second business node in the abstract syntax tree to generate an enhanced abstract syntax tree. The first business node is a business node with instruction constraints among the plurality of business nodes, and the second business node is a business node with data flow dependencies among the plurality of business nodes. The enhanced abstract syntax tree includes the plurality of business nodes and business event data, and the business event data includes the instruction constraint data and the data flow dependency data. Obtain a domain terminology knowledge graph for the target business, which includes the mapping relationship between nodes and business parameters, as well as the mapping relationship between business event data and business event description information; Based on the enhanced abstract syntax tree and the domain terminology knowledge graph, the multiple business nodes included in the enhanced abstract syntax tree are mapped to multiple business parameters, the business event data included in the enhanced abstract syntax tree are converted into business event description information corresponding to the multiple business parameters, and a component description file corresponding to the component source code is generated based on the multiple business parameters and the business event description information.

2. The method according to claim 1, characterized in that, The step of performing multi-level structural parsing of the application programming interface (API) syntax structure included in the component source code to generate the abstract syntax tree corresponding to the component source code includes: The multi-mode parser performs multi-level structure parsing on the various API syntaxes used in the component source code, and maps the parsed API syntax structures into multiple syntax nodes in an intermediate representation form to generate the abstract syntax tree corresponding to the component source code. The abstract syntax tree contains multiple syntax nodes, which include multiple business nodes, and the multiple API syntaxes include Options API syntax or Composition API syntax.

3. The method according to claim 2, characterized in that, The step of parsing the abstract syntax tree to obtain instruction constraint data of the first business node and data flow dependency data of the second business node includes: Identify the instruction constraints on the plurality of syntax nodes in the abstract syntax tree to obtain the instruction constraint data of the first business node in the component source code, wherein the first business node is a syntax node with instruction constraints among the plurality of syntax nodes, and the instruction constraints include at least one of conditional rendering instruction constraints, list rendering instruction constraints, show or hide instruction constraints, or binding instruction constraints. The abstract syntax tree is parsed based on the symbol table, the variables referenced by the multiple syntax nodes in the abstract syntax tree are recorded, and the data flow dependency data of the multiple syntax nodes is obtained, so as to obtain the data flow dependency data of the second business node, wherein the second business node is the syntax node with data flow dependency among the multiple syntax nodes.

4. The method according to claim 3, characterized in that, The process of parsing the abstract syntax tree based on the symbol table, and recording the variables referenced by the multiple syntax nodes in the abstract syntax tree, includes: The symbol table records the definition information and transit relationships of each variable referenced by the multiple syntax nodes in the abstract syntax tree; Based on the definition information and transit relationships of each variable, a data flow dependency graph is generated to record the variables referenced by the multiple syntax nodes in the abstract syntax tree.

5. The method according to claim 4, characterized in that, Before generating the data flow dependency graph based on the definition information and transit relationships of the various variables, the method further includes: When any variable is defined multiple times in the various API syntaxes, the timestamp-based priority strategy retains the definition information declared at the time most recently defined, and uses it as the definition information for any variable.

6. The method according to claim 5, characterized in that, The step of generating a component description file corresponding to the component source code based on the multiple business parameters and the business event description information includes: A multilingual adapter based on federated learning is used to obtain the language type corresponding to the target service. Based on the language type corresponding to the target business, the multiple business parameters and the business event description information are transformed into text language types, and a component description file corresponding to the component source code is generated based on the transformed multiple business parameters and the business event description information.

7. The method according to claim 6, characterized in that, The method further includes: When a syntax change is detected in the component's source code, the business nodes affected by the syntax change are located, the business parameters corresponding to the affected business nodes in the component description file are changed, and text related to the updated business parameters is highlighted in the component description file; or When a variable change is detected in the component source code, the business event data affected by the variable change is located based on the data flow dependency relationship. The business event description information corresponding to the business event data affected by the variable change in the component description file is changed, and the text related to the updated business event description information is highlighted in the component description file.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Based on the reactive logic, the target instruction constraints of the interface are obtained, and the effective conditions of the target instruction constraints are used as conditions to indicate the availability of the component description file. The target instruction constraint includes at least one of the following: conditional rendering instruction constraint, list rendering instruction constraint, show or hide instruction constraint, or binding instruction constraint.

9. A component description file generation apparatus, characterized in that, include: The source code parsing module is used to obtain the component source code and perform multi-level structural parsing on the application programming interface (API) syntax structure included in the component source code to generate an abstract syntax tree corresponding to the component source code. The abstract syntax tree includes multiple business nodes associated with the target business. The source code parsing module is further configured to parse the abstract syntax tree to obtain instruction constraint data of the first business node and data flow dependency data of the second business node, and to annotate the instruction constraint data for the first business node and the data flow dependency data for the second business node in the abstract syntax tree to generate an enhanced abstract syntax tree. The first business node is a business node with instruction constraints among the plurality of business nodes, and the second business node is a business node with data flow dependencies among the plurality of business nodes. The enhanced abstract syntax tree includes the plurality of business nodes and business event data, and the business event data includes the instruction constraint data and the data flow dependency data. The semantic module is used to obtain a domain terminology knowledge graph of the target business, which includes the mapping relationship between nodes and business parameters, as well as the mapping relationship between business event data and business event description information. The semanticization module is further configured to, based on the enhanced abstract syntax tree and the domain terminology knowledge graph, map the multiple business nodes included in the enhanced abstract syntax tree to multiple business parameters, convert the business event data included in the enhanced abstract syntax tree into business event description information corresponding to the multiple business parameters, and generate a component description file corresponding to the component source code based on the multiple business parameters and the business event description information.

10. A computer device, characterized in that, The computer device includes a processor and memory; The memory is connected to the processor, wherein the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and executed as described in any one of claims 1 to 8.

Images