Code document generation method and device

Abstract

This application provides a code documentation generation method and apparatus. The code documentation generation method includes: acquiring relevant information of target code; determining a hierarchical dependency structure between visual objects based on the relevant information of the target code; wherein the hierarchical dependency structure between visual objects is used to characterize the hierarchical dependencies between code elements; responding to a user-triggered document generation command to generate a target document based on the relevant information of the target code and the unique index identifiers of the visual objects; and presenting the hierarchical dependencies between the code elements based on the unique index identifiers of the visual objects. This application can improve the efficiency of code documentation generation and facilitate users in tracing the dependencies between code elements.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method and apparatus for generating code documentation. Background Technology

[0002] Currently, during project development, it is usually necessary to prepare technical documents, and various traceability relationships need to be established during the review process, such as the traceability relationship between requirements and modules, the traceability relationship between modules and classes / components, the traceability relationship between classes / components and functions, and the traceability relationship between functions and unit tests. These tasks are complex and time-consuming, and are usually modified multiple times due to changes in the requirement code, resulting in a large investment of manpower. Summary of the Invention

[0003] The purpose of this application is to provide a code documentation generation method and apparatus to improve the above-mentioned problems existing in the prior art.

[0004] Firstly, this application provides a method for generating code documentation, the method comprising: Obtain relevant information about the target code; The hierarchical dependency structure between visual objects is determined based on relevant information in the target code; wherein, the hierarchical dependency structure between visual objects is used to represent the hierarchical dependency relationship between code elements; In response to user-triggered document generation commands, the system generates the target document based on relevant information from the target code and the unique index identifiers of the visual objects, enabling users to obtain the hierarchical dependencies between code elements based on the unique index identifiers of the visual objects.

[0005] In the above implementation process, by acquiring relevant information from the target code, the system can respond to user-triggered document generation commands and automatically generate target documents based on the relevant information from the target code and the unique index identifiers of the visualized objects, without the need for manually writing template documents, thereby improving document generation efficiency. On the other hand, the relevant information from the target code can determine the hierarchical dependency structure between visualized objects, making it easier for users to obtain the hierarchical dependencies between code elements based on the unique index identifiers in the automatically generated template document, thus avoiding the need to manually construct the hierarchical dependencies between code elements and saving labor costs.

[0006] In an optional implementation, the relevant information of the target code includes the project name of the target code, the module name of the target code, the function information of the target code, the class information of the target code, the interface information of the target code, the component information of the target code, and the unit test information of the target code. In addition, obtain relevant information about the target code, including: Given that the target code's workspace is open, obtain the name of the workspace and set the workspace name as the project name; Respond to user module naming instructions for the target code to determine the module name based on the module naming instructions; The target code is parsed to obtain function information, class information, interface information, component information, and unit test information.

[0007] In the above implementation, if the target code's workspace is open, the project name can be automatically obtained based on the user's open workspace, eliminating the need for manual input and preventing users from entering incorrect project names. Furthermore, user-inputted module naming commands can be responded to interactively, allowing users to customize module names. On the other hand, parsing the target code can automatically obtain information such as functions, classes, components, interfaces, and unit tests, avoiding manual code analysis and thus improving the efficiency of obtaining this information.

[0008] In an optional implementation, the target code is parsed to obtain function information, class information, interface information, component information, and unit test information, including: Determine the project type of the target code; The target code is parsed based on the project type to obtain function information, class information, interface information, component information, and unit test information.

[0009] In the above implementation process, the target code can be parsed based on the project type of the target code, thereby adapting to the parsing of code of different project types and avoiding parsing errors caused by the mismatch between the project type and the parser.

[0010] In an optional implementation, the project type of the target code is determined, including: Obtain the absolute file system path of the target code; Based on the absolute path of the file system, detect whether there are mini-program configuration files or feature page files in the workspace; If a mini-program configuration file or feature page file exists, the project type will be determined as a mini-program. If no mini-program configuration file is available and no characteristic page file is detected, the project type will be determined as a Web project type.

[0011] During the above implementation process, the project type can be automatically and accurately identified based on whether a preset mini-program configuration file or feature page file exists in the workspace. That is, if a mini-program configuration file or feature page file exists, the project type is determined to be a mini-program type; if no mini-program configuration file or feature page file exists, the project type is determined to be a web project type, thus avoiding manual misjudgment of the project type.

[0012] In an optional implementation, the target code is parsed based on its project type to obtain function information, class information, interface information, component information, and unit test information, including: The target code is parsed based on the project type to obtain the abstract syntax tree of the target code; Based on the abstract syntax tree, we obtain function information, class information, interface information, component information, and unit test information.

[0013] In the above implementation process, the target code is accurately parsed by the project type to obtain the corresponding abstract syntax tree. Based on the automatic parsing of the abstract syntax tree, the function information, class information, interface information, component information and unit test information required to generate the target document are obtained, avoiding incorrect parsing of the target code based on the wrong project type.

[0014] In an optional implementation, function information, class information, interface information, component information, and unit test information are obtained based on the abstract syntax tree, including: Traverse all nodes in the abstract syntax tree to obtain all function nodes in the abstract syntax tree; where function nodes in the abstract syntax tree include nodes defined based on arrow function expressions, nodes defined based on function expressions, nodes defined based on method declarations, and nodes defined based on function declarations; Extract function data from function nodes; Based on the function data of the function nodes, we can obtain function information, class information, interface information, component information, and unit test information.

[0015] In the above implementation process, by traversing all nodes in the abstract syntax tree, all function nodes can be identified, thereby ensuring the integrity of functions and other related information and avoiding the omission of information about functions, classes, and other elements.

[0016] In an optional implementation, the function information includes the function's identifier, parameter information, return value information, and comment information.

[0017] In the above implementation process, the function information includes the function's identifier, parameter information, return value information, and comment information, covering most of the data used in document generation, thus improving the level of detail in the document.

