Method, device and equipment for converting data from mind map to table and medium

Abstract

This invention relates to the field of R&D management technology, and discloses a method, apparatus, device, and medium for converting mind maps to tables. The method includes: parsing a mind map file to form a node tree structure; establishing a mapping relationship between the node tree structure and table fields; traversing branch paths and extracting text in reverse to generate data entries containing path fields, name fields, step fields, and result fields; detecting the tag attributes of nodes at a specified level to generate priority identifiers; generating an output file name and writing the data entries and priority identifiers into a table file. This invention can be applied to business scenarios such as fintech and healthcare. By mapping the node tree structure to table fields and extracting text in reverse from branch paths, it achieves automatic conversion between mind maps and tables, reducing manual processing and improving the accuracy of field correspondence.

Description

Technical Field

[0001] This invention relates to the field of R&D management technology, and in particular to a method, apparatus, device, and medium for converting mind maps into tables. Background Technology

[0002] In the actual process of test design and test delivery, testers often use different data organization formats at different stages: during the test design phase, they tend to use hierarchical and logically intuitive mind maps to organize business processes and test paths, while during the test execution, management, and archiving phases, test cases must be submitted in structured table format. This inconsistency in expression formats leads to frequent manual conversions between mind maps and table files. Manually identifying node hierarchy relationships, manually matching fields, concatenating multi-level node text, and migrating marker information is not only time-consuming but also prone to problems such as incorrect path matching, misaligned fields, missing text, and lost marker information, directly affecting the accuracy and usability of test cases.

[0003] In the fintech business, test objects typically involve complex business scenarios such as underwriting processes, underwriting rules, claims processing paths, risk control rules, fund clearing and settlement logic, and transaction process backtracking. Testers use mind maps to outline multi-branch business paths during the design phase, but when submitting to the test management system or compliance filing system, these must be converted into a table with a fixed column structure including path information, step descriptions, expected results, and test names. Because mind maps have deep node hierarchies and numerous branches, manual conversion requires determining the role of each node in the test case, which easily leads to field mapping errors and text concatenation errors. Furthermore, the priority or risk markers on nodes are difficult to accurately retain during the conversion process.

[0004] In the healthcare business, testing scenarios often revolve around diagnosis and treatment processes, electronic medical record processing paths, image data processing logic, prescription review rules, and medical device linkage processes. While mind maps are more suitable for breaking down complex processes into layers during the test design phase, standardized tables are required for quality tracking, system verification reports, and audit archiving. Manually converting between these two formats necessitates repeatedly extracting and combining text from different levels of nodes, as well as manually maintaining test priorities and file version information, which can easily lead to information omissions, priority loss, and inconsistent file naming. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for converting mind maps into tables. This invention aims to solve the technical problems in existing technologies when converting hierarchical test design content in the form of mind maps into structured table test cases. These problems stem from the reliance on manual identification of node relationships, manual field mapping, and migration of marker information, which leads to errors in field mapping, inaccurate splicing of node text, and the inability to reliably retain priority information.

[0006] To achieve the above objectives, the present invention provides a data conversion method from mind maps to tables, comprising: Parse the mind map file to obtain a node tree structure containing a root node and multiple levels of child nodes; Establish a mapping relationship between the node tree structure and the table fields. The mapping relationship defines the path field corresponding to the root node, the result field corresponding to the end node, the step field corresponding to the parent node of the end node, and the name field corresponding to the concatenation of the node text from the specified node position to the root node. Traverse the branch paths in the node tree structure, and extract the text content in reverse from the end node of the branch path according to the mapping relationship, to generate a data entry containing a path field, a name field, a step field, and a result field; Detect the tagging attribute of a node at a specified level in the branch path, and convert the tagging attribute into a priority identifier; The output file name is generated based on the mind map file name and the current time, and the data entries and priority identifiers are written into the table file.

[0007] Furthermore, to achieve the above objectives, the present invention provides a data conversion device for mind maps to tables, comprising: The node parsing module is used to parse mind map files and obtain a node tree structure containing the root node and multi-level child nodes; The field mapping configuration module is used to establish the mapping relationship between the node tree structure and the table fields. The mapping relationship defines the path field corresponding to the root node, the result field corresponding to the end node, the step field corresponding to the parent node of the end node, and the name field corresponding to the concatenation of the node text from the specified node position to the root node. The path reverse extraction module is used to traverse the branch paths in the node tree structure, extract text content in reverse from the end node of the branch path according to the mapping relationship, and generate data entries containing path field, name field, step field and result field. The marker recognition module is used to detect the marker attributes of nodes at a specified level in the branch path and convert the marker attributes into priority identifiers. The file generation module is used to generate an output file name based on the mind map file name and the current time, and to write the data entries and the priority identifier into a table file.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a mind map to table data conversion program stored in the memory and executable on the processor, wherein when the mind map to table data conversion program is executed by the processor, it implements the steps of the mind map to table data conversion method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a mind map to table data conversion program, wherein when the mind map to table data conversion program is executed by a processor, it implements the steps of the mind map to table data conversion method as described above.

[0010] Beneficial Effects: This invention relates to the field of R&D management technology and discloses a method, apparatus, device, and medium for data conversion from mind maps to tables. The method includes: parsing a mind map file to obtain a node tree structure containing a root node and multi-level child nodes; establishing a mapping relationship between the node tree structure and table fields; traversing the branch paths in the node tree structure; extracting text content from the end nodes of the branch paths in reverse according to the mapping relationship; generating data entries containing path fields, name fields, step fields, and result fields; detecting the marker attributes of nodes at specified levels in the branch paths; converting the marker attributes into priority identifiers; generating an output file name based on the mind map file name and the current time; and writing the data entries and priority identifiers into a table file. This invention can be applied to business scenarios such as fintech and healthcare. By using the mapping rules between the node tree structure and table fields and the reverse extraction method of branch paths, it achieves automatic data conversion between mind maps and tables, reducing manual field organization, improving conversion efficiency, and reducing field correspondence error rates. Attached Figure Description

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

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

[0013] The mind map to table data conversion method provided in this invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can parse the mind map file through the client to obtain a node tree structure containing a root node and multi-level child nodes, and establish a mapping relationship between the node tree structure and table fields. It then traverses the branch paths in the node tree structure, extracting text content from the end nodes of the branch paths according to the mapping relationship, generating data entries containing path, name, step, and result fields. It detects the marker attributes of nodes at specified levels in the branch paths and converts these attributes into priority identifiers. Based on the mind map file name and the current time, it generates an output file name and writes the data entries and priority identifiers into a table file. This invention can be applied to business scenarios such as fintech and healthcare. Through the mapping rules between the node tree structure and table fields, and the reverse extraction method of branch paths, it achieves automatic data conversion between mind maps and tables, reducing manual field organization, improving conversion efficiency, and lowering the field correspondence error rate. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The following detailed description of specific embodiments further illustrates this invention.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the mind map to table data conversion method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the data conversion method from mind map to table proposed in this invention includes the following steps: S10, parse the mind map file to obtain a node tree structure containing the root node and multi-level child nodes; In this embodiment, a mind map file is an electronic document in a specific format that encodes graphically organized thought content in a structured manner, storing topics, subtopics, and the connections and hierarchical information between them. In the fintech business field, such files may be used to describe complex business process testing scenarios, such as a file recording key verification points for the entire cross-border fund clearing process, including the various nodes and their relationships from transaction initiation and compliance screening to final settlement. Parsing this file refers to reading the file's stored content through a computer program, decoding and semantically understanding the file's data encoding according to the file's public or private specifications, transforming the file from a sequence of bytes on the storage medium into a set of recognizable and operable data objects in the program's memory. This process involves file system input / output operations, possible data decompression, and syntactic analysis of the internal markup language.

[0016] From the intermediate data generated by the parsing operation, information is extracted, filtered, and reorganized according to specific logical rules, ultimately forming a new data output with a clear structure. The output is not a simple copy of the parsed data, but a product of logical reconstruction. A node tree structure containing a root node and multiple levels of child nodes is a data model built in memory. This model reflects the hierarchical relationships between elements in a mind map using a tree graph theory structure. The root node is the sole entry point to this tree structure; it represents the central theme or top-level concept of the mind map and has no parent node pointing to it. Multiple levels of child nodes are a series of nodes connected to the root node or other child nodes through direct parent-child references. They represent different aspects, steps, or attributes subdivided under the central theme, and each child node may have even more sub-child nodes, forming a multi-level nested hierarchy. The construction of the node tree structure requires traversing all the data units obtained after parsing, identifying the theme element represented by each unit, and dynamically creating node objects in memory based on the parent element identification information recorded in these units, and establishing reference pointers between these objects, thereby assembling a tree-like topology network that fully reflects the hierarchical logic of the original mind map.

[0017] When performing parsing operations, you can directly call software development kits (SDKs) specifically packaged for .xmind or .mm formats. The toolkits provide interface functions to load the file and directly obtain a pre-structured document object model. Alternatively, you can start processing from the file's basic byte stream, first reading the file header information to determine its version and whether it's compressed. If compressed, the corresponding algorithm library is called to decompress it, obtaining a text content string, usually in XML or JSON format. Then, a standard XML or JSON parser is used to parse this string, generating a document object containing all elements, attributes, and text content. To adapt to networked deployment environments, when the mind map file is stored on a remote server or cloud storage bucket, the initial data source for parsing can be a data stream downloaded from a network interface. The program needs to handle potential network latency and chunked transmission.

[0018] When obtaining the node tree structure from parsed data, one approach is to build it synchronously during the parsing process. Whenever the parser identifies a new topic element, it immediately attaches it to the corresponding parent node based on its recorded parent topic identifier. Another approach is to first complete all parsing, obtaining a flat list containing all topic elements and their parent-child relationship identifiers, and then write an algorithm to traverse this list. This algorithm can first scan the entire list, find the element whose parent topic identifier is empty or points to a non-existent element, establish it as the root node, and create a corresponding root node object. Then, it can recursively search the list for all elements whose parent topic identifiers match the current node ID, create child node objects for each such element and establish links, and then recursively perform the same process on these child nodes until all elements are placed in the tree. During the construction process, different traversal strategies can be chosen to establish links as needed, such as depth-first or breadth-first search. For mind maps with extremely large amounts of data, a lazy loading strategy can be adopted, initially building only the structure of the upper-level key nodes, and dynamically parsing and building the corresponding branches when accessing deeper nodes is needed, in order to optimize memory usage.