[0018] In an optional implementation, the hierarchical dependency structure between visual objects is determined based on relevant information in the target code, including: The relevant information based on the target code is input into the project management tool to generate visual objects; these visual objects are task items in the project management tool. The hierarchical dependency structure between visual objects is determined based on the hierarchical dependencies between code elements.

[0019] In the above implementation process, by inputting relevant information of the target code into the project management tool, the project management tool can be used to construct visual objects through its task items, and the hierarchical dependency structure between visual objects can be determined based on the hierarchical dependency relationship between code elements, allowing users to trace the hierarchical dependency relationship between code elements based on the visual objects.

[0020] In an optional implementation, the document generation instructions include a document type; In addition, in response to user-triggered document generation commands, the system generates the target document based on relevant information from the target code and the unique index identifier of the visual object, including: Determine the document template based on the document type; The target document is generated based on the document template, relevant information of the target code, and the unique index identifier of the visual object.

[0021] In the above implementation process, it can respond to the document type specified by the user, and then generate a document of the type specified by the user based on the document template corresponding to that document type, so as to flexibly generate the target document according to the user's document type requirements.

[0022] Secondly, this application provides a code documentation generation apparatus, the apparatus comprising: The acquisition module is used to obtain relevant information about the target code; The determination module is used to determine the hierarchical dependency structure between visual objects based on relevant information of the target code; wherein, the hierarchical dependency structure between visual objects is used to characterize the hierarchical dependency relationship between code elements; The response module is used to respond to user-triggered document generation commands, generate target documents based on relevant information of the target code and unique index identifiers of visual objects, and enable users to obtain hierarchical dependencies between code elements based on the unique index identifiers of visual objects.

[0023] In the above implementation process, by acquiring relevant information from the target code, the system can respond to user-triggered document generation commands and automatically generate target documents based on the relevant information from the target code and the unique index identifiers of the visualized objects, without the need for manually writing template documents, thereby improving document generation efficiency. On the other hand, the hierarchical dependency structure between visualized objects can be determined through the relevant information from the target code, making it easier for users to obtain the hierarchical dependencies between code elements based on the unique index identifiers in the automatically generated template document. This avoids the need for users to manually construct the hierarchical dependencies between code elements, saving labor costs.

[0024] Thirdly, this application provides an electronic device, comprising: Processor; and The memory is configured to store machine-readable instructions that, when executed by a processor, perform the method as described in any of the foregoing embodiments.

[0025] In the above implementation process, the processor calls the program instruction in real time, thereby automatically obtaining relevant information of the target code and automatically generating hierarchical dependencies between visual objects based on the relevant information of the target code. Then, when the user triggers the document generation instruction, it automatically generates a document with unique indexes of visual objects based on the information of the target code. This allows the user to trace the hierarchical dependencies between code elements based on the unique indexes of the visual objects and the hierarchical dependencies between the visual objects, ultimately achieving automatic document generation without manually extracting relevant information of the target code and avoiding the need for users to manually construct hierarchical dependencies between code elements, thereby saving labor costs.

[0026] Fourthly, this application provides a storage medium storing a computer program, which is executed by a processor using the method described in any of the foregoing embodiments.

[0027] In the above implementation process, the computer-readable storage medium completely solidifies the power control method into computer program instructions. When the medium is read and run by the processor, the processor automatically acquires the relevant information of the target code according to the instructions, and automatically generates the hierarchical dependency relationship between the visual objects based on the relevant information of the target code. Then, when the user triggers the document generation instruction, the document with a unique index of the visual object is automatically generated according to the information of the target code. The user can trace the hierarchical dependency relationship between code elements based on the unique index of the visual object and the hierarchical dependency relationship between the visual objects, and finally realize the automatic generation of the document without manually extracting the relevant information of the target code and avoiding the need for the user to manually build the hierarchical dependency relationship between code elements, thereby saving human input costs. Attached Figure Description

[0028] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a schematic diagram of a code documentation generation method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a code document generation device provided in an embodiment of this application; Figure 3 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0031] Please see Figure 1 , Figure 1 This is a flowchart illustrating a code documentation generation method provided in an embodiment of this application. Figure 1 As shown, this code documentation generation method includes the following steps: 101. Obtain relevant information about the target code; 102. Determine the hierarchical dependency structure between visual objects based on relevant information in the target code; wherein, the hierarchical dependency structure between visual objects is used to represent the hierarchical dependency relationship between code elements; 103. Respond to the document generation command triggered by the user, generate the target document based on the relevant information of the target code and the unique index identifier of the visual object, and enable the user to obtain the hierarchical dependency relationship between code elements based on the unique index identifier of the visual object.

[0032] In this embodiment, target code refers to the collection of source code for the document to be generated, including but not limited to source files implemented in various computer languages. For example, target code can be front-end JavaScript project code or back-end Java service class code.

[0033] In this embodiment, the relevant information of the target code refers to various types of structured or semi-structured data that are directly associated with the target code to be processed and can be used for parsing, analysis, document generation or visualization. It may include metadata of code elements, such as function names, class names, parameter lists, access modifiers, etc., as well as project context information, such as project type, module affiliation, file path, dependency configuration, etc.

[0034] In this embodiment, a visual object refers to an abstract task item or node element used to represent code elements in a graphical interface. For example, it can be a task card in the Jira project management tool or a node in a Mermaid flowchart.

[0035] In this embodiment, code elements refer to a collection of program units in the target code that have independent semantics, can be uniquely identified, and undertake specific functions or structural responsibilities. These may include modules, components, classes, functions, interfaces, and unit tests. Further, a module refers to a collection of code that implements a specific function, corresponding to a file or namespace, used to encapsulate variables, functions, classes, etc., to achieve code isolation and reuse. A component refers to a smaller collection of code that implements a specific function compared to a module. An interface, in typed languages ​​(such as TypeScript and Java), is used to define object contracts or behavioral specifications, without containing a specific implementation. A function refers to a callable unit that performs a specific calculation or operation, including ordinary functions, arrow functions, methods, etc. A class refers to an encapsulation unit in object-oriented programming, used to encapsulate data attributes and behaviors, and supports inheritance and polymorphism.

[0036] In this embodiment, the hierarchical dependency structure refers to the hierarchical structure formed by logical relationships such as calls, inheritance, or composition between code elements. For example, the "Order Service" class is the top-level node, and its internal method createOrder() calls the checkStock() method of the "Inventory Service" class and the getUserInfo() method of the "User Service" class; while InventoryService further depends on the database access component (DbConnector).

[0037] In this implementation, the hierarchical dependency structure can be represented by a tree diagram. For example, projects, modules, components or classes, functions, interfaces, and unit tests constitute a tree diagram, where the project is the root node.

[0038] In this embodiment, one specific way to obtain relevant information about the target code is to scan the project directory through an integrated development environment (IDE) plugin to extract structural information such as functions, classes, and interfaces from the source code. Alternatively, static code analysis tools can be used to analyze the code library and generate metadata containing code elements and their interrelationships. Here, the integrated development environment can refer to VSCode, which stands for Visual Studio Code, a source code editor.

[0039] In this embodiment, a specific way to determine the hierarchical dependency structure between visualization objects based on relevant information of the target code can be as follows: First, extract relevant information of code elements based on relevant information of the target code, and construct visualization objects based on relevant information of code elements. Each code element corresponds to one visualization object; for example, a function corresponds to an issue in the Jira project management tool, where an issue in the Jira project management tool refers to a task item in the Jira project management tool. Then, extract the hierarchical dependencies between code elements and other code elements based on relevant information of the target code. Finally, construct the hierarchical dependency structure between visualization objects based on the hierarchical dependencies between code elements and other code elements. It should be noted that the Jira project management tool refers to a project management tool named Jira.

[0040] In this embodiment, the hierarchical dependency structure between visual objects can be stored in a database associated with Jira project management. When the hierarchical dependency structure between visual objects is needed, it is read from this database. This database can be a database such as MySQL. In this implementation, a "Generate Document" button can be added to the IDE toolbar. When the user clicks it, it is considered that the user has triggered a document generation command. In addition, the user can also trigger a document generation command through the command line tool.

[0041] In this embodiment, the unique index identifier of the visual object refers to the identifier used to locate the visual object. After the target document is automatically generated, if the user needs to trace the dependency relationship between a function and other code elements (such as modules, classes, and components), the relevant information of the extracted target code can be imported into the Jira project management tool. The Jira project management tool automatically generates a tree diagram based on the relevant information. The tree diagram includes several nodes, and the hierarchical relationship between each node corresponds to the hierarchical relationship between code elements.

[0042] In this embodiment, the visual object corresponding to the function can be located based on the unique index identifier. The Jira project management tool then queries the data associated with the unique index identifier of the visual object. The data associated with the unique index identifier includes other visual objects associated with the visual object and its own attributes. For example, the user inputs the unique index identifier of the visual object A corresponding to the function f1 in the target document into the Jira project management tool. The Jira project management tool queries the database for other visual objects associated with the visual object and its own attributes. The user can then see other visual objects associated with the visual object A and its own attributes based on the data returned by the Jira project management tool, that is, see other code elements associated with the function f1 and its own attributes.

[0043] In this embodiment, when creating a visualization object, each visualization object is assigned a unique index identifier. The unique index identifier can be generated based on information such as the document name and project name. For example, the document name, project name, and other information can be input into the MD5 algorithm to obtain a unique identifier, which is the unique index identifier of the visualization object.

[0044] In this implementation, presenting the hierarchical dependencies between code elements can refer to displaying these dependencies using a tree diagram. For example, function F depends on component G, and component G depends on module S. In this case, module S is the root node of the tree diagram, component G is a child node of module S, and function F is a byte node of component G. Furthermore, since IDEs (such as VSCode and IntelliJ IDEA) commonly use tree-shaped sidebars to display project structures or API levels, users have already formed usage habits. Using a tree diagram to present dependencies can seamlessly integrate into existing workflows and reduce the learning cost for users.

[0045] In this embodiment, presenting the hierarchical dependencies between code elements can also refer to presenting the hierarchical dependencies between code elements in the form of a mind map.

[0046] In the above implementation process, by acquiring relevant information from the target code, the system can respond to user-triggered document generation commands and automatically generate target documents based on the relevant information from the target code and the unique index identifiers of the visualized objects, without the need for manually writing template documents, thereby improving document generation efficiency. On the other hand, the relevant information from the target code can determine the hierarchical dependency structure between visualized objects, making it easier for users to obtain the hierarchical dependencies between code elements based on the unique index identifiers in the automatically generated template document, thus avoiding the need to manually construct the hierarchical dependencies between code elements and saving labor costs.

[0047] To illustrate the above implementation process, consider this example: In traditional software development, a company needed to maintain API documentation for a system containing over 200 microservices. Each system upgrade required three dedicated documentation engineers to spend two weeks updating the documentation, and inconsistencies between the documentation and the code frequently occurred, necessitating additional clarification from the integration team. The average debugging time for each API call was as long as four hours. Using this method, the development team only needs to click the "Generate Documentation" button once to obtain complete and accurate documentation within 15 minutes. This not only shortens the documentation update cycle from two weeks to one day but also reduces API call debugging time to 30 minutes, significantly improving documentation generation efficiency.

[0048] In an optional implementation, the relevant information of the target code includes the project name, module name, function information, class information, interface information, component information, and unit test information of the target code. Obtaining the relevant information of the target code includes the following sub-steps: Given that the target code's workspace is open, obtain the name of the workspace and set the workspace name as the project name; Respond to user module naming instructions for the target code to determine the module name based on the module naming instructions; The target code is parsed to obtain function information, class information, interface information, component information, and unit test information.

[0049] In this embodiment, function information refers to metadata about the function extracted from the code, including function name, parameter list, return type, access modifier, file location, and call relationship.