[0019] For example, in the fintech field, suppose there exists a mind map file used to plan the "backtesting of the robo-advisor client risk assessment model." The parsing process will identify the data stored in the file with "risk assessment model backtesting" as the central theme, and further identify the first-level sub-themes directly related to this theme, such as "historical data preparation," "model parameter traversal," and "assessment indicator calculation," as well as the second-level sub-themes stored under the "historical data preparation" sub-theme, such as "client transaction data extraction" and "market data alignment." Ultimately, a tree-like data structure is obtained in memory, with "risk assessment model backtesting" as the root node object, and the aforementioned sub-themes forming multi-level child node objects, accurately reflecting their original hierarchical relationships through pointers.

[0020] In the healthcare field, consider a mind map file for designing a "stability test for a remote patient vital signs monitoring platform." By interpreting the file format, extract the coded information centered on "platform stability testing," along with its subordinate branch topics such as "multi-device connection concurrency testing," "data transmission latency testing," and "abnormal disconnection and reconnection verification," as well as more specific test items within these branches. The result is a node tree constructed in the program's memory. The root node corresponds to "platform stability testing," and each level of child nodes corresponds to a level of test topic. The entire structure fully preserves the hierarchical logical relationship of the original test design.

[0021] This embodiment automates the interpretation of mind map file storage format through programming, accurately converting its inherent hierarchical relationships into a node tree data model in computer memory. This process eliminates the need for manual reading of the graphical interface and manual summarization. The data model is built upon direct analysis of the original file data, ensuring the integrity and fidelity of the information conversion and avoiding potential omissions of topics, misjudgments of hierarchy, or misunderstandings of relationships that could result from manual intervention. The resulting node tree structure provides a solid, reliable, and programmable data foundation for all subsequent automated processing steps that rely on this structured information. This allows subsequent rule mapping, content extraction, and format generation to be executed deterministically, thus creating the primary technical conditions for achieving high-efficiency and high-accuracy format conversion.

[0022] S20, establish the mapping relationship between the node tree structure and the table fields. The mapping relationship defines the path field corresponding to the root node, the result field corresponding to the end node, the step field corresponding to the parent node of the end node, and the name field corresponding to the concatenation of the node text from the specified node position to the root node. In this embodiment, establishing a mapping relationship between the node tree structure and table fields refers to defining a specific set of correspondence rules. This set of rules associates nodes at specific positions or with specific attributes in the node tree structure with predefined data columns in the spreadsheet. The node tree structure is an in-memory data model reflecting the logical hierarchy of the mind map, while table fields are columns in the target spreadsheet file used to carry different categories of information. For example, in a test case management scenario, these fields might be named test case path, test case name, operation step description, expected result, etc. The mapping relationship is essentially a transformation rule that specifies how to extract information from specific parts of the source data structure and populate specific positions in the target data structure.

[0023] The mapping relationship defines a series of specific correspondence rules. The root node corresponding to the path field means that the text content of the root node at the top level of the node tree structure is used as a complete test path or category identifier, and filled into the column representing path information in the spreadsheet. In fintech business, the root node might be the name of a credit approval process, which, after mapping, becomes the field value in the Excel spreadsheet identifying the business module to which the test suite belongs. The terminal node corresponding to the result field means that the text content of the last leaf node on each branch path in the node tree is used as the final verification point or expected output of the test scenario represented by that path, and filled into the column marked as the expected result in the table. The parent node corresponding to the step field means that the text content of the node one level above the terminal node is used as the specific operation or input action required to achieve the aforementioned expected result, and filled into the column describing the operation steps in the table.

[0024] The naming field, resulting from concatenating the node text from a specified node position to the root node, follows a more complex combination mapping rule. The specified node position is a starting node determined on the branch path based on preset conditions. This condition can be a fixed hierarchical offset relative to the ending node, such as the third-to-last node. Starting from this specified node, the process traces backward along the branch path, sequentially traversing each node until the root node, extracting the text content of these nodes. Text concatenation combines these sequentially extracted text fragments into a complete string using specific connectors. This concatenated string is ultimately filled into a field in the spreadsheet representing the test case name or title. This rule allows for the generation of a compound name with hierarchical meaning, such as combining department-module-functional point hierarchical information into a complete test item name.

[0025] Mapping relationships can be implemented by hard-coding a rule configuration object in the program. This object internally uses a dictionary or hash table data structure, with node type or position descriptors as keys and the identifier of the target table field as the value. Alternatively, mapping rules can be stored in an external configuration file such as JSON or YAML. The program reads this file at startup and parses it into an in-memory configuration object. This approach improves the maintainability and modifiability of the rules. In implementation, separate mapping entries can be created for the four corresponding rules. For example, one entry maps elements with the node type of root node to field index 0, and another entry maps elements with the node position of end node to field index 3.

[0026] When determining the position of a specified node, a fixed offset method based on backward counting from the end node can be used, such as always taking the node reached two levels back from the end node. Alternatively, a configurable parameter can be introduced, allowing users to set this offset and flexibly determine the level from which to start concatenating the name. Text concatenation operations can be performed by traversing the node sequence from the specified node to the root node, accessing the text attributes of each node sequentially and appending them to a string builder, while inserting predefined separators such as hyphens or forward slashes between adjacent text. The concatenation logic can support different separator strategies and can also handle skipping or placeholder behavior when node text is empty.

[0027] This embodiment establishes a clear and structured mapping rule set in advance, precisely associating nodes at different logical positions in the mind map node tree with specific fields in a spreadsheet, providing a deterministic basis for subsequent automated content extraction and filling. This step transforms the conversion logic, which originally relied on manual understanding and comparison, into machine-executable rule definitions, making the conversion process from unstructured tree data to structured tabular data programmable and repeatable. In particular, the definition of complex mapping logic, including compound text concatenation, enables the conversion to retain and reorganize the hierarchical semantic information in the source data, generating more descriptive and standardized output content. This lays a core rule foundation for overcoming common problems in manual conversion, such as mismatched correspondences, information fragmentation, and loss of meaning.

[0028] S30, traverse the branch paths in the node tree structure, extract text content in reverse from the end node of the branch path according to the mapping relationship, and generate a data entry containing a path field, a name field, a step field and a result field. In this embodiment, traversing the branch paths in the node tree structure refers to systematically accessing all complete node sequences in the tree-like data model in memory that start from the root node and terminate at any leaf node. The node tree structure consists of interconnected node objects, each containing its text content and references to its child and parent nodes. A branch path represents a complete logical chain in a mind map from the central topic to the finest-grained subtopics. In computer programs, traversal typically requires a graph traversal algorithm, such as a depth-first search algorithm. This algorithm starts from the root node, recursively visits its first child node, and continues to delve deeper until it reaches a leaf node with no child nodes. At this point, the order of nodes traversed from the root node to the leaf node constitutes a branch path to be processed. Subsequently, the algorithm backtracks to the previous branch point, exploring other unvisited child node paths, until all paths from the root to the leaf in the tree have been enumerated. In the fintech field, a node tree describing the entire process of supply chain finance accounts receivable pledging testing may have a branch path that connects a series of nodes such as "financing application initiation", "core enterprise ownership confirmation", "movable property pledge registration" and "bank loan disbursement", thus fully depicting a business scenario.

[0029] Reverse text extraction based on mapping relationships, starting from the end node of a branch path, refers to the process of obtaining a sequence of nodes for a specific branch path. Following the established rules for mapping node positions to table fields, the process begins with the end node (leaf node) of the path and proceeds upwards along the parent reference pointers between nodes, selectively extracting text strings from nodes at specific locations. The mapping relationship acts as an extraction guide, clearly defining which role or position of a node in the path its text should belong to which table field. The reverse extraction process first identifies the end node of the current path and retrieves its stored text information. For example, in a financial anti-fraud test, the end node text might be "The system intercepted this transaction," which, based on the mapping relationship, is assigned to the result field. Then, the program moves along the parent pointer to the immediate parent node of the end node and extracts its text, such as "Enter a large transaction that does not conform to the cardholder's spending habits." This text is assigned to the step field. Next, the program needs to locate the starting node for generating the name field, i.e., the specified node position. This is achieved by calculating a fixed-level offset relative to the end node; for example, an offset of 2 would locate the node two levels back up from the end node. Starting from that node, the program continues traversing upwards along the parent pointer, sequentially extracting the text of each node encountered until the root node. These text fragments are then fed into a string concatenation tool, which inserts separators such as hyphens or colons between adjacent text to form a complete string, such as "Unconventional Transactions - Large Transaction Monitoring - Anti-Fraud Rule Engine Test". This string is ultimately filled into the name field. Finally, the program accesses the starting point of the path, the root node, and extracts its text, such as "Anti-Fraud Rule Engine Test", as the content of the path field.

[0030] Generating a data entry containing path, name, step, and result fields involves integrating and encapsulating the four text units extracted and categorized according to rules into a single, structured data record. This data entry can be instantiated in memory as an object with four attributes, each storing the text value of a field; or represented as an ordered four-element array, where each index corresponds to a predefined field. This encapsulation operation signifies that all the key information carried by a branch path has been transformed from a tree-like topology with complex parent-child relationships into a standardized, flat data record with clearly defined columns. In the healthcare field, such a generated data entry might correspond to a test record regarding the retrieval performance of a medical image archiving and communication system, where the path field value is "Image Retrieval Module," the name field value is "Multi-condition Combined Query - Advanced Search - Image Retrieval Module," the step field value is "Search by simultaneously setting the patient ID, examination date range, and modality type in the advanced search interface," and the result field value is "The system returns a list of matching images within 2 seconds."

[0031] When performing traversal operations, a recursive depth-first search algorithm can be used. When a leaf node is visited, the sequence of nodes in the current recursive stack is recorded as a path. Alternatively, a non-recursive iterative approach can be used, employing an explicit stack data structure to simulate the recursive process, manually managing the pushing and popping of nodes, and recording the path upon popping. For particularly wide and shallow tree structures, a breadth-first search combined with path recording may be more efficient. This typically requires a queue to manage the nodes to be visited and their accumulated path information. In scenarios requiring extremely high processing speeds, the tree structure can be preprocessed by assigning a unique preorder traversal index to each node and pre-calculating the range of subtrees, thus allowing for the use of simple loops to enumerate paths.