[0050] In this implementation, class information refers to the structural information of a class extracted from object-oriented code, such as class name, inheritance relationship, member variables, method list, access control, annotations / decorators, etc.

[0051] In this embodiment, interface information refers to the relevant information of the interface defined in the program, including the interface name, the declared method signature, the class that implements the interface, generic parameters, etc.

[0052] In this embodiment, component information refers to the information of functional modules in the software system that can be deployed or reused independently, including component name, dependencies, exposed services, etc.

[0053] In this implementation, unit test information refers to metadata related to unit tests, such as test class / function name, mapping relationship of the function under test, test coverage, number of assertions, test framework (such as JUnit, pytest), etc.

[0054] In this implementation, the workspace refers to the root directory of the currently loaded project in the integrated development environment (IDE). For example, the workspace can be the Workspace Folder in VS Code or the ProjectRoot in IntelliJ IDEA.

[0055] In this embodiment, the module name refers to the logical division label of the code functional unit by the user. For example, it can be a name such as "user authentication module" or "product management module".

[0056] In this embodiment, code parsing refers to the process of extracting program structure information through syntax analysis. This can refer to generating an AST (Abstract Syntax Tree) based on lexical analysis and syntax analysis, or extracting comment blocks based on regular expression matching.

[0057] In the above implementation, obtaining the workspace name includes: reading the standard metadata file in the workspace root directory and extracting its naming field as the project name. This method can obtain the naming convention and project name, avoiding the use of temporary or test names. For example, even if the local directory name is "test_project_v2", the system still uses the official name in the configuration file to ensure the correctness of the project name.

[0058] In the above implementation, obtaining the workspace name also includes: if no standard configuration file is found, using the workspace directory name as the default name and providing an entry point for modification. This method is compatible with non-standard or script-based projects, improving applicability. For example, for small toolsets without configuration files, the system automatically names them and allows users to confirm with one click, simplifying the operation process.

[0059] In the above implementation, one specific way to respond to the user's naming instruction for the functional area is to allow the user to select a text item from the drop-down list as the name in the graphical interface.

[0060] In the above implementation, if the target code's workspace is open, the project name can be automatically obtained based on the user's open workspace, eliminating the need for manual input and preventing users from entering incorrect project names. Furthermore, user-inputted module naming commands can be responded to interactively, allowing users to customize module names. On the other hand, parsing the target code can automatically obtain information such as functions, classes, components, interfaces, and unit tests, avoiding manual code analysis and thus improving the efficiency of obtaining this information.

[0061] For example, in the traditional approach, users need to manually enter the project name and manually assign each code section, which is not only time-consuming but also prone to inconsistencies between the subsequent documentation and the actual code due to spelling errors or path confusion. However, according to the technical solution of this embodiment, when a user opens a project in the development environment, the system can automatically read the project name from the workspace, eliminating the need for the user to type it again and avoiding name discrepancies caused by manual input. For example, even if the local directory is temporarily renamed to a test name, the system can still extract the accurate project identifier from the internal configuration, ensuring the reliability of the basic information in the generated documentation.

[0062] In an optional implementation, the target code is parsed to obtain function information, class information, interface information, component information, and unit test information, including the following sub-steps: Determine the project type of the target code; The target code is parsed based on the project type to obtain function information, class information, interface information, component information, and unit test information.

[0063] In this embodiment, the project type is used to characterize the technology platform on which the target code is implemented. The target code can be implemented based on the mini-program technology platform or the web page technology platform. Therefore, the project type of the target code can include mini-program type and web type.

[0064] In this embodiment, one specific way to determine the project type of the target code is to obtain the source code file of the target code and then identify the project type of the target code based on the suffix of the source code file.

[0065] In this embodiment, the mini-program may include mini-programs implemented on different platforms such as Alipay mini-programs and WeChat mini-programs.

[0066] In the above implementation process, the target code can be parsed based on the project type of the target code, thereby adapting to the parsing of code of different project types and avoiding parsing errors caused by the mismatch between the project type and the parser.

[0067] For example, when the target code belongs to a WeChat Mini Program project, its code structure typically includes ".json configuration files", ".wxml template files", ".wxss style files", and ".js logic files", and the pages and components are defined through a specific registration method. If a general Web project parser is used to process it directly, it may fail to recognize methods or custom component properties, resulting in the failure to extract class or component information. Conversely, if the target code is a typical Web project (such as a React-based front-end application), its core consists of JSX components, ES6 modules, and route configuration. The parser needs to understand import / export syntax, the structure of React functional components or class components, and the organization of Jest unit tests. Therefore, the system first identifies the project type, determining it to be a Mini Program by checking the app.json file in the project root directory, or a Web project by checking for the existence of React dependencies in package.json, and then calls the corresponding parsing module to accurately extract function, class, interface, component, and unit test information, effectively avoiding misjudgments or parsing interruptions caused by mismatch between the parser and the project structure.

[0068] In an optional implementation, determining the project type of the target code includes the following sub-steps: Obtain the absolute file system path of the target code; Based on the absolute path of the file system, detect whether there are mini-program configuration files or feature page files in the workspace; If a mini-program configuration file or feature page file exists, the project type will be determined as a mini-program. If no mini-program configuration file is available and no characteristic page file is detected, the project type will be determined as a Web project type.

[0069] In this embodiment, the mini-program configuration file refers to a specific file in the mini-program platform used to declare global or page configurations, such as app.json or page.json, which contains metadata such as page routes, window styles, and network permissions.

[0070] In this embodiment, the characteristic page file refers to the combination of page files with a distinctive structure in the mini-program project. It usually includes files with the same name such as ".js (logic)", ".json (configuration)", ".wxml (template)" and ".wxss (style)" (e.g., index.js + index.wxml), which are used to determine whether the project is a mini-program.

[0071] In this implementation, the Web project type refers to a standard Web application project that runs in a browser, typically based on HTML / CSS / JavaScript or modern front-end frameworks (such as React and Vue), and does not contain configurations or file structures specific to mini-programs.