[0032] The specific implementation of reverse text content extraction can be achieved by directly obtaining the node object when traversing the leaf nodes of each path. Then, through a loop, based on the correspondence logic between the fields defined in the mapping relationship and the node position, it sequentially visits its parent node, great-grandparent node, etc. When locating a specific node position, in addition to using a fixed offset count based on the end node, dynamic rules based on node depth or node type can also be used. The text concatenation process can use a mutable string builder to avoid the performance overhead of frequently creating new string objects. The separator can be configured as underscore, space, or direct concatenation without a separator. For the mapping relationship, it can be implemented as an independent rule engine that receives the position index and role information of a node in the path and returns the target field identifier to which it should be mapped.

[0033] The structure for generating data entries can be lightweight tuples or lists, storing the four field values ​​in a fixed order. In object-oriented design, a test case data class can be defined, whose constructor accepts four string parameters and assigns them to the corresponding properties. To adapt to different target table formats, data entry generation can be designed to be pluggable, allowing the output of data rows conforming to CSV, Excel, or other database table structures by implementing different data entry factory interfaces. When handling massive branch paths, a producer-consumer pattern can be used, placing traversal and extraction tasks in a queue, with multiple worker threads concurrently generating data entries to fully utilize multi-core processor resources.

[0034] This embodiment automatically traverses all logical paths in the node tree and strictly follows predefined mapping rules to extract and reorganize text content in a reverse and orderly manner from the end of each path, ultimately generating well-structured data entries. This process achieves precise and batch conversion from non-linear tree-like thinking structures to linear table row data. It eliminates the need for manual reading of mind map branches and manual transcription, classification, and splicing of information, transforming highly repetitive and error-prone manual labor into a computational task executed deterministically by the program. The reverse extraction mechanism ensures the consistency of information extraction order and logical dependencies, while the structured generation of data entries provides ready-to-use data units for subsequent direct writing operations. This greatly improves processing efficiency in the core of the conversion process and fundamentally eliminates content mismatches, order reversals, or field omissions that may occur due to manual operation.

[0035] S40, detect the tag attribute of the specified level node in the branch path, and convert the tag attribute into a priority identifier; In this embodiment, detection is an active, programmatic verification and analysis process, referring to the computer system accessing the pre-built branch path data structure in memory. A branch path represents an ordered sequence of nodes extending from the root node to a leaf node. In a fintech scenario, this path might describe a complete credit approval or cross-border payment verification process. For this path, the system precisely locates a specific node object in the node sequence based on pre-defined hierarchical positioning rules, such as a fixed offset relative to the end of the path; this is the designated level node. This node may have been given special visual or logical markers in the original mind map design to convey additional semantics.

[0036] A tag attribute is a data feature carried by a node object at a specified level, used to represent this special semantic meaning. In common mind map file formats, this attribute may be stored as a specific data field, such as an enumeration value representing the icon type, an RGB code representing the color, a custom label string, or a composite metadata object containing various style information. In financial business test case design, a node might be marked with a red icon to indicate its association with high-risk money laundering detection rules. The detection operation involves reading the metadata fields corresponding to the node object through a program interface, parsing and extracting the key information representing the tag.

[0037] Converting tag attributes into priority identifiers is a rule-based mapping and assignment process. The conversion logic relies on a predefined set of correspondences that establishes a mapping from the feature values ​​of the source tag attributes to the target priority text identifiers. Priority identifiers are textual descriptions used for categorizing or sorting in the target table, such as high, medium, low, or P0, P1, P2, etc. For example, the mapping rule might stipulate that when the extracted color feature value is a specific RGB code representing red, the output text is high; when the feature value is a code representing yellow, the output is medium. The conversion process first standardizes or encodes the extracted tag attribute features, then searches and matches them in the mapping set, and finally determines the matched text output value as the priority identifier corresponding to that path. This process transforms graphical, unstructured visual tags into structured text data that can be further processed and sorted.

[0038] When detecting the tag attributes of nodes at a specified level, the raw values ​​can be obtained by directly accessing the predefined icon, color, or tags attribute fields in the node object model. If the raw data is complex, a dedicated parsing function can be written to extract key tag feature codes from the composite style object. When implementing hierarchical localization, a method of backtracking a fixed number of steps from the end node can be used to determine the target node, for example, always selecting the third-to-last node. Alternatively, a dynamic calculation method based on node depth indexing can be used, or the selection rules for the target node can be specified through an external configuration file, such as using keywords contained in the node text to assist in localization.

[0039] One approach to converting tag attributes to priority identifiers is to create an in-memory lookup table, such as a hash table, using the standard encoding of the tag attribute as the key and the priority text as the value. After retrieving the tag attribute, the program first normalizes it to the standard encoding, then retrieves it from the hash table and returns the value. Another approach is to write the mapping rules as a set of if-else or switch-case conditional statements. For increased flexibility, the mapping relationships can be stored in a separate JSON or XML configuration file, which is loaded and parsed at runtime, allowing for dynamic updates of the mapping rules without modifying the code. When handling unknown or undefined tag attributes, default conversion rules can be defined, such as uniformly mapping to a default priority or marking it as pending.

[0040] The granularity of detection can be adjusted for different application environments. For example, in scenarios requiring fine-grained management, detection can extend beyond icons or colors to include multiple attributes such as bold font and underline, with a composite set of rules designed to comprehensively determine priority. The conversion process can also incorporate simple threshold judgments; for instance, when the marker attribute is color, its RGB value can be compared with a preset color range to determine its category. For scenarios demanding extremely high processing speed, the mapping logic can be optimized for fast matching based on bitwise operations or lookup tables.

[0041] This embodiment automatically detects the additional marker attributes of nodes at specific locations in a branch path through programming, and accurately converts them into textual priority identifiers according to predefined rules. This process replaces the traditional method of manually viewing the graphical interface, subjectively judging priorities, and then manually entering the information. Automated detection ensures that the priority information of each marked node is captured and identified without omission when processing a large number of test paths in batches. Rule-based conversion guarantees the objectivity and consistency of priority determination, eliminating possible misunderstandings from different personnel. This technology enables the efficient and reliable extraction and transformation of important classification information contained in the visual markers of mind maps into structured data, providing a key basis for the subsequent sorting, filtering, and management of test cases, thereby improving the standardization and efficiency of the entire test asset management.

[0042] S50, generate an output file name based on the mind map file name and the current time, and write the data entries and the priority identifier into a table file.

[0043] In this embodiment, generating the output filename based on the mind map filename and the current time is a process of constructing a unique file identifier. The mind map filename refers to the name identifier of the original mind map file to be converted within its storage system, typically a string containing the base name and extension, such as "Cross-border Payment Test Cases.xmind". Obtaining this filename is usually accomplished by parsing the file path through a file system interface; sometimes, the directory path and extension need to be stripped away, retaining only the core name. The current time refers to the point-in-time data obtained from the operating system's real-time clock service when the conversion operation is performed, with an accuracy down to the millisecond level. The core operation of generating the output filename is combining these two information elements into a new string according to predetermined rules. These rules typically involve using a connector such as a hyphen or underscore to link the core filename with a formatted time string. The time string is often converted to a compact numeric sequence format, such as "YYYYMMDDHHMMSS" or a timestamp. The fundamental purpose of this step is to ensure that the filename generated by each conversion is unique, thereby avoiding the problem of new files overwriting old files due to multiple conversion operations, which is particularly important in automated deployment and continuous integration scenarios.

[0044] Writing data entries and priority identifiers to a spreadsheet file is a data persistence and formatting process. A data entry is a structured data record generated for each branch path in the preceding steps, containing the text values ​​of the path, name, step, and result fields. A priority identifier is a textual priority label, such as high, medium, or low, corresponding to each branch path. The object of the write operation is a spreadsheet file, typically a spreadsheet document conforming to a specific format, such as a .xlsx or .csv file. This operation first requires initializing an empty file structure or workbook object conforming to the target format in memory or storage. Then, the program iterates through all generated data entries, and for each data entry, sequentially fills the four field values ​​into consecutive cells of a new row in the spreadsheet file. For example, the path field value is written to column A, the name field value to column B, the step field value to column C, and the result field value to column D. Simultaneously, the priority identifier associated with that data entry is written to a specified column in that row, such as column E. This process must adhere to the cell addressing and data writing interface specifications of the target spreadsheet software to ensure accurate data placement. Finally, the spreadsheet file containing all the written data is saved to the storage system, and its name is the same as the previously generated output file name, thus completing the complete conversion loop from unstructured mind map to structured spreadsheet document.

[0045] When generating output filenames, the core name (excluding the extension) can be extracted from the original file path string, and the part after the last dot can be removed using a string splitting function. The current time can be obtained by calling system APIs such as `LocalDateTime.now()` in Java or `datetime.now()` in Python, and then converted to a string using a date and time formatting tool. For example, formatting it as "20231024153045" represents October 24, 2023, 3:30:45 PM. The choice of connector can be underscores, hyphens, or even direct concatenation without connectors. To prevent filenames from containing characters prohibited by the operating system (such as colons and forward slashes), the core filename can be cleaned by replacing illegal characters with underscores. In distributed or high-concurrency environments, to further enhance uniqueness, a random number or process ID can be appended after the timestamp.

[0046] When writing to a spreadsheet file, you can use a dedicated spreadsheet library, such as Apache POI for Java and openpyxl for Python. First, create a new workbook object using library functions and activate or create a worksheet within it. The program can predefine headers, writing column headings such as "Test Path," "Test Name," "Operation Steps," "Expected Result," and "Priority" in the first row. Then, iterate through each data entry object, setting cell values ​​at specific row numbers (e.g., starting from row 2) and column indices using the interface provided by the workbook object. Priority indicators can be written to predefined columns. Besides writing plain text, cell styles can be applied, such as automatically setting cell background colors (red, yellow, green) based on the priority indicator value (high, medium, low). After writing all data, call the workbook's save method, passing the previously generated complete output filename (including the path and the .xlsx extension) as an argument to write the file to disk. For scenarios where complex formats are not required, you can also choose to generate a CSV file. This is a plain text format that separates field values ​​with commas, with each line representing a record. It is simpler to implement, requiring only string concatenation and writing to a text file.

[0047] This implementation automates the construction of unique output filenames by combining the original mind map name with a precise timestamp. It then programmatically writes all structured data entries and priority markers into a standard spreadsheet file in batches and accurately. This process completely replaces the tedious and error-prone operations of manually naming files, creating spreadsheets, and copying and pasting data row by row. The filename generation rules ensure the uniqueness and traceability of the output files, avoiding file overwriting risks and facilitating version management and archiving. The data writing process directly maps structured objects in memory to rows and columns in a spreadsheet, guaranteeing the integrity and formatting of the information conversion. This final step automates the delivery of the conversion results, generating standardized documents that can be directly used for test management, review, or import into other systems. This solidifies the efficiency improvements and accuracy guarantees brought about by the entire automated conversion process at the final output stage.

[0048] In one embodiment, step S10 includes: S101 reads the binary data stream of the mind map file and identifies the file compression format of the mind map file; S102, decompress the binary data stream based on the file compression format and extract structured text data describing the node hierarchy relationship; S103, Invoke the document parser to read the structured text data and convert the structured text data into a collection of node objects; S104, Traverse the set of node objects, identify node objects that do not have parent node references, and mark the node objects as root nodes; S105, recursively traverse the objects in the node object set that have a reference relationship with the root node, and identify multi-level child nodes; S106, The root node and the multi-level child nodes are associated and combined according to the parent-child reference relationship to obtain the node tree structure.

[0049] In this embodiment, reading the binary data stream of the mind map file is a low-level input / output operation. Its goal is to obtain the raw byte sequence constituting the mind map file from physical storage media or a network location. This byte sequence is a precise representation of the file content at the storage level, without any pre-defined structured interpretation. Identifying the file compression format of the mind map file is a process of analyzing and matching specific byte patterns at the beginning of this byte sequence. Many mind map file formats contain a fixed sequence of magic number bytes at the beginning of their file. These sequences serve as format signatures, identifying the specific technical specifications the file follows and whether the internal data has been compressed using a specific algorithm. For example, a file might begin with four bytes in a specific byte order, indicating that it is packaged in a ZIP container format. The identification process is accomplished by comparing these header bytes with a known library of format features, thereby determining the decompression and parsing path required for subsequent processing.

[0050] Decompressing binary data streams based on file compression formats refers to using the appropriate decompression algorithm to decode the payload portion of the data stream, excluding the header signature, based on the identified format information. If the format is identified as ZIP, the ZIP decompression library function is called to parse the central directory, locate compressed entries, and restore the compressed data blocks to the original byte stream according to the ZIP file format specification. Extracting structured text data describing the hierarchical relationships between nodes occurs after decompression. At this point, the original byte stream is reassembled, containing document content encoded in a specific text format. Common structured text formats include XML or JSON, which use tags, attributes, and nested structures to explicitly describe the parent-child, sibling, and other hierarchical relationships between thematic elements in a mind map. The extraction operation means converting the decompressed byte stream into a string using the correct character encoding, ensuring that the string completely contains all the tokenized data defining the nodes and levels.

[0051] Reading structured text data using a document parser is a process of syntactic analysis and semantic understanding. A document parser is a software component specifically designed to handle the grammatical rules of a particular text format. For XML, the parser loads the text string, identifies start tags, end tags, attribute name-value pairs, and text content, and constructs a document object model based on the nesting relationships of tags. For JSON, the parser recognizes structures such as objects, arrays, and key-value pairs. The result is the transformation of a linear sequence of text into an in-memory, hierarchical intermediate representation. Converting this structured text data into a collection of node objects is a data mapping and object instantiation operation. The program traverses the intermediate representation tree generated by the parser, creating a node object for each element representing a mind map topic. This node object is a program-defined data structure instance whose attributes store information extracted from the text data, such as the topic's text content, a unique identifier, and, most importantly, a reference to its parent topic identifier. This reference information is crucial for subsequently constructing the node tree; it records the logical dependencies between nodes as data fields. Ultimately, all created node objects are organized into a list or array to form a collection of node objects. However, at this point, these objects are not yet linked directly by program pointers, but are only indirectly associated through the stored parent identifier field.

[0052] Traversing a collection of node objects means sequentially or iteratively accessing each node object in the collection. Identifying node objects without parent references requires checking the parent identifier field of each node. In a collection of node objects, if a node's parent identifier field is empty, points to a non-existent identifier, or its parent identifier points to the node itself, then logically, that node has no parent. In graph theory, such a node corresponds to the root of a directed tree or forest. Marking a node object as the root node is a state assignment operation; you can set a boolean root flag attribute for the node object or add it to a dedicated list of root nodes, thus allowing for quick location of this starting point for building the tree structure in subsequent processing.

[0053] Recursively traversing the set of node objects that reference the root node is a depth-first graph traversal process. Starting from the marked root node, the process compares the node identifier with its parent identifier, searching the set for all node objects whose parent identifier matches the current root node's identifier. These objects are the root node's direct children. For each found direct child node, this search process is recursively repeated; that is, from the perspective of itself as the new current node, the search continues for nodes whose parent identifier matches its identifier. This recursive process deepens layer by layer until a node no longer has any children. Identifying multi-level child nodes is a natural result of this recursive traversal. Through the depth of the recursive call stack and the chained search of parent-child relationships, all nodes directly or indirectly connected to the root node through references are systematically discovered and accessed, forming a logically multi-level child node system.

[0054] Associating and combining root nodes with multi-level child nodes based on parent-child references is a process of constructing a concrete data structure in memory. After traversing and identifying each level of child nodes, these logical parent-child relationships need to be transformed into actual pointers or reference links between program objects. For the root node object, references to its direct child node objects are stored in a child node list attribute. For each child node object, in addition to pointing its parent node reference to the root node, its own child node list is also recursively processed. Through this bidirectional or unidirectional reference establishment operation, all discrete node objects are connected into a coherent, pointer-navigable network structure. The resulting node tree structure is the final product of this associative combination process; it represents a node-based tree graph data structure that fully reproduces the original hierarchical logic of the mind map in memory. This data structure has a definite root, and each node knows its parent node and child node set, providing a direct and efficient data access foundation for all subsequent tree-based operations.

[0055] This embodiment systematically reads the original file byte stream, accurately identifies and decompresses the file format, calls a dedicated parser to transform text data into a collection of objects, and automatically identifies root nodes and constructs multi-level relationships based on the reference identifiers between objects using traversal and recursive algorithms. Ultimately, it forms a node tree structure in memory that accurately reflects the hierarchical relationships of the original mind map. This process achieves fully automated, high-fidelity data reconstruction from storage format to memory model, replacing the inefficient methods of manually interpreting graphical interfaces or manually sorting out logical relationships. It lays a unique and reliable structured data foundation for subsequent automated mapping and transformation, fundamentally ensuring the accuracy of the starting point of the information conversion process and the program's processability.

[0056] In one embodiment, step S20 above includes: S201, Initialize the data structure used to store the rules corresponding to the fields as a mapping relationship; S202, Configure association rules in the mapping relationship to point the text content of the root node to the path field; S203, define the leaf node without child nodes in the node tree structure as the terminal node, and configure the association rule in the mapping relationship to point the text content of the terminal node to the result field; S204, define the direct parent node of the terminal node as the parent node of the terminal node, and configure association rules in the mapping relationship to point the text content of the parent node of the terminal node to the step field; S205, define a node at a preset hierarchical depth relative to the end node as a specified node position, and configure association rules in the mapping relationship to point the text concatenation logic from the specified node position to the root node to the name field.

[0057] In this embodiment, initializing the data structure used to store the rules corresponding to the fields as a mapping relationship is the process of creating a data container in memory specifically responsible for accommodating and organizing the transformation rules. A typical implementation of this data structure in the program can be a hash table or a dictionary, designed to efficiently store and retrieve rules in key-value pairs. The key uniquely identifies the specific role or position of a node in the tree structure, such as "root node" or "end node"; the value declares the identifier of the target table field corresponding to that role, such as "path," "result," or other field column names or indexes. Initializing this container means allocating memory space for it at runtime and possibly performing some basic configurations, such as setting the initial capacity or loading the default rule framework, thus preparing for the subsequent addition of specific mapping entries. Once the mapping relationship is instantiated through this data structure, it becomes a rule base that can be queried and executed.

[0058] Configuring association rules in a mapping relationship, pointing the text content of the root node to the path field, is an operation of inserting a specific entry into the rule base. The root node is unique and identifiable within the constructed node tree structure. Configuring association rules requires defining a key, such as the string "ROOT," which represents the root node role in the rule base. It also requires defining a value, such as the string "PATH_FIELD" or an integer index 0, which represents the column in the target table used to store path information. The program establishes the mapping from the key "ROOT" to the value "PATH_FIELD" by calling the data structure's insert method. Subsequently, when the transformation logic needs to process the root node, it can retrieve "PATH_FIELD" from the rule base by querying the key "ROOT," thus knowing precisely which column's text content should be placed in the table's path field.

[0059] Defining leaf nodes with no child nodes in a node tree structure as terminal nodes is a process of establishing node classification criteria in program logic. In a tree data structure, a node is the end of a branch if its child node reference list is empty. This definition transforms the abstract concept of "terminal node" into concrete program logic that can be determined by checking whether the node's child node set is empty. Configuring association rules in the mapping relationship, pointing the text content of the terminal node to the result field, adds another mapping entry to the rule base. A query key needs to be determined for this category of terminal nodes, such as "LEAF_NODE". During program execution, the aforementioned definition is applied to identify all nodes that satisfy the condition of an empty child node list and classify them as terminal nodes. When processing such nodes, the key "LEAF_NODE" is used to query the rule base to obtain the corresponding target field identifier, such as "RESULT_FIELD", thereby guiding the filling of its text content into the result field.

[0060] Defining the immediate parent node of a terminal node as its parent establishes an alternative logic for determining node roles based on relative position. Given a terminal node already identified, its immediate parent node can be directly located by accessing the parent node reference pointer stored in the terminal node object. This definition transforms the description of "the parent node of a terminal node" into an executable two-step operation: first, locate the terminal node, then obtain its parent node reference. Association rules are configured in the mapping relationship to point the text content of the terminal node's parent node to the step field, adding a third mapping entry. A key is assigned to this role, such as "PARENT_OF_LEAF". During processing, the program performs the operation to obtain the parent node for each terminal node, marking the resulting parent node object as the "PARENT_OF_LEAF" role. This key is then used to query the rule base to obtain a target field identifier, such as "STEP_FIELD," to complete the mapping from text content to the step field.