[0072] During the above implementation process, the project type can be automatically and accurately identified based on whether a preset mini-program configuration file or feature page file exists in the workspace. That is, if a mini-program configuration file or feature page file exists, the project type is determined to be a mini-program type; if no mini-program configuration file or feature page file exists, the project type is determined to be a web project type, thus avoiding manual misjudgment of the project type.

[0073] For example, when a user imports a target code project, the tool first obtains its absolute file system path (e.g., / Users / developer / my_project) and uses this as the workspace root directory for scanning. If an app.json file (a typical WeChat Mini Program configuration file) is found in this directory, or a set of characteristic page files such as index.js, index.wxml, and index.wxss are also present, the system automatically identifies the project type as "Mini Program". Conversely, if neither app.json nor any Mini Program-specific files such as .wxml or .wxss are found, and only index.html, package.json, and React / Vue component files are detected, it is determined to be a "Web project". This automated identification mechanism based on file characteristics effectively avoids the problem of developers manually selecting the wrong project type due to negligence or lack of experience, thereby ensuring that subsequent code parsing, building, or testing processes can adapt to the correct technology stack, improving the accuracy of the toolchain and development efficiency.

[0074] In an optional implementation, the target code is parsed based on the project type to obtain function information, class information, interface information, component information, and unit test information, including the following sub-steps: The target code is parsed based on the project type to obtain the abstract syntax tree of the target code; Based on the abstract syntax tree, we obtain function information, class information, interface information, component information, and unit test information.

[0075] In this implementation, the Abstract Syntax Tree (AST) refers to the tree-like intermediate representation obtained after parsing the target code. It abstractly expresses the syntactic structure of the code using nodes, with each node corresponding to a syntactic element, such as a function declaration, variable declaration, or expression. Nodes form a hierarchical structure through parent-child relationships, reflecting the nested syntactic relationships within the code. The AST can be an ESTree AST or a TypeScript AST.

[0076] In this embodiment, a specific method for parsing the target code based on the project type to obtain the abstract syntax tree of the target code is as follows: A parser is determined based on the project type. Then, the target code is parsed using the parser to obtain the abstract syntax tree. For example, when the project type is a mini-program, the target code is parsed using a mini-program parser to obtain the abstract syntax tree of the mini-program code. It should be noted that the parser is a predefined line of code that can parse the code based on the syntactic characteristics of the target code, for example, based on the syntactic characteristics of a mini-program.

[0077] In the above implementation process, the target code is accurately parsed by the project type to obtain the corresponding abstract syntax tree. Based on the automatic parsing of the abstract syntax tree, the function information, class information, interface information, component information and unit test information required to generate the target document are obtained, avoiding incorrect parsing of the target code based on the wrong project type.

[0078] For example, when the target code belongs to a WeChat Mini Program project, its page logic is usually defined using Page({}) or Component({}) syntax. If it is incorrectly parsed as a regular Web project (such as a React application), the general JavaScript parser may not be able to correctly recognize the constructor semantics specific to these Mini Programs, resulting in the loss of component lifecycle methods or property declaration information in the Abstract Syntax Tree (AST). Conversely, if the system first determines that the project type is "Mini Program type," it will call a parser adapted to Mini Program syntax to accurately construct the AST and extract complete function information (such as onLoad), class / component structure, custom event interfaces, and corresponding unit test cases. For Web type projects (such as those using Vue or React), the parser focuses on features such as ES6 modules, JSX syntax, or Composition API to accurately restore component dependencies and function call relationships. By generating the AST based on the correct project type, the system can reliably extract various structured information needed to generate technical documentation, avoiding missing key content or misleading descriptions due to parsing errors.

[0079] In an optional implementation, obtaining function information, class information, interface information, component information, and unit test information based on the abstract syntax tree includes the following sub-steps: Traverse all nodes in the abstract syntax tree to obtain all function nodes in the abstract syntax tree; where function nodes in the abstract syntax tree include nodes defined based on arrow function expressions, nodes defined based on function expressions, nodes defined based on method declarations, and nodes defined based on function declarations; Extract function data from function nodes; Based on the function data of the function nodes, we can obtain function information, class information, interface information, component information, and unit test information.

[0080] In this implementation, a function node refers to a syntactic structure node in the Abstract Syntax Tree (AST) that represents a function definition. This node contains syntactic elements such as the function's name, parameter list, return type (if applicable), function body, and modifiers.

[0081] In this embodiment, function data refers to a set of structured metadata extracted from function nodes, including but not limited to function name, access permissions (such as public / private), parameter types and names, return value type, file path, class or module, documentation (such as JSDoc), and call relationships.

[0082] In this embodiment, function information can be a further organization and semantic expression of function data, used to describe the function's functionality, signature, and other data.

[0083] In this embodiment, the function data of the function node carries class information. Therefore, the class information can be extracted based on the function data of the function node. For example, the name of a function is usually composed of the module name, class name, etc. Therefore, the class name can be extracted based on the function name and used as the class information.

[0084] In the above implementation process, by traversing all nodes in the abstract syntax tree, all function nodes can be identified, thus ensuring the integrity of functions and related information and avoiding the omission of information about functions, classes, and other elements. For example, when the tool processes a TypeScript-based front-end project, it first parses the source code into an AST. Subsequently, the system recursively traverses every node in the AST, including module declarations, class definitions, interfaces, function expressions, arrow functions, method properties, etc., and identifies all nodes that conform to function semantics. Through this full-coverage traversal, not only can top-level independent functions be captured, but methods in classes can also be accurately extracted, and even anonymous functions in unit test files can be found. If only regular expression matching or partial scanning is relied upon, it is very easy to miss nested functions or logical units in higher-order components. The complete AST traversal mechanism can systematically collect all function nodes and further extract function information, class information, associated interfaces, and component context from them, thereby ensuring that the generated technical documents or analysis reports are complete, structurally sound, and semantically accurate.

[0085] In an optional implementation, the function information includes the function's identifier, parameter information, return value information, and comment information.

[0086] In this implementation, function identification information refers to the basic metadata used to uniquely identify and locate a function. This typically includes the function name, its scope (such as class name or module name), access modifiers, and its location in the source code. The function name refers to the function's declaration name. The scope path refers to the context path in which the function resides.

[0087] In this embodiment, the parameter information of a function refers to the structured information describing the input variables received by the function, including parameter name, type, default value, and whether it is optional. The parameter type refers to the data type of the parameter, such as string or number. The default value refers to the preset value used when the parameter is not passed. In this embodiment, the function's return value information refers to the type and semantic information describing the output result after the function is executed. This information may include the return type, possible exceptions, or the possibility of a null value. Furthermore, the return type refers to the data type of the function's return value. In this embodiment, function comment information refers to the documentation text embedded in the source code that explains the purpose, behavior, or usage of the function. It usually follows a specific format, and function comment information includes documentation comment blocks and structured comments.

[0088] In the above implementation process, function information includes function identification, parameter information, return value information, and comment information, covering most of the data used in documentation generation, thus improving the level of detail in the documentation. For example, when a tool analyzes a function, if its identification, parameter, return value, and comment information are fully extracted, a well-structured and content-rich API documentation entry can be automatically generated. Compared to the traditional method of only displaying the function name and simple signature, this documentation based on multi-dimensional function information not only explains "how to call" but also clarifies "what is passed, what is returned, and when it fails," greatly reducing the developer's understanding cost. Especially in large projects or open-source libraries, such high-fidelity documentation can effectively reduce communication errors and improve collaboration efficiency.

[0089] In an optional implementation, the hierarchical dependency structure between visual objects is determined based on relevant information from the target code, including the following sub-steps: The relevant information based on the target code is input into the project management tool to generate visual objects; these visual objects are task items in the project management tool. The hierarchical dependency structure between visual objects is determined based on the hierarchical dependencies between code elements.

[0090] In this embodiment, the project management tool can refer to Jira or other project management tools.

[0091] In the above implementation process, by inputting relevant information of the target code into the project management tool, a visual object can be constructed using the task items of the project management tool. Based on the hierarchical dependencies between code elements, the hierarchical dependency structure between these visual objects is determined, allowing users to trace the hierarchical dependencies between code elements based on the visual objects. Furthermore, this method combines the tracing of hierarchical dependencies between code elements with the project management tool. Users are typically professionals who operate the project management tool; therefore, when tracing the hierarchical dependencies between code elements using the project management tool, their familiarity with its operation improves tracing efficiency, avoiding the reduced efficiency caused by unfamiliarity with the tool.

[0092] In an optional implementation, the document generation instruction includes a document type; and, in response to a user-triggered document generation instruction, generating a target document based on relevant information of the target code and a unique index identifier of the visual object includes the following sub-steps: Determine the document template based on the document type; The target document is generated based on the document template, relevant information of the target code, and the unique index identifier of the visual object.

[0093] In the above implementation, document type refers to the classification of generated documents based on purpose, audience, or content structure, used to determine the format and content organization method of the target document.

[0094] In the above implementation, a document template refers to a predefined document structure and style framework, including placeholders, chapter layout, formatting specifications, etc., which is used to dynamically populate content and generate the final target document.

[0095] In the above implementation, the document type can be specified by the user. For example, the user can select a type from multiple pre-stored types as the document type through an interactive interface.

[0096] In the above implementation, determining the document template based on the document type can mean: querying the database based on the document type to obtain the document template associated with the document type. The relationship between the document type and the document template is stored in advance in the database. Then, when a user-specified document type is received, the database is queried based on the identifier of the document type to obtain the document template associated with the document type.

[0097] In the above implementation process, the system can respond to the document type specified by the user and then generate a document of the user-specified type based on the document template corresponding to that document type. This allows for flexible generation of the target document according to the user's document type requirements. For example, if the user selects a detailed document type, the target document is generated based on the template corresponding to that detailed document type.

[0098] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of a code document generation device disclosed in an embodiment of this application. Figure 2 As shown, the code documentation generation device includes the following functional modules: Module 201 is used to obtain relevant information about the target code; The determination module 202 is used to determine the hierarchical dependency structure between visual objects based on relevant information of the target code; wherein, the hierarchical dependency structure between visual objects is used to characterize the hierarchical dependency relationship between code elements; The response module 203 is used to respond to the document generation command triggered by the user, generate the target document based on the relevant information of the target code and the unique index identifier of the visual object, and enable the user to obtain the hierarchical dependency relationship between code elements based on the unique index identifier of the visual object.

[0099] In the above implementation process, by acquiring relevant information from the target code, the system can respond to user-triggered document generation commands and automatically generate target documents based on the relevant information from the target code and the unique index identifiers of the visualized objects, without the need for manually writing template documents, thereby improving document generation efficiency. On the other hand, the hierarchical dependency structure between visualized objects can be determined through the relevant information from the target code, making it easier for users to obtain the hierarchical dependencies between code elements based on the unique index identifiers in the automatically generated template document. This avoids the need for users to manually construct the hierarchical dependencies between code elements, saving labor costs.

[0100] Please see Figure 3 , Figure 3 This is a block diagram of an electronic device provided in an embodiment of this application.

[0101] Electronic device 300 may include a memory 311, a memory controller 312, a processor 313, a peripheral interface 314, an input / output unit 315, and a display unit 316. Those skilled in the art will understand that... Figure 3 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device 300. For example, the electronic device 300 may also include components that are more... Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown.

[0102] The aforementioned memory 311, memory controller 312, processor 313, peripheral interface 314, input / output unit 315, and display unit 316 are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The aforementioned processor 713 is used to execute executable modules stored in the memory.

[0103] The memory 311 can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory 311 stores programs. After receiving execution instructions, the processor 313 executes the programs. The methods executed by the electronic device 300 as defined in any embodiment of this application can be applied to the processor 313, or implemented by the processor 313.