[0061] The algorithm defines a node at a preset depth relative to the terminal node as the specified node position. This is a node localization algorithm based on relative path offset. The preset depth is a configurable integer value; for example, the value 2 represents the third-to-last level (assuming the terminal node's depth is 0). The algorithm starts from the terminal node and backtracks upwards along its parent node reference chain. For each level upwards, the current depth counter is decremented by one until the counter reaches the preset depth value. The node at this point is defined as the specified node position. An association rule is configured in the mapping relationship, pointing the text concatenation logic from the specified node position to the root node to the name field. This adds the most complex combination rule entry. The key of this entry can be "NAME_PREFIX_PATH," and its corresponding value is not only a target field identifier such as "NAME_FIELD," but also implicitly contains processing logic. When the conversion program processes this rule, the sequence of operations it needs to perform is as follows: First, locate the specified node position according to the aforementioned algorithm; then, starting from that node, continuously visit the parent nodes and collect their text content until the root node is reached; next, concatenate the collected text fragments into a complete string using delimiters in the order from the specified node to the root node; finally, use this concatenated string as data to fill the name field pointed to by the rule.

[0062] This embodiment systematically establishes and configures a series of precise mapping rules from tree node roles to table fields by initializing a dedicated data structure. This process transforms the transformation logic implicit in the mind map structure into a set of instructions that can be explicitly executed and queried by the machine. It defines the deterministic correspondence between root nodes, terminal nodes, parent nodes, and offset-based nodes with structured fields such as paths, results, steps, and names. In particular, it includes complex rules for generating compound names by concatenating text from multiple nodes. This provides a complete, clear, and flexibly adjustable transformation blueprint for subsequent automated traversal and content extraction, laying the core rule foundation for accurate and consistent mapping from unstructured tree data to regular table row records.

[0063] In one embodiment, step S30 above includes: S301, Scan the node tree structure to identify all complete paths extending from the root node to the leaf node, and use the identified complete paths as branch paths; S302, locate the last node of the branch path as the end node, extract the text content of the end node, and write the text content of the end node into the result field according to the mapping relationship; S303, backtrack to the parent node of the terminal node, extract the text content of the parent node, and write the text content of the parent node into the step field according to the mapping relationship; S304. Based on the specified node position defined in the mapping relationship, starting from the node corresponding to the specified node position in the branch path, extract the text content of all nodes from the specified node position to the root node in reverse upwards, concatenate the extracted text content of all nodes and write it into the name field, and write the text content of the root node into the path field according to the mapping relationship. S305 encapsulates the path field, name field, step field, and result field after the data is written to generate a data entry.

[0064] In this embodiment, scanning the node tree structure to identify all complete paths extending from the root node to the leaf nodes involves performing a systematic path enumeration algorithm on the graph data structure. The node tree structure is represented in memory as a directed acyclic graph (DAG) composed of node objects linked by parent-child pointers, where the root node is the only vertex with an in-degree of 0, and the leaf nodes are vertices with an out-degree of 0. Identifying complete paths requires traversing all reachable paths in the tree. Depth-first search (DFS) is a classic algorithm for achieving this goal. This algorithm recursively visits the tree starting from the root node, maintaining a sequence of nodes from the root node to the current node in the recursion stack. When the algorithm visits a leaf node (i.e., its child node list is empty), the node sequence stored in the recursion stack constitutes a complete path from the root node to that leaf node. The algorithm copies or records this sequence to a path set. Subsequently, the algorithm backtracks to the previous branch point and continues exploring other unvisited sub-branches until all possible DFS paths have been explored. For very wide or deep trees, a non-recursive iterative approach can also be used, employing an explicit stack data structure to manually manage traversal states and path records. Using the identified complete path as a branch path means that each recorded node sequence is encapsulated as an independent data object, usually an ordered list of node objects. This object represents a complete logical thread in the mind map and can be processed independently by subsequent steps.

[0065] Locating the final node of a branch path as the terminal node is achieved by accessing an encapsulated branch path data object. Since the branch path is an ordered list, its last element is the terminal node at its list index. Extracting the text content of this terminal node involves reading the text attribute value stored in the node object; this value is a string. Writing the text content of the terminal node into the result field according to the mapping relationship is a rule-based assignment operation. The program needs to query the established mapping relationship data structure, using the key representing the "terminal node" role to retrieve the corresponding target field identifier, such as "result field". After a successful retrieval, the program creates a temporary data container or directly assigns the extracted text string to the storage location marked "result field" within a data record object under construction. This process establishes a deterministic data flow from a specific node to a specific field in the structured record.

[0066] Tracing back to the parent node of the terminal node is a pointer access operation based on the ordered nature of the branch path. Since the branch path list contains a complete sequence of nodes from the root node to the terminal node, the parent node of the terminal node is the second-to-last element in this list. The program accesses this element directly through the list index, without needing to retrace the tree structure. Extracting the text content of the parent node also involves reading its text attribute string. Based on the mapping relationship, the text content of the parent node is written into the step field, and the rule query and assignment operations are performed again. The program uses the key representing the role of the "parent node of the terminal node" to query the mapping relationship, obtains the "step field" identifier, and then assigns the extracted parent node text string to the corresponding "step field" storage location in the data container.

[0067] Based on the specified node position defined in the mapping relationship, the rule must first be parsed. The mapping relationship stores parameters used to calculate the specified node position, such as a hierarchical offset N relative to the end node. Starting from the node corresponding to the specified node position in the branch path is achieved by calculating the index in the path list. If the offset N is 2, it means tracing back 2 positions from the end node (index L-1), i.e., the node with index L-3. The program performs arithmetic calculations based on the offset and path length to locate the specific node object in the path list. Extracting the text content of all nodes from the specified node position to the root node is an iterative collection process. Starting from the calculated index position, the program iterates towards the beginning of the list, i.e., the index decreases, visiting each node in turn, reading its text attributes, and collecting these text strings into a temporary array in the order of access. Concatenating the text content of all extracted nodes into the name field involves string concatenation operations. The program uses a string builder to append elements from the collected text array sequentially, from the specified node to the root node, inserting predefined separators between adjacent elements to generate a compound string. Then, based on the mapping relationship, the text content of the root node is written to the path field—this is a separate operation. The root node is the first element (index 0) of the branch path list. The program extracts its text content, then uses the key representing the "root node" role to look up the mapping relationship, obtains the "path field" identifier, and assigns the root node text to the "path field" position in the data container.

[0068] Encapsulating the path, name, step, and result fields after data is written to generate data entries is the final assembly and instantiation of the data record. At this point, the temporary data container is filled with string values ​​for the four fields. The encapsulation operation organizes these discrete field values ​​into a coherent, self-contained data structure instance. This data structure can be a class object with four attributes (corresponding to the four fields), or a fixed-length quadruple or array. Generating a data entry means creating a new instance of this structure and initializing all its fields with the already filled values, thus producing a complete, formatted data record representing a structured unit of information transformed from a mind map branch path.

[0069] This embodiment systematically enumerates logical paths in a tree and, based on predefined rules, extracts and allocates node text in a reverse and orderly manner, starting from the end of each path, ultimately encapsulating it into standardized data entries. This process achieves high-fidelity, batch conversion from a non-linear tree structure to linear table records. It transforms the task of relying on manual sequential reading and transcribing into an automated process driven by deterministic algorithms, ensuring the completeness, correctness of order, and accuracy of field correspondence in information extraction from complex hierarchical relationships. This lays the core conversion foundation for generating structured data that can be directly imported into or exported.

[0070] In one embodiment, step S40 above includes: S401, determine the level depth index relative to the end of the branch path, and take the node located at the level depth index as the specified level node; S402, parse the metadata attribute list of the specified level node, and extract the icon encoding information contained in the metadata attribute list as a tag attribute; S403, compare the marked attributes with a preset priority mapping table for features; S404, when the marker attribute matches the first feature code, high-priority text is generated; when the marker attribute matches the second feature code, medium-priority text is generated; when the marker attribute matches the third feature code, low-priority text is generated, and the generated text is defined as a priority identifier.

[0071] In this embodiment, determining the hierarchical depth index relative to the end of the branch path involves performing an arithmetic location calculation based on a known data structure. The branch path is typically represented in memory as an ordered list of node objects, starting from the root node and sequentially stored to the final leaf node. The final node is the last element of this list. The hierarchical depth index is a preset non-negative integer value that defines the number of steps to backtrack from the final node. If the hierarchical depth index is K, then the position index of the specified hierarchical node in the list is the list length L minus (K+1), i.e., index = L-1-K. This calculation directly maps to random access operations on the list; the program can directly obtain the corresponding node object reference through this index value without traversing the entire list. This step implicitly verifies the validity of the index; the calculated index must be greater than or equal to 0 and less than the list length L. Otherwise, the path may be considered not conforming to the preset hierarchical structure requirements, thereby triggering exception handling or skipping logic. Using the node located at the depth index of that level as the specified level node is an operation to complete pointer assignment or role marking, so that the subsequent processing logic of the program can clearly identify the target node object that needs to be checked for the marked attributes.

[0072] Parsing the metadata attribute list of a node at a specified level involves accessing the internal data structure of the node object. In a typical object-oriented model, in addition to storing basic text content, a node object contains a set of attributes to carry additional information, namely the metadata attribute list. This list might be implemented as a dictionary, a hash table, or an array of key-value pairs. Parsing means that the program obtains a reference to this attribute set through the interface methods provided by the node object or by directly accessing its public fields. Extracting the icon encoding information contained in the metadata attribute list as a marker attribute is a key-based exact query operation. The icon encoding information is the value associated with a specific key in the attribute set, such as "iconType" or "colorCode". The program queries the attribute set using this key, and the set returns the corresponding value. This value is the marker attribute, and its data type might be an integer enumeration value, a string identifier (such as "red_circle", "yellow_warning"), or a structured color object. The success of the extraction operation may depend on whether the key exists; if it does not exist, it can return a null value or a default value, which constitutes a branch condition in the conversion logic.

[0073] The process of comparing a tag attribute with a predefined priority mapping table is a data matching and retrieval process. The predefined priority mapping table is an independent data structure created and loaded during program initialization. Its typical implementation is a lookup table (e.g., a hash table) that uses the tag attribute feature code as the key and the priority level description as the value. Feature comparison involves using the extracted tag attribute as the input key to perform a lookup operation in the priority mapping table. The lookup algorithm depends on the data type of the key and the implementation of the mapping table; for integer or string keys, it is typically a hash lookup with O(1) time complexity. A successful match means that an entry has been found in the mapping table whose key is completely equal to the input tag attribute or satisfies some equivalence relation (e.g., case-insensitive string comparison). A failed match may point to an undefined tag, in which case the default processing rule may be triggered.

[0074] When a tag attribute matches the first feature code, high-priority text is generated; when it matches the second feature code, medium-priority text is generated; and when it matches the third feature code, low-priority text is generated. This is a deterministic branch assignment logic based on the search results. The first, second, and third feature codes are predefined key-value pairs in the priority mapping table, corresponding to different priority levels. Generating priority text is not a complex construction process; instead, it directly reads a pre-defined text string from the corresponding value found in the mapping table. For example, the value associated with the first feature code is the string "high". In implementation, the value part of the priority mapping table can directly store these target texts. Defining the generated text as a priority identifier is an assignment and encapsulation operation. The program stores the obtained text string (such as "high") in a data area allocated for the current processing branch path. This area is specifically used to store the priority information of the final output. This string is formally marked as the priority identifier corresponding to the path, becoming an independent attribute associated with the path data entry, ready for subsequent table write operations.

[0075] This embodiment achieves automated and rule-based interpretation and transformation of visually marked information in mind maps by accurately locating specific nodes in the path based on offsets, programmatically parsing their metadata and extracting key codes, using a pre-set mapping table for efficient feature matching, and finally deterministically assigning priority text based on the matching results. It transforms tasks relying on manual visual recognition and subjective judgment into a deterministic computational process, ensuring the objectivity, consistency, and traceability of priority determination, and providing a reliable technical means for integrating important classification and management information into structured output.

[0076] In one embodiment, step S50 above includes: S501, Extract the main name string of the mind map file as the mind map file name; S502, Obtain the real-time clock data of the operating system as the current time, and convert the current time into a timestamp string in digital format; S503, use a connector to combine the mind map file name with the timestamp string to generate the output file name; S504, Create and initialize a spreadsheet workbook object as a spreadsheet file; S505, traverse the data entries, write the path field, name field, step field and result field of the data entries into the row cells of the table file, and write the corresponding priority identifier into the specified column cells of the table file; S506, the table file containing the written data is saved with the output file name using the file output stream.

[0077] In this embodiment, extracting the main name string of the mind map file as the mind map filename is an operation that parses and cleanses the complete path of the original file. The path obtained by the program from the file system interface typically includes the directory structure, the file base name, and the extension. Extracting the main name string means locating the part of the path string after the last path separator (such as a forward slash or backslash) and before the last period. This is achieved through string search and segmentation algorithms, such as using regular expression matching or calling path parsing library functions provided by a specific programming language. If the filename itself contains multiple periods, it is generally agreed that the part after the last period is the extension, and the entire substring before it is considered the base name. The result of the extraction operation is a pure name identifier with the path context and format suffixes removed. This identifier retains the semantic core of the original file and serves as a key component in constructing the output filename.

[0078] Retrieving the operating system's real-time clock data as the current time is a synchronization query initiated to the runtime environment. The operating system kernel maintains a high-precision clock source. Programs obtain a raw data value representing the current moment by calling system APIs (such as `gettimeofday` in POSIX systems or `System.currentTimeMillis()` in Java), typically the number of milliseconds or seconds calculated from a certain epoch. Converting the current time into a numeric timestamp string is a data formatting process. The raw time data value needs to be converted into a human- and machine-friendly string representation according to predefined formatting rules. A common format is "YYYYMMDDHHMMSS", where YYYY represents a four-digit year, MM represents a two-digit month, and so on. The conversion process calls a date and time formatting library, taking the raw time value as input, applying the formatting rules, and outputting a fixed-length string consisting only of numeric characters. This string does not contain any delimiters to maximize compactness and avoid introducing characters that might be prohibited by the operating system in filenames.

[0079] Using a concatenation operator to combine the mind map filename and timestamp string to generate the output filename is a deterministic string concatenation operation. The concatenation operator is a predefined character or short string, such as an underscore "_" or a hyphen "-", which establishes a visual and logical separation between the two components. The concatenation operation follows a fixed order, typically placing the main name string first, the concatenation operator in the middle, and the timestamp string last. The program uses string concatenation operators or string builders to join these three elements sequentially into a new string. To ensure the generated string is a valid filename on any file system, additional cleanup of the main name string may be necessary, such as removing or replacing potentially illegal characters (like colons, question marks, and asterisks). The generated filename constitutes a unique identifier for the output file.

[0080] Creating and initializing a spreadsheet workbook object as a spreadsheet file involves instantiating a document model of a specific file format in memory. This is done by calling the constructor or factory method of a third-party library that specializes in handling spreadsheet files, such as `XSSFWorkbook()` from the Apache POI library or `Workbook()` from the openpyxl library. Initialization means that the newly created workbook object is in a clean state, typically containing a default active worksheet. The program may further configure this initial object, such as setting document properties, adjusting default column widths, or defining cell style templates. This object acts as a container in memory; all subsequent data write operations will operate on it, and it will eventually be serialized into a physical file.

[0081] Traversing data entries is an iterative control structure that sequentially accesses the collection storing all transformed records. The data entry collection is typically a list or array, with each entry being a structure or object containing string values ​​for path, name, step, and result fields. Writing these fields from the data entries into the row cells of the table file involves cell addressing and value setting. The program maintains a row counter, typically starting at 1 or 2 (to reserve the first row for the header). For the currently iterated data entry, the program determines the column index where each field value should be written, based on mapping rules (e.g., path field to column A, name field to column B, and so on). Through the interface provided by the workbook object, the program calls the cell value setting method at the cell position determined by the current row number and the specified column index, assigning the corresponding string value. The corresponding priority identifier is also written to the specified column cell of the table file—a parallel assignment operation. Each data entry is associated with a unique priority identifier string. Based on a preset column index (e.g., column E), the program calls the same cell value setting method in different columns within the same row to write the priority identifier string. This cycle of traversal and writing continues until all data entries in the collection have been processed, forming consecutive rows of data in the workbook.

[0082] Saving the spreadsheet file containing the written data as an output filename using a file output stream is the final step in data persistence. A file output stream is an abstraction provided by the programming language for writing sequences of bytes to the file system. The program first needs to construct a complete file system path based on the generated filename and possibly the output directory path. Then, a file output stream object pointing to that path is created. Next, the spreadsheet library's method for writing workbook objects to the output stream is called. This method serializes the workbook object in memory according to its format specification (such as OOXML for .xlsx), encodes it into a byte stream, and continuously writes these bytes to the specified location on disk via the file output stream. After writing is complete, the output stream is closed, ensuring all data buffers are flushed to disk, and a spreadsheet file containing all the transformed data and with a unique name is generated at the target location.

[0083] This embodiment achieves standardized and traceable delivery of the transformation results by automatically constructing unique filenames, creating formatted document containers in memory, systematically writing structured data entries and priority identifiers into cells in batches, and finally serializing them into physical files. It eliminates all steps of manual naming, manual spreadsheet creation, line-by-line copying and pasting, and saving, ensuring the consistency, uniqueness, and complete accuracy of the output files, and achieving a seamless transition from automated processing to the final usable document.

[0084] In one embodiment, prior to step S20, the method further includes: S2001, Receive key node parameter information, the key node parameter information includes field mapping parameter information, specified node position parameter information and specified level node parameter information; S2002, Perform integrity verification on the key node parameter information and generate verification results; S2003, when the verification result indicates that the verification is successful, a mapping relationship parameter set is generated based on the field mapping parameter information, and a hierarchical parameter set is generated based on the specified node position parameter information and the specified level node parameter information; S2004, Based on the mapping relationship parameter set and the hierarchical parameter set, generate mapping relationship initialization information, which is used to establish the mapping relationship.

[0085] In this embodiment, receiving key node parameter information is the initial operation for the system to establish a data input channel with an external configuration source. The key node parameter information, as a composite data structure carrier, encapsulates the core control instructions required during the conversion process. Its internal field mapping parameter information defines the semantic correspondence rules between different role nodes in the tree structure and target table columns, such as mapping the root node to a path column. The specified node position parameter information is a numerical parameter that precisely specifies the hierarchical offset for backtracking upwards from the end node on each branch path, thereby determining the starting node position for the name concatenation operation. The specified level node parameter information is another independent numerical parameter that defines another hierarchical offset for backtracking upwards from the end node on the same branch path, used to locate the target node for which subsequent tag attributes need to be checked. These parameter information can originate from graphical user interface input forms, command-line arguments, external configuration files, or API calls from other systems. The receiving process means that the program obtains this raw data through a predefined interface contract and loads it into a specific buffer or object in the program's memory, preparing raw materials for subsequent logical processing.

[0086] Performing integrity checks on key node parameters is a programmatic verification checkpoint set up before data flows into the core processing logic. Integrity checks are not simply null checks, but a series of assertions based on business rules and data type constraints. The verification logic verifies whether the structure of the field mapping parameter information conforms to expectations, such as ensuring it contains necessary key-value pairs and that the key names are valid. For numerical parameters such as specified node position parameters and specified level node parameters, the verification confirms that their values ​​are non-negative integers and are likely within a reasonable empirical range, such as not exceeding the maximum depth of a typical mind map. Verification may also involve consistency checks between parameters, such as ensuring that two offset parameters do not point to invalid or overlapping locations. After performing this series of verifications, the program synthesizes the results of all checkpoints to generate a standardized verification result object. This object not only contains a Boolean status flag indicating pass or fail, but may also carry detailed failure reason codes or messages, thus providing the system with clear fault diagnosis information.

[0087] The validation result indicating success marks a critical program branch decision point. Based on the status flags in the validation result object, the system decides whether to continue the subsequent parameter conversion process. If the result indicates success, the program enters the active processing branch; if it fails, it switches to the exception handling or user prompt branch. Generating a mapping parameter set based on field mapping parameter information is a data reconstruction and standardization process. The original field mapping parameter information may be in a loose format that is easy for humans to read or edit. Generating the mapping parameter set requires parsing, transforming, and encapsulating it into a data structure that the internal processing engine can directly and efficiently use. This set is typically implemented as a hash table or dictionary, where the keys are internal identifiers representing node roles, and the values ​​are the corresponding target field identifiers. For example, the program might parse the user-configured root node mapping into an entry in the internal mapping table.

[0088] Generating a hierarchical parameter set based on specified node position parameters and specified level node parameters is another parallel parameter transformation operation. These two numerical parameters represent two different addressing requirements starting from the end node. Generating the hierarchical parameter set means organizing them into a unified structured container. This container not only stores the two original offset values ​​but may also calculate some derived values, such as index conversion formulas for fast access. In some implementations, it may be necessary to verify whether these two offsets point to the actual possible node positions in the tree, but this is usually checked dynamically during subsequent traversal. The hierarchical parameter set, as a set of closely related configuration parameters, is bundled together and passed to modules that require position calculation logic later.

[0089] Generating mapping relationship initialization information based on the mapping relationship parameter set and the hierarchical parameter set is an integration and encapsulation of configuration information. At this point, the system already has two independent, verified, and transformed parameter components: one responsible for field semantic mapping, and the other responsible for node location. Generating mapping relationship initialization information involves merging these two components according to a predetermined internal format to create a single, self-contained data object containing complete mapping rule configuration. The structure of this object is designed to minimize the computational overhead of subsequent mapping establishment steps; it may package hash tables with offset values ​​or serialize them into an intermediate representation. The mapping relationship initialization information is used to establish mapping relationships, clarifying the final purpose of this information object. This initialization information object is passed as a key input parameter to the subsequent process responsible for constructing the mapping relationship data structure. This process reads the mapping relationship parameter set within it to populate key-value pairs and refers to the hierarchical parameter set to set complex mapping rules that depend on location calculations, thereby completing the instantiation from configuration information to runtime rules.

[0090] For example, in the fintech field, the testing team needed to perform functional verification on a complex new version of the "Anti-Money Laundering Transaction Monitoring Rule Engine" and designed detailed test cases using a mind mapping tool. The mind map file was named "AML_Transaction Monitoring Rule Test_v1.2.xmind". Its central theme was "Anti-Money Laundering Transaction Monitoring Rule Engine Test," representing the root directory and business path of the entire test suite. Multiple logical branches branched out from it. One typical branch structure was: from the central theme, a sub-theme "Large Transaction Monitoring," followed by "Cross-border Transfers for Corporate Clients," then "Triggering Regulatory Thresholds for Reporting," and finally "System Generating High-Risk Warnings and Suspicious Transaction Reports." Another branch might be "Customer Risk Level Update Monitoring," which includes themes such as "Real-time Screening of Risk Lists," "System Automatically Upgrading Customer Risk Levels," and "Generating Risk Event Alerts." Furthermore, on the "Cross-border Transfers for Corporate Clients" theme, testers added a red priority icon based on business importance.

[0091] Upon launching the conversion tool, the system first performs a parsing operation. It reads the binary data of the "AML_Transaction Monitoring Rules Test_v1.2.xmind" file, identifies it as a compressed file in a specific format, and then decompresses it, extracting structured text data in XML format that describes all the aforementioned topics, subtopics, and their nested relationships. The document parser reads this XML data and converts it into a collection of node objects containing all topic elements and their attributes (such as text content, parent-child relationship IDs, and icon attributes). The program traverses this collection, identifying and marking the topic "Anti-Money Laundering Transaction Monitoring Rules Engine Test," which has no parent ID, as the root node. Subsequently, it recursively searches for all other topics that directly or indirectly reference this root node ID, such as "Large Transaction Monitoring" and "Cross-border Transfers for Corporate Clients," identifying them as multi-level child nodes. Based on these parent-child references, the program associates and combines the root node with all child nodes in memory, forming a complete node tree structure.

[0092] Next, the system establishes a mapping relationship based on preset or received key node parameter information. The parameters define the central topic (root node) as the "test case path," the penultimate topic (leaf node) of each branch as the "expected result," the penultimate topic as the "step description," and the concatenated text of all topics from the penultimate topic up to the central topic as the "test case name." Based on this, the program initializes an internal data structure as the mapping relationship and configures specific rules: the text content of the root node, "Anti-money laundering transaction monitoring rule engine test," is pointed to the path field; all leaf nodes without child nodes in the node tree (e.g., "The system generates a high-risk warning and generates a suspicious transaction report") are defined as terminal nodes, and their text content is pointed to the result field; the direct parent node of each terminal node (e.g., "Triggering the reporting regulatory threshold") is defined as its parent node, and the parent node's text content is pointed to the step field; the node at a preset hierarchical depth relative to the terminal node (e.g., an offset of 2) (i.e., the penultimate topic, such as "Cross-border transfer for corporate clients") is defined as the specified node position, and the text concatenation logic from this node to the root node is configured to point to the name field.

[0093] Then, the program begins traversing all branch paths in the node tree. Taking the first branch as an example, it identifies the complete path from the root node "Anti-money laundering transaction monitoring rule engine test" to the leaf node "System generates high-risk warning and generates suspicious transaction report". It locates the last node of this path, extracts its text "System generates high-risk warning and generates suspicious transaction report", and writes it into the result field of this record according to the mapping relationship. It traces back to the parent node of this last node, extracts the text "Trigger reporting regulatory threshold", and writes it into the step field. Based on the mapping rules, starting from the third-to-last topic "Corporate customer cross-border transfer", it extracts the text of this node and the root node in reverse order, concatenating them into the name "Corporate customer cross-border transfer - Anti-money laundering transaction monitoring rule engine test". Simultaneously, it extracts the root node text "Anti-money laundering transaction monitoring rule engine test" and writes it into the path field. Finally, it encapsulates these four field contents to generate a data entry containing complete test logic.

[0094] For priority handling, the program checks the marker attributes of a specified level node (i.e., the third-to-last topic, which can be customized) in each branch path. In the above branch, the metadata attribute list of the node "Cross-border Transfers for Corporate Clients" is parsed to reveal encoded information containing a red icon. The program compares this marker attribute with a preset priority mapping table; the red icon matches the "high priority" feature code, thus generating the text "high" as the priority identifier for this test case.

[0095] After traversing, extracting, encapsulating, and prioritizing all branch paths, the program generates the final file. It extracts the main name "AML_Transaction Monitoring Rules Test_v1.2" from the original filename, and simultaneously obtains the current system time and converts it into a numeric timestamp string such as "20231025143015". The two are combined using an underscore connector to generate the output filename "AML_Transaction Monitoring Rules Test_v1.2_20231025143015.xlsx". The program creates a new Excel workbook, iterates through all generated data entries, and sequentially writes the path, name, step, and result fields of each entry into columns A, B, C, and D of each row in the workbook, while writing the corresponding priority flag (such as "high") into column E. Finally, the program saves the Excel workbook containing all the data using the generated filename using a file output stream. This process automatically transforms a mind map containing complex business logic and priority markers into a standardized, traceable Excel test case document, ensuring the standardized management of financial business test assets.

[0096] This embodiment establishes a pre-defined, structured parameter receiving and procedural verification process, and generates standardized configuration information objects based on this. This process transforms what might otherwise be a scattered and error-prone manual configuration task into a controlled and verifiable automated data preparation stage. It ensures that the rule parameters driving the core conversion logic are complete and reasonable before execution, providing purified and integrated high-quality input for the stable and correct establishment of subsequent mapping relationships, thereby improving the reliability and configurability of the entire conversion system from the source.

[0097] In one embodiment, a mind map to table data conversion device is provided, which corresponds one-to-one with the mind map to table data conversion method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the mind map to table data conversion device of the present invention. The modules include a node parsing module 10, a field mapping configuration module 20, a path reverse extraction module 30, a marker recognition module 40, and a file generation module 50. Detailed descriptions of each functional module are as follows: The node parsing module 10 is used to parse mind map files and obtain a node tree structure containing a root node and multi-level child nodes. The field mapping configuration module 20 is used to establish the mapping relationship between the node tree structure and the table fields. The mapping relationship defines the path field corresponding to the root node, the result field corresponding to the end node, the step field corresponding to the parent node of the end node, and the name field corresponding to the concatenation of the node text from the specified node position to the root node. The path reverse extraction module 30 is used to traverse the branch paths in the node tree structure, extract text content in reverse from the end node of the branch path according to the mapping relationship, and generate data entries containing path field, name field, step field and result field. The marker recognition module 40 is used to detect the marker attributes of nodes at a specified level in the branch path and convert the marker attributes into priority identifiers. The file generation module 50 is used to generate an output file name based on the mind map file name and the current time, and to write the data entries and the priority identifier into a table file.

[0098] In one embodiment, the node parsing module 10 is specifically used for: Read the binary data stream of the mind map file and identify the file compression format of the mind map file; The binary data stream is decompressed based on the file compression format to extract structured text data describing the hierarchical relationship of nodes; The document parser is invoked to read the structured text data and convert the structured text data into a collection of node objects; Traverse the collection of node objects, identify node objects that do not have parent node references, and mark the node objects as root nodes; Recursively traverse the set of node objects that have a reference relationship with the root node to identify multi-level child nodes; The root node and its multi-level child nodes are associated and combined according to the parent-child reference relationship to obtain a node tree structure.

[0099] In one embodiment, the field mapping configuration module 20 is specifically used for: Initialize the data structure used to store the rules corresponding to the fields as a mapping relationship; Configure association rules in the mapping relationship to point the text content of the root node to the path field; Define the leaf node with no child nodes in the node tree structure as the terminal node, and configure association rules in the mapping relationship to point the text content of the terminal node to the result field; Define the direct parent node of the terminal node as the parent node of the terminal node, and configure association rules in the mapping relationship to point the text content of the parent node of the terminal node to the step field; Define a node at a preset hierarchical depth relative to the end node as a specified node position, and configure association rules in the mapping relationship to point the text concatenation logic from the specified node position to the root node to the name field.

[0100] In one embodiment, the path reverse extraction module 30 is specifically used for: Scan the node tree structure to identify all complete paths extending from the root node to the leaf node, and use the identified complete paths as branch paths. Locate the last node of the branch path as the end node, extract the text content of the end node, and write the text content of the end node into the result field according to the mapping relationship; Backtrack to the parent node of the terminal node, extract the text content of the parent node, and write the text content of the parent node into the step field according to the mapping relationship; Based on the specified node position defined in the mapping relationship, starting from the node corresponding to the specified node position in the branch path, extract the text content of all nodes from the specified node position to the root node in reverse upwards. Concatenate the extracted text content of all nodes and write it into the name field. Then, according to the mapping relationship, write the text content of the root node into the path field. The path field, name field, step field, and result field after the data is written are encapsulated to generate data entries.

[0101] In one embodiment, the marker recognition module 40 is specifically used for: Determine the level depth index relative to the end of the branch path, and take the node located at the level depth index as the specified level node; Parse the metadata attribute list of the specified level node and extract the icon encoding information contained in the metadata attribute list as a tag attribute; The marked attributes are compared with a preset priority mapping table for feature matching; When the tag attribute matches the first feature code, high-priority text is generated; when the tag attribute matches the second feature code, medium-priority text is generated; when the tag attribute matches the third feature code, low-priority text is generated, and the generated text is defined as a priority identifier.

[0102] In one embodiment, the file generation module 50 is specifically used for: Extract the main name string of the mind map file as the mind map file name; Obtain the operating system's real-time clock data as the current time, and convert the current time into a timestamp string in digital format; Use a connector to combine the mind map file name with the timestamp string to generate the output file name; Create and initialize a spreadsheet workbook object as a spreadsheet file; Traverse the data entries, write the path field, name field, step field, and result field of the data entries into the row cells of the table file, and write the corresponding priority identifier into the specified column cells of the table file; The table file containing the written data is saved using the file output stream with the output file name.

[0103] In one embodiment, the field mapping configuration module 20 is specifically used for: Receive key node parameter information, which includes field mapping parameter information, specified node position parameter information, and specified level node parameter information; Perform integrity verification on the key node parameter information and generate verification results; When the verification result indicates that the verification is successful, a mapping relationship parameter set is generated based on the field mapping parameter information, and a hierarchical parameter set is generated based on the specified node position parameter information and the specified level node parameter information; Based on the mapping relationship parameter set and the hierarchical parameter set, mapping relationship initialization information is generated, and the mapping relationship initialization information is used to establish the mapping relationship.

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

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

[0106] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Parse the mind map file to obtain a node tree structure containing a root node and multiple levels of child nodes; Establish a mapping relationship between the node tree structure and the table fields. The mapping relationship defines the path field corresponding to the root node, the result field corresponding to the end node, the step field corresponding to the parent node of the end node, and the name field corresponding to the concatenation of the node text from the specified node position to the root node. Traverse the branch paths in the node tree structure, and extract the text content in reverse from the end node of the branch path according to the mapping relationship, to generate a data entry containing a path field, a name field, a step field, and a result field; Detect the tagging attribute of a node at a specified level in the branch path, and convert the tagging attribute into a priority identifier; The output file name is generated based on the mind map file name and the current time, and the data entries and priority identifiers are written into the table file.

[0107] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Parse the mind map file to obtain a node tree structure containing a root node and multiple levels of child nodes; Establish a mapping relationship between the node tree structure and the table fields. The mapping relationship defines the path field corresponding to the root node, the result field corresponding to the end node, the step field corresponding to the parent node of the end node, and the name field corresponding to the concatenation of the node text from the specified node position to the root node. Traverse the branch paths in the node tree structure, and extract the text content in reverse from the end node of the branch path according to the mapping relationship, to generate a data entry containing a path field, a name field, a step field, and a result field; Detect the tagging attribute of a node at a specified level in the branch path, and convert the tagging attribute into a priority identifier; The output file name is generated based on the mind map file name and the current time, and the data entries and priority identifiers are written into the table file.

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

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

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

[0111] It should be noted that if any AI models, software tools, or components not belonging to our company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use.

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

Claims

1. A method for converting mind maps to tables, characterized in that, Includes the following steps: Parse the mind map file to obtain a node tree structure containing a root node and multiple levels of child nodes; Establish a mapping relationship between the node tree structure and the table fields. The mapping relationship defines the path field corresponding to the root node, the result field corresponding to the end node, the step field corresponding to the parent node of the end node, and the name field corresponding to the concatenation of the node text from the specified node position to the root node. Traverse the branch paths in the node tree structure, and extract the text content in reverse from the end node of the branch path according to the mapping relationship, to generate a data entry containing a path field, a name field, a step field, and a result field; Detect the tagging attribute of a node at a specified level in the branch path, and convert the tagging attribute into a priority identifier; The output file name is generated based on the mind map file name and the current time, and the data entries and priority identifiers are written into the table file.

2. The data conversion method from mind map to table as described in claim 1, characterized in that, Parse the mind map file to obtain a node tree structure containing a root node and multiple levels of child nodes, including: Read the binary data stream of the mind map file and identify the file compression format of the mind map file; The binary data stream is decompressed based on the file compression format to extract structured text data describing the hierarchical relationship of nodes; The document parser is invoked to read the structured text data and convert the structured text data into a collection of node objects; Traverse the collection of node objects, identify node objects that do not have parent node references, and mark the node objects as root nodes; Recursively traverse the set of node objects that have a reference relationship with the root node to identify multi-level child nodes; The root node and its multi-level child nodes are associated and combined according to the parent-child reference relationship to obtain a node tree structure.

3. The data conversion method from mind map to table as described in claim 1, characterized in that, Establish a mapping relationship between the node tree structure and table fields. This mapping relationship defines a path field corresponding to the root node, a result field corresponding to the end node, a step field corresponding to the parent node of the end node, and a name field corresponding to the concatenated node text from the specified node position to the root node. This includes: Initialize the data structure used to store the rules corresponding to the fields as a mapping relationship; Configure association rules in the mapping relationship to point the text content of the root node to the path field; Define the leaf node with no child nodes in the node tree structure as the terminal node, and configure association rules in the mapping relationship to point the text content of the terminal node to the result field; Define the direct parent node of the terminal node as the parent node of the terminal node, and configure association rules in the mapping relationship to point the text content of the parent node of the terminal node to the step field; Define a node at a preset hierarchical depth relative to the end node as a specified node position, and configure association rules in the mapping relationship to point the text concatenation logic from the specified node position to the root node to the name field.

4. The data conversion method from mind map to table as described in claim 1, characterized in that, Traverse the branch paths in the node tree structure, and extract text content backwards from the end node of the branch path according to the mapping relationship, generating data entries containing path field, name field, step field, and result field, including: Scan the node tree structure to identify all complete paths extending from the root node to the leaf node, and use the identified complete paths as branch paths. Locate the last node of the branch path as the end node, extract the text content of the end node, and write the text content of the end node into the result field according to the mapping relationship; Backtrack to the parent node of the terminal node, extract the text content of the parent node, and write the text content of the parent node into the step field according to the mapping relationship; Based on the specified node position defined in the mapping relationship, starting from the node corresponding to the specified node position in the branch path, extract the text content of all nodes from the specified node position to the root node in reverse upwards. Concatenate the extracted text content of all nodes and write it into the name field. Then, according to the mapping relationship, write the text content of the root node into the path field. The path field, name field, step field, and result field after the data is written are encapsulated to generate data entries.

5. The data conversion method from mind map to table as described in claim 1, characterized in that, Detecting the tag attributes of nodes at a specified level in the branch path and converting the tag attributes into priority identifiers includes: Determine the level depth index relative to the end of the branch path, and take the node located at the level depth index as the specified level node; Parse the metadata attribute list of the specified level node and extract the icon encoding information contained in the metadata attribute list as a tag attribute; The marked attributes are compared with a preset priority mapping table for feature matching; When the tag attribute matches the first feature code, high-priority text is generated; when the tag attribute matches the second feature code, medium-priority text is generated; when the tag attribute matches the third feature code, low-priority text is generated, and the generated text is defined as a priority identifier.

6. The data conversion method from mind map to table as described in claim 1, characterized in that, Generate an output filename based on the mind map filename and the current time, and write the data entries and priority identifiers into a table file, including: Extract the main name string of the mind map file as the mind map file name; Obtain the operating system's real-time clock data as the current time, and convert the current time into a timestamp string in digital format; Use a connector to combine the mind map file name with the timestamp string to generate the output file name; Create and initialize a spreadsheet workbook object as a spreadsheet file; Traverse the data entries, write the path field, name field, step field, and result field of the data entries into the row cells of the table file, and write the corresponding priority identifier into the specified column cells of the table file; The table file containing the written data is saved using the file output stream with the output file name.

7. The data conversion method from mind map to table as described in claim 1, characterized in that, Before establishing the mapping relationship between the node tree structure and the table fields, the following steps are also included: Receive key node parameter information, which includes field mapping parameter information, specified node position parameter information, and specified level node parameter information; Perform integrity verification on the key node parameter information and generate verification results; When the verification result indicates that the verification is successful, a mapping relationship parameter set is generated based on the field mapping parameter information, and a hierarchical parameter set is generated based on the specified node position parameter information and the specified level node parameter information; Based on the set of mapping relationship parameters and the set of hierarchical parameters, initialization information for mapping relationship is generated, and the initialization information for mapping relationship is used to establish mapping relationship.

8. A data conversion device for mind maps to tables, characterized in that, The mind map to table data conversion device includes: The node parsing module is used to parse mind map files and obtain a node tree structure containing the root node and multi-level child nodes; The field mapping configuration module is used to establish the mapping relationship between the node tree structure and the table fields. The mapping relationship defines the path field corresponding to the root node, the result field corresponding to the end node, the step field corresponding to the parent node of the end node, and the name field corresponding to the concatenation of the node text from the specified node position to the root node. The path reverse extraction module is used to traverse the branch paths in the node tree structure, extract text content in reverse from the end node of the branch path according to the mapping relationship, and generate data entries containing path field, name field, step field and result field. The marker recognition module is used to detect the marker attributes of nodes at a specified level in the branch path and convert the marker attributes into priority identifiers. The file generation module is used to generate an output file name based on the mind map file name and the current time, and write the data entries and the priority identifier into a table file.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a mind map to table data conversion program stored in the memory and executable on the processor. When the mind map to table data conversion program is executed by the processor, it implements the steps of the mind map to table data conversion method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a mind map to table data conversion program, which, when executed by a processor, implements the steps of the mind map to table data conversion method as described in any one of claims 1-7.

Images