[0104] The aforementioned processor 313 may be an integrated circuit chip with signal processing capabilities. The processor 313 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a digital signal processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor.

[0105] The peripheral interface 314 described above couples various input / output devices to the processor 313 and the memory 311. In some embodiments, the peripheral interface 314, the processor 313, and the memory controller 312 can be implemented in a single chip. In other instances, they can be implemented by separate chips.

[0106] The input / output unit 315 described above is used to provide user input data. The input / output unit 315 can be, but is not limited to, a mouse and a keyboard.

[0107] The aforementioned display unit 316 provides an interactive interface (e.g., a user interface) between the electronic device 300 and the user, or displays image data for the user's reference. In this embodiment, the display unit can be a liquid crystal display (LCD) or a touch display. If it is a touch display, it can be a capacitive touchscreen or a resistive touchscreen that supports single-point and multi-point touch operations. Supporting single-point and multi-point touch operations means that the touch display can sense touch operations generated simultaneously from one or more locations on the touch display and pass the sensed touch operations to the processor for calculation and processing.

[0108] In the above implementation process, the processor calls the program instruction in real time, thereby automatically obtaining relevant information of the target code and automatically generating hierarchical dependencies between visual objects based on the relevant information of the target code. Then, when the user triggers the document generation instruction, it automatically generates a document with unique indexes of visual objects based on the information of the target code. This allows the user to trace the hierarchical dependencies between code elements based on the unique indexes of the visual objects and the hierarchical dependencies between the visual objects, ultimately achieving automatic document generation without manually extracting relevant information of the target code and avoiding the need for users to manually construct hierarchical dependencies between code elements, thereby saving labor costs.

[0109] Furthermore, embodiments of this application also provide a storage medium storing a computer program, which is executed by a processor using the method described in any of the foregoing embodiments.

[0110] In the above implementation process, the computer-readable storage medium completely solidifies the power control method into computer program instructions. When the medium is read and run by the processor, the processor automatically acquires the relevant information of the target code according to the instructions, and automatically generates the hierarchical dependency relationship between the visual objects based on the relevant information of the target code. Then, when the user triggers the document generation instruction, the document with a unique index of the visual object is automatically generated according to the information of the target code. The user can trace the hierarchical dependency relationship between code elements based on the unique index of the visual object and the hierarchical dependency relationship between the visual objects, and finally realize the automatic generation of the document without manually extracting the relevant information of the target code and avoiding the need for the user to manually build the hierarchical dependency relationship between code elements, thereby saving human input costs.

[0111] Furthermore, this application also provides a code generation system, which is divided into an entry layer, a command layer, a parsing layer, a data layer, a processing layer, a service layer, and a user interface layer from bottom to top. The entry layer is responsible for activating the VSCode plugin and registering commands; the command layer handles user interaction commands (such as extracting code information, uploading Jira, generating documentation, etc.); the parsing layer extracts code structure information based on AST; the data layer manages memory storage and database persistence; the processing layer implements the creation, updating, and association of JiraIssue; the service layer provides basic services such as database, Jira interface, and documentation generation; and the user layer implements visual interaction through WebView.

[0112] Furthermore, this is accomplished through VSCode's command registration interface, where each command is mapped to a corresponding processing function. Registered commands include: extract module, extract class / component, extract function, extract interface, extract unit test, open main panel, upload to Jira, and generate documentation.

[0113] When a user executes the command to retrieve a module, the system first verifies whether the workspace is currently open. If not, the user is prompted to open the workspace first. Next, the system retrieves the workspace name from the workspace configuration and uses it as the default name for the project. Then, the system queries the module data set in memory. Specifically, it calls the static method `getModuleData()` of the `ModuleWindowData` class. If the module data does not exist in memory, this method returns `null`, and the system creates a new `ModuleData` object with its `projectName` property set to the workspace name, its `title` property an empty string, and its `funDescription` property initialized to an empty array. After creation, the new object is stored in memory for later use. Finally, the system calls the command to open the main panel, displaying this module data in the module tab of the main panel, allowing the user to customize the module title.

[0114] To extract function, class / component, and interface information, the system performs a series of core operations. First, the system retrieves the currently active text editor instance. If the user has not opened any files, the system will prompt them to open one. If a file is already open, the system will obtain the workspace path for subsequent project type detection.

[0115] To identify the project type, the system uses a project type detector to analyze the workspace directory structure. The detector first checks for the existence of a `project.config.json` (WeChat Mini Program identifier) ​​or `mini.project.json` (Alipay Mini Program identifier) ​​file. If these configuration files are found, the project is marked as the corresponding Mini Program type. If no configuration file is found, the detector recursively scans the directory, looking for characteristic page files such as ".wxml" or ".axml" for further identification. If all these methods fail, the system marks the project as a regular Web project.

[0116] Depending on the identified project type, the system selects different parsers for code parsing. For mini-program projects, the system instantiates the MiniProgramParser parser. This parser attempts to identify Page function calls in the code and extract the methods defined in its page object; if Page is not found, it attempts to identify Component function calls to extract component methods. For regular web projects, the system instantiates the TypeScriptParser parser.

[0117] TypeScriptParser uses the TypeScript Compiler API to convert source code into an Abstract Syntax Tree (AST) and traverses it using the visitor pattern. This traversal begins at the root node of the syntax tree (the SourceFile node) and systematically visits each child node through recursive functions. The technical advantage of this approach is that it can completely identify all possible function definitions in the code, ensuring that no function is missed, whether it's a file-level function declaration, a method in a class, an arrow function expression, or a function expression.

[0118] During the AST traversal, the parser extracts relevant information based on the node type. For example, when encountering a function declaration node, it extracts the function name, parameter list, and return type; when encountering a method declaration node, it records the name of the class in which it is located; for arrow functions or function expressions, it also checks whether they are part of variables or object properties and extracts relevant information.

[0119] For all identified functions, the parser extracts their detailed information, including function identifier (name, type, class name), parameter information (name, type, default value, optional identifier), return value information, and documentation description extracted from the JSDoc comments above.

[0120] The extracted function information is converted into a standard data structure format. The system performs a deduplication check, comparing the title of the new data with existing data. If the title already exists, it is skipped; otherwise, it is appended to the function data set. This data is then displayed on the user interface for easy viewing, editing, and addition.

[0121] When a user performs the "Upload to Jira" operation on the visual panel, the system persists the data to a MySQL database. Before saving, the system first checks if a duplicate record already exists in the database (based on unique identifiers such as module title and project name). If it exists, an update operation is performed; otherwise, an insert operation is performed, and the generated primary key value is retrieved after saving.

[0122] Next, the system converts the extracted code information into Jira Issues and establishes relationships between them to form a hierarchical structure. First, the system verifies the integrity of the Jira configuration (server address, username, password, project ID). Then, using the Handlebars template engine, it loads the corresponding template file based on different processor types, passes the data object to the template to generate formatted text content, and populates the various custom fields of the Jira Issue.

[0123] This hierarchical structure reflects the organization of the code: modules are the root nodes, classes / components are their child nodes, functions and interfaces belong to their respective classes / components, and unit tests correspond to specific functions. To establish this structure in Jira, the system calls the Jira REST API's Issue Link interface. Specifically, after creating various Issues and obtaining their key values, the system establishes links according to predefined association types: the association type from module to class is SWE.2.C_SWE.2.M, the association type from class to function is SWE.3_SWE.2.C, the association type from class to interface is SWE.2.I_SWE.2.C, and the association type from unit test to function is SWE.4_SWE.3. Through these associations, users can achieve bidirectional traceability from modules to unit tests in Jira. The key value returned after successful Issue creation is persisted to the database, providing data support for subsequent document generation.

[0124] Finally, during the document generation stage, users can select the desired document type (such as a detailed design document) in the panel. The system will then read relevant data from the database, use the template engine again to generate the final document content, and save it to the specified location.

[0125] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0126] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0127] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0128] It should be noted that if a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0129] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0130] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for generating code documentation, characterized in that, The method includes: Obtain relevant information about the target code; The hierarchical dependency structure between the visual objects is determined based on the relevant information of the target code; wherein, the hierarchical dependency structure between the visual objects is used to characterize the hierarchical dependency relationship between code elements; In response to a user-triggered document generation command, a target document is generated based on relevant information of the target code and the unique index identifier of the visualization object; and the hierarchical dependencies between the code elements are presented based on the unique index identifier of the visualization object.

2. The method as described in claim 1, characterized in that, in, The relevant information of the target code includes the project name of the target code, the module name of the target code, the function information of the target code, the class information of the target code, the interface information of the target code, the component information of the target code, and the unit test information of the target code; The acquisition of relevant information about the target code includes: With the target code's workspace open, obtain the name of the workspace and determine the workspace name as the project name; Responding to the user's module naming instruction for the target code, the module name is determined based on the module naming instruction; The target code is parsed to obtain the function information, class information, interface information, component information, and unit test information.

3. The method as described in claim 2, characterized in that, The step of parsing the target code to obtain the function information, class information, interface information, component information, and unit test information includes: Determine the project type of the target code; Based on the project type of the target code, the target code is parsed to obtain the function information, the class information, the interface information, the component information, and the unit test information.

4. The method as described in claim 3, characterized in that, Determining the project type of the target code includes: Obtain the absolute file system path of the target code; Based on the absolute path of the file system, detect whether there is a mini-program configuration file or feature page file in the workspace; If the mini-program configuration file or the feature page file exists, the project type will be determined as a mini-program type; If the mini-program configuration file does not exist and the characteristic page file is not detected, the project type will be determined as a Web project type.

5. The method as described in claim 3, characterized in that, The process of parsing the target code based on the project type yields the function information, class information, interface information, component information, and unit test information, including: Based on the project type, the target code is parsed to obtain the abstract syntax tree of the target code; The function information, class information, interface information, component information, and unit test information are obtained based on the abstract syntax tree.

6. The method as described in claim 5, characterized in that, The process of obtaining the function information, class information, interface information, component information, and unit test information based on the abstract syntax tree includes: Traverse all nodes in the abstract syntax tree to obtain all function nodes in the abstract syntax tree; wherein, the function nodes in the abstract syntax tree include nodes defined based on arrow function expressions, nodes defined based on function expressions, nodes defined based on method declarations, and nodes defined based on function declarations; Extract the function data from the function node; Based on the function data of the function node, the function information, class information, interface information, component information, and unit test information are obtained.

7. The method according to any one of claims 2-6, characterized in that, in, The function information includes the function's identifier, parameter information, return value information, and comment information.

8. The method as described in claim 1, characterized in that, The process of determining the hierarchical dependency structure between visual objects based on relevant information from the target code includes: The relevant information based on the target code is input into the project management tool to generate a visual object; wherein, the visual object is a task item in the project management tool; The hierarchical dependency structure between the visual objects is determined based on the hierarchical dependencies between the code elements.

9. The method as described in claim 1, characterized in that, in, The document generation instructions include document types; The response to a user-triggered document generation instruction generates a target document based on relevant information of the target code and the unique index identifier of the visualization object, including: Determine the document template based on the document type; The target document is generated based on the document template, the relevant information of the target code, and the unique index identifier of the visualization object.

10. A code documentation generation device, characterized in that, The device includes: The acquisition module is used to obtain relevant information about the target code; The determination module is used to determine the hierarchical dependency structure between visual objects based on relevant information of the target code; wherein, the hierarchical dependency structure between visual objects is used to characterize the hierarchical dependency relationship between code elements; A response module is used to respond to a user-triggered document generation command, and to generate a target document based on relevant information of the target code and the unique index identifier of the visualization object; and The presentation module is used to present the hierarchical dependencies between the code elements based on the unique index identifier of the visualization object.

Images